MainWP Security tab remove registed information from URLs

Hey there!

I’ve always been wondering but never found a clear-cut answer to this:

is there realistically no downside in doing

Scripts and Stylesheets registered version information has not been removed from URLs

in the security tab? like, will it not risk any issue with newer version and what not? namely I use elementor/astra usually on my websites, and I avoid doing the last bothersome 1% final optimization to most websites, as often enough they need to be edited and worked on.

Hi @Jayddo, I am not 100% that I understand your concerns, can you please provide us more details?


MainWP’s basic security check gives, among others, these two warnings:

Scripts and Stylesheets version information has not been removed from URLs
After fixing this issue, versions will be removed
Scripts and Stylesheets registered version information has not been removed from URLs
After fixing this issue, registered versions will be removed

and I am asking if there are any drawbacks in doing so

In some very rare cases, I have seen that removing scripts version with the first option can cause issues with loading scripts. In case this happens, you should fix only the second one.

1 Like

Thank you very much, I’ll just do it on every site one at a time and check if everything works properly, but it means I can do it for the most part.


You are welcome. Let us know how it goes and if you stumble upon any issues.

It certainly is a problem as scrips and stylesheets are not cache-busted anymore if your remove this. The only way to counter it if you remove the version parameters from the URL’s is to make sure that the files themselves have different names between versions, which is harder to do, especially if the plugins/themes are not made by yourself.

Is it not possible to make these two security checks optional in the settings? Especially if you have a bunch of sites and those two checks are left in an “unfixed” state, the overview is always showing that there are “security issues”. Making these two settings optional (globally) would be a big welcome for me.

1 Like

Hi @Ronnerd, yes we already have on our todo list to add the ability to disable/ignore specific Security checks. I don’t have a timefreame yet, but I hope this will be handled in one of the next updates.

So, do you mean that we have to wait for the update? Please, could you say would it be in this next months or later?

I really don’t have any time frame at this moment. We will give our best to get it done as soon as possible.

Good to hear it’s in the pipeline. I’ll wait on the update that includes it, thx!

Thanks for your patience!

Yeah so we’ve been trying to diagnose issues with Beaver Builder and it’s created a huge support nightmare for us. We finally discovered this is what broke 423 of our client WordPress sites. Is there a way to “bulk unfix” the Scripts and Stylesheets version information detection?

Clarification… is there a script that could be run through WP CLI or snippets that could unfix the one check or if easier unfix everything? Technically my Nginx hosting environment takes care of many of these things.

Perhaps an idea could be to deactivate and uninstall the MainWP Child plugin in bulk on those sites using WP-CLI and then do the same thing in reverse.

Or another option would be to install two empty WP sites and put MainWP child on it. On one of those installs, apply the “version information fixes” and then compare the wp_options tables to see what’s different. My guess is is that this “fix” is just a simple toggle written in the wp_options table. If so, create a SQL update statement and apply to the databases of those 423 sites in bulk.

Just checked what’s written in the wp_options table. It’s an option with the name “mainwp_security”. Removing that record from the wp_options table also removes the two fixes.

After removing that record and then syncing the child site with the dashboard again, I did not find any misbehavior or other things related to that record that were negatively impacted. But perhaps it’s an idea to update the name of the record to something else as a test.

UPDATE wp_options
SET option_name = 'backup_mainwp_security', autoload = 'no'
WHERE option_name = 'mainwp_security';

And if things do go wrong, revert it using

UPDATE wp_options
SET option_name = 'mainwp_security', autoload = 'yes'
WHERE option_name = 'backup_mainwp_security';

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.