Account page links randomly redirect the user to be signed out [Bluehost]

General HivePress
1

Describe the issue in as much detail as possible. Please remove the sections below if the issue is obvious enough and doesn’t require extra details.

Steps to reproduce

Create an account, confirm email and sign in. Go book a listing, pay for the listing. Click on your name to go to your dashboard/bookings page, click “Orders”, click “Settings”, sometimes it signs you out here, sometimes you have to click Orders, Bookings, Settings, Orders, and you’ll be signed out on your next click of Bookings. It’s inconsistent but only happens on the account pages.

Example redirect link: https://example.com/account/login/?redirect=https%3A%2F%2Fexample.com%2Faccount%2Fsettings%2F

(Swapped my domain name for example.com for privacy, the site has not launched)

Actual result

User is forcefully signed out.

Expected result

User should never be signed out unless they choose to be.

Extra details

I have tried rolling back 95% of customizations I have done to my site. I built most modifications in a child theme, and I have disabled that child theme and gone back to the parent theme. I turned off the 3 code snippets I have and uninstalled most plugins. I can’t figure out what is causing this.

WordPress version 6.9.4

I had built some custom redirecting logic in the functions.php of my child theme, but that is all disabled now since I am using the parent theme. I even deleted my staging site because I thought there might be some session key conflicts since BlueHost builds the staging site in the same files as the parent site directory.

Anyone experienced this before or have any pointers?

2

Hi @travisdee95,

It sounds like there might be a caching issue.

  • Can you confirm if you’re using a caching plugin?
  • Have you disabled caching for logged-in users?

The following documentation explains how to optimally set-up the official caching plugin recommended by HivePress, LiteSpeed.

(Disabling cache for logged in users is one of the mentioned recommendations.)

I hope this helps!

Cheers,
Chris :victory_hand:

1 Like
3

Chris!

Edit: I realized I didn’t answer your questions.

No I am not using a caching plugin, just allowing BlueHost to handle it. I clear the cache on that end regularly and even turn it completely off in my WP Admin >BlueHost >Performance.

I haven’t disabled caching specifically like that, only globally as described above.

Thank you so much for the suggestion. I assumed it was a caching issue too, but I have cleared my host cache so many times, used incognito mode, different devices, cleared browser caches etc, and the issue persists. I’ll definitely follow the guide for the plugin.

If I use the plugin, do you know if that takes over caching from BlueHost?

4

Hi @travisdee95,

I don’t use BlueHost myself, but I’d recommend at least disabling it temporarily, if you do choose to try out the LiteSpeed plugin, so as the two aren’t competing against each other.

If you don’t have a specific option to disable cache for logged-in users in your hosting settings, you can also try this code snippet to disable caching for logged in users.

I hope this helps!

Cheers,
Chris :victory_hand:

5

I’m contemplating moving off BlueHost because of this. I couldn’t complete all the settings from the link you sent (mainly Object Caching) because I think they are conflicting. Even if I disable BlueHosts managed caching I still can’t Enable it. It won’t even let me enable the BlueHost object caching. With everything I could enable (disable caching for logged in users being one of them that it did successfully do) I got the redirect sign out still.

8

Hi,

I hope you had a relaxing weekend.

It seems that the topic is resolved, but I wanted to add that this most likely looks like a caching issue, since we haven’t received any other complaints about this behavior and it is part of the core functionality of HivePress.

It is possible that the caching solution (especially server-side or hosting-level cache) is not correctly detecting the logged-in user state via REST API responses. In such cases, logged-in and logged-out versions of pages can get mixed or cached incorrectly.

If needed, there may also be a way to programmatically clear or bypass cache on user login via a hook, but this depends on the caching system used by your host. In some cases, switching off page caching for logged-in users or excluding authenticated requests from cache resolves the issue immediately.

Alternatively, testing on a different hosting environment (or temporarily disabling server cache) can help confirm this is the root cause.

9

kseniia

Thank you for your reply. We just renewed our hosting with BlueHost so I am going to try sticking it out. I opened a ticket with them and they have escalated it to their tech team. Specifically regarding the fact that I can’t enable object caching and the sign out redirect issue. If they can’t resolve it, I might just have to eat the cost and move to Hostinger so I can use Litespeed. Everything points to caching issues. I have disabled caching by BlueHost completely and the issue persists but I don’t know if it’s just holding on to a cached version of the pages or not. It seems like no matter how “disabled” I set their caching, something still behaves as if it’s cached.

10

Thanks for the details.

Please keep us updated.

11

kseniia,

BlueHost support was able to enable Object Caching on my site, but unfortunately the redirect sign-out issue is still persisting. Do you guys have any documentation/guidance on how to properly configure caching for BlueHost environments? They don’t give me much control over it on my end as it’s “Managed Caching”. You guys list them as a recommended host so I was hoping you guys had something as far as a caching configuration guide like you do for LiteSpeed. Overview of the Best WordPress Hosting Providers | HivePress

Thanks!

13

If possible, please reach out to their support to clarify if there is any code snippet to programatically flush the cache they’re using, AI provided a few options but I’m not sure which one applies to your current server / hosting plan:

do_action('flush_cache');
do_action('wp_cache_clear_cache');
endurance_page_cache_purge_all();

If they provide a code to flush cache for the current user (or page), we can provide a code snippet that will flush cache on user login action.

14

ihor I will do that and update you.

I was troubleshooting with Gemini last night and it had me run through some Developer Tool testing in the browser and thought it had it figured out but the changes it had me make to my .PHP code didn’t help (I figured it wasn’t the issue since disabling my code entirely, the issue persists.)

I was wondering if this still sounds like a caching issue to you guys or something else. Please just let me know if I am getting outside the scope of this forum, I completely understand if so.

Here is what it had me check and what was found:

In your first and third screenshots, look at the x-redirect-by: WordPress header, along with cache-control: no-cache. This means Bluehost’s edge cache is not interfering. The request is successfully reaching your server, and WordPress itself is making the conscious decision to kick you out.

In your second screenshot (the Application tab), the wordpress_logged_in_[hash] cookie is completely missing. You have the WooCommerce session cookie (wp_woocommerce_session_...), but the core WordPress login cookie is gone.

If that cookie isn’t there, your browser legitimately does not have the “security badge” to access /account/settings/. When WordPress sees you trying to access a protected HivePress page without that cookie, it naturally issues a 302 redirect to the login page (which we see in the network tab).

Since we know WordPress is actively doing this, it narrows our suspects down to three things:

Suspect A: The Custom “Bouncer” Code We know from your previous notebook entries that you have custom “Bouncer/Vetting Guard” PHP code in your functions.php to redirect certain user roles. If that code has a misconfigured strictness check, it might be calling wp_logout() or destroying the session inadvertently when you hit specific HivePress endpoints.

Suspect B: The Login Handshake Never Finished Sometimes, in an Incognito window, strict browser privacy settings will block cookies if there is a domain mismatch. For example, if you log in at www.example.com but the HivePress settings link tries to send you to example.com (without the www), the browser drops the cookie for security reasons.

Suspect C: WooCommerce / HivePress Session Collision You have the WooCommerce session cookie, but not the WordPress one. Sometimes, checking out or interacting with a WooCommerce cart block can regenerate a session in a way that clobbers the main WordPress authentication token if they aren’t synced properly in your server’s memory.

We need to figure out if the cookie is never being created, or if it’s being murdered when you click a link.

  1. Keep your F12 Application tab open to that Cookies list.

  2. Log in to the site.

  3. STOP. Do not click anything else yet.

  4. Look at the Application tab. Does the wordpress_logged_in_[hash] cookie appear in the list immediately after you log in?

My response after testing:

Yes the cookie showed up in both the login/? redirect page and the settings page under Network > Cookies

Image 3
Image 3909×725 129 KB

Gemini:

This is a massive breakthrough!

If the wordpress_logged_in_[hash] cookie is showing up in the Network tab for those requests, it means your browser is completely innocent. It has the security badge, and it is actively handing it to the server.

The reality is that WordPress is receiving your valid cookie, looking at it, deciding it is invalid, and deliberately rejecting it (which triggers the 302 redirect back to the login page).

17

Thanks for the details, we’ll test this in more detail on our side.

One possible explanation is that the hosting cache may be interfering specifically with the login process performed via the REST API. In some environments, aggressive caching or security layers can prevent the login cookie from being properly set after the REST API request is completed.

If that happens, the authentication request itself may succeed, but the browser never receives or stores the login cookie, making it appear as if the user is not logged in.

1 Like
18

kseniia,

Thank you! I’ll verify with BlueHost. So I should make sure that user caching is disabled for logged in users, and the REST API calls are not cached. I’ll update you when I find out.

Thank you!

1 Like
19

Good morning. I spoke with BlueHost. They confirmed that they do not handle disabling caching of logged in users or REST API requests, but that a 3rd party plugin running along side their caching would not cause issues. They tell me they designed it to work alongside plugins :person_shrugging: .

I enabled LiteSpeed Caching and followed the guide posted by ChrisB in the first comment of this thread. I thought it was the fix, because I could navigate around quite a bit on my site, in and out of user profile pages without issue. But this morning I noticed I do still end up getting the sign-in redirect. :sad_but_relieved_face:

I noticed too that it behaves differently if I am in a user page and then navigate to a non-user page and the break happens (like a property category, or the home page), it just looks like I was never signed in to begin with. No indication that I was signed out, just a fresh page as if I was a guest.

Should I try other plugins? Or stick with the LiteSpeed configuration suggested on the HivePress article?

20

Hi,

I am the king of having issues with caching :slight_smile: You can look through this thread Logged in users not shown as logged in [LiteSpeed Cache/CDN Issue (Hostinger)] - #7 by Escape and see if something is helpful. I use Hostinger, and you use Bluehost, but your issue sound similar.

In short, my users would log in and appear logged out on every page they were before when logged out. So the hosting provider was caching those “logged out” pages, no matter what I tried, and I tried everything. It seems the issue lies with CDN at hosting level.

On Hostinger you can set it to Development mode, which is almost the same as OFF, and then the issues dissapear. Try to find something like that on Bluehost. If there is only the option to turn CDN OFF, then try that and check. Obviously there will be a penalty if your site has loads of users, but until CDNs stop fighting Hivpress REST APIs, I don’t know the solution.

NOTE: in my case, users were not really logged out, they simply saw the logged out version of the page they were on. If they would refresh the page, they would mostly show logged in again.

Hope this helps. It can be very frustrating!

2 Likes
21

Thank you! I’ll look into it! I was having that issue before, they looked signed out until refresh and magically they would be signed in again, but that’s not the case anymore. A refresh doesn’t log you back in. If it happens on a user account page they are actually sent to the sign in page since they are accessing an account page and the site thinks they aren’t signed in. When it happens on a non-account page, a refresh does nothing, they stay signed out :pensive_face:

Edit after reading the linked thread

“I assume the issue occurs because we implement logging in via REST API (instead of legacy WP AJAX API), so the login cookie is set via REST API, but the cached website front-end is not “aware” of this. LiteSpeed seems to detect this without issues, but various hosting-side caching solutions may not.”

So it is a HivePress issue assumedly? If hosting providers are all starting to offer server-side caching that is causing this issue, is a patch to HivePress in the works to combat this? I’ve literally considered scrapping my entire site and starting over without HivePress because of this. I simply can’t go live with a website that sporadically kicks users out. If there is speculation as to what this is I feel like this should be addressed?

I’ll look into my BlueHost caching settings to see if I can disable or weaken CDN but I don’t think I even have that option.

Edit 2: BlueHost does have CDN via Cloudflare but I have it off already and it says “Cloudflare is not installed”

23

Thanks for the details.

We believe that this is a hosting-side issue since they shouldn’t continue serving cached HTML pages after the user is logged in. We use core WordPress functions to log users in, like wp_set_auth_cookie(), and we also run the wp_login action to ensure compatibility with third-party plugins and caching solutions.

Any third-party cache solutions should use the wp_login action to flush cache, but it seems that the hosting provider caches the website front-end and REST API separately.

At the same time, we understand that these hosting providers are pretty popular and may offer an alternative in future updates, for example a legacy login form using AJAX instead of REST API.

If it’s urgent, we can only provide a code snippet to flush cache on login, but in this case we need to know the code used by the hosting provider to flush their hosting-specific cache. Another option is moving your website to another hosting provider with more control over caching (then you can use LiteSpeed or any other caching plugin of your choice and fully control its settings), for example we can recommend Cloudways.

24

So they get you to interact with their AI before getting to a person, and this is what it told me:

I will attempt to contact them again tonight. I don’t get much time to sit in queues and wait for an agent :slight_smile: . I plan to uninstall LiteSpeed and implement the code snippets the AI recommended, and see if BlueHost can give me a specific snippet for clearing their Page Caching on login.

Blu AI Response:

In that case, your caching layers are primarily Bluehost’s server-side caching and WordPress object caching.

To dynamically clear cache on user login without Cloudflare, you can:

  1. Use the snippet to flush the Redis object cache on login:
add_action( 'wp_login', function( $user_login, $user ) {
    if ( function_exists( 'wp_cache_flush' ) ) {
        wp_cache_flush();
    }
}, 10, 2 );

  1. For page caching managed by Bluehost, unfortunately, there is no public API to clear it programmatically per user action.

  2. To avoid serving cached signed-out pages to logged-in users, consider disabling page caching for logged-in users in your caching settings if possible, or contact Bluehost support to explore options.

  3. Alternatively, you can set cache-control headers in your WordPress theme or plugins to prevent caching of pages for logged-in users.

If you want, we can help you with code to set those headers or guide you on disabling page caching for logged-in users.

We’re here to help you with disabling page caching for logged-in users and setting headers to control caching behavior.

Here’s how you can do both in WordPress:

  1. Disable page caching for logged-in users:

Add this code to your theme’s functions.php or a custom plugin to prevent caching for logged-in users by sending appropriate headers and stopping caching plugins from caching those pages:

function disable_cache_for_logged_in_users() {
    if ( is_user_logged_in() ) {
        // Prevent caching by sending no-cache headers
        header( 'Cache-Control: no-cache, no-store, must-revalidate', true );
        header( 'Pragma: no-cache', true );
        header( 'Expires: 0', true );
        // Disable page caching if your caching plugin respects this constant
        if ( defined( 'DONOTCACHEPAGE' ) ) {
            define( 'DONOTCACHEPAGE', true );
        } else {
            define( 'DONOTCACHEPAGE', true );
        }
    }
}
add_action( 'send_headers', 'disable_cache_for_logged_in_users' );
  1. Set cache-control headers globally or conditionally:

To set headers that instruct browsers and proxies how to cache pages, you can add or modify headers like this:

function set_custom_cache_headers() {
    if ( is_user_logged_in() ) {
        // For logged-in users, prevent caching
        header( 'Cache-Control: no-cache, no-store, must-revalidate', true );
        header( 'Pragma: no-cache', true );
        header( 'Expires: 0', true );
    } else {
        // For guests, allow caching for 5 minutes (adjust as needed)
        header( 'Cache-Control: max-age=300, public', true );
    }
}
add_action( 'send_headers', 'set_custom_cache_headers' );

Important notes:

  • Bluehost’s server-level page caching may still cache pages despite these headers in some cases. Disabling page caching for logged-in users is often handled automatically by Bluehost, but this code adds an extra layer of control.

  • Avoid using third-party caching plugins on Bluehost as they can conflict with built-in caching.

  • After adding these snippets, clear your site cache from the Bluehost Portal Performance tab to apply changes.

25

I pretty much agree with @ihor and don’t think it is a Hivepress issue, since as he says, they use mostly standard Wordpress functions, and not many other users reported problems.

I believe it is more the specific combination of standard functions that happens on Hivepress that some hosting providers are not working well with.

I tried many code snippets, many Litespeed settings, many other things, believe me, days on end. I am pretty sure it has to do with caching at hosting/CDN level.

I know the fristrating feeling, but switching from Hivepress to something else might not be a solution, since it is still the hosting provider who sets caching policies, CDN policies, etc..besides the ones you set at plugin level.

Switching hosting might be an option, since it seems only people using Hostinger or Bluehost are having issues. I do not have much traffic so I can live without the CDN for now. Later I might reconsider my Hosting.

This being said, it is only my opinion :slight_smile:

2 Likes
26

Well. I’ve successfully made it worse.

I had a must use plugin called “endurance page cache”. I deleted the file and removed references to it from my .htaccess file and now every page redirects to the sign in page.

I implemented the code I mentioned above and that did not improve anything.