Skip Navigation

[Fermé] Conflict between Responsive CouponPress and WP Views on DesktopServer Platform?

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Marqué : 

This topic contains 11 réponses, has 3 voix.

Last updated by Adriano Il y a 7 années et 9 mois.

Assigned support staff: Adriano.


I'm running a local development environment, and have come across a very odd behavior that may indicate some form of a conflict. I have setup a local development site prior to pushing it to an Internet hosting provider, so its nothing I can give direct access to. However, here's my setup; Windows 7 x64 development machine, running DesktopServer Premium v3.6.1, a WordPress 3.8.1 local development site and the PremiumPress Responsive Coupon Theme (used to be CouponPress) version 6.3, and WP Views 1.5.1. When I activated WP Views, brand new, with no views defined, and no debug mode activated, the front-end of the development website now displays an array of SQL calls, timings, and required files between a pair of PRE tags. I have tried activating and deactivating WP Views debug options. NO other plugins are running.

    [0] => Array
            [0] => SELECT option_value FROM wp_options WHERE option_name = 'widget_pages' LIMIT 1
            [1] => 0.00099992752075195
            [2] => require('D:\DII\WWW\Dev\\wp-blog-header.php'), require_once('D:\DII\WWW\Dev\\wp-load.php'), require_once('D:\DII\WWW\Dev\\wp-config.php'), require_once('D:\DII\WWW\Dev\\wp-settings.php'), do_action('init'), call_user_func_array, wp_widgets_init, do_action('widgets_init'), call_user_func_array, WP_Widget_Factory->_register_widgets, WP_Widget->_register, WP_Widget->get_settings, get_option

    [1] => Array

Dear David,

I will pass this information to the development team, but first I need to see the complete error stach, could you provide that?


There is no "error" stack. Just what appears to be an SQL debug trace of all website calls for each page of my website, at the bottom of every page, when Views is an active plugin on the site. I have already given you the steps necessary to recreate the issue in what I previously posted. If you are requiring me to post the entire contents of the SQL debug dump, then understand that it includes private information and WILL NOT be posted to this PUBLIC web forum.


Dear David,

Ok, I will check that with our main Views developer. Thank you for your understanding.


Thank you.


After further debugging on my own, I have discovered the EXACT cause of the issue. The PremiumPress Responsive Coupon Theme (v6.3) has a file named "class_white_label_themes.php" that contains the following code on lines 7135 - 7139 that displays all SQL queries for the existing page if a built-in WordPress definition IS SET... (true or false... does not matter)

if ( defined('SAVEQUERIES') ){
	echo "<pre>";
	echo "</pre>";

SAVEQUERIES can be set anywhere... and normally would be put into wp-config.php, but themes and plugins can also set it. While Coupon Theme does NOT properly place controls around the display of the SQL calls ( illustrates the display of the output as part of a secrured "if ( current_user_can( 'administrator' ) )" statement)... lines 34 - 36 of WP-Views file "wpv-query-debug.class.php" contain the following...

	if ( !defined('SAVEQUERIES') ){
		define('SAVEQUERIES', true);

Therein lies the conflict.

WP Views defines something that, at that moment, IS NOT USED by WP Views, and Coupon Theme blindly follows by displaying code to everyone, including non-administrators, simply based upon a definitions mere existence and irrespective of its value.

I recommend that WP Views not define SAVEQUERIES until such time as a its debug mode is activated. I will also notify the PremiumPress developer and recommend changes to Coupon Theme.


Now that I think about it, I have to wonder. SAVEQUERIES is by DEFAULT defined to TRUE by WP Views (1.5.1)... so that should be causing WordPress to use resources to save a debug array of SQL query information on each page refresh at a minimum. So how much of a backend performance hit is that causing, even without that debug data being called to be displayed by the front-end? I'd think on huge sites that might be measurable.



Timezone: Europe/Madrid (GMT+01:00)

Hi David

This is Juan,l ead Views developer.

Yep, you are right. Thanks for catching this. It has slipped trough our testing and debugging, and you are right: the SAVEQUERIES is always being set to true. I have fixed that and this will be shipped in our next release, but if you are interested I can pass you a patch. Basically, we just needed to move one closing bracket, so it is a quite simple fix.

Let me know if I can help you with anything else. And, again, thanks for catching this.

Juan de Paco


Yes, if I can get the patch, that would be good. I can also test it for you. Should be simple.



Timezone: Europe/Madrid (GMT+01:00)

Hi David

I just sent you a patched version of a file that you need to upload to your server. Please test it and let me know how it goes.

Juan de Paco


Partially tested and so far, looks resolved. Still have a few scenarios I want to run it through.


Dear David,

Could you confirm if is the main issue solved?

Le sujet ‘[Fermé] Conflict between Responsive CouponPress and WP Views on DesktopServer Platform?’ est fermé à de nouvelles réponses.