doffine

Hi @freemp,

we just found that Avada is not the only thing causing this problem.

We can leave Avada and your plugin activated and disable only WPML – then the jQuery error is gone, too.

Or we can leave your plugin and WPML activated and replace Avada with Twenty Twenty-Two – then the error is also gone.

But: We have other WP installations with both Avada and WPML that don’t show this error with your plugin. So it seems to be quite complicated. We really don’t know what the problem is and are not very confident that involving Avada or WPML support will solve this problem.

So we deinstalled your plugin and replaced it with a manual 404 redirection of the author archive page.

Anyway many thanks for your quick response. Perhaps at least it can be useful for you if you have heard of such problems when there should be future similar cases.

Greetings and thanks for your work,
-doffine

Hi @gravid7, @mirkogosch,

since we are not versed in things like that and because we don’t want to have any risk for our customer’s shop we would prefer not to make this test on our site and would like to wait until an official update is there.

@mirkogosch – have you already implemented this solution and can say anything about it?

Greetings and many thanks to both of you,
-doffine

Thank you very much! If we could drop another 5 stars we would do so :-).

Greetings,
-doffine

Hello @aweissinpsyde,

thank you very much for coming back to us.

You mean this plugin here: https://wordpress.org/plugins/woocommerce-paypal-payments/ ?

We see 1.5 stars out of 5 with nearly 200 ratings. Many users write very bad things about this plugin. This doesn’t look very trustworthy, what do you think?

Greetings,
-doffine

Hello @foobarstudio,

thank you very much for coming back to us.

Unfortunately we don’t have the skills and also no developer to patch your plugin on our own. If you don’t have the time to support compatibility with the other plugin, could you please consider the following?

With your plugin end users are able to upload files. We all know if you let end users upload anything, they literally do upload anything. Uploading files with problematical characters in their file names can trigger all kinds of issues. This starts from upper and lower case characters in different file systems and goes to backup and restore processes or a change of the server (OS).

So if you let end users upload files to WordPress it should be possible that these file’s names are automatically sanitized. Ideally all characters should be replaced that are no (lower case) letters, numbers, periods, hyphens and underscores.

If it is too much work to support compatibility with the other plugin, it might be much easier for you to add a small function that can be switched on or off that simply sanitizes uploaded file names just within your plugin during the upload process. I think this would be an advancement for your plugin, too.

Would that be possible?

Thanks again so much, greetings,
-doffine

Thanks for letting us know how your plugin works. In the meantime we contacted the other mentioned Plugin “WP Customer Area” and they said it may have something to do with hooking into wp_handle_upload_prefilter which may be the reason why WP Customer Area plugin does not find the files afterwards.

Here’s the thread: https://wordpress.org/support/topic/incompatibility-with-other-plugin-clean-image-filenames/

They further noted that WP Customer Area is open-source, and they offer to help a developer to find their way into their code by pointing out the files and classes.

Since we do not have the skills or a developer to look into this we thought you might be interested to look into this as it could help with the compatibility of your plugin with another popular plugin “WP Customer Area”.

Both plugins have a large installation count and it would be extremely useful and also in your own interest to make your plugin compatible with plugins like “WP customer Area”. I think it’s not far fetched to want uploaded files in a customer area to be clean. It’s actually crucial to have clean file names as it might trigger all kinds of issues.

Would you be able to look into this compatibility issue with your plugin?

Hi @abidhasan112,

thanks for coming back to us. Ok, great that you are already looking into it and for letting us know as soon as it is fixed.

Until then we’ll simply do the re-save manually after every plugin update.

Thank you for your work and have a good day, too.

-doffine

Hi Aleksandar,

to answer your question: We see that “wgact” is being loaded when we surf to the website in Google Chrome and press F12. In the tab “sources” you can see that it’s loading an external source “wgact” and if you expand it you can see a “webpack” and “./src/js/public” with lots of .jsx files in it. We have your feature “Explicit Consent Mode” and Borlabs Cookie Tool active.

Thanks!