Chris

Well I guess we’ll just have to blame it on a plugin conflict, because no, I can not do any of that. This is a live site and we are not turning everything off just to test your plugin, and I don’t have a testing area set up anymore.

I’m sure it works perfectly fine when there is nothing else on the site. Whatever it’s incompatible with, I don’t have the time to test for.

Both are the latest versions:
reCaptcha by BestWebSoft 1.68
WordPress 6.0.2

Okay, hopefully that is soon I will keep checking back on this.

Also, just because you have replied here does not mean this is resolved. Why do you keep marking this as resolved EVERY time you reply? This will not be resolved until the problem is fixed.

You were correct – the other plugin is using sweetalert2-v6.6.4, from five years ago!

I’m still not sure of a solution, but I’ll mark this as resolved here since it is not an issue with your plugin. I’ll update this thread if the other plugin changes or if I find a workaround.

Thanks!

So that confirms it. That is a very old version of sweetalert2. Why are you using a five year old version? Sweetalert2 seems to be regularly updated.

Are there plans to ever update your plugin to use the latest version of sweetalert2?

What version of sweetwater2.min.js are you using? The other plugin author said this might be where the compatibility issue is – they are using the latest version.

Could you give me the name that your version of sweetwater2 is enqueued as?

Author’s response because they refuse to post here:

Hello Christopher,
Thanks for reaching out to us!

Your raised issues/queries:

Conflict with Super Page Cache for Cloudflare upload.js

Guidance to chase the issue or next steps:

Please note that we don’t have any native compatibility or integration with the Super Page Cache for the Cloudflare plugin so any expected outcome is unknown. However, as we are using the sweetalert2 JS library inside our plugin, you can try excluding that asset that is flagging.

Thanks & Regards!

—
MM Aurangajeb
Support Coordinator (Remote)
[email protected]`

Hi @isaumya,

Thanks for the quick and detailed response!

I will mention the sweetalert2 issue to the other plugin developer.

However, everything you said about nonces and caching seems to be irrelevant – I already said this page is not being cached.

Hi @saifislam01,

I filled out the contact form on the website. However, responses need to be posted here so others might find them useful.

Thanks!

Hi Stefano, I’m running in to the same issue. They are overriding other implementations with their own, and as you noticed, they don’t include everything in the SDK.

How is this marked as resolved? Were you able to come up with a solution?

I’ve been a proud BackWPup user for years, but now that I’m working on another plugin using the AWS SDK, I may have to find an alternative if there is no way around this.

Hi Marko, thanks for the info.

So if I remove that line, is W3TC not going to automatically add it back? If so, that’s an option, but it sounds like either way there will be an unnecessary notification somewhere.

I disagree with the idea that it would not make any sense to add it and remove it every time the option is enabled/disabled. I do not believe this is an option that would be changed that often. That’s just my opinion though.

The other plugin is a statistics plugin that can use a different method of tracking if caching is enabled, but the default method is preferred if pages are not being cached.

Thanks for the info though!

The changelog from today? No, but it looks like today’s update addresses the problem and that probably fixes the issue, as the file sizes would be different. I’ll run some tests later to see if the issue is fixed with this new update.

There are no references related to this in the previous changelogs except in December 2018 when they fixed an issue with duplicates. So maybe at that time it was set to block uploads with just the same filename and the update today changes it to require the same filename and the same file size. That would solve the problem for me.

Just wanted to add on to this. Although putting the reCaptcha field in the form solves the initial problem, when you go back to edit a post, the reCaptcha field is not displayed and editing the featured image here causes the same problem.

I’m guessing it is intentional that the reCaptcha field is not included on the edit page (they already had to do it once to add the post, so they have already passed the test and I guess there is no reason to show it again), but is there a way to have it always show the reCaptcha field anyway, even when editing a post?

I haven’t tested the form with all other plugins turned off or using a default theme. If I find some time to set up a test site I’ll give it a try.

Thanks for the confirmation! I just finished testing and adding reCAPTCHA worked for me too.

I’ve posted the bug on the GitHub page, maybe it will get looked at there.

I’m having a very similar problem, likely the same problem, so I’ll tag on to this topic.

I created a post form many months ago, and recently, after clicking the button to upload a featured image and selecting an image to use, the submit button at the bottom of the form is disabled and greyed out.

I’m a developer so I started looking into what could be causing the problem. Directly after picking the image, the browser console log shows an uncaught reCAPTCHA error, “No reCAPTCHA clients exist.”

We aren’t using reCAPTCHA here and do not have the reCAPTCHA keys entered into the plugin’s settings.

I’m going to try setting up the reCAPTCHA keys and see if that fixes things, but we really don’t need it for our purposes.

@aryan36500 If you know how to access your browser’s console log, can you check to see if you are getting the same error as I am?