why would be a good question…   your query example format ‘wp_xxx_sferrorlog’ seems to show wp multisite… is that what you are running?  and if so, how many network sites do you have? and roughly how many db tables?

If you want to disable error logging:

in file sp-site-support-functions.php, around line 160 find and comment out this code:

        $wpdb->hide_errors();
        set_error_handler(‘sp_construct_php_error’);

comment out both lines…

we have one other multisite install that is experiencing something similar…

Hi Mr Papa,

No, it’s not WP Multisite – it’s a plain WP with woocommerce installed.

On the site’s homepage (not even the forum section) we have 69 calls to sferrorlog. I am copying here the first 3 and the last 3 as an example:

1. • Time: 0.0052900314331055
   • Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
   • Call from: require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), include_once(‘/plugins/tab-section/tab-section-loader.php’), define, sp_construct_php_error
2. • Time: 0.00089597702026367
   • Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
   • Call from: require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), include_once(‘/plugins/tab-section/tab-section-loader.php’), define, sp_construct_php_error
3. • Time: 0.00078296661376953
   • Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
   • Call from: require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), include_once(‘/plugins/theme-my-login/theme-my-login.php’), require_once(‘/plugins/theme-my-login/includes/class-theme-my-login.php’), sp_construct_php_error
4. • Time: 0.00090503692626953
   • Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
   • Call from: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/bazar/problem-with-post-edit-buttonome.php’), get_template_part, locate_template, load_template, require(‘/themes/bazar/blog.php’), get_footer, locate_template, load_template, require_once(‘/themes/bazar/footer.php’), wp_footer, do_action(‘wp_footer’), call_user_func_array, Debug_Queries->the_queries, Debug_Queries->get_queries, mysql_fetch_object, sp_construct_php_error
   • 1. • Time: 0.00071001052856445
        • Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
        • Call from: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/bazar/problem-with-post-edit-buttonome.php’), get_template_part, locate_template, load_template, require(‘/themes/bazar/blog.php’), sp_construct_php_error
     2. • Time: 0.00071001052856445
        • Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
        • Call from: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/bazar/problem-with-post-edit-buttonome.php’), get_template_part, locate_template, load_template, require(‘/themes/bazar/blog.php’), sp_construct_php_error

On the /forum/ section of my site I get a very similar number of calls to sferrorlog. Here is a copy of the 1st one. Always SHOW TABLES LIKE

• Time: 0.00085997581481934
• Query: SHOW TABLES LIKE ‘wp_xxx_sferrorlog’
• Call from: require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), include_once(‘/plugins/tab-section/tab-section-loader.php’), define, sp_construct_php_error

As Steve said above – we have two such reports so you are not alone!

I would strongly suggest you implement the temporary code change we gave you in post 2 above. Rest assured that this change should not have any detrimental side-effect.

We are currently looking into this although it is always difficult when we are unable to replicate things.

I do have one question however as I am most curious. The first set of log entries you set were all being generated from the WooCommerce plugin. This should not really be subject to the forum error trapping code unless the Woo components appear ion the same page as the forum – like in a sidebar for example. Can you tell me if this is the case please?

The site is fotoloco.fr

The forum and woocommerce are completely seperate. Neither should be called from the homepage.

so that would make it weird that woo commerce stuff was erroring on the forum page, no?

did you turn off the error logging to see if it helped??

This is weird indeed.

It’s clearly the same issue we were experiencing after the last update. I presumed it was related to the number of tables in our multisite db. For the record, we do not run woocommerce.

Blaise, FYI: Issue was resolved by disabling error logging as suggested in post 2 above.

yeah, two sites who had better operation when disabling error logging… dont get it, but hey, if it works…  one had many tables, one did not…

next version will include an option to disable error logging as we try to dig into this further… but kind of a needle in a haystack…

Mr Papa said
next version will include an option to disable error logging…

That’s great, any chance the default state could be off? Or perhaps we could get a hack for making it so. Activating the plugin (at least in our case) allows very little time to do anything before loads spiral out of control.

Thanks!

PS: I don’t get it either, figured this certainly had to do with the size of our multisite db.

I was kind of hoping it was table number related too.. but Andy looked at the show tables like query too and it shouldnt matter…  another reason why I asked for the explain on yours to make sure what it was actually trying to do…

no, the default state will be on… and we certainly wouldnt change auto turn off logging for current users on upgrade – that would be unexpected especially since almost all users are not having an issue…  but once you set it off, it will stay off unless you turn it back on..

Mr Papa said
the default state will be on… and we certainly wouldnt change auto turn off logging for current users…

That’s understandable. What admin tab will have the option?

Or, perhaps you could provide a hack to set the default state for those of us who may have very little time to access the option after plugin activation.

The SHOW TABLE query has also been retired in favour of a different non-db solution. Although I personally do not think that the SHOW TABLE query as such was responsible for your problems.

For the record, I was able to update to SP 5.4 without hacking any core files or disabling error logging and have encountered no issues as previously described in this topic. Thanks again for all the hard work mates.

Happy New Year!

…and we hope that 2014 is a successful and good year for you guys as well.

Actually – for all our users!