Conflict with WP Google Maps – cannot use with AO

Hi @ck-macleod

Thank you very much for your findings, I’ve not seen get_shortcode_regex in any of our profiling however we will be investigating that today. I think it’s reasonable to say we can come up with a more efficient mechanism for this.

@optimizingmatters If you could add a filter to exclude CSS, perhaps by regex or path, that would be really helpful. We can definitely integrate with something like that as a workaround.

Regarding the crashes you are seeing – this could be a “catastrophic backtrace”. You can read about that here, it’s only an educated guess but if your server is completely crashing, this is the only other situation in which I’ve seen this happen before.

I hope that’s of some help!

Kind regards
– Perry

In our e-mail discussion from 6 months ago about the crashing user’s site I found we identified this as root cause;

so the content clearly gets lost when restoring the script tags (in autoptimizeBase.php) as called from CSS optimization (autoptimizeStyles.php).

So excluding CSS (for which there is a filter) would not (have) worked in this case?

And catastrophic it certainly was ??

Hi @optimizingmatters

I’m not sure if we can answer that question – that sounds familiar (it has been some time) however it sounds like this is something that would need to be fixed from your end, if it hasn’t been already.

If there’s anything we can change that would help, please do let us know!

however it sounds like this is something that would need to be fixed from your end, if it hasn’t been already.

problem is it all depends on server config (pcre config as part of PHP compilation) and on amount of JS (in this case) thrown at it; as per our research the crash only happened with a (very) large amount of map data defined in inline JS on what seemed to be a sub-par server.

re. possible workarounds:
* making CSS disabling depend on the number of map data added in inline CSS?
* a filter (or option) to allow your users to override the CSS opt. disabling?
* the extra shortcode ck-macleod mentioned?

frank

Hi Frank

Sorry – Is this an inline JS, or inline CSS problem?

If it’s large amounts of inline JS then our upcoming major release addresses this by using the REST API to transfer data as opposed to inline JS.

Kind regards
– Perry

inline JS indeed: when optimizing CSS, inline JS is hidden first, then CSS is extracted and then inline JS is made visible again. it is that unhiding that caused the “catastrophic backtrace” in the issue we debugged together.

so yeah, REST API would be a big step forwards in this case, removing the need to stop CSS optimization disabling. thumbs-up from me! ??

Great stuff!

We’ll look into measuring the size of that data and adding a retrospective warning.

We’ll considering this solved as of version 8’s release.

Thank you very much again for your time on this!

Hey @perryrylance – if I understand correctly, by the time you release a version 8 of WPGM, the line I’ve been commenting out, setting the nooptimize filter – will be gone. Any idea when Ver 8 will be released? Can we reasonably expect that alterations to legacy-core.php made in the meantime will simply be overwritten? I’m assuming that should be the case.

Also, your mention of the REST API brings up a separate issue that seems to be WPGM-related, and may be of interest to @optimizingmatters either way. It seems that, in addition to all of the Google Map scripts and images that get loaded (and damage performance scores), a call to the REST API also is initiated that independently takes up to a second (usually more in the 600 to 700ms range) to load fully. For the staging site linked above, it shows up on a waterfall chart like so, right before the Google Map scripts get loaded:

https://staging-calldixie.duffymarketing.com/wp-content/uploads/2019/06/gmaps_v2_2019-06-10-242.jpg

I know that Google Maps can’t be hosted locally in the same that that Google Analytics can be,but I wonder if it’s true that this V2 invocation is a result of a new-ish WPGM feature, and if there’s anyway it can be disabled when not necessary.

Unfortunately, disabling the REST API for non-logged in users merely removes the response, but the call produces a not found error, and still take about the same amount of time to resolve, at least according to a waterfall chart.

I don’t know how much of a complicating factor this would be, but I wonder if for some sites and maps, simply disabling the nooptimize filter (could be a checkbox in advanced settings) wouldn’t be a better solution, at least from a performance (or performance score) perspective.

• This reply was modified 5 years, 5 months ago by CK MacLeod.

Hi @ck-macleod

if I understand correctly, by the time you release a version 8 of WPGM, the line I’ve been commenting out, setting the nooptimize filter

We weren’t able to find any reference to nooptimize in our code, is this something you’d like us to look into adding? Forgive me, it’s been so long since we last spoke I don’t remember the details on this.

Any idea when Ver 8 will be released?

Version 8 will be released this month.

Regarding performance, I’m afraid we can’t speed up loading the Google Maps API at all. This is completely in their hands, you would need to reach out to them for advice on this.

We’ve already removed the client side REST API that calls v2, this should improve performance further.

We integrate with this plugins which adds REST caching to your site, with great results. You could try that, we find using this plugin, requests complete in roughly 25% of the time they do without caching.

We are looking into issues with security plugins blocking the REST API.

I don’t know how much of a complicating factor this would be, but I wonder if for some sites and maps, simply disabling the nooptimize filter (could be a checkbox in advanced settings) wouldn’t be a better solution, at least from a performance (or performance score) perspective.

Again if you are able to shed more light on this I’m sure we can build that in for you!

Kind regards
– Perry

Hi, Perry – I think you may have me confused with someone else. Indeed, your reply makes me wonder a little if we’re talking about the same plugin, although I think it was just a typo on my part (in the statement you quote, not earlier!) that caused confusion: The filter call appears right near the end, before the return statement, of the wpgmaps_tag_basic function, like so:

// Autoptimize fix, bypass CSS where our map is present as large amounts of inline JS (our localized data) crashes their plugin. Added at their advice.
	add_filter('autoptimize_filter_css_noptimize', '__return_true');

That’s the same statement that I’ve been commenting out. I don’t know how you’re handling it in your update, of course.

Incidentally, the shortcode regex call I mentioned earlier appears in the same file in wpgmaps_check_shortcode.

Yeah, I’ve been using the REST cache plugin, with inconsistent results. Not sure how you’re integrating it with WPGM, of course, but if you’ve eliminated or reduced unnecessary calls to the v2 route that would be a good thing, in my view!

• This reply was modified 5 years, 5 months ago by CK MacLeod.
• This reply was modified 5 years, 5 months ago by CK MacLeod.

Hi @ck-macleod

We’re definitely on the same page in the sense this is our plugin. It looks like we may have removed that line some time ago. We’ll get that re-added with a setting retrospectively for our < v7 users.

We’ve removed the shortcode regex check, we’ve also removed the client side REST API load so that the v2 endpoint is not contacted when our plugin loads.

Please feel free to reach out to us for a pre-release if that’s of interested to you.

Kind regards
– Perry

Er… I don’t want that line – the noptimize add_fillter line – re-added! I’d be happy to have it removed so that I don’t have to comment it out.

It appears in the latest versions of WP Google Maps in the WordPress repo: Version 7.11.29, updated 5 days ago.

I’d be happy to take a look at the pre-release version – where should I ask for it?

I beg your pardon – I made a typo searching for that string. I can see that in place now.

We’ll add a checkbox for this shortly.

Regarding pre-releases, please contact us through our support desk indicating that you’re interested, we’ll send you everything you need in confidence there.

A checkbox sounds like the right solution. To repeat myself from the WPGM support thread – thanks for being so responsive to this issue. Thahks also to @optimizingmatters for facilitating this discussion, whose result ought to benefit users of both plugins.

Great outcome guys, thanks!