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

Feature
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…

Note

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.

1 Like
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

1 Like
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.

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.

11 Likes
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?

6

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

7

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

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 {
    display:none;
}

// Ah but make sure you can save edits!

.category-tools .submit-panel .create {
    display:inline;
}

Ooh ooh! Me too!
Previous discussions:

2 Likes
9

Thanks for sharing this & the code.

Unfortunately it doesn’t solve this though -

10

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

1 Like
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.)

4 Likes
12

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

6 Likes
13

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

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.

6 Likes
15

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

4 Likes
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.

7 Likes