Files from /public_html/wp-admin/css/ Quarantined after Updating BPS Pro Plugin to Version 14.7

[Living Miracles]

Hello,

For the past few days, we’ve been working on updating the BulletProof Security Pro plugin from 14.6 to 14.7 on some of our websites before updating it on all of them (30+). However, we’re noticing something odd where on the staging sites that we first updated the plugin for, there were four files (i.e., ie-rtl.css, ie-rtl.min.css, ie.css, and ie.min.css) from the /public_html/wp-admin/css/ folder path that were getting quarantined shortly after the update. We then updated the plugin on some production sites and the same four files were getting quarantined, but this time it happened at various longer lengths of time after the update compared to the staging sites. For example, a few sites even took about 24 hours for these files to get quarantined but when we tested out ARQ ourselves by uploading a simple file to the site via FTP, it was caught and quarantined within one ARQ cron cycle, so within a short number of minutes.

Also, after doing a brief check of the files, we felt they weren’t malicious and decided to restore them but, after many hours, these same four files were getting quarantined again. We did try for one of the sites to delete the files from the quarantine but, also after many hours, these same four files got quarantined again. So we tried this one more time, but after deleting the files, we turned off ARQ, deleted the wp-admin backup files, then re-backed up the wp-admin files, and turned ARQ back on. At this point, they haven’t shown up in the quarantine again and it has been several hours.

With that, we wanted to ask a few questions at this point:

1. Why are these exact files now getting quarantined when we update the plugin to version 14.7?
2. Can you confirm that these four files, that are getting quarantined, are supposed to get deleted? Or are they files we actually need and they should be restored/kept instead?
3. Why is it taking so long for these files to get quarantined? If ARQ seems to be working correctly as we tested, they should be getting quarantined within a matter of minutes not hours or even a day, right?

Thank you,
Living Miracles

[AITpro Admin]

I updated the AutoRestore Old Backup File Deletion code, which is a Cron job that runs once per day (every 24 hours) that deletes old WordPress Core files that are backed up in the AutoRestore backup folder. I just checked the ARQ OBFD code and yep found a typo/bug in this section of code below. This variable name is wrong: $ie_css_js. It should be $ie_css.

Your workaround solution is the correct way to fix this problem. I have posted the workaround fix steps below. I’ll get a new BPS Pro version released tomorrow with a fix for this bug.

Workaround solution:
Go to the AutoRestore page.
Turn ARQ Off.
Click the Delete Backup Files button under wp-admin Files column.
Click the Backup Files button under the wp-admin Files column.
Turn ARQ On.

case version_compare( $wp_version, '5.5', '>=' ) && version_compare( $wp_version, '5.6', '<' ):

	if ( file_exists($ie_css_arq) && ! file_exists($ie_css_js) ) {

[Living Miracles]

Thank you for your response. We’re not sure we still understand what this specific Cron does or how it is supposed to work exactly or what issue that typo/bug with the variable name caused exactly here.

However, these are our main questions now:

1. To be clear, you’re confirming that we should delete the four files (i.e., ie-rtl.css, ie-rtl.min.css, ie.css, and ie.min.css) from the quarantine, right?
2. When can we expect this update to be available today? Will this be a new update (e.g., version 14.7.1) or will your fix just be applied to the code in the current update (e.g., version 14.7)?
3. With this update, will these files still get quarantined and, therefore, require us to delete them from there and use those workaround steps?
4. Depending on your previous answers, for the websites that we’ve already updated to version 14.7, do we still need to use those workaround steps since those files are in the quarantine at the moment, or will this somehow get handled?

Thank you,
Living Miracles

[AITpro Admin]

The ARQ OBDF cron deletes old WordPress Core files that were backed up in AutoRestore backup.  When WordPress releases a new version of WordPress, that new version of WordPress has a “cleanup” function that deletes any old folders and files in previous versions of WordPress that are no longer used in the current version of WordPress. In a nutshell, the ARQ OBDF cron does the exact same thing as the WordPress “cleanup” function.  The difference being that ARQ OBDF deletes copies of the files in ARQ backup and the WordPress “cleanup” function deletes the Live WordPress Core files that are no longer being used.

1. Yes, delete the old WordPress Core files in Quarantine that are no longer being used in your current version of WordPress:  e-rtl.css, ie-rtl.min.css, ie.css, and ie.min.css
2. The new version: BPS Pro 14.8 will be released any time today between:  1pm to 6pm.
3. The new BPS Pro 14.8 version fixes the current problem in BPS Pro 14.7. So the answer would be no the same problem will not occur.
4. The new BPS Pro 14.8 version will not repeatedly quarantine those old WordPress Core files since the bug/problem will be fixed in BPS Pro 14.8. You can either wait to upgrade to BPS Pro 14.8 today and delete old WordPress Core files in Quarantine. Or of course you can do the workaround solution now on any websites if you’d prefer to do that instead.

[AITpro Admin]

Actually I decided to push back one of the new changes in BPS Pro 14.8. So BPS Pro 14.8 will be released in about 1 hour from now.

[Living Miracles]

Thank you for explaining that to us. That all started to feel more understandable and clear for us.

We updated the sites with the new version that were already affected with those files in the quarantine yesterday after you published it to take care of those and updated the rest of the sites today. From what we can see from our end, the issue indeed seems to be resolved now.

Thanks again for quickly helping us with this and resolving the issue.

[AITpro Admin]

Great! Thanks for confirming that fixed the problem. On a personal note, I have a bad habit of copying similar code blocks to save time instead of retyping new code blocks. Occasionally I miss an edit. The same problem would have shown up for me during testing, but those files had already been deleted by WP when I upgraded WP on my test site.

[Author]

Posts