page reload after login

Could you let us know which caching plugin you’re using and if your site uses any other type of caching, such as from your server or Cloudflare?

Hi have the following 4 plugins active. They are:

• Jetpack
• MailPoet 3
• OptinMonster
• WPForms Lite

Also – your question made me look to see what was creating the wp-content/endurance-page-cache directory – and that lead me to the “Must-use” plugins, where I have the “Endurance Page Cache” plugin Enabled. I used the “purge cache” option (which deleted the wp-content/endurance-page-cache directory), disabled that plug in, and repeated the test. I still see the same behavour – after login – I need to reload the page to see that I have logged on – after loggof – the page is upated to reflect that I am logged off.

For Jetpack, I have enabled “Enable site accelerator”, and its sub-toption “Speed up image load times”. I have not enabled “Speed up static file load times”.

As far as I know, the other plugins do not do any caching. As far as I know,

Hmmm, there is still something doing caching. I used Chrome Developer Tools to monitor the traffic

• When I go the blog URL, the HTTP status returned is “200 (from disk cache)”
• When I press the reload button, which causes “cache-control: max-age=0” to be included on the request, the HTTP status returned is just “200
• When I login, the status code when I am sent back to the blog page is “302 (from disk cache)” – and the request headers do not specify “cache-control: max-age=0”
• When I again press reload, the next request does specify “cache-control: max-age=0” and the response is “200” – no “reason phrase” – so not from disk cache
• When I select logout, I see the traffic for “wp-login.php?action=logout,&redirect_to=myurl/&_wpnonce=526d5eb935”, followed by the GET for the BLOG page – the request header DOES NOT specify “cache-control” and the response is “200” – I am not sure why it is not a 302 – since it is a redirect – and I am not sure why is does not do a “(from disk cache)”

I will keep looking – and would really appreciate any ideas.

Twomore things:

• My service provider uses the cPanel interface. I found that there was a “Website Caching” option I could control. I cleared the cache, and disabled caching. I still get the “200 (from disk cache)” response to my itital request for the blog page
• I ran this grep against my home directory /grep -r “from disk cache”/ – and did not find the string

Hi @sandyalexc, you’ve tried a bunch of things already, which is great.

What I would try next is to switch off all your plugins temporarily to see what happens then. This way you can eliminate any plugins causing this behaviour.

Also, I would temporarily switch to a default WordPress theme, just to make sure this is not theme related (although I don’t think it is).

Caching can be tricky. It’s great for speeding up your site, but can cause ‘weird’ things too.

The 302 status code you mentioned in your initial post means ‘redirect’; so it doesn’t mean anything is loaded from cache (just wanted to clarify that).
And the 200 status codes that follow mean ‘ok’; found the resource.

I’ve ran the same sequence with the same discussion settings you have on a test-site and after logging in the following happens:

1. A 302 redirect back to the original post I wanted to comment on (no cache)
2. A 200 load of the document (the post), indicating it was found (no cache)
3. A set of stylesheets, fonts, scripts and images, all loading with a status of 200 (so found), and all loaded from memory cache or disk cache. These cache files come from my local browser or computer, so they are not loaded fresh from the server. The time to load for all of them is almost instant (0 to 2 ms).
4. A single file loads with a 304 status code (my gravatar image), which means the browser checked if there was a newer version of that file on the server, and received the answer back that there isn’t.

My test-page showed me immediately that I was logged in, and I was able to comment right away without having to reload the page in any way.

I’m just sharing this to indicate that this is the way it should work, and that your case in indeed not how it would normally work.

More things to try:

Could you try this in a different browser and in a private/incognito browser window?

Could you re-save your permalinks and try again?

I’m also wondering if this might have anything to do with your browser’s cookie settings. I’ve seen similar behaviour on the main WordPress login page, where you login, but then get presented with the login page again (with a message that you need to allow cookies in the browser). When you then refresh the page without filling in the login credentials again, you go to the dashboard. Does that happen on your site by any chance?

Finally, there could be a something in your .htaccess file causing this. Could you try deleting what’s in your .htaccess file now and replace it with the default code WordPress normally has in there, which is:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

I hope this helps and look forward to hearing how it goes.

Good luck!

• This reply was modified 2 years, 6 months ago by Dave.

Hello Dave (@dvaer ), thanks very much for your help – some answers to your questions below – and guess what – I have made some progress in understanding this issue!

• Yes, if I need to, I will try turning off all plugins.
• Yes, good idea. What wordpress themes are considered default? I am currently using PressBook. I did experiment with Twenty Twenty-Two – but it was confusing me, so stayed with Pressbook.
• Yes, thanks, I realized after I submited the origional post that I had experienced a “brain fart” and stated that wrong – 302 is a temp redirect – the response I am seeing is “302 (from disk cache)”
• Thanks very much for sharing what it should like like! Hmmm, I guess the good news is that is must be something specific I have set, but, I wonder what.
• Yes – I primarly use Google Chrome – but I have tried this sequence with Microsoft Edge – and I had the exact same result. I may try incognitio mode
• Not sure how to “re-save permalinks”. I went to the test blog post, changed the permalink, did an update, changed it back, and did an update. Is that what you meant? It did not seem to have any effect
• Cookie settings are default in both broswsers
• My .htaccess does contain some interesting stuff. BUT – it all seems to make sense. For instance – a group of ExpiresByType statements within a “<IfModule mod_expires.c>” block. I note that it does appear that ‘ExpiresByType text/html “access plus 2 hours”‘ is in effect – and that makes sense to me. I will see if I can find more info about the Apache config at my service provider if I need to.

Okay – NEXT – here is what I discovered this morning:

• Open a Chrome tab, start Developer Tools, as well as selecting “Preserve Logs”, select “Disable Cache”
• BINGO – when I logon – the blog page is correct – I can reply – I do not need to hit reload

Summary

• This is a browser cache issue.
• For some reason, the redirect following a login can be satisfied by the browser cache (if browser cache is enabled – which it should be).
• BUT – following a logoff – something about the request format requires the request to be sent to the server

My Next steps are to carfully look at the differences between the two requests to see if I can isolate the key differences, and to have a good look at RFC9111 to see if it has any hints.

I will keep this entry updated.

Okay, I have a work-around. I do not think this is an ideal fix, more on that in a minute.

My .htaccess “out-of-the-box” contained the following

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresByType image/jpg "access plus 24 hours"
	ExpiresByType image/jpeg "access plus 24 hours"
	ExpiresByType image/gif "access plus 24 hours"
	ExpiresByType image/png "access plus 24 hours"
	ExpiresByType text/css "access plus 24 hours"
	ExpiresByType application/pdf "access plus 1 week"
	ExpiresByType text/javascript "access plus 24 hours"
	ExpiresByType text/html "access plus 2 Hours"
	ExpiresByType image/x-icon "access plus 1 year"
	ExpiresDefault "access plus 24 hours"
</IfModule>

I changed the ExpiresbyType for text/html as follows
ExpiresByType text/html "access plus 0 seconds"

This worked. BUT – I do not think it is ideal – since in means that no “text/html” browse cache will be used.

I think an ideal solution would be to allow text/html to cache – and the default of 2 hours makes sense to me. Then, following a logon, send a request formatted so that it cannot be satisfied by cache – so that the reformatted page is returned from the server.

Any idea how to do that?