[mica123]

I am so sorry – I thought I sorted out all problems associated with the installation of bbpress.
Alas, I’ve just come across a very strange issue: I logged in as one of the users with moderator role. The login was fine, it redirected me to the forum after login. Then I looked at one of the forums – still logged in. Then I looked at one of the topics to which I had replied before as the very same user but now there is a message saying: You must be logged in to reply to this topic. And I find to my surprise that I am not logged in.
This is extremely frustrating. I do hope I’ll ge help with this as well.
Thank you.

[Robkk]

Post the possible issue that you are getting from your host, so I can try to help other users that may come across something similar.

[Pascal Casier]

Hi mica123,
Keep us aligned if your provider comes up with a solution. I have received your email and tomorrow evening I should have some time to check.
Pascal.

[mica123]

I can only hope my host will come back with something. So far they didn’t actually say that there is an issue, they are just replicating the issue to see what i am talking about.
I’ll let you know.

[Robkk]

@mica123

You need to start seeing if other parts of your site is being cached and it is not just the bbPress portions, if it the bbPress portions make sure to see if it is just you must be logged in notice or other areas like the user’s profile pages to see if it is related to @gperez-tl’s issue.

You may need to create me a test user account so that I can confirm of the issue you are getting, and to also test other areas the cache issue might be present.

[mica123]

@robkk

I did more network testing on my bad site via the web developer.
All other pages display the following:
Response header:
main site url:
Cache Control: max-age=3600
bbpress:
Cache-control:max-age=2592000

Request headers:
main site url:
Cache-control: max-age=0
bbpress:
Cache-control:max-age=0

After login:

After login:
wp.login:
Cache-control:no-cache, must-revalidate, max-age=0

Without refreshing the page
bbpress:
Cache-control: max-age=2592000 –

On refreshing the page
bbpress:
max-age=2592000

The information for bbpress does not change at all.

This is different from the results gleaned from my good site as I reported earlier:
bbpress
cache control: max-age=2592000, public, proxy-revalidate, public, proxy-revalidate, must-revalidate
Cache control: max-age=0

After login:
Response header:
Cache control: no-cache, must-revalidate, max-age=0

So would this indicate that all is not well on my webhost provider’s server
regarding cache even if they say that it is not enabled?

[Pascal Casier]

Hi mica123,
I logged-in, played around and got indeed the same effect like you described.
I check your installation configuration and it seems all normal.

Can you confirm that when you tested it on the other provider, you had the same theme (responsive) installed there ? And the same options set ? Because I see in some javascript that the theme is talking about ‘applicationcache’.

Please delete the test topics/replies and the login you created for me.

Pascal.

[mica123]

Yes, I copied everything – www folder plus database to the other provider and used the same theme responsive. Not sure what you mean options? I just used everything that was copied over, so the same options must have been set. I’ll delete the test topics and the login.
My provider doesn’t understand what I am talking about, so I am having a hard time to convince them that there is something wrong – so far I have not succeeded because they keep saying that they can create topics in some forums and some they can’t. I keep explaining to them that it depends on which page they saw before logging in. I am really desperate.
What would be the meaning of ‘applicationcache’?
Also, everything is normal on my local computer in xampp – I use exactly the same what I have on the live site.

[Pascal Casier]

So they were the same…

The only option I see is to really insist with your current provider, sorry for not being able of more help.
For the application caching, a lot of pages exist, like http://www.sitepoint.com/common-pitfalls-avoid-using-html5-application-cache/

BEFORE DOING THE NEXT LINES, MAKE SURE YOU HAVE DIRECT ACCESS TO YOUR FILES ON THE SERVER IN CASE IT GOES WRONG.
Just a test to see if it helps, can you go in your dashboard, ‘Appearance > Editor’, choose on the right the ‘Header’ (header.php) file and when the file opens, find somewhere the <head> tag and copy the following lines just below :

<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />	

If it helps, it could be a workaround for now, but you should not keep this forever.

Keep subscription to this topic. If I find something else, I’ll post it here, but for now I have no clue.

Pascal.

[mica123]

Thank you. I will not do the header.php changes for now – I’ll try to battle it out with the provider – at least to get them to see what I mean.
The only other thing I would like to check is that in my functions.php I have the following
for the customised wp-login:

`function my_login_stylesheet() {
wp_enqueue_style( ‘custom-login’, get_stylesheet_directory_uri() . ‘/css/style-login.css’ );
wp_enqueue_script( ‘custom-login’, get_stylesheet_directory_uri() . ‘/css/style-login.js’ );
}
add_action( ‘login_enqueue_scripts’, ‘my_login_stylesheet’ );

Do I have to load style-login.js – if not, should I delete that part:
wp_enqueue_script( ‘custom-login’, get_stylesheet_directory_uri() . ‘/css/style-login.js’ );

[Robkk]

@mica123

When you said you got this.

bbpress
Response headers:
cache control: max-age=2592000

I think you just selected something similar to this in your dev tools.

bbpress.css?ver=2.5.8-5815

This is a CSS file, and the cache information you are outputting is just the browser cache information for that CSS file.

Usually you might find this in your htaccess file for code for browser caching, and this exactly for some CSS files.

ExpiresByType text/css A2592000

In the list of names of files being requested, you can try to pick another CSS file like

responsive.css?ver=1.9.7.7

And you should see the caching age be the same thing since it is a CSS file.

Most of the time the browser caching code would be present in your htaccess file wrapped in something like this.

<IfModule mod_expires.c>

But there could also be WordPress plugins that add browser caching like some minify plugins.

You and your dev have to backtrack and find out where and what is causing the browser caching. It is tough for me to find it on my end without a bunch of guessing, but if you want me to try to take a look at it, you can contact me through email here. https://robkkdev.wordpress.com/contact/

Also that custom login script would not cause this type of issue.

Also you can delete this piece of code since you are probably not using it correctly.

wp_enqueue_script( ‘custom-login’, get_stylesheet_directory_uri() . ‘/css/style-login.js’ );

[mica123]

I’ve just emailed you. I won’t be removing the line with the style-login.js – the script works flawlessly. I was only grasping at straws.

[mica123]

This issue is now finally resolved. After a long battle, the web host came back to me to ask me to put the following code into .htaccess:

FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"

They said the following: This should prevent my website from being cached by Apache and may help to solve this issue. The website is not currently sitting behind their caching
server so this cannot be the cause of the issue but Apache itself can cache
sites so perhaps this will help to resolve the issue.

This may help others having similar problems.
Last but not least, my heartfelt thanks to @robkk and @casiepa for their steadfast support without which I would have coped very badly. @robkk tirelessly tested every possible issue under the sun. Huge thanks again to both of them. All in all, everything pointed to a caching problem on the server side.