Quarantine Issue When Updating the WordPress Core Using Automatic or Third-Party Methods

[Living Miracles]

Hello,

We’ve been working on updating the WordPress core from version 5.4.2 to 5.5.1 on our sites lately. Until now, we’ve always had the automatic updates disabled in our wp-config.php file and had been doing them manually from the back-end of each of our WordPress sites as this felt safer. However, due to various reasons (including the fact that we have 40+ WordPress sites when counting our staging sites), we’ve now started exploring and experimenting with automatic WordPress core updates. The purpose for us writing to you about this is because we’ve now tried some different ways to auto or even manually update the WordPress Core and it isn’t working correctly with the BulletProof Security Pro plugin.

What’s happening for us is that when the update occurs on the site, it goes down and stays down after the ARQ Cron gets triggered as 66 WordPress files get quarantined. Then, the only way, or at least the easiest way to bring the site back up is to restore it from a recent backup. We’ve tried “native” automatic WordPress core updates, auto and manual updates from the interface/system of our web host provider (SiteGround), and manual updates from our ManageWP account (for sites on this server as well as another), and every time the same WordPress files are getting quarantined and the site goes down. The only methods that have worked to do this update, is to either do it from the “WordPress Updates” page in the back-end of the site or to turn off ARQ first, then use any of the other methods mentioned, next delete all the ARQ Backup Files, and after that to back up all the ARQ Backup Files. But neither of these options are really ideal with the number of sites we have, and it would be truly helpful if these other options I’ve mentioned to more quickly or efficiently update the WordPress core would correctly work with the BulletProof Security Pro plugin and therefore not have the site go down or have any files get quarantined during this process.

Do you know why this is happening? Is this something that you can fix?

Along with this, we do want to mention another related issue. We’ve noticed, at least with this situation where these WordPress files are getting quarantined and we’ve needed to do a restore of the site to bring it back up, that the files are still in the /wp-content/bps-backup/quarantine folder afterward. Is that normal behavior? To us, we would assume that if we restored the site from a backup, that occurred before the update and the files getting quarantined, that the “quarantine” folder should be empty after a restore.

Thank you,
Living Miracles

[AITpro Admin]

See this forum topic for common causes for this problem and how to fix this problem > https://forum.ait-pro.com/forums/topic/website-not-loading-after-wordpress-upgrade-or-theme-upgrade-500-error-files-quarantined/

See the AutoRestore|Quarantine Guide forum topic for general information about what AutoRestore|Quarantine is and how it works > https://forum.ait-pro.com/forums/topic/autorestore-quarantine-guide-read-me-first/.

[Living Miracles]

Thank you for those links. I have checked them out but I have to say I’m not sure if they have totally answered our question about what we’ve been noticing. However, I do feel they’ve explained well enough what we can do to bring the site back up, besides needing to restore the site from a recent backup, when it goes down due to all these files getting quarantined.

I read in the second link that “AutoRestore works seamlessly with WordPress Automatic Updates,” so from that it does seem like there might be some sort of issue with the plugin that would need to be fixed since we ran into this quarantine issue with a native WordPress automatic core update (i.e., we weren’t updating the core through any third-party methods).

But from what I also read, it seems that this quarantine issue is possibly a “known issue” when updating the WordPress core automatically or manually through a third-party (e.g., SiteGround, ManageWP, etc.) and it is unavoidable without maybe turning off ARQ beforehand (which wouldn’t be ideal for us to do with 40+ WordPress sites as I previously mentioned). Did I understand that correctly?

As for the last question I asked in our opening post, I suppose you may not be able to answer it and this might be more a question for our web host provider but I feel to ask again if, from everything you’re aware of, that seems like normal behavior for using a restore from a recent backup, that occurred before files were quarantined, to not affect or overwrite the /quarantine/ folder and have quarantined files still in it afterward?

Any part of all of this that you can elaborate on for us so that we can truly understand, would be greatly appreciated.

[AITpro Admin]

AutoRestore Automation did fail on one of my sites once about 3 years ago.  The reason it failed that one time in 9 years was an extreme latency issue on my web host server.  The majority of people have never had AutoRestore Automation fail and then some people contact me just about every WordPress upgrade because AutoRestore Automation fails due to one of the listed common known problems causing the problem.

AutoRestore Automation hooks into the WordPress Upgrade function using filters.  As long as something else, such as remote management plugin is also hooking into the WordPress Upgrader function then everything will work correctly.  Both the ManageWP and InfiniteWP remote management plugins hook into the WordPress Upgrade function. AutoRestore Automation works seamlessly with both of these plugins. So if you are manually installing WordPress or installing WordPress without triggering the WordPress Upgrade function then AutoRestore Automation will not be able to tell who or what is adding files to your website/server.  Upgrading WordPress from your web host control panel is a manual installation of WordPress.  Upgrading from within your WordPress Dashboard on the Updates page is not a manual installation and AutoRestore Automation will be able to tell what the WordPress Upgrade function is doing with the filters in AutoRestore Automation that hook into the WordPress Upgrade function.  WordPress Automatic Updates also use the WordPress Upgrade function.

If you are going to restore your website from a backup then AutoRestore needs to be turned Off during the file restore.  You can choose to include or exclude the /bps-backup/ folder in your backups. Personally I recommend that you exclude the /bps-backup/ folder in your backups.  I can’t answer your question because I don’t understand what you are asking.  In any case you don’t need to do a restore if this type of problem occurs.  If you use the steps in the first link I posted it would take you about 10 minutes to fix the problem.

What you want to do at this point is to do a standard WordPress upgrade using the WordPress Bulk updater on the WordPress Dashboard > Updates page > click the Install Now or Re-Install Now button. Let me know if you run into a problem and I’ll work with your to figure out what on your website or host server is causing the problem.

[Living Miracles]

Hello,

Thank you for all the information that you shared. I just wanted to report back, at this point, that we’ve been working on resolving some optimization issues on our server, and, after partially resolving one of the issues, one of the native automatic WordPress core updates did work successfully without us running into this quarantine issue. The second test of this, as well as two tests involving doing the WordPress core updating through our ManageWP account, did not work successfully, unfortunately, and they experienced the quarantine issue.

There are still some things to resolve with our optimization issue, so once that is handled, we can see how our sites do with the next automatic WordPress core updates or doing them via ManageWP. At that point, if there is still an issue, we may respond back to this forum post to further troubleshoot this.

Thank you,
Living Miracles

[AITpro Admin]

See this ManageWP forum topic (Note: That topic is 3 years old so things might have changed with ManageWP since then) > https://forum.ait-pro.com/forums/topic/managewp-read-me-first/

[Living Miracles]

Thanks for linking that forum topic. From my understanding of your last reply on October 4th on this topic, it seemed liked doing WordPress core updating from ManageWP should work correctly with ARQ so that we don’t end up with the quarantine issue. You wrote:

AutoRestore Automation hooks into the WordPress Upgrade function using filters. As long as something else, such as remote management plugin is also hooking into the WordPress Upgrader function then everything will work correctly. Both the ManageWP and InfiniteWP remote management plugins hook into the WordPress Upgrade function. AutoRestore Automation works seamlessly with both of these plugins.

However, when I read through the forum topic you linked, my understanding now of this is that only plugin and theme updates from ManageWP work seamlessly with ARQ while updating the WordPress core purely from ManageWP won’t. Is that correct?

I also see in that other forum topic that you wrote:

Currently this particular task of creating new ARQ Automation code just for WP Core updates and WP remote management plugins has been pushed back due to higher priority tasks taking precedence. The next 2 versions of BPS and BPS Pro are Dev locked, which means that after the next 2 versions of BPS and BPS Pro are released we would look at this particular task again and other tasks on our list of tasks and resort the task list again based on priority order.

Since that topic was from three years ago, can you share whether or not this was looked into again since then and if there is any possibility of the BPS Pro plugin ever working seamlessly with WordPress core updates purely from ManageWP, or other WP remote management plugins so that the quarantine issue doesn’t occur?

Thank you,
Living Miracles

[AITpro Admin]

I corrected this sentence – “For WP Core Bulk updates (manual updates on the Updates page), AutoRestore Automation uses AJAX trigger functions instead of using the WP upgrader_pre_install and upgrader_post_install filters.”  The other statement was made before the very beginning forum topic was updated.

You would want to use these steps to update WordPress from ManageWP or use WordPress Automatic Updates.

1. Use the ManageWP Open WP Dashboard feature to connect to your WordPress Dashboard.
2. Update WordPress from the WP Dashboard. AutoRestore Automation will automatically turn Off AutoRestore, backup files and turn AutoRestore back On.

Or

1. Use the ManageWP Open WP Dashboard feature to connect to your WordPress Dashboard.
2. Turn AutoRestore Off.
3. Update WordPress from the Manage WP Dashboard.
4. Run the BPS Pro Setup Wizard.

Note:  Enabling WordPress Automatic Updates will automatically install any/all new versions of WordPress when they are available.  So manually updating WordPress either from your WP Dashboard or from the remote ManageWP Dashboard is not really necessary.

[Living Miracles]

Okay, so are you saying that BPS Pro plugin won’t get updated for this because it’s just not possible for WordPress core updates to work smoothly if they are done purely from the ManageWP account without doing those extra steps you mentioned from the back-end of the WordPress site as well?

[AITpro Admin]

What I’m saying is don’t know exactly what ManageWP is doing regarding remote WordPress Core updates.  I checked the ManageWP site years ago and just now.  I still have no idea what ManageWP is doing regarding remote WordPress Core updates because there is not any documentation about that.  I can add the WordPress upgrader_pre_install and upgrader_post_install filters in the BPS Pro WordPress Core manual Bulk update AutoRestore Automation code for WordPress manual Bulk updates, but there is no guarantee that things will work from ManageWP using the Update All feature.  Since the Update All ManageWP feature works for Plugins and Themes there is a good chance it will work for remote WordPress Core Bulk updates too.  I’ll roll the dice in BPS Pro 15 and you can be my guinea pig to test whether ManageWP triggers the upgrader_pre_install and upgrader_post_install filters for remote WordPress Bulk updates.  LOL

You could always try and ask ManageWP if they hook into the WordPress upgrader_pre_install and upgrader_post_install filters when a remote Update All is done from ManageWP.  Maybe you will have better luck since you’re a customer.  I never heard anything back from them.  😉

[AITpro Admin]

At this point I am putting this on hold again.  I wasted a week testing ManageWP and trying to figure out how ManageWP is triggering whatever it is triggering to do Remote WP Core Bulk Updates.  ManageWP does not appear to be hooking into the WordPress upgrader_pre_install and upgrader_post_install filters like they do for Remote Plugin and Theme installations.  Or they are doing it in a way that I have not been able to figure out.  It’s a shame I can’t look at their code since I would know exactly what I would need to do in BPS Pro to work with ManagWP, but you only get to see the client ManageWP Worker plugin and not what is happening at the Source > ManageWP itself.  I will take another stab at this in BPS Pro 15.1.  The BPS Pro 15 version release has been held up long enough due to wasting time trying to guess what ManageWP is doing.

I’m thinking I may need to take another approach.  Something like check if the ManageWP Worker plugin is installed and if it is then somehow figure out when a remote WP Core Bulk Update is occurring from ManageWP and automatically turn Off AutoRestore to prevent files from being quarantined.  If that is the only route available for me to take then that will leave a manual step that will still need to be done, which would be to run the BPS Pro Wizards on each site that had a remote WP Core Bulk Update done on it.

[Living Miracles]

Wow, well, thank you for taking another deep look into this! Hopefully, the answer will become apparent when you try this again for version 15.1.

[Living Miracles]

Hello,

I wanted to write back and let you know that I ended up recently writing to ManageWP about this issue, as per your previous suggestion. They wrote back sharing that they would like to try and fix this issue and asked if I could reach out to you again and request your contact details so that they can try and reach out to you about this. I shared with them that they could probably use the info @ ait-pro . com address, as that is what we’ve previously used, but they asked if I could double-check with you about the address to make sure it is the correct one to use in this situation. So is that the best address they should use to connect about fixing the compatibility issue when using ManageWP to remotely update the WordPress core and BPS Pro then quarantining WordPress core files?

Thank you,
Living Miracles

[AITpro Admin]

Awesome!  Yep info at ait-pro dot com is the correct email address to use.

[Living Miracles]

Great, thanks! I’ll write back to let them know and hopefully, they’ll reach out to you about this soon in the coming days.

[Author]

Posts