JBGR

Boy howdy am I glad that I didn’t submit a bug report for this. I’ve managed to identify a conflict with one of my browser extensions that is causing this importmap issue. If I go through my same testing procedure (using the WordPress Developer Blog as the example site) then I do not trigger the error. If I re-enable the extension and perform my testing procedure (open a new tab, open the JS console, load the developer blog) then I am able to produce the error 100% of the time. Refreshing the same tab eliminates the error but a fresh tab always produces it with my extension enabled.

Absolutely. I’ve just posted a 5-star review. Thanks so much for your assistance on this matter :).

Thanks so much for the help on this issue we can mark this as resolved!

Thanks for the response!

The issue happens after 24 hours even when visiting the secret URL. I tried yesterday on one of the sites affected (which has been an issue for a few versions of the plugin) in an incognito window. The cookie gets added but I am still redirected.

The salt postfix is not enabled using this plugin and one of the affected sites is using version 5.2.7, the other on 5.2.9 but I think you might have finally helped me figure out what the conflict is!! :).

The websites are also using the Sucuri security plugin and the affected ones have the Automatic Secret Keys update feature enabled which would change the AUTH_KEY and AUTH_SALT. Sites that haven’t had the issue don’t have this feature enabled on the Sucuri plugin and some don’t have the Sucuri plugin installed at all.

I’ll test this on one of the affected sites but I think you have helped me FINALLY nail down what the inconsistency is and what was causing this feature to stop working on a few of the sites where we’ve implemented the cookie-based protection.

THANK YOU!!!!! @hjogiupdraftplus

On cache-less sites and sites that use object cache and page cache. I made sure for testing purposes for this post that I was testing on a clean install with a default theme, no plugins and no extra server-side caching such as memcached. I’ll submit a bug report!

Sorry I wasn’t clear enough I was just clearing my browser cache in testing the issues.

The clean installation that I have been performing tests on does not have any Memcached Object Caching or Page Caching setup (typically I use WP-Super-Cache) but I wanted these tests to be done on as clean an installation as possible. On production websites where we see the issue some are using Memcached Object Caching, WP-Super-Cache or both.

My original tests were done using PHP 8.1.27 but I am also able to reproduce the issue on PHP 7.4.33.

It only seems to affect the first time the page is loaded and subsequent reloads are not affected, clearing cache between reloads or otherwise.

@macmanx I’ve performed the tests using a fresh install of WordPress on the Twenty-Twenty-Four theme not Twenty-Twenty-Three as I am a block theme developer and use FSE throughout my sites. This has been tested with just that theme and 0 plugins. I am also still experiencing it on the WordPress Developer Blog site.

I ran into an identical scenario today on WordPress 6.5.2 with TEC 6.3.6 and wished I had found this post sooner I thought there was an issue with the REST API. Would be great to be able to include past events in a query loop or have additional controls to explicitly show or hide them. Thankfully WordPress makes this possible by allowing you to Extend the Query Loop.

Thank you for posting this solution! Deleting the _transient_wp_core_block_css_files record fixed the problem for me on 6.3.1.

@illuminice I appreciate your response! We are using the premium versions and there have been 3 instances in the last year where Yoast has caused crippling issues to our website.

Sure enough, deactivating Yoast not only seems to have suppressed the 404 errors but we have noticeable performance gains.

I am just hoping that opening this up will get the Yoast team looking at it. I am now exploring alternatives such as RankMath or developing an in-house solution so we can have complete control and confidence in our stack.

This issue has seemed to crop up on one of our websites after updating to Version 20.

Inexplicably, randomly and without consistency we would receive 404s or redirects when trying to access standard content such as a:

• Post
• Category
• Product
• Tag
• Page
• Custom Taxonomy

Revisiting the same URL would sometimes cause the issue to not re-appear and then would suddenly crop up a few minutes later and then a few minutes after that everything would be fine.

Flushing the permalinks multiple times did not yield success.

There have been no other changes to the stack other than updating Yoast. We have also been unsuccessful in running the SEO data optimization if that is a relevant piece.

If it continues again I am happy to hook into whatever action/filter is necessary to trace this.

This issue is clearly not resolved yet.

I agree with @fssbob it is nonsensical for blame to be placed on The Events Calendar.

There is a reason PHP has conditions to check if functions/classes/methods exist before calling them, they can be very useful when integrating with another plugin where you do not control what they deprecate.

After some testing and investigating the Yoast code, the errors on our sites (memory exhaustion of 512MB leading to 504 Gateway-Timeout) were being triggered when Yoast is trying to generate the Structured Data for Events.

These sites were built using the DIVI builder with premium versions of TEC and Yoast both installed at latest version. WP is running 6.1.

Yoast is checking tribe_is_month() before trying to pull the Events and generate the schema. Within this condition they are calling the deprecated The Events Calendar static method. In our cases the tribe_is_month() condition was always returning true on all pages and Yoast was trying to retrieve ALL events from the database before adding them to the schema markup.

Rather than editing the Yoast SEO plugin, I was able to locate their own filter they are hooking into if The Events Calendar is active and remove_all_filters from this hook. It only seems that this hook is used by Yoast for The Events Calendar integration during the structured data generation. Our solution was adding this to the theme functions.php file:

add_action( 'wp', 'thebaum_filter_for_one_action' );
function thebaum_filter_for_one_action() {
  remove_all_filters('wpseo_schema_graph_pieces', false);
}

This not only prevented the timeouts but had a considerable improvement on overall page load times. The required structured data was still in place so Google Search Console should not throw any errors. This function just removes the Event portion form the Yoast schema output. The Events Calendar schema is still output correctly.

The other general problem with this issue is the fact that this part of the integration does not need to exist and adds a conflict to the HTML output. The Events Calendar makes it very clear that they handle structured data output for Events TEC Structured Data .

If Yoast is able to add condition checking and remove this part of their integration it should help minimize future issues.