p15h

@wfpeter, good to hear you have plans to migrate to the semantically more appropriate 429 for rate limiting. That’d be a most welcome improvement!

This answer is on the right track, thank you!

Since Pro is outside the scope of this forum, let me return to my initial question. You wrote:

To address this, you can create custom templates and assign them to those specific URLs.

The only way this solution (creating custom templates) is going to work is by first knowing which ‘specific’ URLs require custom templates.

Has Elementor figured out yet exactly which URLs require such a custom treatment?

Dear @marthaeli

Thank you for this. The specific slugs I mentioned – /uncategorized/ (on sites that don’t use categories) and /embed/ (for any page’s oEmbed iframe) – aren’t covered in any of the articles you sent me to. Which shows it’s a question Elementor hasn’t dealt with before.

The issue is this: these two URLs (and potentially other ones) are part of any default WP installation, so they should be included in your Theme Builder in order for a site to have a uniform look. Currently, however, only search and archive pages are covered by Theme Builder, leaving /uncategorized/ and /embed/ unstyled without additional hand-coding.

Ah, it’s called ‘queue’ here and I was looking for ‘cron’. That’s why I couldn’t find it!

While I’m at it, may I offer a comment on the legend:

By default this plugin purge the cache after 10 seconds from the purging action, to avoid a high number of purge requests in case of multiple events triggered by third party plugins. This is done using a classic WordPress scheduled event. If you notice any errors regarding the scheduled intervals, you can deactivate this mode by enabling this option.

The notion of a 10-second delay only covers the case of wp-cron.php. On sites where this is disabled for performance reasons (a common scenario) and crontab and WP-CLI are used instead, the purge is delayed to whatever time is scheduled in the crontab. So there’s probably room for the wording here to be improved.

Tested. Looks good to me!

Yes, that’s correct – pls see my second post above ??

We’ve identified Rank Math as the culprit that prevents purge_object_cache() (which calls wp_cache_flush())?from taking effect, though the precise reason is unclear to them. So switching to the more robust sitemap of WP Core immediately solves the problem.

Wow that’s great news, Krasen! Will definitely keep an eye on the changelog.

We’ve identified Rank Math the culprit that prevents wp_cache_flush() from taking effect, though the precise reason is unclear to them.

l3rady helpfully pointed out to us that WP CLI doesn’t share php-fpm’s object cache and so can’t manipulate functions defined in object-cache.php.

We solved the original issue by turning off Rank Math’s fragile implementation of sitemap and switching to the robust and more than adequate native sitemap of post-5.5 Core WP.

The remaining issue is the incompatibility of this plugin’s purge_object_cache() with APCu-based object cache, for which I’ll open a separate thread.

That certainly works. But I’m still curious about the cause behind it. Does object cache gets successfully flushed by this plugin on yours sites because you are using a different object cache than APCu?

So the problem is caused by wp_cache_flush().

And since on sites where persistent object cache is enabled, a call to wp_cache_flush() will be routed to wp-content/object-cache.php, I suspect the issue may have to do with the particular way wp_cache_flush() interacts with the wp-content/object-cache.php for APCu. On our machine, wp_cache_flush() obviously doesn’t actually flush APCu object cache; conversely, manually flushing APCu object cache never leads to disappearance of the sitemap.

Saumya, could you share which plugins (APCu, Redis or Memcached) provide the wp-content/object-cache.php on your sites and whether triggering cache_controller::purge_object_cache from your end always results in the entire persistent object cache being deleted?

I’ve managed to narrow down the culprit to the following code in libs/cache_controller.class.php:

function purge_object_cache() {

        if( !function_exists('wp_cache_flush') )
            return false;

        wp_cache_flush();

        $this->objects = $this->main_instance->get_objects();

        $this->objects['logs']->add_log('cache_controller::purge_object_cache', 'Purge object cache' );

        return true;

    }

It causes the Rankmath sitemap to disappear when run as part of ajax_purge_single_post_cache, but not when run by cronjob as part of purge_cache_on_post_edit.

So I was able to fix the problem by turning off the option ‘Automatically purge the object cache when Cloudflare cache is purged’.

I’ve been able to make some progress this week.

Both Rankmath and this plugin on our machine are now the latest versions. And I’ve also verified that the 404 only happens when a Purge cache link is manually hit; auto purge triggered by an edit doesn’t cause the sitemap to disappear.

Interestingly, the 404 isn’t just about the loss of three wp rewrite rules, as I’d previously assumed. After a manual purge, even if I visit the URI index.php?sitemap=1 directly (ie not relying on pretty link & wp rewrite), the sitemap doesn’t show up.

So, for the next step, I’ll probably have a look at the code for triggering a manual purge.

If there’s nothing in the code that suggests a cause, let me try and collect more information and report back.