John Keegan

We’re also seeing a performance issue we’ve traced to the 2.0.8 SmartCrop update. It’s actually caused one site to consume 5x more resources… Can we get this looked into SmartCrop team?

Thank you for this truly valuable plugin and thoughtful support, Ollie.

I just got this error @macmanx after updating to 7.5.2 … Log file shows:

2019-07-07 14:16:46.388314 [NOTICE] [172203] [< IP REDACTED>:51947] [STDERR] PHP Fatal error:  Uncaught Error: Class 'Automattic\Jetpack\Connection\Client' not found in /var/www/vhosts/<DOMAIN REDACTED>/httpdocs/wordpress/wp-content/plugins/jetpack/class.jetpack-ixr-client.php:38
Stack trace:
#0 /var/www/vhosts/<DOMAIN REDACTED>/httpdocs/wordpress/wp-content/plugins/jetpack/sync/class.jetpack-sync-actions.php(191): Jetpack_IXR_Client->query('jetpack.syncAct...', Array)
#1 /var/www/vhosts/<DOMAIN REDACTED>/httpdocs/wordpress/wp-includes/class-wp-hook.php(286): Jetpack_Sync_Actions::send_data(Array, 'deflate-json-ar...', 1562523406.3867, 'sync', 0.0010969638824463, 0.0046019554138184)
#2 /var/www/vhosts/<DOMAIN REDACTED>/httpdocs/wordpress/wp-includes/plugin.php(208): WP_Hook->apply_filters(Array, Array)
#3 /var/www/vhosts/<DOMAIN REDACTED>/httpdocs/wordpress/wp-content/plugins/jetpack/sync/class.jetpack-sync-sender.php(244): apply_filters('jetpack_sync_se...', Array, 'deflate-json-ar...', 1562523406.3867, 'sync', 0.0010969638824463, 0.0046019554138184)
#4 /var/www/vhosts/<DOMAIN REDACTED> in /var/www/vhosts/<DOMAIN REDACTED>/httpdocs/wordpress/wp-content/plugins/jetpack/class.jetpack-ixr-client.php on line 38

• This reply was modified 5 years, 8 months ago by John Keegan.

Seems like the issue was related to this:

https://www.ads-software.com/support/topic/facebook-main-account-fail?replies=11

Also seeing that on a site I manage… Any ideas on how to fix?

I think it’s more likely that you have a plugin causing conflicts. If you have access to the Apache error log, check that out.

Or try renaming your plugins directory to ‘plugins.bak’ and then creating a new empty plugins directory. If your blog pages re-appear, then you know the issue was with a plugin. Add them back one by one until you find which one was the culprit.

Try running something like this from your command line:

grep -lr 'id="email" value=".*@.*"' /path/to/your/cache/directory

See what it returns… Are you perhaps seeing that some wp-cache files are cached with the commenters’ information in it?

We saw the same thing, and still see it; we’ve yet to resolve it.

Thinking we may be seeing a plugin conflict issue… Most of the problem accounts had earlier versions of the Share-this plugin; when this plugin was removed or updated, wp-cache began function normally and generated the .meta files properly.

Yes, I tried that actually but it appears that when you do that the 404 page gets cached but the actual response header that gets sent out when the cached page is retrieved is 200…

So it would be an acceptable temporary measure but not something I’d want to do permanently (i.e. send all my 404s with 200 response headers). It would be nice if that functionality was built in so that the 404s were actually returned with 404 response headers.

So is anyone else seeing this or have an explanation? We’re still seeing supercached pages contain that comments which were supposed to have been moderated and are listed with “Your comment is awaiting moderation”..

I appreciate Otto42s help, but the issue can not possibly have to do with the rewrite rules, as those rules only govern who should see the supercached pages and do not relate to what content gets supercached…

Thanks for the info, Otto. But unfortunately it doesn’t appear to be working that way.

Is it possible that WordPress and supercache generate a supercache page in response to the comment submission, then the client is sent to the wp-cache version based on his cookie?

I.e. – the client who submitted the comment is indeed sent to the correct version of the page but in the meantime a supercached version was created based on that submission? That the issue is that the supercached page gets built -in response- to the comment submission even if it is not the page sent to that original client that submitted the comment?

Because the issue is not with the original client, Otto, it is that the comment moderation message is built into some server response that gets supercached and subsequent non-cookied users see that response…

Nope, just using the standard method…

And isn’t that line only there to determine whether or not to show an end user the super-cached version of the page or not? I can’t see how that line would affect what content is saved to the supercache directory.

See what I mean? The anonymous user submits their comment and the page returned by WordPress is cached if no supercache version existed… What wp-super-cache is not taking into account is that the page was not a “generic” version of the page but a page only created for that one user who submitted the comment that was sent into moderation…

We’ve had that line in .htaccess and in httpd.conf and it does not seem to be preventing this from occuring …