Ok, not sure how viable the bulk-toggle might be for categories with tens of thousands of topics. Might rails bulk / batch conversion jobs be option? :thinking:
And is this reversible? Can a threaded topic be converted back to a flat topic?
Yes I do agree with you. This is a limitation for now, and something we will absolutely keep thinking about.
The big reason why I chose not to convert historical topics in a category when it is enabled, is that users are likely going to interact differently. In flat mode, the various Reply buttons don’t matter as much. The post is going at the bottom of the topic. I’m not sure users always intentionally press the “right one” that would translate to the nested view.
Basically I worry that admins will enable it for historical topics and then suddenly the conversation is unreadable. We’ll keep thinking about it. The easiest change I can think of is when the category setting is toggled, we have a modal popup saying “do you want to apply this to existing topics?”
Does this suggest it should be tested in our communities in isolation first, before we all pull the trigger and convert every existing topic? :thinking:
That’d work, providing it supported tens of thousands of topics.
But it’d need to be made very clear that there is no coming back from this :sweat_smile:
Will this feature be implemented here on meta first, or on https://try.discourse.org so we can test it outside of our production environments?
If it were my community I would test in isolation first. On the other hand we would get more valueable feedback faster by you enabling for your whole community :wink: . Jokes aside, I do think testing in isolation is probably smart but there is no destructive data migrations here. It can be enabled and disabled safely. No decision you make here will lock you in either direction.
I guess I sorta accidently answered this part! Enabling nesting simply creates a nested_topic record for each topic in the DB and kicks off a job to calculate reply counts down the ancestry tree. Disabling nesting removes that nested_topic record and you’re back to flat, no issue.
/* add text to Reply button for the original post (aka Topic) */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Adding this content after Reply
content: " to this Topic";
}
}
}
}
/* add text to Reply button for all subsequent posts (I'm calling them comments) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Adding this content after Reply
content: " to this comment";
}
}
}
}
/* add text to blue Reply (to Topic) button appearing at the end of the page */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// Adding this content after Reply
content: " to main Topic";
}
}
}
}
Ok, not sure how viable the bulk-toggle might be for categories with tens of thousands of topics. Might rails bulk / batch conversion jobs be option? :thinking:
And is this reversible? Can a threaded topic be converted back to a flat topic?
Yes I do agree with you. This is a limitation for now, and something we will absolutely keep thinking about.
The big reason why I chose not to convert historical topics in a category when it is enabled, is that users are likely going to interact differently. In flat mode, the various Reply buttons don’t matter as much. The post is going at the bottom of the topic. I’m not sure users always intentionally press the “right one” that would translate to the nested view.
Basically I worry that admins will enable it for historical topics and then suddenly the conversation is unreadable. We’ll keep thinking about it. The easiest change I can think of is when the category setting is toggled, we have a modal popup saying “do you want to apply this to existing topics?”
Interesting…
Does this suggest it should be tested in our communities in isolation first, before we all pull the trigger and convert every existing topic? :thinking:
That’d work, providing it supported tens of thousands of topics.
But it’d need to be made very clear that there is no coming back from this :sweat_smile:
Will this feature be implemented here on meta first, or on https://try.discourse.org so we can test it outside of our production environments?
If it were my community I would test in isolation first. On the other hand we would get more valueable feedback faster by you enabling for your whole community :wink: . Jokes aside, I do think testing in isolation is probably smart but there is no destructive data migrations here. It can be enabled and disabled safely. No decision you make here will lock you in either direction.
I guess I sorta accidently answered this part! Enabling nesting simply creates a
nested_topicrecord for each topic in the DB and kicks off a job to calculate reply counts down the ancestry tree. Disabling nesting removes thatnested_topicrecord and you’re back to flat, no issue.Feel free to play with it in this category:
I always felt the “reply” labels could be more specific – so a while back I used some custom CSS to add context:
screenshot
CSS
the issue with this solution is it won’t be translated in the UX for members who have a non-english language setting in their preferences
edit: i have solution here: