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 🙂
In code processing you will see that last displayed message for the last code function that was processed. Is it possible that you are looking at the last message for the last code function that was processed? Your actual current status can be checked by either Refreshing your Browser or clicking the BPS Menu link.
When automatic .htaccess file updating occurs on BPS upgrades the root .htaccess is automatically unlocked to 644 permssions so that BPS can write any new .htaccess code or make any new changes to the root .htaccess file. The automatic update will NOT change any custom .htaccess code that you personally added to your root .htaccess file and will ONLY change the standard BPS .htaccess code that needs to be modified or add new additional .htaccess code.
If you have AutoLock turned On then your root .htaccess file is automatically locked again with 404 file permissions. It is of course possible that some particular situation, scenario, difference or restriction on your particular web host or Server will prevent AutoLock from working correctly.
Thanks for the response… tastes a little bit like it was “canned” (when did you start doing that?)
I’ll pick choice #3 since this has nothing to do with cached messages, and the update has no problem with changing the permissions as needed.
The problem is that with the autolock feature set to “ON”, the .htaccess file permissions get changed from 404 to 644. The permissions are not autolocked back to the 404. This is easy to confirm by looking at the current security status in the admin panel (after reloading the page). It’s also clear that the permissions are not reset to 404 by looking at the permissions via file manager or FTP client.
Conclusion: Autolock is not working correctly.
Question: Is there a fix?
Here’s my server info:
==Website / Server / Opcode Cache / Accelerators / IP Info== Website Root Folder: http://mywebsite.com Document Root Path: /home/mywebsite/public_html/sites/mywebsite WP ABSPATH: /home/mywebsite/public_html/sites/mywebsite/ Parent Directory: /home/mywebsite/public_html/sites Server / Website IP Address: xxx.xxx.xxx.xxx Host by Address: xxx.xxx.xxx.xxx DNS Name Server: xxx.xxx.xxx.xxx Public IP / Your Computer IP Address: xxx.xxx.xxx.xxx Server Type: Apache Operating System: Linux Server API: cgi-fcgi - Your Host Server is using CGI. cURL: cURL Extension is Loaded Zend Engine Version: 2.2.0 Zend Guard/Optimizer: Zend Optimizer Extension is Loaded ionCube Loader: ionCube Loader Extension is Loaded Version: 40202 Suhosin: Suhosin is Not Installed/Loaded APC: APC Extension is Not Loaded eAccelerator: eAccelerator Extension is Not Loaded XCache: XCache Extension is Not Loaded Varnish: Varnish Extension is Not Loaded Memcache: Memcache Extension is Not Loaded Memcached: Memcached Extension is Not Loaded ==PHP Server / PHP.ini Info== PHP Version: 5.2.17 PHP Memory Usage: 34.61 MB WordPress Admin Memory Limit: 256M WordPress Base Memory Limit: 40M PHP Actual Configuration Memory Limit: 64M PHP Max Upload Size: 64M PHP Max Post Size: 64M PHP Safe Mode: Off PHP Allow URL fopen: Off PHP Allow URL Include: Off PHP Display Errors: Off PHP Display Startup Errors: Off PHP Expose PHP: On PHP Register Globals: On PHP MySQL Allow Persistent Connections: Off PHP Output Buffering: PHP Max Script Execution Time: 30 Seconds PHP Magic Quotes GPC: Off PHP open_basedir: not in use PHP XML Support: Yes PHP IPTC Support: Yes PHP Exif Support: Yes ==SQL Database / Permalink Structure / WP Installation Folder== MySQL Database Version: 5.5.23-55 MySQL Client Version: 5.5.23 Database Host: localhost Database Name: mywebsite_mywebsite Database User: mywebsite_mywebsite SQL Mode: Not Set WordPress Installation Folder: / WordPress Installation Type: Root Folder Installation Network/Multisite: Multisite is Not enabled WP Permalink Structure: /%year%/%monthnum%/%day%/%postname%/ Permalinks Enabled: ? Permalinks are Enabled PHP Version Check: ? Using PHP5 Browser Compression Supported: gzip, deflate
Not sure what you mean with “canned”?
Messages would not be cached. What happens with coding is this. You create a function and when the function is processed/executed then the text message that you have added within the function is displayed in that particular Browser window at that moment when the Browser is Refreshed.
So what can happen is something like this.
The automatic file updating starts by processing/executing the function that does that. When the function completes you see the message that goes with the function, but where you actually are in the code processing/execution is you have already moved on to the next function that is now doing whatever it is designed to do. The Browser is still where it was and displays the last function that was processed/executed. If I were to force Browser Refreshes then you would see your actual status in real-time. Since this is frowned upon in general then forcing Browser Refreshes is not something that I will probably ever do. I may do something with the PHP sleep() function though in the future to trick the eye into seeing/believing real-time status display.
AutoLock works perfectly fine on the BPS testing sites:
Standard single WordPress installation testing site.
– root and subdirectory testing sites
Network/Multisite WordPress installation testing site.
– subdirectory and subdomain
GWIOD WordPress installation testing sites.
– standard WordPress installation testing site
– Network/MU WordPress installation testing site
Various subdomain and subdirectory combinations of the sites listed above.
Let me rephrase my statement. Your web host or Server configuration for your particular Host may cause AutoLock not to be working correctly for any one of various possible reasons. From the feedback that I get the AutoLock feature appears to work fine on 1,000’s of different web hosts with millions of different possible configuration scenarios/possibilities, but of course there are going to be some configuration scenarios where I assume AutoLock would not work.
So in summary, I am not sure why AutoLock is not working on your particular website/Server/Configuation. On all the BPS testing site types it works fine. The general feedback that I get is AutoLock works fine so this leaves the only possible conclusion.
Something about your particular website/Server is causing AutoLock not to work. It is also possible that another plugin could be preventing AutoLock from locking the file I guess. So the next logical troubleshooting steps would be to figure out what on your particular website is causing AutoLock not to work.
Your Server info although very helpful in eliminating several different possible reasons for AutoLock not working on your particular website does not display what is causing the problem on your particular website.
Try this test.
Edit your root .htaccess file and change the version number in your root .htaccess file with the BPS built-in .htaccess file editor. Then Refresh you Browser. What should happen is that your Root .htaccess file should be unlocked and the version number will be changed. Next click on the BPS Menu link. The displayed messages from the last function that was processed will go away and the next function that locks the root .htaccess file should now show that status of the next function that has been processed.
Let me know if the root .htaccess file is locked again after doing these testing steps.
Did you try the test? Oh and I forgot to mention that when you change the version number just change it back one version for testing. Change .47.9 to .47.8. Let me know if the root .htaccess file is locked again after doing these testing steps.
I did all the steps you indicated.
I was able to edit the current .htaccess file to change the version number. Of course, I had to unlock the file using the unlock feature. That worked fine.
I did the refresh and so on, and never saw any error message about the version number (re: “If you edit the BULLETPROOF .47.9 >>>>>>> SECURE .HTACCESS text above you will see error messages on the BPS Security Status page”).
The .htaccess file did not autolock.
I did this on two sites: one with version .47.8 the other version .47.9.
I can make you an admin at one of my sites if you want to give it a try. Just let me know where to email you the login credentials.
We cannot offer to login to folks sites because we do not have the time or resources to offer that kind of service.
Ok so we know for sure that AutoLock does NOT work on your website for some odd reason. AutoLock does work in general so it is not an issue with the BPS AutoLock coding itself. So the next logical thing to look at would be plugins or maybe some Server configuration issue or maybe some setting in your web host control panel.
let’s start with plugins. Please post a list of all the plugins you use.
I do have a HostGator testing Hosting account so I will test and see what happens. I noticed that you have posted this same issue a few times in the past so let me check and see if there is some kind of issue with HostGator itself. I seriously doubt that, but will eliminate that possibility.
Ok i just tested upgrading from .47.8 to .47.9 on HostGator and AutoLock works fine. It is not your web host so either you have setup something in cPanel that is blocking AutoLock or one of your plugins is doing this or you have done some sort of custom configuration/custom coding on your particular website that is causing AutoLock not to work.
Also by default HostGator accounts have WP Super Cache already installed and configured so it might be possible that this has something to do with it. On my HostGator testing account WP Super Cache is activated and is in use.
Are you using cPanel HotLink Protection? If so, this wreaks all kinds of havoc not only with BPS, but also with WordPress itself.
Did you give up on figuring out what is causing this on your website? Thanks.
Resolving. If you want to work on this at a later time then unresolve this Thread and post your lastest status. What you have tested or not tested, etc.
I have a recently installed WP site in which I deactivated all the plugins except BPS. Reverted to the previous BPS version. Set it up, set the permissions, did the upgrade no problem – But, the autolock did not work.
I do not have hotlink protection on (never have).
I do not use automatic installations of WP from webhost cPanels. I do it myself. I do not use any caching.
What sort of settings would I be looking for that might be the problem. Something in a custom PHP.INI? Custom directive/setting an the root .htaccess? I may have done some tweaking settings in those files as if recommended for better server security. Maybe something is too restrictive? So, what would I be looking for?
The cPanel HotLink Protection is always on – you cannot turn it off – the Enable/Disable options are also broken, but if your root .htaccess file is locked then it will prevent the tool from automatically wiping out your root .htaccess code.
I don’t think the HotLink Protection Tool is the problem in your case. Actually I am completely out of ideas. Since the automatic unlocking of the file is working from 404 to 644 then nothing on your website is blocking the CHMOD function itself so it should also work the same to CHMOD back from 644 to 404 to lock the file again.
The only idea I have left for you to check would be to check your php error log file or your Server log file for the problem that is occurring on your site. But the error is probably only going to tell you that the code is failing for some reason on your site and not what is actually causing that code to fail.
- The topic ‘Autolock not working’ is closed to new replies.