On the left the sidebar since the PM has been installed on Coop, on the right safe-mode.
- the order is different
- my beloved “categories” is missing
Ha! I thought that was deliberate!
It isn’t surprising as that is how the plugin manager was configured, and it is just reflected in the sidebar.
Don’t be in a rush to fix it - with a few tweaks I suspect that we could end up with something very cool.
Yeah, I suppose the new items were deliberate (and indeed cool) but why have I lost my category links?
1 Like
I’m out of the loop on the sidebar - are there plans from CDCK on making it customizable per user to some degree? There’s stuff I want to see there and stuff that I really don’t…
It is already quite user-customisable, with categories and tags under user control (with admin-set defaults).
They are working on user-customised links for the top section at the mo, and this should be live soon I think.
@angus do you know why the “Categories” could be missing?
I have already cleared and re-entered the categories for sidebar in my preferences, but that did not help either.
In discourse.pluginmanager.org it seemed as though ‘Categories’ were renamed to ‘Plugins’, so I suspect it was rooted in the piece that enabled that customisation.
The order of the sections of the sidebar is static and determined by what appears in this template.
The reason categories are not there is because they’re removed from the template override in the plugin manager plugin, so in that respect @NathanK is right that this is a leftover from the approach to categories on the old system.
So, where should plugins appear vis-a-vis the other elements in the sidebar (assuming we’re putting a list of categories back in there)?
The “standard” order of elements is:
- Community
- Categories
- Tags
- Messages
- Custom ← this is where plugins would appear if we didn’t override the template, i.e. at the bottom of the page.
I’m not sure if you need to override the template.
You can just add a section and then rearrange them using CSS flex order. The example below would make Plugins appear just below Community and keep everything else the same.
.sidebar-section-wrapper {
order: 9;
}
.sidebar-section-community{
order: 1;
}
.sidebar-section-plugins{
order: 2;
}
1 Like
Yup, also a valid approach, albeit with it’s own risks (changing the CSS could also break the layout).
Either way we need to decide what order we want them to appear in. So just below community?
@Eli You seem to also have strong feelings on this?
I would opt for just below community yes
Given the volatility of the templates, especially the sidebar ones, and the implicit goal to keep things backward compatible with older versions I would strongly urge towards only overriding templates when there is no other way to accomplish what we want.
I have feelings but no strong feelings. I don’t use most of the sidebar but getting categories back would be a quick fix to adding the part I do use. 
1 Like
It depends on the complexity of the template. The CSS is just as volatile as the templates, perhaps even more so. In a case like this where the template is relatively simple, save for the custom sidebar section itself (which is what we’re using) I prefer to override the template. The use of the template override is not the issue here. The categories section was removed intentionally.
To illustrate the point, try applying your suggested approach using the browser console. It’s not as straightforward as it seems. Moreover using the order hack to achieve different ordering (which I admit I’ve done myself a few times for similar reasons as you’re suggesting here) tends to break accessibility. See
I guess we’ll agree to disagree here. In my experience, template overriding is the #1 reason that plugins break against newer Discourse versions and/or against stable. Of course, you might have a different experience.
I don’t think “order” is a hack, the ages of CSS Zen Garden can finally be back 
Not really important but I wonder why the categories were removed in the first place?
It used to be, and I used to have the strict view you’re expressing here. However, I use it selectively now because I find it to be, on balance, less volatile if used appropriately.
It is effectively a hack if used in big ways like this. The MDN article explains it well
These small tweaks are the sort of cases where the
orderproperty makes sense. Keep the logical order as the reading and tab order of the document, and maintain that in the most accessible and structured fashion. Then useorderfor purely visual design tweaks. When doing so take care that you are not reordering items that could be accessed by the keyboard as a user is tabbing around. Especially when using newer layout methods you should ensure that your browser testing includes testing the site using only a keyboard, rather than a mouse or a touchscreen. You will quickly see if your development choices make getting around the content difficult.
Because on the old system each plugin was a parent category. The category list in the sidebar was confusing in that layout.
One other reason that comes to mind is that you’ll run into problems when two plugins override the same template.
But at this moment I’m perfectly happy if those categories come back one way or another
Yes, I know. Keep in mind we’re talking about a plugin only we use.
The issue here was not just the categories section. The plugins section does not show up at all for guests (i.e. if you’re not logged in). There is a hard division between anonymous and guests in the code. Custom sections don’t show up at all for guests. After some experimentation I’ve settled on the approach of using the “community” section which is the only relevantly common section between the two.
Implementation
We’re now overriding a specific function in the relevant classes to set the order of the links in that section. See this part of the plugin’s initializer, where you can see a relatively descriptive list of our links. We should allow the ordering to be set via as a site setting at some point perhaps. Or even PR that into Discourse itself.
api.modifyClass("component:sidebar/user/community-section", {
get defaultMainSectionLinks() {
return [
EverythingSectionLink,
DocumentationSectionLink,
SupportSectionLink,
PluginStatusSectionLink,
AdminSectionLink,
];
}
});
api.modifyClass("component:sidebar/anonymous/community-section", {
get defaultMainSectionLinks() {
return [
EverythingSectionLink,
DocumentationSectionLink,
SupportSectionLink,
PluginStatusSectionLink
];
}
});
@richard we should document this somewhere for our own benefit, any thoughts on where?
(note this is currently being deployed via the admin panel so…sit tight 
)
1 Like
I’m so happy!!! Thanks Angus!
2 Likes