Not a bug Just updated to latest version of 2.2.10, users are now complaining about having to refresh in order for link to show as read

Oersted

Member
Affected version
2.2.10 Patch 1
We just updated to the latest version of 2.2.10 from 2.2.8, and we have gotten hit with a bunch of complaints from users saying that after reading a thread, the unread thread hyperlink isn't clearing/showing to be "read" (unbolded) when returning to the thread list. They have to physically refresh the browser in order to make those clear. Same goes for a "sticky" alerts notification, which will still show red with an alert number even after having viewed the alert. Again, that clears upon a forced refresh of the page. Historically, these cleared even if one just used the back button on my browser.

Has there perhaps been some change in how pages are cached? Is there a way to adjust this behavior?
 
So to be clear, I see that it is also doing this here on xenforo.com/community. So I am curious as to whether this is how it was meant to work or not. Our users certainly are not happy about the change.
 
we have gotten hit with a bunch of complaints from users saying that after reading a thread, the unread thread hyperlink isn't clearing/showing to be "read" (unbolded) when returning to the thread list.
Isn’t that the way all web pages work? Using the browser back button goes back to the page, so it is as it was before you clicked on the link
 
I had another thought about this.

So you see the new posts list, and then you click on an unread (bolded) link and read the thread or latest posts in that thread.

You then go back to the list, surely you must be able to remember that you read that thread a few seconds ago. I don’t see a problem.
 
Last edited:
There have been no changes in this area between those versions and to the best of my knowledge, echoing @jeb35, the behaviour has always been like that.
 
Use the back button... get the old data... use the link to go back to the base location, get a refresh. Been that way since I started using XF in 2012.
 
OK, I understand this was not a bug, but that is how it worked on our site, until we updated the site. I even then disabled addons on a test site to see if one of them was causing this, but they were not. So strange.
 
I am quite disappointed by the response we have gotten on this issue, especially as @twollert has confirmed that they also had this issue on this site, which further confirms for me that this is not due to some 3rd party plugin or customization on our end. We have a ton of users continuing to complain about this change, and I am not even sure what to tell them.
 
I am quite disappointed by the response we have gotten on this issue
What do you expect when you post a bug report and there is no issue with XF? 🤔

Apparently there was an auto-refresh when using the "Back button" on your forum. Maybe this has something to do with some kind of no-cache header, that had been sent by your server? Or changes on your local system (as you say the behavior changed here on XF.com for you as well)? 🤷‍♂️
 
Sorry, going to agree say that this isn't a new thing isn't an issue with XF. It's going to depend on your personal configuration and/or changes to any of the browsers that people use. Typically, using the back button just pulls the old page back from the local cache and doesn't force a refresh from the server. There are some configurations that don't work this way, those usually have a warning 'don't use your browsers back button etc.'

The read markers in XF won't reflect until the browser requests a new page from the server.
 
(as you say the behavior changed here on XF.com for you as well)?
I don't know if the behavior changed on XF.com for me. What I meant was that I realized that the way it works now on our site, is the way it works on XF.com now. I didn't test this on XF.com on earlier versions of XF.

Sorry, going to agree say that this isn't a new thing isn't an issue with XF. It's going to depend on your personal configuration and/or changes to any of the browsers that people use. Typically, using the back button just pulls the old page back from the local cache and doesn't force a refresh from the server. There are some configurations that don't work this way, those usually have a warning 'don't use your browsers back button etc.'

The read markers in XF won't reflect until the browser requests a new page from the server.
OK, the point here is that a hundred or so users are now complaining on our site, right after the update. All we did was update our site, and now the behavior changes. So it doesn't really make any sense to blame this on personal and browser configuration, when the only variable that we are aware of was the update.

I am simply trying to understand why this happened, not trying to say there is something wrong with XF. If it was due to an issue on our end, then fine, but I haven't found any evidence to suggest that.
 
OK, the point here is that a hundred or so users are now complaining on our site, right after the update.
I see, then referring to my previous post:
Maybe this has something to do with some kind of no-cache header, that had been sent by your server?
Did you change server configuration in any way?

You can try placing this in your .htaccess file in the XF root folder:

Code:
<IfModule mod_headers.c>
    Header set Cache-Control "no-cache"
</IfModule>

That's just for testing. I would not recommend this, but it should bring back the old behavior, as this does completely deactivate caching on the browser-side (including images, font awesome and so on).
 
I just had 2 new complaints that are similar today on our site. Saying new post to thread not making it bold to show new unread replies.
 
Top Bottom