I'm getting multiple reports that threads aren't opening at the first unread post, but at page 1, post 1. The new posts were posted today. Do you know of anything that could be causing this? Anything I can look out for?
Thanks.
Thanks.
Me - Firefox. But many users reporting this on many different platforms.What browser are you using?
I don't think it's any of these.What browser are you using?
Could your problem be related to these threads?
![]()
Browser issue - Clicking on new post; then as images load the focus moves up the page away from the new post
Hi all, I'm facing an issue that may just be by design. Whenever I click on the latest post it does initially take me to the last post in the thread, however images load in up the page and immediately take me to the loaded in images. Is there a way I can combat this? I'm thinking lazy load...xenforo.com
![]()
Partial fix - Navigating to posts broken when page contains Twitter media embeds
E.g. https://dvcinfo.com/forum/threads/2018-dvc-condominium-association-meeting.11979/post-81270xenforo.com
![]()
XF 2.2 - Clicking on Latest Post loads images higher up in the page and takes users there instead
Hi all, I'm facing an issue that may just be by design. Whenever I click on the latest post it does initially take me to the last post in the thread, however images load in up the page and immediately take me to the loaded in images. Is there a way I can combat this? I'm thinking lazy load...xenforo.com
Will in this case still be possible to "go to first unread"? As this happened to me, even if I was positioned at first page of very old thread (in sense, started long time ago, but had new posts recently), I could go to first unread posts.It is possible you have read the thread before, but it the last time would've been more than <that lifetime value> ago, so we no longer have the data tracked.
Read marking data lifetime is set to 30 days and the threads have had replies more recently than that. In some cases, earlier in the same day.If you go to the top of page 1, that means that we have no read marking data for you for that thread (and nothing from the forum). Thus we will take you to the first post in the thread. This is controlled by the "Read marking data lifetime" option. It is possible you have read the thread before, but it the last time would've been more than <that lifetime value> ago, so we no longer have the data tracked.
So really it's a case of in-page post anchors randomly not working? How the hell do we diagnose that problem?I'll say again - I doubt it has anything to do with Unread (unless there are several separate issues occurring).
It is also happening with the link in
Clearly "unread" is the more likely type of link that demonstrates, but I believe it's a red herring.
- an alert (eg for a "liked" post)
- the "unchecked" marker provided by our CheckPoint Add-On
The "jump to new" link shown within the thread will explicitly take you to the first post that is labeled as "new".Will in this case still be possible to "go to first unread"? As this happened to me, even if I was positioned at first page of very old thread (in sense, started long time ago, but had new posts recently), I could go to first unread posts.
It's not exactly about the date of the last reply, but the date the thread was last read by the user in question. If they visited the thread earlier in the day, someone posted a reply and they returned, it should have attempted to take them to that reply. If they haven't visited the thread in more than <read marking lifetime> days, even if there have been 20 replies in that time, it'll take them to the start of the thread by default because there's no data tracked to indicate that they've read the thread. Increasing the cutoff will maintain the data for longer (though admittedly, going particularly high could introduce some performance concerns as it expands the window in which certain things are checked).Read marking data lifetime is set to 30 days and the threads have had replies more recently than that. In some cases, earlier in the same day.
Well one issue right now is that there are conflicting descriptions of the problem. My reply is specifically based on the "top of page 1" situation (ie, it's not taking you to a post at all). If it takes you to the top of any subsequent page, that would be a distinct issue (and not one we've seen). If it takes you to the correct post initially and then the page shifts around, that is what the linked threads relate to (though at this point, in the current term, there isn't much more we can do and browsers have generally adopted systems that should help mitigate this internally).So really it's a case of in-page post anchors randomly not working? How the hell do we diagnose that problem?
#post-1234) If so, it's not the read marking issue. Has it scrolled you anywhere down the page but you're not looking at the correct post? It's probably images shifting the page around, as discussed in some of the linked threads. Is there an anchor but you're at the top of the page? Well that's weird and might indicate that the actual anchor elements aren't present in posts for some reason or there's something else custom causing issues.If you read everything I wrote, you'd know that I'm aware of that. And I was just trying to help solve this issue (if it is an issue) by informing you that I still had option to go to first unread posts, even if I landed on first posts of threads when I tried to open them at first unread posts.The "jump to new" link shown within the thread will explicitly take you to the first post that is labeled as "new".
<!-- Quantcast Choice. Consent Manager Tag v2.0 (for TCF 2.0) -->
<script type="text/javascript" async=true>
!function(){var t=window.location.hostname,e=document.createElement("script"),a=document.getElementsByTagName("script")[0],n="https://quantcast.mgr.consensu.org".concat("/choice/","v88e89CxF10j2","/",t,"/choice.js"),i=0;e.async=!0,e.type="text/javascript",e.src=n,a.parentNode.insertBefore(e,a),function(){for(var t,i="__tcfapiLocator",n=[],o=window;o;){try{if(o.frames[i]){t=o;break}}catch(t){}if(o===window.top)break;o=o.parent}t||(!function t(){var e,a=o.document,n=!!o.frames[i];return n||(a.body?((e=a.createElement("iframe")).style.cssText="display:none",e.name=i,a.body.appendChild(e)):setTimeout(t,5)),!n}(),o.__tcfapi=function(){var t,e,a=arguments;if(!a.length)return n;"setGdprApplies"===a[0]?3<a.length&&2===a[2]&&"boolean"==typeof a[3]&&(t=a[3],"function"==typeof a[2]&&a[2]("set",!0)):"ping"===a[0]?(e={gdprApplies:t,cmpLoaded:!1,cmpStatus:"stub"},"function"==typeof a[2]&&a[2](e)):n.push(a)},o.addEventListener("message",function(n){var i="string"==typeof n.data,t={};try{t=i?JSON.parse(n.data):n.data}catch(t){}var o=t.__tcfapiCall;o&&window.__tcfapi(o.command,o.version,function(t,e){var a={__tcfapiReturn:{returnValue:t,success:e,callId:o.callId}};i&&(a=JSON.stringify(a)),n.source.postMessage(a,"*")},o.parameter)},!1))}();var o,s=function(){var t=arguments;typeof window.__uspapi!==s&&setTimeout(function(){void 0!==window.__uspapi&&window.__uspapi.apply(window.__uspapi,t)},500)};void 0===window.__uspapi&&(window.__uspapi=s,o=setInterval(function(){i++,window.__uspapi===s&&i<3?console.warn("USP is not accessible"):clearInterval(o)},6e3))}();
</script>
<!-- End Quantcast Choice. Consent Manager Tag v2.0 (for TCF 2.0) -->
We use essential cookies to make this site work, and optional cookies to enhance your experience.