Similar to some bugs before, if you look at the post count given in the linking box of a post, it gives the post #. However, this doesn’t match the numbers displayed in the navigation bar on the right.
So the last post on the topic (at the time of writing) is being called “post #580”, but but the scroll bar shows 256 / 257. Looking at the second post in the topic, it is numbered #303, so I’m guessing there are some whispers before it.
Okay - if that’s the case on that topic, please check a topic with whispers (or whisper here then post a test reply?) because you will have the same effect.
Unfortunately this bug has been noticed on my forums by critical/paranoid members who somehow imagine something terrible going on
Post numbers are assigned when the post is created, (they get the next available number) and cannot be changed after the fact, as this would break references/links to a specific post.
Whispers are just a post in the topic that has a permanent “Staff Only” flag. Like any other post, they get a post number when they are created. Would you assign the number in a different way?
If it’s a matter of not trusting staff, perhaps your community needs to have all moderation &tc. done transparently out in the open?
The post # should match the post number computed in the scroll bar and thus ‘skip’ the whispers for non-mods. Linking to whisper posts could still be supported, but perhaps using a slightly different URL format e.g. /topicid/w-postid where the ‘w’ prefix denotes the postid is a whisper.
We are very open, but that still doesn’t stop a few people pointing out how many whispers they think are on a topic and trying to stir things up.
That still wouldn’t change the fact that the counts would be off if there were deleted posts in the topic. They’d still be wary/paranoid over the discrepancy… and you’d lose the whisper function unnecessarily.
A simple explanation to the users about why there is a difference in the numbers being caused by deleted posts should suffice. Other than that, the users’ have to get over their unfounded fears (or conspiracy theories).
My last post was requesting just the ‘cosmetic’ fixup of the post # mismatching the count, as shown in the screen shot - you said all the other stuff was a lot of work for little benefit, so I dropped it.
This is a problem that has stuck around for years, and a few attempts have been made to improve it and this is where we ended up.
I’m of the opinion that it’s a combination of necessary transparency and not-going-to-be-noticed. (Yes, that’s a partial contradiction.)
We aren’t willing to compromise on the position of displaying posts in order (such as how large platforms like Twitter are handling the deleted posts issue). These numbering discrepancies seem to be a necessary cost of that.
Would you be willing to expand or link to reference on what twitter is doing? I’m not a tweeter, so have no reference to compare/contrast what discourse is doing here.
By constantly shuffling the order that replies are shown, deleted or unwanted replies can be conveniently buried with no easy way for you to prove this is happening.
Additionally, incendiary responses can be boosted to the top, algorithmically stoking the flame wars instead of cooling them.
That’s why I think it would be better if the two ‘post numbers’ shown on the same screen agree (screen shot is in my post above), even if the post number in the URL (which usually needs scrolling) would still give away the actual post sequence number.
Given the scroller on the page knows the ‘visible’ number of each post, I’m not sure why this would be hard to re-use on the post dialog, but then I’ve not looked at the code either!
I also don’t know how the code handle it, but my guess is that the total count can be done fast with an aggregate database select that counts the non-deleted and non-whispered posts using a postgres index.
On the other hand, showing each post actual number (ignoring whispers and deleted posts) could cause a huge penalty in the performance to have a near zero benefit. It could also be made with a background process that updates the numeration of the posts whenever a new post is created or deleted (and having a wrong numeration in the meantime).
Both options don’t sound good to me, although I’m guessing more or less how the total count is calculated (if the post ids are retrieved first and the total amount is calculated later, it might be more likely that what you asked can be achieved with less penalties).
(Here I’m just considering changing the display number, not the url, because changing the url would be even worse, with links pointing to wrong posts as time passes)
I think about this “problem” in the numeration as a trade-off: it’s not the ideal scenario, but among the other possibilities, I consider the way it’s doing now as the best one. Furthermore, which practical scenario would be the ideal one? (that’s why I say it’s a trade-off)
Another thing that would have to be done in the background would be to change the URLs where links have been referenced in other topics.
Here’s where there could also be problems: Shared links to other sites.
If the URLs were changed to match the time slider, they won’t match the URLs that had been previously shared.
I think that’s unlikely. As you scroll down a page, the actual visible post number is already shown in the scroll / navigation bar on the right. The request is simply to use this number in the popup box when looking to link a post.
Link box:
Scroll bar:
On this topic they match (because there are presumably no deleted posts or whispers). Yay
I can’t test with this topic because the numbers are correct, but if the current number in the timeline is correct and can be associated with the post, then that would require only a small change at the front-end. So, yeah, that could be achieved without penalties (as long as only the post number changes, not the url).
check that date
