Developing Discourse Plugins - Part 2 - Connect to a plugin outlet

Not a direct technical answer to your question but why would you want to do that?

Only the admins can do this. They usually have full control of the server most likely anyway and could read the database, so hiding a button is a bit futile: emails will also show up in the Email logs and on your mail service logs. I’m afraid site admins are going to see a lot of email addresses!

Admins have full control, they see everything (except passwords presumably), so this is normal.

If you are an admin, get used to the responsibility which comes with knowing all of this!

My concern was that moderators can access some things in the admin dashboard.
They can navigate to the ‘users’ tab and see the Export and the Show Emails buttons

We don’t want our moderators to be able to grab bulk emails like this.
I understand that the emails are visible on users profiles, but we didn’t want an easy way to get this information.

So I was trying to create a plugin that hides these buttons.

Could be wrong, but this suggests it’s not an issue … have you Impersonated a Mod?

Yes, the screenshot I took was from impersonating a mod.

We have a similar setup as the link you provided (Moderators ability to see emails inconsistent).

I’m not requesting the Discourse team makes any changes though, this isn’t an issue with Discourse.

I am trying customize Discourse for our situation. I was hoping that using a plugin outlet and referencing the files within that plugin was the right way to overwrite a template in Discourse. I just wasn’t able to successfully overwrite these files:


My changes never showed up. So I thought this plugin outlet topic could help

1 Like

Perhaps someone else can chime in, but I’ve always seen Outlets as additive. You may need an override technique instead (via javascript/Ember). I’m still learning this myself :).


I’m thinking that if overriding a template is the goal that it might be better to do this with a theme instead of a plugin.

I was thinking that as well, but I didn’t want a user to swap their theme and be able to get different functionality. So I figured a plugin outlet would do the trick

I think you can probably hide those with CSS.


Yes, and presumably you can apply to every available Theme so this can’t be switched off? (to address @sarahann concern about this approach).

I could use display: none but it might now be as secure as we need it to be. And I figured it would be helpful to have a discussion on how to remove / change Discourse UI templates.


It’s tricky to do properly, unfortunately. For a big customer of ours who needs functionality removed, my approach has been to hide the elements with CSS and remove the controller side actions by using add_to_class to overwrite the methods with an error in plugin.rb.


I have a same problem. I’m working on plugin with topic, and I have to change the html structures but it’s impossible with only CSS. So I was tried to overwrite template but changes never applied.
So do you have find any solution for that?

You can override any template in the application if you like (although outlets are always preferred!). How were you doing it? did you confirm the name is exactly the same as the template you are replacing?


I tried to override the “list/topic-list-item.raw.hbs” template, but even though I removed all of the content in template, the topic items still appearing as original, any changing in override template never worked.
Please help me what I was wrong.

See: for an example of how it is done.


When I run the command git grep “plugin-outlet” – “*.hbs” in my Linux Terminal, nothing shows up. Any ideas why? Thanks for your help!

Caveat: This is a sysadmin answer, not a plugin developer answer, and I can’t guess what you might have done before you did your git command.

Did you add it to git? What about

 grep -r plugin-outlet .

Building on Jay’s shoulders here, you can of course focus on the specific file type:

grep -r "plugin-outlet" --include \*.hbs


Is there anything you need to consider differently if the plugin outlet looks like this?

{{plugin-outlet name="users-top" connectorTagName="div" args=(hash model=model)}}

do the connectorTagName and args attributes mean that plugin developers have particular constraints or extra accesses when using these outlets?

Yes you are meant to work with the API that the outlets establish.

In the users-top you are passed a model which you can use, and the connector will be rendered with a div in this case.