I came to this page after having the same issue. I found mine was because I was using special characters. I use a password generator to create a random 32 character long password. Once I turned off special characters ($&%^, etc.) I had no issues. It’s less secure, but at 32 characters of randomness, the likelihood of it being brute forced is pretty slim.
I am using Chrome and the Password Protection doesn’t work.
Did you find a fix for this problem?
Rita
I was experiencing this problem on my work computer, and after hours of troubleshooting I decided to try on my phone and personal computer and it appears to work fine. So it must be something installed on my work computer that prevents the redirect.
Hopefully this small bit of info helps someone out there.
UPDATE:
It was because I removed the google site verification TXT that did the trick!
It was just coincidence that it started working when I tried it on a different device.
Check length of your password, it needs to be less than 20 letters, mine was too long.
Hello,
I solved it on my website by adding this hook:
function do_not_cache_password_protected_pages() {
if ( is_admin() ) {
return;
}
$post = get_post();
//if (!empty($post->post_password)) { // switch to this condition, if you want to disable cache also on already authenticated pages
if (post_password_required()) {
nocache_headers();
}
}
add_action( 'template_redirect', 'do_not_cache_password_protected_pages' );
This was very tricky for me to figure out. I have 2 webshostings by the same provider and yet for one it worked and for the other with almost identical wordpress setup it didn’t.
I could make it work on a PC by hard refresh (Ctrl+F5) or by Disabling the browser cache in a console. Which is both not feasible for phones or any regular website visitors.
When I compared the request headers, I found out that the working site was always sending the "cache-control: max-age=0" header no matter what (also slows down the website a lot), while the other one was sending always "cache-control: max-age=300" no matter what (fast but causes this caching problem). I couldn’t find out what exactly causes this difference. But the function above sets the pages which are protected by a password to not be cached by the browser.
Now, no hard refresh after setting the password is needed anymore. But if you e.g. delete the password cookie, you would still need to wait until it expires or do the hard refresh to go back to the Password form. This can be “fixed” by switching the IF condition to the commented one which will turn off the cache for the password protected pages altogether – making them a bit slower, but safer.
I hope this will help somebody 🙂 It would definitely be nice, if WordPress could fix this internally.
Where should that hook be added?
bidraz, I don’t like editing any files as I would need to maintain it every time I install updates. So I just installed the plugin https://wordpress.org/plugins/my-custom-functions/ and pasted the customization into its settings.
@goldenbluespiral can I use the plugin [Insert Headers and footers] to add this hook? Thanks you!
@phongphongtam You need some plugin which is able to execute PHP code. I am not sure if the Insert Headers and Footers plugin can do that.
The solution from @marcusgregory worked for me. I did exactly as follows and it worked.
I did a bit more reading and found this information about advanced-cache.php (https://www.infinityfolder.com/advanced-cache-php-error-in-wordpress/) and I think it happened not long after installing Cloudflare. I’m also using the Divi theme. Perhaps a conflict between the caching of these caused the conflict and created this error as a drop-in plugin.
My case was similar to others. It wouldn’t accept the password (however if I was a logged in user it would accept the password). I disabled Cloudflare and changed the nameservers back to their original settings. It often worked when using Safari, but not on Chrome. I had updated all plugins, updated the them and WordPress to the latest and nothing had worked. As soon as I found and deleted the drop-in plugins in my files using cPanel it all started working properly again. Thank you to everyone for adding their feedback. That was a scary few hours but glad to have a solution.
marcusgregory (@marcusgregory)
2 years, 11 months ago
Got a solution… at least for my situation.
Somehow a file named objectcache.php was a “Drop-In” plugin. You can see those at the top of the Plugins page (e.g., All, Active, Inactive, etc.). I never saw a Drop-In plugin before nor do I know where it came from. When you click on the Drop-In header (will only appear if you have Drop-Ins), it will tell what plugins are dropping in and where they are hiding.
Mine was in the “wp-content” folder, which of course I learned you can’t access from WordPress admin page. You need to get into your “wp-content” folder via an FTP server (or you may have a different way) and delete it there (which was a whole new learning experience).
I deleted the objectcache.php (and two other files associated with it) and boom, problem fixed. Password protected page now working again like a charm. Hope this helps someone.
ugh, the above worked for a bit, but back to doing it again.
@iamjimbob Have you gone through my troubleshooting steps? It’s a huge pain in the ass but one of the steps is pretty sure to work. https://wordpress.org/support/topic/password-protected-pages-not-working-5/page/4/#post-11344766
If you need help, contact me.
I’m actually planning on compiling all of the suggestions into a post on my blog later today, and I’m working on a plugin that would have toggle on/off fixes to try. It’s a bear. Can’t believe this thread is still active lol
Thanks @jrevillini , I’ve done a bunch of those steps and will have to take another look. I’ve made a testing site so I’ll tinker on there where I can turn off the plugins and see what happens.
@jrevillini I’ve been though everything on that list, and much more, and still having an issue. My hosting company is trying to help but we’re no closer.
One thing I have discovered is I can go to a password-protected page, enter the password, and when it asks for the password again I edit the url to http:// (instead of https://), hit enter and and it lets me right in.
I can see using Chrome that there is no cookie at the start of the process, its creates a cookie so I know it’s trying to let me in, and then when I change it to http it lets me through. (and then als switches to https like I’d expect it to.
The hosting company still says thinks its plugin related, but I have deactivated all plugins, one by one and testing in a private browser as I go, and it hasn’t fixed it.
