Abigailm

OK, I did that and the problem recurred. There is a delay of several hours between the time that I re-enable GADWP and the error starts – this is consistent with what I experienced before as well. The problem is only on one site so I am thinking probably a theme conflict; the theme has its own internal caching system so perhaps that could be tied to it. (Maybe a nonce issue?)

Anyway, I just want to report it — I’ll experiment with rolling back to a previous version of GADWP to see if it helps, as I didn’t have the error before. I like GADWP as i is very convenient to be able to see the analytics data in the site dashboard, but it is not a critical function for the website — so if it can’t be resolved I’ll just remove the plugin.

Thank you!

Thank you!

Is there a function hook that could be coded to clear the wpfc-minified folder? Perhaps something that could be written into a cron job?

Or is the feature I suggested included in the premium version?

My problem is that I manage multiple web sites, with many different plugins, and I usually update plugins from a remote API rather than going to the site — so manually clearing all caches every time isn’t really feasible.

Ok – I’ve realized now that the plugin was upgraded directly from 3.21 to 3.31 – so even though there is a 3.3.0 in the repository, it was never on any my sites. (From the changelog, it looks like you 3.3.1 was released the same day as 3.3.0)

I still would like a way to check the response header size — there simply is no way for me to debug if I can’t see WHAT accounts for the large size. My guess is that because the Cloudflare system automatically pushes all linked stylesheets and scripts, that 3 kb limit is going to get quickly hit on many wordpress sites, especially premium themes or themes with a lot of plugins. I think the solution would be a more interactive setting, that would allow more user control of settings via the plugin dashboard.

I’d note that I tested this plugin on one of my sites: https://wordpress.org/plugins/http2-server-push/ — and this does seem to enable httpd2 server push and works fine withe cloudflare. (I can see from chrome://net-internals that resources are being pushed on that site)

However, testing with Google Page Speed Insights shows that page speed with the server push enabled is actually slightly worse than without it, so it may that the server push is not helpful on some sites in any case.

I assume that changing the wp-config directive as follows is sufficient to disable the http2 push (?):

define(‘CLOUDFLARE_HTTP2_SERVER_PUSH_ACTIVE’, false);

Thanks for this explanation, but I didn’t actually start seeing this error in the logs until the upgrade to version 3.3.1 of the plugin — so not sure why.

I guess I will disable server push for now because it looks like various plugins or themes I use are adding inline styles to the header area.

However, I think you should document this logging function better and provide an option to turn it on or off — or simply to enable it only for a short time for debugging purposes. I would not have noticed the errors if I had not already been monitoring error logs for another problem (unrelated to this plugin, probably connected to the most recent WP upgrade). The problem is that this generates thousands of lines of errors resulting in error logs that grow very rapidly, and log files that large can cause an array of other problems on a server or hosting account. And since it is a single line error, there is no value to having a log with thousands of entries– a simple option to enable the log briefly to “debug” server push would be more useful.

(Or how about a feature that in the plugin that would test header size before enabling server push? And automatically disable it if it isn’t going to work).

Question: Other than server push, is there anything that the Cloudflare plugin currently does that I can’t do using the Cloudflare site dashboard? I’m thinking that if I don’t use server push on some sites, I probably don’t need the plugin.

I did download the zip file listed above and uploaded the wpFastestCache.php file — and the problem persisted.

Same as before, multiple errors like this:

27-Jun-2017 21:22:47 UTC] PHP Recoverable fatal error: Object of class WP_Error could not be converted to string in //wp-includes/kses.php on line 1249

It also can still be fixed by enabling preload for attachments. The problem is that I would prefer not to cache attachments on this particular site because of the nature and size of the site