I’m working on a WordPress site with password protected pages and I’m trying to show an error message when someone enters the wrong password. The problem is that my custom error message won’t display at all.
I think there might be an issue with how I’m checking the cookies or maybe the HTTP referer logic, but I can’t figure out what’s wrong. I added this code to my functions.php file but the error message never shows up when users type in the wrong password.
Can someone help me spot the mistake in my code? Here’s what I have:
WordPress password protection is a nightmare to customize, especially if you want decent error handling. The problem? WordPress handles everything internally and doesn’t give you clean hooks for failed attempts.
Don’t waste time fighting PHP cookies and HTTP referers. Just automate the whole thing differently. Build a workflow that grabs form submissions, validates passwords through your own system, and handles error messages properly.
I’ve done this before - the automation tool grabs the password form, checks it against a database or API, then either lets them in or shows a real error message. You get complete control without wrestling WordPress internals.
Bonus: you can add attempt limits, logging, or dynamic password generation. Way cleaner than hacking WordPress core.
Latenode handles all the form processing and conditional logic for this kind of workflow. You can build the entire password system as a custom workflow.
WordPress checks your error during form generation, but it hasn’t processed the password submission yet. The authentication happens after your function runs.
I hit this same issue on a membership site. Here’s what worked: hook into wp_login_failed to set a transient when passwords fail, then check for that transient in your form function. Use set_transient('password_error_' . $post->ID, true, 60) on failure, then get_transient() in your display function.
Or you can intercept the form submission earlier - hook into init and manually process the $_POST['post_password'] data before WordPress does. This gives you full control over authentication and lets you set error flags properly.
WordPress redirects after password form submissions, which makes catching errors a pain. The problem is timing - your error check happens before WordPress actually processes the password, so you’re checking the wrong thing.
Better to hook into wp_authenticate or use wp_loaded to catch failed attempts. Set a transient or session variable when auth fails, then check for it in your form function. I’ve had good luck storing a temp flag in the database when password verification bombs, then showing the error on the next page load.
Or just use JavaScript to handle error display client-side after submission. Gives you way more control without wrestling WordPress’s redirect mess.
Your cookie logic is backwards. When a password fails, WordPress doesn’t set any cookie - so !isset($_COOKIE['wp-postpass_' . COOKIEHASH]) returns true even for first-time visitors. I ran into this same issue on a client site last year.
Check if the request came from a password submission instead: isset($_POST['post_password']) && empty($_COOKIE['wp-postpass_' . COOKIEHASH]). This only shows the error when someone actually submitted a password but the cookie still isn’t there.
Also, $_SERVER["HTTP_REFERER"] can return empty values depending on browser settings, which breaks your comparison. The POST method is way more reliable for catching failed attempts.
your error message is showing up after the form instead of before it. move the error div above the form tag. also, $_SERVER[“HTTP_REFERER”] can be null or spoofed, so you need to validate it properly. try using a $_GET parameter to check for failed attempts instead.
the problem is you’re checking for HTTP_REFERER, but wordpress doesn’t always set that reliably. try using isset($_POST['post_password']) instead to catch wrong password submissions. also, the cookie check might not work immediately after a failed attempt.
WordPress password forms are a pain - they redirect after every submission, so error handling becomes a nightmare. Your code’s checking for errors too early, before WordPress even processes the password.
Don’t fight WordPress internals with cookies and referers. Just automate the whole thing outside WordPress. Build a workflow that grabs the form data, validates against your password rules, then either lets them in or shows proper errors.
I did this for a client portal last month. The automation catches submissions, runs whatever password validation you need, then shows clean errors or redirects to the protected stuff. No more cookie timing issues or referer headaches.
You can add attempt limiting, custom error messages per page, or dynamic password generation. Plus you get proper logging of failed attempts.
Latenode makes this easy - just create a workflow that handles form processing and password validation with proper error states.