How do I set the order of pinned topics

Great, it might make better sense that they don’t reorder once they’re closed anyhow. So once the desired order is set, can close them and freely edit them without worrying about the order.

Aaahaa :bulb:
Good piece of info to save the hassle of always having to do the re-ordering jig if I edit something :slight_smile:

1 Like

I actually don’t have this effect: when editing the 3rd pinned topic down the list of pinned topics, it doesn’t bump it at the top. Any idea why? Unpinned topics do behave as expected (bump when edited).

[EDIT] Those pinned topics aren’t closed.

[EDIT] Unpin & re-pin globally still makes it reappear at the 3rd place.

Editing the post shouldn’t have anything to do with pin order.

However, un-pin and re-pin should change order. On try.discourse.org I pinned these three topics in this order:

I unpinned the bottom one (What’s your all-time) and then re-pinned … and that did NOT affect the pin order, so our advice here is no longer correct. Even un-pinning the second one (A bear) and re-pinning it did not affect the order!

Looks like @metadiscourseuser was right. There’s a new additional step. Un-pin, edit, then re-pin. We need some kind of fix or solution here – can you schedule this for next week @eviltrout?

1 Like

Also I just realized there are a few variables here:

  • pin globally
  • pin in category

It’s possible that global pins aren’t influenced by un-pin and re-pin in the way that category pins are, so we have to figure out which one we’re talking about. I’ll test in a bit.

@tshenry can you take this for the coming week? We need some proper testing and a solution here. I’m not a fan (to put it mildly…) of pinned topics, but there should be a way to set their order, as previously defined in this topic.

3 Likes

Here’s what I found with my testing:

  • When looking at sets of global pins and sets of category-specific pins, the order appears to be influenced exclusively by bump date
  • Pinning and unpinning do not appear to cause a bump and therefore do not affect the order of the pinned topics
  • I checked the following bump actions and they successfully placed a pinned topic above the others:
    • Replied to a pinned topic
    • When there are no replies, edited the OP
    • Set a 1 minute “bump” topic timer (you can delete the small action past and the bump will persist)

Let me know if there are any other scenarios you would like to test!

1 Like

Looks OK to me, @sam @eviltrout what are your opinions on this? Should we make it easier, or is this sufficient?

(from my perspective, we want friction around pinned topics, so I vote for the status quo, but properly documented)

1 Like

I don’t love to support “quirk that works for our purposes.” If the order of pinned topics is important we should add a way to specify it in the database properly with some kind of interface. My vote would be to leave as is unless we want to do that.

1 Like

Sure. What do you think @sam? My vote is “as-is” but I think your opinion could make the final decision.

1 Like

I guess the question … leading all the way up to the OP here is.

Should pinning ignore topic list ordering? At the moment when you look at latest, it sorts pins by bumped_at and then the rest by bumped_at.

Fiddle with ordering on the list, you will impact the ordering of both pins and non pins.

I do feel for this feature request and the change is trivial.

We could unconditionally regardless of topic list ordering, order pins based off “pinned_at” date. We already have all the information and the cost of the change is low.

Advantage from a site operators perspective is that they can easily and unconditionally keep the most important pin at the top. (want something on top, unpin / pin)

3 Likes

Ok then it is decided! Since the work is easy, let’s make it so! :raised_hands:

4 Likes

Sure, @Osama a small one for you, careful with the tests and perf, topic_query gets very complicated.

Low priority, no urgency here at all.

4 Likes

I read and follow the conversation here, down to this statement (which suggests that this approach is decided upon and implemented). I am however not observing re-ordering based upon unpinning/repinning.

Is there something I’m obviously missing?

EDIT: I just discovered that in fact this operation is still being influenced by whether the Topic is Closed or not. So, opening it seemed to do the trick.

Kenny, my suggestion is still on @Osama’s list, we will get this sorted over the next 2 weeks or so.

2 Likes

This PR implements this :arrow_up: behavior:

2 Likes

Hi all, I just noticed the change after updating our community. For our use case, this new behavior is very suboptimal. Any chance to have an option for the old behavior via a setting in the admin section?

I would probably want to report that as a bug if I had been using Discourse for longer. It makes the change on the basis that the previous behaviour is undesirable, removing behaviour that admin and regular users will have come to expect and may or may not desire.

In addition, the way the feature is described implies that the purpose is to give admin more control over the order, however that feels incomplete as there is no means of reordering the pins besides unpinning/pinning.


I think pin ordering should be a setting at category level. An option to choose between bumped_at and pinned_at, defaulted to bumped_at for a relatively simple change that doesn’t affect existing admin. (I recognise that is made non-trivial by localisation though.)

Longer term, I think this should be a fixed pin positions checkbox with UI to reorder the pins much like the UI for reordering categories when using fixed category positions.

2 Likes

100% agree. For us, this latest change has a negative impact. As we dynamically globally pin and unpin topics based on engagement via the API. Now users can’t see anymore to which of the pinned topics another user replied last because the whole pinned section is not dynamic anymore but static.

1 Like

Engagement in our community is already falling off the cliff since this change. Kindly can we get a setting for this and optionally revert to the old behavior, or do I have to patch this change out of core?

This topic was automatically closed after 10 days. New replies are no longer allowed.