p15h

@isaumya current_time( ‘Y-m-d H:i:s’ ) doesn’t remove seconds (which is ‘s’). What I found necessary to remove is the 2nd argument of the function: $gmt. Omitting it just makes it default to false.

Dear @isaumya

As $gmt of current_time only uses the offset when set to the default false, I find it necessary to adjust the code to current_time( 'Y-m-d H:i:s' ) (without the second arg) to get it to show the correct time. Hope this helps!

Just to add that we’ve tested Elementor with line 227 from /wp-content/plugins/wp-cloudflare-super-page-cache/libs/cache_controller.class.php commented out for quite some time with no side effect. Perhaps the fix could be considered for the next release too?

I agree date_default_timezone_set() is probably not a route we want to go down, especially given it’s discouraged by Core for the sake of correct operation.

Could we just replace PHP’s date() with WP’s current_time(), which calls get_option( ‘gmt_offset’ ) from within itself?

then you will have that for all requests, n to just for HTML. I have just tested it on a few sites. Working perfectly.

Yeah, that’s how it’s supposed to work. My guess is it could be due to the ETags we put on the static files? That’d explain why CF only compressed html, which doesn’t take ETags.

@jwchong what Content-Encoding header do you see in your browser’s developer tool? That’ll help with troubleshooting.

Just chiming in to report that when we switched on Brotli in CF, the only things that got the br response header were the htmls. So we ended up taking a two-pronged approach and implemented Brotli for static assets through httpd’s mod_brotli.

Many thanks for walking me through the options you’ve already considered @isaumya!

How about using instead get_option( ‘gmt_offset’ ) or perhaps DateTimeImmutable::getOffset?

Thanks for putting us on the right avenue, @isaumya! For the benefit of those who may have stumbled on the same thing in their error log, here’s the relevant doc:

PHP will create additional elements with values from request headers. These entries will be named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens. For example, the Accept-Language header would be available as $_SERVER['HTTP_ACCEPT_LANGUAGE'].

So ‘HTTP_HOST’ is contents of the Host: header from the current request, if present.

In our specific case, the request came from a user agent belonging to our hosting company. My suspicion is the request was sent directly to our ip address, hence the lack of a Host: header.

Many thanks for clarifying this! So, short of refactoring the bypass logic to take account of these different purposes, I guess for now we would use CF’s transform rules to modify the header for the pages in question.

@isaumya, are you referring to cases where pages selected for bypass (eg is_archive) may also be pages behind login?

You’re absolutely right, @isaumya. I was wondering too why the value isn’t there in the first place. The WP-CLI handbook, however, has this to say:

The $_SERVER superglobal is an array typically populated by a web server with information such as headers, paths, and script locations. PHP CLI doesn’t populate this variable, nor does WP-CLI, because many of the variable details are meaningless at the command line.

Which appears to imply the superglobal isn’t populated by default. Do you know where $_SERVER is supposed to be defined?

Our fix for now is to do the hardcoding in wp-config.php, which seems to be what they advise.

Yes we do! So /path/to/autoptimize_(?:single_)?[a-z0-9]+.(?:css|js)

Thank you very much for reminding us!

That makes sense, Frank. I appreciate the prompt response.

So what we did is we automated requests for htmls to happen whenever AO cache gets cleared, to speed up cache building. We also set the precaching route to /path/to/autoptimize_[a-z0-9]+.css etc to avoid service worker caching the autoptimize_snippet_hash.css/js files residing in the same folders.

That’s great to hear, @krasenslavov! As there doesn’t seem to be plans for WP core to support this anytime soon (no trac ticket yet), perhaps it’d be a good idea to build on what is already implemented in plugins like Simple Featured Image, and add the bulk edit capability on top of it?

Was mistaken about the scripts that caused ReferenceError: Can't find variable: wp. The culprit was hooks.min.js and i18n.min.js being deferred even when excluded from the combined js file (n.b. i18n.min.js is excluded by default).

Our temporary fix is to use another plugin to handle the minify/aggregate/defer of js.

After some more testing, it turns out the error with <script id='wp-i18n-js-after'> was in fact caused by /wp-content/plugins/elementor-pro/assets/js/frontend.min.js being mistakenly deferred.

The real issue seems to be this: even though the plugin is said to ‘Defer loading JavaScript combined files from?<body>?(applies?defer="defer"?attribute to the combined script tags)’, it applies the attribute even to those scripts excluded from the combined files when the box in question is checked.

Looking forward to a fix in the next release.