In my opinion, I think that the #theme-component tag would serve its purpose better as a subcategory. At least for me, they’re easier to find compared to tags, and in recent years, theme components have become more and more significant in contrast to their #plugin counterparts (many of which are being converted to theme components for easier use). For lack of a better term, they deserve… “equal” treatment. After all, they’re extremely popular and are very much an integral part of Discourse nowadays.
I hope you take it into consideration. I’m not a native English speaker, so sorry for my lack of articulation.
I think that language is going to create confusion. Admin->Customize is only for themes and theme components. #theme contains everything which can be introduced to a site via that UI.
We already see occasional issues with users putting themes in their YML and trying to add git repos for plugins via the UI. Eliminating the delineation just makes those errors more likely.
Plugins really need to stay in their own category, don’t they?
The difference between a theme component and plugin is already blurry in my head. Anything we can do to make it easier for folks to know which is which will go a long way, I’m sure.
This is kind of funny, for a long time WordPress developers had a call to make on where to include functionality, and debates were had on how much code belonged in a “theme” versus a “plugin”. That debate is almost quaint, now, where anything and everything is a JS block, but because of it’s relationship to the core software, we still have to figure out where code goes, in a “plugin” or a “block pattern”.
I’ve never had such a sense with plugins in Discourse, mostly because folks have come up with some brilliant theme component hacks over the years. If someone asked me what the difference between “plugins” and “theme components” is, my first thought would be: one takes a URL field to install, and the other requires a site rebuild.
I’m definitely up for giving the categories and tags a health-check. There have been a couple of good suggestions about giving the structure a bit of a tweak recently, so I’ll collate all of this together and see where we land. I think anything that makes Meta more intuitive for new people/occasional users can only be a good thing.
This should be less of an issue now there’s a dedicated Community Moderator. () I think having me sort and organise as I go should cover a lot of that. And we have a decent number of TL3s and TL4s, so hopefully reinforcing a consistent pattern will make it easier for other people to join in too.
I still think of it as Frontend versus Backend changes, but the upgrade to ember has blurred what that means to me now too. It seems like it’s made so many more things possible in a theme/theme component than before (which is great if you’re hosted and don’t have easy access to add a plugin ).
I think that’s quite a useful distinction for non-developers. Red = /admin/customize, Yellow = app.yml. I think that’s probably all you really need to know if you’re an admin installing an existing customisation, rather than a developer wanting to make a new one.
Thanks for the suggestion @Decorbuz I’ll put some ideas together, and see what we can do.
Same question than are smarter phones computers or not. Borders aren’t that sharp any more.
That’s why every forum must make logical choise how to arrange things: Somewhere it must be per idea or use (UX and target matters) or are technical solution more important (dev/code basis thinking).
There is no right or wrong solutions, as long users find what they are looking for.
Well, there is wrong solutions every now and then. Mixing healthy plugins/themes/components with broken ones in the way, that you have to find out right tag, is really really bad idea
And in generally there is another mistake than admins quite often do and if I’m remembering right, even tag-doc or similar by Meta is warning about too: category doesn’t generate creation of content, but empty or low traffic ones just make things messy.
A lack of clarity doesn’t automatically mean they need to be merged, particularly under the name Justin suggested above. We could equally add better explanations to each category and tackle some of the ambiguity that way.
#theme and #theme-component encapsulate the pre-packaged customizations which can be made at runtime.
#plugin topics require a rebuild and can only be performed by users with root access. They’re higher risk changes which affect the availability of the site.
I think of them like that either. If it requires some change in the backend (ruby code) be it store something in the database or change some API behavior you most likely need a plug-in.
If the change is only the UI it is better to start with a theme component and fallback to a plug-in later if things escalate, get more complicated and changes in the backend turn out to be necessary.
I like this idea. It is a bit more convoluted than a single category with different tags but I like a stronger boundary between this different customization elements.
A theme can be only about looks while a plug-in requires access to the OS in the machine to install. They’re are very different things and proper categories allow for example the first topic in the category would allow provide context to new users about the differences about them. How to install, development docs, etc.
Anything we can do to make it easier for folks to know which is which will go a long way, I’m sure.
I think anything that makes Meta more intuitive for new people/occasional users can only be a good thing.
