Thank you Rikard, please close the topic.

Thanks Rikard.
Credentials in the private area.

Hi Rikard,

that did it – thank you!

Best regards
Steph

Hi Rikard

I have another update on that topic.
I tried to narrow down the error by deleting element after element in this site – now most of the page is empty, but the error is still there – please have a look at the link below.
I ve ended up getting another (3rd) console error while above mentioned site was still in draft. I will add a screenshot link below.
I have no idea how to investigate this any further unfortunately.

BR, Jay

Hi Rikard,

I’ve disabled (and then again enabled) all plugins but the error in the console of the page in question is still there either way.

I can’t reproduce the issue with the post/page preview currently either – a theme update might have taken care of it already. The page is still, inexplicably, broken though and we’re not sure what happened or how to fix it without having to rebuild the whole thing.

I’ve included an image link of the console error.

Best regards

Hi Rikard,

we’ve updated to 4.8.6 but, unfortunately, both issues are still occuring.

Best regards

Hi Ismael,

disabling the User Switching plugin didn’t do anything for us. Disabling User Role Editor Pro plugin solved the issue but we have this combination of theme and plugin across multiple pages and don’t have this error usually.

However, it reminded me of a similar issue we had a while ago: https://kriesi.at/support/topic/maintenance-page-in-footer/#post-1203426

I’ve tried changing the class-avia-custom-pages.php file as described in the post I’ve linked to, which resolved the issue.

Best regards
Steph

Hi Ismael,

we’ve moved the cookie banner to a test page, you can find the new login data in the private content field.

Changing the class of the parent div container seemed to work. We added a little styling for the toggle to make it checked as well.
This works for accepting all cookies as well as opening the modal and saving settings there.

However, if you change the cookie settings after initally accepting (main navigation link “cookies” reopens the settings modal), the custom cookie PHPSESSIDDisabled will be true, blocking our cookie. Saving it again will unblock it again, the value switching between true and false. The goal is for it to stay “false” though so PHPSESSID is always allowed (being defined as an essential cookie)

The classes of the parent div seem to match now, so the problem may lie elsewhere.

Hi Mike,

yes the thread can be closed, thank you.

BR

Hi Mike,

we’ve found what’s causing the error and it was indeed a polyfill issue.

In IE11 some ‘modern’ JS functions don’t work, which is why a lot of libraries stock up on them. WordPress is doing this with wp-polyfill, Google Maps does the same thing – these two code parts collided.

Our solution was to only load 90% of the polyfills since the missing 10% will be delivered by Google Maps. wp-polyfill will assume that the browser already knows the functions and therefore this part will not be loaded double.

To achieve that, we’ve added the following code in the last line of our functions.php

// load custom polyfill for IE11 <-> Google Maps collision 
function maps_my_custom_js() {
       echo '<script src="https://polyfill.io/v3/polyfill.js?features=Symbol%2CObject.getOwnPropertySymbols%2CSymbol.asyncIterator%2CSymbol.for%2CSymbol.hasInstance%2CSymbol.isConcatSpreadable%2CSymbol.iterator%2CSymbol.keyFor%2CSymbol.match%2CSymbol.replace%2CSymbol.prototype.description%2CSymbol.search%2CSymbol.species%2CSymbol.split%2CSymbol.toPrimitive%2CSymbol.toStringTag%2CSymbol.unscopables"></script>';
}
add_action( 'wp_head', 'maps_my_custom_js' );

That solved the issue for us and the map is being displayed again.

Best regards
Steph

Hi Mike,

each of the plugins we have on this site, is integrated with the same version on another page of ours where Store Locator Plus works on IE11 as well.

I’ve attached a screenshot of the errors our IE11 console is giving us.
We’ve had enfold running on Gutenberg at first but switched to WP classic editor as we saw the polyfill error. Could it still have something to do with that?

Best regards
Steph

Hi Victoria,

thanks for the tip!

As far as I’ve seen now, the error originally occurred because a 1/4-row above wasn’t filled with four columns.
That somehow had effects on the following rows and arranged them weirdly that way.

BR
Steph

Hi Ismael,

the FB Pixel as well as Google Analytics is integrated into the website via the Google Tag Manager.
We can’t seem to block these cookie, therefore they’re being set upon page load. They’re already set as Custom Cookies but that doesn’t have any effect on the behaviou.

Best regards
Steph

Hi,

added them again.

Kind regards,
Steph

Did you have a chance to take a look at this already?