Hi Ehsan,
The “Login required” box on the messages page is the standard WordPress login form — Better Messages doesn’t handle the session itself, it just shows WordPress’s own login. So when you log in and then end up logged out again, the WordPress login cookie isn’t being kept between requests. That’s almost always caused by the hosting/site setup rather than the plugin. A couple of things to check:
- Quick test to confirm: Log in directly at yoursite.com/wp-login.php (not through the chat page), then open a few pages of your site. If you don’t stay logged in there either, the issue is site-wide and not Better Messages.
- Page caching. This is the most common cause on shared hosting. If your host has caching (LiteSpeed, Varnish, NGINX cache) or you have a cache plugin, it may be serving the cached “logged-out” version of the messages page. Please exclude the Messages page from caching, make sure caching is disabled for logged-in users, and purge the cache, then try again.
- Site URL mismatch. In Settings → General, check that WordPress Address (URL) and Site Address (URL) match and that you always visit the site on the same one (both www or both non-www, and both https). A mismatch makes the browser drop the login cookie.
- Security plugins / host firewall. Anything that protects or renames wp-login.php (or a host-level mod_security rule) can break the login POST.
As an alternative, you can also go to Better Messages → Settings → General and enable “Redirect Guests to Login” — this sends visitors to your normal WordPress login page instead of showing the embedded form, which sidesteps caching of the messages page.
Could you let me know your hosting provider, whether any caching or security is active, and the result of the /wp-login.php test above? That’ll pin it down quickly.
Thanks!
I logged in directly from site.com/wp-login.php and stay login and see the chat page.
I don’t install any cache plugins but the shared host has litespeed.
WordPress Address (URL) and Site Address (URL) match and that I always visit the site on the same one.
I don’t have any security plugins but I change wordpress admin url from wp-admin to my own url. I change it from functions.php file.
Thanks, that’s exactly what was needed — it points right at the cause.
The key detail is that you changed your WordPress admin/login URL with a snippet in functions.php. Better Messages’ “Login required” box is the standard WordPress login form, and like WordPress’s own login form, it submits to wp-login.php. Your snippet is almost certainly intercepting requests to wp-login.php and redirecting them to the homepage — so when you submit the login form on the chat page, the request is bounced home before WordPress can log you in. That’s the “redirects to the homepage, still logged out” behavior. Direct login works because there you use your new custom login URL, which the snippet allows through.
Could you paste the exact snippet you added to functions.php here, so we can analyze it? Once we see it, we can tell you precisely what to change (usually it’s a matter of letting POST submissions to wp-login.php through, while still redirecting normal visits) so the login box works without giving up your custom URL.
Quick way to confirm in the meantime: temporarily remove that snippet, open the chat page in a private/incognito window, and log in through the box. If it works, the snippet is the cause.
This is my problem because of changing the WordPress login URL.
I removed the code from the functions.php and the problem was solved.
Then I tried another solution, which was to create a PHP file in wp-content/mu-plugins and put the following code in it, but the same redirect problem still occurred:
<?php
add_action('login_init', 'custom_login_url_protect');
function custom_login_url_protect() {
$secret_key = 'MY-CUSTOM-URL';
if (isset($_GET['action']) && $_GET['action'] === 'logout') {
return;
}
$allowed_actions = ['lostpassword', 'rp', 'resetpass', 'register', 'postpass'];
if (isset($_GET['action']) && in_array($_GET['action'], $allowed_actions, true)) {
return;
}
$is_valid_url = isset($_GET[$secret_key]);
$is_valid_post = isset($_POST['secret_login_field']) && $_POST['secret_login_field'] === '1';
if (!$is_valid_url && !$is_valid_post) {
wp_redirect(home_url());
exit;
}
}
add_action('login_form', 'add_secret_field_to_login');
function add_secret_field_to_login() {
echo '<input type="hidden" name="secret_login_field" value="1" />';
}
Glad it’s solved, and thanks for confirming — that’s exactly what was happening. Your protection code hooks login_init and redirects any request to wp-login.php that doesn’t carry your secret_login_field value (or the GET secret key) to the homepage. The Better Messages login box — like WordPress’s own wp_login_form() — posts to wp-login.php without that field, so it was redirected home before the login could complete.
You don’t have to leave your protection off, though. You can keep it and just make WordPress’s login form include your secret field. Add this next to your protection snippet:
add_filter( 'login_form_bottom', function( $content ) {
return $content . '<input type="hidden" name="secret_login_field" value="1" />';
} );
That injects secret_login_field into every wp_login_form() output, including the Better Messages login box, so your check will let those submissions through just like your own login page does. After adding it, you can restore your login-URL protection code and the chat-page login form will keep working.
Glad it’s working now — let me know if anything else comes up!
