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

Home Forums BulletProof Security Pro Quarantine Issue When Updating the WordPress Core Using Automatic or Third-Party Methods

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #39376
    Living Miracles


    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.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.