Sii Cockerill

As far as I can see, the WooCommerce’s Product Summary block is a wrapper for WordPress’s own Post Excerpt block.

<!– wp:post-excerpt /–>

All the Product Summary block does is call Post Excerpt and pass a namespace that references the data (as seen via the Code Editor).

<!– wp:post-excerpt {“__woocommerceNamespace”:”woocommerce/product-query/product-summary”} /–>

It would be nice if the Post Excerpt block had the option to render the content with <p> tags along with the option to limit the number of words displayed.

The problem was not related to the coding of the plugin, but to the assumption that the default tabs would appear in addition to custom tabs on all product pages.

The Reviews tab —?one of the current defaults?— had to be manually added to those Products that had a custom tab.

I believe that for the products where the Reviews tab is missing and has to be manually added, the Reviews tab was not one of the defaults at the time the product was created.

It would be great if the changes to the default tabs could be updated on all previously created products, but I doubt that is possible without considerably more development of the plugin.

Thanks Maykato,

We found the problem.

My host has a service that will kill queries if they are too long (not too slow, just too long).

The site in question has so many orders that on the new host, the query was long and therefore never executed —?it just returned 0 results.

They had asked me to find out if specific updates to WooCommerce had been the cause, but it turned out, it was their own safeguards after all.

Thanks for your willingness to help.

I tried your suggestion, but no results appeared.

It’s really strange —?a search for “NJ 08” returns results, but not “NJ 0”.

+1

+1

Hi Garrett,

I’ve been experiencing exactly the same problem. It doesn’t look like you got any reply from the plugin developer. Surely your solution isn’t a viable one on a large scale?

I’m experiencing a similar issue.

I can’t enable any of my Custom Post Types in the new AMP section of the SEO plugin (added via the Glue plugin) – after saving, the ‘enabled’ toggles back to ‘disabled’.

Whilst the Glue plugin is activated, the /amp endpoint redirects to the normal custom blog post, almost as if the Glue plugin bypasses my endpoint enabler.

/**
* Custom Post Type Support
* https://github.com/Automattic/amp-wp/blob/master/readme.md
*/
function dt_amp_add_cpt() {
add_post_type_support( ‘blog’, AMP_QUERY_VAR );
}
add_action( ‘amp_init’, ‘dt_amp_add_cpt’ );

Cheers Paul!

Thanks for taking the time to look into it.

I’ve tailed the live error log and access log simultaneously and reviewed the URLs that seem to cause the errors.

Visiting those URLs doesn’t replicate the issue, so I’m pretty much at a loss.

Hi Paul,

Unfortunately not – the errors continued even with User Role Editor disabled.
I’ve tested the site locally and see no errors in the log when I browse the normal site pages.

In the live server logs, there are fatal errors throw several times per minute, but none of them say which script caused the error to be thrown. They occasionally list a referrer, but if I try those URLs myself, no PHP error is thrown.

It’s quite odd. I’m wondering if it’s bot activity… but even then, that doesn’t help use figure out what’s causing it.

I need to be able to see the errors being generated on my local or staging server, in order to then disable the plugins one by one to find the problem.

Do you have any ideas how to explore the error logs further to work out what produces the error?

Thanks Paul,

First thing I’ll do is try and prove that User Role Editor is the culprit.

Thanks Paul,

There’s a plugin called User Role Editor that allows management of user capabilities.
From the look of the error, that could be culpable… difficult to switch that off on the live site though.

The logs show the same error on these pages:

index.php
/blog/wp-comments-post.php
/blog/wp-login.php
/blog/xml-rpc.php
/blog/wp-admin/profile.php
/blog/wp-admin/admin-ajax.php
/blog/wp-admin/index.php
/blog/index.php

Index is getting the most hits, but it seems that it is every page load.

Hi Paul,

Here’s the full stack trace.

Error message
E_ERROR: Call to undefined function wp_get_current_user()
Sample stack trace
in current_user_can called at /var/www/website/blog/wp-includes/capabilities.php (1387)
…w/website/blog/wp-content/plugins/wp-simple-firewall/icwp-plugin-controller.php (843)
…website/blog/wp-content/plugins/wp-simple-firewall/src/features/login_protect.php (54)
…ar/www/website/blog/wp-content/plugins/wp-simple-firewall/src/features/base.php (534)
…ar/www/website/blog/wp-content/plugins/wp-simple-firewall/src/features/base.php (232)
in ICWP_WPSF_FeatureHandler_Base_V3::action_doFeatureShutdown called at ? (?)
in call_user_func_array called at /var/www/website/blog/wp-includes/plugin.php (496)
…w/website/blog/wp-content/plugins/wp-simple-firewall/icwp-plugin-controller.php (623)
in ICWP_WPSF_Plugin_Controller::onWpShutdown called at ? (?)
in call_user_func_array called at /var/www/website/blog/wp-includes/plugin.php (496)
in do_action called at /var/www/website/blog/wp-includes/load.php (613)
in shutdown_action_hook called at ? (?)