WordPress.org

Support

Support » Plugins and Hacks » [Resolved] Autolock not working

[Resolved] Autolock not working

  • Updating my site from .47.8 to .47.9

    I always have all my file/folder permissions set as recommend by BPS. I believe these settings are consistent with what my host allows, as they work just fine.

    When I do the update, all the permissions remain intact – except for the ../.htaccess which goes from the recommended 404 to 644.

    I can easily re-lock it to 404 using the handy lock feature in the BPS admin panel.

    I do have the autolock set to “ON”.

    I can post or email you my system info details if that helps. I’m on a standard HostGator shared server that is generally setup to be very friendly for this sort of thing.

    Although I’m only now reporting this, I’m pretty sure this has been the case for me for at least the last two version updates (possibly more).

    Thanks once again for this awesome plugin 🙂

    http://wordpress.org/extend/plugins/bulletproof-security/

Viewing 15 replies - 16 through 30 (of 31 total)
  • Plugin Author AITpro

    @aitpro

    Hmm ok I thought of another possibility.

    These web hosts are automatically excluded from locking the file.

    $ExcludedHosts = array('webmasters.com', 'rzone.de', 'softcomca.com');

    If the php dns_get_record() function is being blocked then maybe that might cause the issue, but I very seriously doubt that would be the problem.

    The BPS autolock code check:

    if (@$permsHtaccess == '644.' && !in_array(bps_DNS_NS(), $ExcludedHosts) && $options['bps_root_htaccess_autolock'] != 'Off') {
    		if (substr($sapi_type, 0, 3) == 'cgi' || substr($sapi_type, 0, 9) == 'litespeed' || substr($sapi_type, 0, 7) == 'caudium' || substr($sapi_type, 0, 8) == 'webjames' || substr($sapi_type, 0, 3) == 'tux' || substr($sapi_type, 0, 5) == 'roxen' || substr($sapi_type, 0, 6) == 'thttpd' || substr($sapi_type, 0, 6) == 'phttpd' || substr($sapi_type, 0, 10) == 'continuity' || substr($sapi_type, 0, 6) == 'pi3web' || substr($sapi_type, 0, 6) == 'milter') {
    		chmod($filename, 0404);
    		}}

    What you could do to eliminate that first part of the check is not working on your site for some reason is to comment out the first set of “if” checks and comment out the last brace as shown below. Then test and see what happens. This code is in the /bulletproof-security/includes/functions.php file at code line 330.

    //if (@$permsHtaccess == '644.' && !in_array(bps_DNS_NS(), $ExcludedHosts) && $options['bps_root_htaccess_autolock'] != 'Off') {
    		if (substr($sapi_type, 0, 3) == 'cgi' || substr($sapi_type, 0, 9) == 'litespeed' || substr($sapi_type, 0, 7) == 'caudium' || substr($sapi_type, 0, 8) == 'webjames' || substr($sapi_type, 0, 3) == 'tux' || substr($sapi_type, 0, 5) == 'roxen' || substr($sapi_type, 0, 6) == 'thttpd' || substr($sapi_type, 0, 6) == 'phttpd' || substr($sapi_type, 0, 10) == 'continuity' || substr($sapi_type, 0, 6) == 'pi3web' || substr($sapi_type, 0, 6) == 'milter') {
    		chmod($filename, 0404);
    		}
    //}

    I commented out the first part of the check as you suggested. Ran a few tests. The file unlocks to write, but still does not autolock.

    There’s nothing in any php error logs.

    Thanks for trying.

    Plugin Author AITpro

    @aitpro

    wow crazy stuff. I guess this will just have to remain an unsolved mystery. Sorry.

    I suppose the thing that has been lurking in my mind the whole time with this issue is this:

    If I can lock the .htaccess file using the “Lock .htaccess File” button in the BPS admin panel, why can’t the Autolock feature do the same thing? Clearly, it’s working with the same server configuration and WP installation. Doesn’t that seem odd to you? What are these features doing that are the same/different?

    I need something that can “auto-click” that file lock button…

    Plugin Author AITpro

    @aitpro

    Yep logically the autolock code should be working on your site. Try using the WordPress Debug code in your wp-config.php file to see if it finds out what on your website is preventing the autolock code from working normally.

    The WordPress debug log is created here – /wp-content/debug.log. Post any errors you see related to the autolock code.

    /**
    * For developers: WordPress debugging mode.
    *
    * Change this to true to enable the display of notices during development.
    * It is strongly recommended that plugin and theme developers use WP_DEBUG
    * in their development environments.
    */
    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', true);

    Did that. Ran some tests. No debug.log file created – so I guess, no errors. Also no errors were shown in the server error log file during this testing.

    Oh well.

    Plugin Author AITpro

    @aitpro

    Well actually that is a clue in itself that the CHMOD function is not being blocked/failing in any way and also that the autolock code itself is not being blocked/failing.

    So that means the code is being processed/executed, but is not fully completing successfully for some reason on your site.

    This could be because you have some custom .htaccess code that is breaking the sequence of root .htaccess code checks and then when it gets to the CHMOD function it does not actually even fire because of that custom .htaccess code. This is a hypothetical logical guess.

    Do these steps.
    1. Make a backup of your .htaccess files using BulletProof Security built-in Backup.
    2. Click the AutoMagic buttons – If you have custom .htaccess code that you added to BPS Custom Code then make a copy of it and delete it BEFORE you click the AutoMagic buttons. You can add it back later after testing.
    3. Activate All BulletProof Modes.
    4. Change the version number at the top of the root .htaccess file from .48 to .47.9 using ONLY the BPS htaccess file editor (do not do this manually via FTP) to force the autoupdate function to fire.
    5. Click on the WordPress Dashboard link/panel or any other WordPress link/panel like the Plugins panel/link – DO NOT Refresh your Browser.
    6. Go to the BPS Edit/Upload/Download page and check if your root .htaccess file was locked.

    Let me know what happens.

    Plugin Author AITpro

    @aitpro

    I updated the steps. Please check them again. Thanks.

    (didn’t we do this test about 6 days ago, or one very similar?)

    I followed your step by step instructions above.

    The version number change on the root .htaccess was successful.
    The file did not autolock.

    More info: Yesterday I temporarily removed my server’s root .htaccess file (at the root of all my server files at public_html). I did this to see if there were any settings there that might be problematic, and to disable my custom tweaked global php.ini. It made no difference.

    Plugin Author AITpro

    @aitpro

    hmm what exactly is your site architecture? The autolock function only checks the .htaccess file for the site where BPS is installed, but it is possible that you have some sort of site architecture or maybe DNS or maybe some other unusual setup that is causing this problem.

    Where is your website installed exactly and what exactly is in the .htaccess file in the /public_html folder?

    Example:
    my website is installed in this subfolder – /myWordPressSite
    the .htaccess file in the website root folder / public_html is a standard WordPress .htaccess file or is a BPS secure .htaccess file without any modifications / with modifications, etc.

    Do you have a GWIOD site? – Giving WordPress Its Own Directory

    It’s nothing unusual. It’s standard HostGator Baby Croc. I’ve got a few dozen addon domains that I keep in separate folders in a sub folder off of public_html. The root .htaccess file in public_html effects the server settings in the subfolders. Things like allowing indexes or denys, etc. Each addon domain has it’s own installation of WP with all the files like .htaccess that go with it. No funny DNS stuff.

    My root .htaccess is here:
    serverroot/public_html/.htaccess

    Each WP site is in it’s own domain/folder:
    serverroot/public_html/addeddomains/domain1/ (wordpress index.php is here)
    serverroot/public_html/addeddomains/domain2/ (wordpress index.php is here)

    Plugin Author AITpro

    @aitpro

    So are all of your websites under this Hosting account having the same problem with autolock?

    If so, that tells you that the problem is with something that controls/is configured/is a setting applied to all of your sites and not an issue that is occuring on each individual site, unless of course you have some plugin installed on all of these sites that is causing this problem.

    The only other thing that i can think of is this. HostGator has some automated script setup to do some sort of check for WP Super Cache .htaccess code. On my HostGator testing site I have left WP Super Cache installed and configured on that site.

    So here is a logical hypothetical scenario that could be what is happening. Since you are not using WP Super Cache then maybe the HostGator check to see if the WP Super Cache .htaccess code exists is interrupting/interfering with the autolock check or is unlocking the file again after it has been locked.

    What i have noticed is that if i remove the WP Super Cache .htaccess code then HostGator automatically adds it back into the root .htaccess file. What this means is that HostGator is unlocking the file automatically so that it can check and add that WP Super Cache .htaccess code if it does not exist. Logically then what could be happening is that autolock does lock the file, but HostGator unlocks it again to do the check for the WP Super Cache .htaccess code.

    There is a checkbox setting somewhere, which i cannot remember where exactly since i did this so long ago that is specifically for WP Super Cache. So maybe you need to change or uncheck this checkbox?

    Plugin Author AITpro

    @aitpro

    And this is just an FYI for BlueHost/HostMonster/FastDomain folks. If you have a domain that is suspended due to forgetting about paying the yearly domain renewal then this Host will automatically unlock the root .htaccess file and add several lines of .htaccess code in the root .htaccess file. The .htaccess code serves as a reminder and I don’t remember exactly what that code does, but it gives folks some sort of heads up notification to remind them about the domain renewal that needs attention.

    I’ll keep looking to see if I can dig up any server settings or configuration that might be causing this issue.

    In the mean time, let’s revisit this part of the mystery…

    My earlier question: “If I can lock the .htaccess file using the “Lock .htaccess File” button in the BPS admin panel, why can’t the Autolock feature do the same thing? Clearly, it’s working with the same server configuration and WP installation. Doesn’t that seem odd to you? What are these features doing that are the same/different?”

    It’s not like my server configuration won’t allow the chmod of the file. If I click that button – it locks the file. So, why can’t the autolock do it’s check and use the same routine to lock it? Does it do the locking differently in those two functions? To me, this is the most baffling part 🙁

    Plugin Author AITpro

    @aitpro

    The autolock On / Off buttons create a database entry/option that is either On or Off. The coding check that processes the part of the function that autolocks your root .htaccess file looks for “if autolock is not set to Off”. If autolock is set to On or if no database entry/option exists then the root .htaccess file is automatically locked during BPS upgrades.

    Something is breaking/interfering/preventing autolock from working on ONLY YOUR WEBSITES.

    autolock works perfectly on all my testing sites and the 100,000’s of other WordPress websites with BPS installed on them.

Viewing 15 replies - 16 through 30 (of 31 total)
  • The topic ‘[Resolved] Autolock not working’ is closed to new replies.