p15h

Perhaps something along the lines of:

function replace_text($text) {
	$text = str_replace('decoding="async"', 'fetchpriority="high"', $text);
	return $text;
}

Ah, hidden in plain sight! I’m terribly sorry for missing it…

I can confirm no file gets created in the folder in question after clicking on this button. But the error messages no longer appear, and the purge works fine. I gather this means the plugin is again running smoothly?

Thanks again for working with me on these glitches with such patience!

Many thanks for this! I don’t remember seeing a Purge Cache button inside the plugin’s settings. Could you let me know where it’s supposed to be located?

I did hit the Purge CF Cache link for individual pages on the Pages page and refreshed the folder right away, and I can confirm I didn’t see any cache_queue.json created briefly within that folder.

I’m sending the shot of the folder: https://ln5.sync.com/dl/d04cf5fe0/fzhvgbz5-gsskz84s-vxsp2zv9-q9sqp29g

Hope it helps!

Hello @isaumya

Yes, that’s how /wp-content/wp-cloudflare-super-page-cache/ looks like on our server. The redacted part is a folder with our site name in the format

www.example.com

Please let me know if there is any other information I can provide!

Sorry, I sent the wrong shot! Here’s the correct one: https://ln5.sync.com/dl/b38ba4620/yc6zzmj5-5a659v74-e7ewzfu7-5rmnvfbb

Here’s the screenshot: https://ln5.sync.com/dl/7615c7670/zp8zivve-79tc3zdx-qhvszzwn-ft2wxiv7

The first error was triggered when we hit Purge CF Cache for individual pages. The second one simply occurred after the fresh install.

Hello @isaumya

I have just done a fresh install, and have been able to reproduce both errors.

The referrer for the first one was /wp-admin/edit.php?post_type=page; for the second error it was /wp-admin/options-general.php?page=wp-cloudflare-super-page-cache-index

Looking forward to your response!

Thanks for this, @isaumya. From studying the log after editing a variety of Elementor components in the past few days including templates and custom fonts (we don’t have a proper pop-up in use at the moment sorry, though I don’t remember it behaving differently back when we did have one), what I’ve observed is a purge always gets triggered in response to ‘Fired action: clean_post_cache’ + ‘Fired action: edit_post’ when a component is saved.

For more thorough testing, perhaps we could pin a separate post in this forum and ask other Elementor users to weigh in?

Hello again @isaumya

I can now confirm that commenting out the Elementor Ajax Update line does indeed fix the issue! A purge gets triggered once I hit the save button, and there’s no redundant purges during the editing any more.

Look forward to the fix being included in a future release, and thanks again for your help!

Thank you very much indeed for your reply.

2) Commenting the line out sounds just what I was looking for! I’ll report back how it works.

3) Following your instructions, I checked my ‘don’t cache feed’ option which is selected. And since our home page doesn’t show the latest post, the constant has been duly set to false. What confuses me is the fact that /page/2 /page/3 and /feed still get preloaded anyway whenever the preloader is on, despite these settings. I guess this is a relatively trivial issue, but I wonder if the behaviour means that the preloader is ignoring the ‘don’t cache feed’ setting and the SWCFPC_HOME_PAGE_SHOWS_POSTS constant here?

• This reply was modified 1 year, 9 months ago by p15h.

Many thanks for your very helpful explanation, and for the reference to the faq which I should have studied more closely!

• This reply was modified 1 year, 9 months ago by p15h.

Dear @isaumya

Terribly sorry to hear about the accident, and I hope the surgery is a success! Please do take your time to recover fully and don’t worry about our tickets.

Your work on the plugin has been a boon to nonprofits like us!

Dear Saumya

Many thanks for your prompt reply. We did indeed observe the tug of war and tried editing .htaccess manually, to no avail. Fortunately, the two plugins appear to have figured out a way to coexist after a while, and our security headers finally get validated.

@mazedulislamkhan Many thanks for your detailed response and for being willing to work with the limited information we provided.

You explanations have been really helpful. We, too, can confirm that Google’s rich results test decodes our ü correctly, and will continue monitoring the issue.

Would it be possible by any chance for you to point us to some websites using yoast that have mobile sitenames with umlaut?