AutoRestore|Quarantine Guide

Home Forums BulletProof Security Pro AutoRestore|Quarantine Guide

Viewing 15 posts - 46 through 60 (of 87 total)
  • Author
  • #37999

    @ Geoff – It was working fine for me when I added a php closing tag.  What has changed?

    I made some coding changes to the file and three others in same folder, added the closing tag, turned of ARQ, uploaded file, clicked on Backup files for Root Files , and turned ARQ back on. All files were quarantined, I restored all the files.  The same one would still be quarantined while the others were not quarantined.  Any idea or am I doing something wrong?  Thanks – Geoff


    AITpro Admin

    @ Geoff – Backing up Root Files in AutoRestore does not backup Added Files.  Root Files are any files (WordPress or non-WordPress files) in your website Root folder (/public_html/ or other hosting account root folder name) ONLY.  Any files in subfolders (/public_html/subfolder1, /public_html/subfolder2, etc.) under your Root hosting account folder are not files in the Root hosting account folder.  The AutoRestore Added Files feature is an independent feature that does not have any Backup Files buttons on the AutoRestore page.  If you want to backup Added Files you would rerun the Setup Wizard.  The Setup Wizard backs up all files (Root Files, wp-admin Files, wp-includes Files, wp-content Files and Added Files).  Or you can normally just restore the Added Files in Quarantine if they are quarantined.  In your particular case there is something odd about the particular file that is having this problem.  Send me the file so I can test it on a test server to see if I can figure out what about the file is causing the problem.  Send the file to:  info at ait-pro dot com.


    Hi – every so often (irregularly, but roughly at weekly intervals), the root .htaccess files on a couple of my websites wind up in Quarantine. After investigation, it seems this is due to some job in cPanel (triggered presumably by hosting provider) that attempts to append the following block to the htaccess file:

    # php -- BEGIN cPanel-generated handler, do not edit
    # Set the “ea-php71” package as the default “PHP” programming language.
      AddHandler application/x-httpd-ea-php71 .php .php7 .phtml
    # php -- END cPanel-generated handler, do not edit

    This same directive is already inserted into .htaccess by BPSPro, albeit without the check for mime_module, at the start of the file:

    # PHP/php.ini handler htaccess code
    AddHandler application/x-httpd-ea-php71 .php .php7 .phtml

    Can I just restore the quarantined version of the file to allow the cPanel generated addition, or is there any issue or conflict in having both handler directives (the one from BPSPro and the one from cPanel) in the file? If the latter, should the BPS custom code top be removed?

    The affected sites are with the same hosting provider (different servers); hasn’t been happening with other sites under another provider. PHP versions 7.0.x/7.1.x. BPSPro is v14.2.

    Thanks in advance

    AITpro Admin

    What you want to do is replace the php/php.ini handler htaccess code that is currently saved in BPS Custom Code with the exact php/php.ini htaccess code that cPanel is automatically adding to your root htaccess file including the marker text – BEGIN to END.  Or in other words, the entire block of php/php.ini handler htaccess code that cPanel is generating.  After saving your cPanel php/php.ini htaccess code in BPS Custom Code go to the Security Modes page and click the Root Folder BulletProof Mode Activate button.


    Thanks very much for the advice, greatly appreciated! I’ve given that a go as per your suggestion, so far so good – if no more trips to Quarantine after a week or so more, that should hopefully imply the cPanel job is happy now and it’ll leave the files alone. Cheers


    @ AITPro Admin – Unfortunately, that doesn’t seem to have worked — the cPanel job ran on one of the sites last night and actually moved the php/php.ini handler code block from the BPS custom code section at the top of the .htaccess file where I’d put it, back down to the end of the file again. Consequently, it’s back into the Quarantine slammer again.

    I tried moving the php/php.ini handler code block down to the end of file where the cPanel job seems to want to put it, but that brings up a “HUD Check: PHP/php.ini handler htaccess code check” alert from BPS on the dashboard. Can that alert just be dismissed, or would it keep occurring?

    Alternatively, would it be better to just keep the code block in the BPS custom code section at the top in the place where you’ve suggested, and just let the .htaccess file updates done by cPanel keep getting sent to Quarantine whenever it tries to move the block? That is, assuming the handler directive it wants will be interpreted correctly wherever it’s placed in the file.


    AITpro Admin

    @ CJLLWdigital – If you copy the php/php.ini handler code into this Custom Code text box:  14. CUSTOM CODE BOTTOM HOTLINKING/FORBID COMMENT SPAMMERS/BLOCK BOTS/BLOCK IP/REDIRECT CODE after all other htaccess code in the Custom Code text box then the php/php.ini handler code will be at the very bottom of your htaccess file.

    The “HUD Check: PHP/php.ini handler htaccess code check” message is a Dismiss Notice.  When you dismiss a Dismiss Notice it is dismissed forever or until you reset all Dismiss Notices.

    Got to say what your web host is doing is very silly.  The php/php.ini handler htaccess code can go anywhere in an htaccess file.  So not sure why your web host thinks it needs to go at the bottom of the htaccess file.  Probably a coding mistake by them.


    Yes, it’s hard to fathom why they seem so intent on placing it there. I’ll ask next time I speak with them.

    No matter, I’ve arranged things as per your recommendation, hopefully that will take care of it. Thanks again for your advice and help, much appreciated! Cheers



    Alex Laxton

    Just Scrolling and Wondering such a wonderful post you have written. Good to see this of solution from this forum


    Hi, Various sites just updated to WP 5.3, all of them have quarantined 60 files. e.g. From log files:

    [BPS Pro 14.2: wp-content File Quarantine Logged: November 13, 2019 6:01 am]
    Quarantined Filename: index.php
    Quarantine Path: /home/
    Restore Path: /home/

    Question? Do I need to do anything, restore etc? As sites appear to be working fine.

    Thanks for your advice.

    AITpro Admin

    @ ICTsource – I recommend doing a manual reinstall of WordPress on the WordPress > Dashboard > Updates page > click the Re-Install Now button.  Then delete all files in Quarantine.  Or you can restore all files in Quarantine.


    We had 250 files quarantined…  I was multitasking…

    I forgot to disable autorestore…

    I manually restores everything via FTP.

    I updated the site plugins, theme, etc.

    Now Quarantine went up to ~1500 files.

    Turned AutoRestore Off

    Manually Restored files again.

    Re-ran preinstall & install.

    Refresh Quarantine list

    It still says ~15oo…


    AITpro Admin

    @ Michael – If you have manually restored all files then just delete the files that are in quarantine.


    Not sure you remember the issues I was having with my custom scrips being quarantined and restoring would not work.  I moved some external files around and same thing is happening no matter how many times I try to restore them.  I finally gave up and turned it off.

    I would like to turn this feature back on to have this feature again.  Any ideas?


Viewing 15 posts - 46 through 60 (of 87 total)
  • You must be logged in to reply to this topic.