Can someone clarify the difference between these three Discourse concepts: theme-component, plugin, and pluginAPI. Especially between theme-component and plugin. If I want to customize my forum, how do I know which to build? (sorry if I missed this distinction in the intro, but I’m not seeing it there)

Thanks, guys. This is helpful. I think the key distinction I am picking up: –if you want to change something that is only about what’s on the front end, build a theme. –if you want to change something that requires interaction with the backend, build a plugin. Does that sound right? Here’s a concrete example I have in mind that I’m trying to work out: I want to make it so that any category moderator can pin topics in that category. The broad strokes, I think, are: Evaluate whether the user is a moderator of the category (this requires going to the backend for information about the user and category) If user is moderator, show the pin button (this is front end) If user clicks the pin button, push that topic to the top (actually not sure where this happens in discourse code–maybe also front end and backend?) Here, because I need to converse with the backend (probably in (1), maybe also in (3)?), i’d have to use a plugin. Does that sound right?

[image] JQ331: If user is moderator, show the pin button (this is front end) The superficial part might be, but it will involve the backend because it relates to rights and security. You can’t give the front end discretion on what privileges someone has.

[image] merefield: The superficial part might be, but it will involve the backend because it relates to rights and security. You can’t give the front end discretion on what privileges someone has. Do you mean that programmatically answering “Is this user a moderator of this category” is something that will involve multiple files across front and back end? Hmm…

[image] JQ331: Here, because I need to converse with the backend (probably in (1), maybe also in (3)?), i’d have to use a plugin In a theme, you should be able to know if a user is moderator and also make backend calls if the discourse API exposes an endpoint that you can call from the front-end (after all the theme can use javascript), so you probably don’t need a plugin for [1]. You would need only if you need to change the backend behaviour or expose an API. But you probably need for [3], because, like @merefield said, it relates to rights and security (if the backend blocks a moderator to pin a topic, you would have to change it to start allowing). [image] JQ331: Do you mean that programmatically answering “Is this user a moderator of this category” is something that will involve multiple files across front and back end? Hmm… Like I said above, it probably won’t require a plugin just to make that validation (to know if the user is a moderator or not), but it will probably require because of the action of allowing him to pin the category. If the discourse has an option to allow any moderator to pin a topic (I don’t know if it has), then you wouldn’t need a plugin (but you probably wouldn’t need a theme too, unless the pin button is not shown to moderators, and you use a theme just to show it to moderators and call the endpoint in javascript when he clicks the pin button).

That’s very helpful regarding themes v plugins and also regarding the specific example I mentioned. Thanks. So far my approach to entering changes has been to sort through the specifics of the Discourse code (where is this object defined, what controls this template, where is the logic that handles this action, etc..). But that has been slow going. I’m thinking that probably a more efficient route would be to focus on the API. That way, I don’t need to sort through all the details of the mature Discourse code, and can also focus on building a theme instead of a plugin–or perhaps just entering changes in the “customize” dashboard. Basically, figuring out how the API works seems a lot more manageable than figuring out the Discourse code base. To stick with the example I mentioned: If user is a moderator of a category, allow that user to pin topics on the category page. Could I do this without a plugin? Let me see if I can sketch it out: 1. Is a user a moderator of a category? I currently don’t see an anything in the api that would tell me if a user is a moderator of a category. I’d expect it to be found in a GET call for retrieving a category, but I don’t see such a call there. Or maybe in the GET call for retrieving a user, but there I don’t see a listing of categories the user is a moderator of. Could I add these in? Or, alternatively, maybe I could create a custom_field on the user or the category to identify being a moderator, and then make an API call to that custom field when a category page loads. 2. If user is a moderator, show the pin button. If I can answer (1), then I assume I can just add this button with front end javascript+css, showing it if a user is a moderator. 3. User (who is moderator) clicks button, and that pins the topic On the API, topics do seem to have a “pinned” trait (a boolean). I assume this correlates to whether they are pinned in their category, as it looks like each topic only has one category. So here, when the moderator hits the “pin” button, I could probably update the “pinned” status of the topic to True. If that doesn’t work, custom fields could also be a solution here too (although I am not seeing how to add custom fields to a topic). So with that, or something like it, it seems like I could accomplish this task with the API that, were I to do it with a plugin, would require a lot of sorting through the files of the Discourse code base. Does that sound right?

I have seen that previously, but I’m taking a closer look now. Thanks for the reminder. Im trying to sort through: –where in the API I would get the info about who the moderator of a given category is (I’m not seeing it in the info returned about categories or users–obviously it has to be somewhere) –can you use the API to add new fields to an entry? For example, Could I use the API to add a custom field to a topic? (I don’t think topics generally come with custom fields)

[image] JQ331: obviously it has to be somewhere I would look in the database. [image] JQ331: add a custom field to a topic The database has a posts table and you could add a field there, but then you will be off the ranch and get no support.

Thanks–this is all very helpful. [image] EricGT: I would look in the database. What database do you mean? To confirm, my idea here would be to use the API to do some of this stuff that might otherwise require a plugin. So, for example, my site itself would be making a call to the API to determine if a user (or group, as case may be) is a moderator of a category. The call would be hardcoded into the customize panel, or in a theme or plugin. To make these kinds of calls, I’ll need to be authenticated, with I believe requires creating an API key from the admin panel. The admin panel API creation process requires a “Description” and a “User Level”–I’m not sure how that applies here. In my case, I want my app to make the API call. It’s not being made for a particular user. So I may be misunderstanding. Do you know what User Level is appropriate for that kind of API call or what I should enter there?

[image] JQ331: What database do you mean? When Discourse is installed per the standard it is in a Docker container. Persistence of data is achieved using a PostgreSQL database. See: Data Explorer Plugin If you have admin rights you can grab one of the backups, it is SQL compressed into a tar.gz file. You can use the SQL to reload the data into another PostgreSQL database and do even more.

Theme-Component v Plugin: What's the difference

Development

EricGT (EricGT) June 5, 2020, 7:47pm 9

Have you found: How to reverse engineer the Discourse API

Topic		Replies	Views
"theme-component" should be a subcategory instead of a tag Site feedback	15	1896	July 18, 2022
About the Customization category Customization	0	280	February 25, 2026
Can I use the JSON API instead of building a plugin? Development	3	1118	June 6, 2020
Questions about the technical architecture of Discourse Development	18	2078	January 2, 2024
How far can we push Discourse in customization? Product Support	18	434	July 29, 2026

Theme-Component v Plugin: What's the difference

Related topics