Edits to Wikis with Replies Should Cause Timestamp Change / Post Shown as Updated

(Alex Sherwood) #1

Note I use the terms topic / post & Wiki interchangeably throughout the post, all mentions of topics / posts are referring to Wikis.

At the moment, edits to Wikis which don’t have replies cause the topic’s timestamp to be updated & the topic to be bumped to the top of the New / Updated posts list.
But once a user has replied to the topic, only edits to that last reply will cause the topic’s timestamp etc. to update.

I need users who have never interacted with the post before to be alerted of those changes - for example, I have a Wiki which lists upcoming events -

And I need that topic to appear at the top of the New / Updated posts list when details of an event are added / changed.

Pinning the post to the top of the list is not an option because we have too many Wikis like this & it would swamp the feed.

Once a topic is closed (to prevent replies), edits to that topic which are still possible, don’t cause the timestamp etc. updates so this isn’t an option either.

If there are any other potential solutions, please do let me know…


But once a user has replied to the topic, only edits to that last reply will cause the timestamp etc. update.

This seems to contradict the below guidance but that is the bahviour that I’ve observed.

(Jeff Atwood) #2

Another option is to put these in a category that has no write permission for non-staff users. Then nobody can reply.

I do agree that closing the topic immediately after the first post, then having edits to the first post not bump, is arguably a bug. cc: @sam

(Alex Sherwood) #3

That would address this challenge from a practical standpoint, assuming that non-staff users would be able to put posts in this category - if they can create a Wiki, you’d want them to be able to use the accompanying category…

The downside is that you’re separating these topics from the category which they would usually belong in so they’ll be harder to find & less visible to users navigating the community.

Ultimately if this could be addressed, that would be perfect.

(Sam Saffron) #4

What I really want is a “special” wiki mode where every edit on the OP generates a “system” message on the topic linking to the diff that was made.

It would make public wikis much more interesting cause you could more easily discuss changes and so on.

When wikis are edited, they should be bumped
(Alex Sherwood) #5

That would be really cool!

In the meantime, would it be possible to address this without staff having to create a read-only dedicated category so that I can avoid the fragmentation issue which I mentioned?

(Jeff Atwood) #6

We generally tend to move on things like this for hosting customers. Are you a hosted customer?

(Alex Sherwood) #7

Yes Monzo is a hosted customer, is that bad news for me then?

(Tom Newsom) #8

What we’ve done is hide all the Reply buttons in Wiki Categories so people can’t make replies. Doesn’t prevent reply-by-email, but the creation of new wiki topics is rare enough for this not to be an issue.

// Hide controls in Wiki categories to prevent new replies

.category-tools .create {

// Ah but make sure you can save edits!

.category-tools .submit-panel .create {

Ooh ooh! Me too!
Previous discussions:

(Alex Sherwood) #9

Thanks for sharing this & the code.

Unfortunately it doesn’t solve this though -

(Tom Newsom) #10

In which case the “edits to closed topic counts as News” bug fix should fix both of our problems :slight_smile:

(Jeff Atwood) #11

The logic would be:

  • if the first post is a wiki

  • and the topic is closed, with no other replies

  • and there is an edit to the wiki post

Then allow the topic to get bumped as if the edit was to the last post in the topic. Could you take this @techapj?

(Essentially the topic close “Reply” is causing the intended behavior not to happen.)

Category setting: new topics are wiki by default
(Dave McClure) #12

In the mean time, one can also just delete the “topic is closed” post when using the work around:

(Alex Sherwood) #13

Thanks for sharing this David! I’m just waiting to have a chance to test it.

(Sam Saffron) #14

I prefer @mcwumbly’s hack here over adding more special logic internally for this condition.

Special case bump bypasses end up just leaving us with a very complex pipeline.

(Jeff Atwood) #15

That’s fine as long as the workaround is acceptable.

(Alex Sherwood) #16

I’ve finally had a chance to test this & @mcwumbly’s suggestion does work (thanks again for sharing it!).

Just to note the behavior - the timestamp isn’t changed when edits are made but the update to the post is picked up & it’s bumped to the top of the new / updated posts list :thumbsup:

Thanks @codinghorror & @sam for your work to find a solution here.

(Jeff Atwood) #17