Discourse 1.2 Extensibility Game Plan

(Robin Ward) #1

Now that we’re in December, I’m planning on shifting gears and working on extensibility for our 1.2 release of Discourse.

Extensibility is unfortunately one of those projects that can go on forever. I feel like no matter how much time I set aside to work on it, it will easily fill up that block. Instead, I’m going to focus on a few tasks that I feel are achievable by the end of the year.

I am going to approach this by working with two plugins that we feel are important, Tagger and Akismet, and making sure they integrate very nicely into Discourse. I will identify extension points that they need and try and make them as simple as possible.

I am going to be reiterating on them, sanding down any rough edges in Discourse in order to support development of this kind of thing.

Along the way, I have some secondary goals I’d like to achieve if time permits:

  • Allow plugin development without constantly deleting the tmp directory
  • Add a few webhooks to Discourse for integration with Github or Slack type services.
  • Support ES6 modules in the server side rendering pipeline
  • Convert the rest of Discourse to ES6 modules (we’ve done most of the hard work already on this)

Is there anything you’d like to see in extensibility? Any particular pain points or issues you’d like to see resolved?

Discourse Version 1.2
(Michael Downey) #2

Would (better) API documentation be an appropriate request?

(Spero Koulouras) #3

A specific earlier request we made was to provide a mechanism for allowing topic excerpts to be included with topics. It was suggested at the time that this would be a good candidate for the extensibility work. This would be on our “nice-to-have” list.

(etewiah) #4

What I’m very interested in knowing is how the extensibility story will change with a transition to ember cli. For me, one of the nice things about ember cli is the opportunity to bypass the rails asset pipeline. Right now though, the rails asset pipeline is key to extending discourse.
Will there be a way with ember cli to bypass the rails asset pipeline and still be able extend discourse with plugins?

(Sam Saffron) #5

Some other points

  • Ensure “scss” assets work in production (broken now)
  • Allow for customising columns on the topic list
  • Clean up the way we override translations, should be trivial as opposed to majorly complicated like it is now.
  • Clean up the way we add site settings from a plugin

(Erlend Sogge Heggen) #6

This community effort will have to do for now.

Maybe it’s too soon, but a Discourse equivalent of the WordPress Plugin Boilerplate would be a fantastic resource.

(Jeff Atwood) #7

Another minor extensibility point, as you have time: to add new “share” destinations on the share dialog:

(Admir Hodzic) #8

(Benjamin Kampmann) #9

Does this mean, you will add more plugin-outlets?

I think a major problem the plugin system is facing right now is that many things are extension or changes on the template/UI level, which is almost not supported by DC whatsoever – unless you do very limited, specific things like adding something to the composer or another button to the post-menu. A simple example is that DC pre-emptivly decides where tagger shows the tags by only providing one specific point to do that with. But I can see various use-cases and designs in which it is not desired to have them under the title but somewhere else – at the end of the first post for e.g. . You can’t do this without either forking your own discourse or create a plugin which overwrites the entire template. Both make it hard to stay up to date with latest DC changes.

(Robin Ward) #10

Lots of inline replies coming, sorry guys but this is the best way to reply in bulk :smile:

I feel like I could get a lot more done to help plugin authors if I wasn’t bogged down with docs this month. It’s something that perhaps other people in the community can contribute?

What do you mean by this? It sounds somewhat like a feature to me?

Our eventual goal is to get up on ember-cli, but first we have to convert everything to ES6 modules (that is a secondary goal in this sprint). I can’t say for sure how easy it will be to adapt plugins, but right now they currently support ES6 modules and it’s likely I will continue to do it that way for my work in the next little bit.

As for bypassing the asset pipeline for some plugins when we support ember cli, I don’t see why that wouldn’t be possible if ember-cli is packaging the JS bundles for us.

I like this idea a lot! I’ll see what I can do.

I think this is a good idea but I can’t see myself getting to it this month, sorrry :frowning:@sam is right that we have the basic skeleton in our codebase to support it, it’s just not really generic enough.

I’m sure that is the least of what I will be doing. My hope is that by dissecting the tagger plugin I can identify many points where we need to support things like outlets or other forms of extensibility so that it’s completely painless and doesn’t override any templates.

(Spero Koulouras) #11

I was referring back to this old topic

with response from @sam in October

(Blake Erickson) #12

(Claus Strasburger) #13

I personally would love heavier usage of the DiscourseEvents class – this and some quick notes about the emitted events could make plugin development for tightly integrated things a lot less painful, if not delightful.

(Scott Trager) #14

Installation of Plugins should be made easier - as they are now they are Mods and not Plugins. For them to be actual PLUGINS you would need to be able to either connect to some sort of (adjustable ideally) update server (ala Google Chrome) or load up the compressed plugin files and click install (ala Drupal).

(Michael Downey) #15

I wouldn’t say they’re quite that difficult. Yes, you do have to paste a line of code in a file and restart a server, but while inconvenient I don’t think it qualifies as painful. And all the plugins I’m using seem to update at https://discourse.example.org/admin/upgrade along with the main app itself.

(Benjamin Kampmann) #16

Regarding that. May I ask to have a plugin-outlet in the admin-menu to add your own entries?

Like right there:

Then I would not have to overwrite the entire template anymore for the curated home plugin.

Also, for another plugin coming up (focused on representing workflows and status in topics using custom-fields), there will be the need to have at least a few entry-points per topic and post. Could we have one maybe here with access to the post?

For Tagger, I feel one right at the end of the posts content would be nice.

(mountain) #17

Thank you for this, @eviltrout. If I may suggest an extensibility feature for future plugins, I was wondering if some outlets can be made to inject arbitrary css classes into specific spots so the ui can change based on if a condition is met or not met via a plugin.

Here are some to start:

For any topic listing view: Topic list item (id is ember# for each topic)
Single topic view: The user’s entire post, the user’s avatar and username, the topic’s title.
User’s profile: The user’s avatar and username.

I am guessing if I did this via a plugin, I’d have to re-write whole parts of the front end.

(Sam Saffron) #18

the template for a row is overridable, adding 20 hooks inside makes little sense and we would take a perf hit for it.

(mountain) #19

Thank you for the explanation. I’ll see what I can do with minimal rewrite.

(Benjamin Kampmann) #20

And maybe a plugin-outlet one for the Admin-Menu, so we can stop doing this ridiculous thing every time