Adding Custom Static Pages

(Martin Potthast) #1

I was wondering whether a feature to add custom static pages would be interesting. Currently, there are only the pages FAQ, Terms of Service, and Privacy. Do you think, one might want to add custom pages to the list?

For example, the possibility to add custom headers suggests you had in mind that Discourse would be integrated with an existing web page, right?

But what about the other way around, say, what if Discourse was the main landing page? Wouldn’t people want to add perhaps a couple of pages to talk about things like the topic, the team, or similar stuff, without adding them manually to the source code?

Static pages plugin
How do I create a page not a topic?
(Jeff Atwood) #2

Sure, that totally makes sense. It would be nice to have an arbitrary number of custom pages.

(Martin Potthast) #3

Alright. Perhaps I’ll manage to develop a first proposal for this. May take me some time, though.
I’ll try to keep things simple as I reckon you don’t want Discourse to become a CMS in disguise…

(StanBright) #4

Nice idea. I was thinking for the same thing yesterday :slight_smile: .

How about two main kinds of pages: Local & Remote? Where

  • Local: Name + content
  • Remote: Name + link

And an option defining whether a page to be listed in the main menu (the drop-down).

(Martin Potthast) #5

Over the weekend, I’ve come up with a first draft proposal for this feature. Here’s the branch on Github.

In this implementation, admins can add new pages from the admin console just like they can add new styles and headers. You can set up custom routes in the form /pages/{path} where {path} can be chosen for each page. Pages that are flagged “enabled” will be displayed by calling /pages.

The pages fully support HTML and ERB, so that I’ve successfully managed to show the static Terms of Service page by copying and pasting its source code into the admin view. I believe, this will make this feature a powerful tool.

No doubt, there are countless things to do before this is finished. I probably won’t be able to continue with this before next weekend. So I would like to take the opportunity to invite feedback!

(Richard - #6

That sounds like a bit too powerful to me - actually a huge security risk.

(Martin Potthast) #7

I have deliberated the risk, but came to the conclusion that, since this is done on the server side, and since only administrators have access to this facility, the risk-benefit ratio is in favor of allowing for executable code in custom pages.

Of course, administrators are not all the same, and by social engineering, some might be lead to paste code into their Discourse instance that shouldn’t be there. So, I’d perfectly understand if the general consensus is against executable code in custom pages.

Perhaps, as a compromise, this might be a setting which is deactivated by default but can be activated if need be. How about that?

(Richard - #8

I would like to be able to distinguish between a “functional manager”, i.e. the forum admin, and the “technical manager”, i.e. the person managing the server. A functional manager should be able to change content, but not code. A Discourse Administrator is a functional manager.

That would be helpful.

However, please be also aware of the risk that this functionality might be misused by people trying to find an easy way to make plugins, possibly bypassing a quality process for plugins. Low quality plugins might have a negative effect on perception of the complete software package, as happened to Joomla.

(Martin Potthast) #9

Agreed. All this depends on the strategy of how plugins are managed and advertised, though. Will there be a central repository for plugins, or can anyone just publish their half-baked stuff?

For the Terms of Use, which incorporate site-wide variables, this would be the only way of managing them via this facility. But this also raises the question whether the static pages and the custom pages should be unified?

While we’re at it: what about JS code in custom pages?

(Martin Potthast) #10

Would that include a setting to make a custom static page the default landing page?

(Robin Ward) #11

Wow I really appreciate the effort, but have you seen the recently added content editing stuff in the admin section? It provides an interface for editing content that is inserted into the site in various places.

The original idea was to consolidate it with the style editing (customizations) but the data structures were slightly different. Right now if we accepted your work (great job btw) we’d have three different ways of doing almost the same thing.

What I’d really prefer is to have one interface for all our “blob” style editing. It would support editing by key (for site content), and adding something new (page, site style). Then we could squish the three sections into one, sharing a lot of code and all that.


(Jeff Atwood) #12

That seems like a very odd choice in a forum, I can see wanting the list of categories (and 6 topics) each to be the default, but a static page of HTML? That’s very un-discussion-y.

(Martin Potthast) #15

You’re welcome; it was fun! I have overlooked this feature, but had a look at it right now. If I understand correctly, the listed items consist of boilerplate messages (such as welcome messages) as well as contents from a now hard-coded static page.

This feature appears to be more general than mine in that it allows for collecting arbitrary contents that will be useful for new Discourse owners (such as messages, mails, posts, and what not). What it does not offer at present is the possibility of adding new such contents, but I can easily see that happening.

In my implementation, I was, too, thinking of pre-populating the database with the three currently hard-coded static pages (although that would require support of i18n), just as you demonstrate in the Site Content page.

Indeed. And if you look closely at my code, you will notice it is basically a copy of the site customization code in admin space and the code that serves static pages in user space. I first wanted to integrate my stuff with the site customization, but opted for implementing it next to it, also because of slight differences, and because I didn’t want to mess up the existing feature.

That makes total sense. There’s no reason to have three roughly similar things sitting next to each other among the links in the admin console. However, the UI would still have to make a clear distinction between the different kinds of possible customizations. There’s even a fourth prospective kind of static content to be considered, which was discussed here, namely to insert custom content in between posts, such as ads.

My question now is: Should I proceed with what I’ve begun, or rather drop it in favor of the existing stuff? A possible strategy might be to first pull all the relevant stuff together, and then consolidate it. However, given I have only limited time for this, I don’t want to waste it on something you guys may already consider superseded. Please advise.

(sparr) #16

It is often the case that someone wants to host a website that is 99% forum and 1% web pages. Not needing to install a whole different CMS (when Discourse already has nice account / formatting / editing / publishing tools) for 2-3 static pages is a benefit that would be put to good use on a lot of sites.

(Ted Strauss) #17

Considering that truly integrating the forum into an existing site would present a formidable challenge, having a few static pages, including home/landing page would be a great advantage. Even if security settings are max’ed out for these pages.

(Jacques Visser) #18

OK so I just discovered Disclosure via BoingBoing. Dumbfounded at first, I was like, why would someone create something so useful.

I immediately logged in to AWS fired up two micro instances, deployed Disclosure manually on Ubuntu, it was mostly a breeze! Then used Bitnami’s AMI for the other micro instance. Both worked flawlessly.

Anyhow Jeff 'n crew thanks for a totally useful product (open sores and all). I am about to embark on several integration’s just for the heck of it.

Just one question, can someone post some info on how to provide a static html landing page and wrap / integrate this into an existing site.



(Jono Bacon) #19

Apologies for bumping this topic, but I wanted to see if static discourse pages are on the radar for the development team.

I run a few Discourse sites (,, and there have been cases on all these sites where it would be helpful to define a new static page that can be configured by the admin and take full HTML.

As others have pointed out, this is because 95% of what I need is a forum, but I could benefit from some additional pages to provide guidance and other facilities.

Is anyone planning on working on this?


(Sam Saffron) #20

no on the roadmap at the moment and nobody is working on it.

on another note you got to change your footer on badvoltage to use the new method @zogstrip added (are there instructions anywhere?) .

(Jono Bacon) #21

Not quite sure what you mean, @sam. I just used Customize -> Text Content -> Bottom of the pages to add the footer. I don’t think I found instructions for how to use this, I just stumbled across it. :smile:

Also, on another note, thanks so much for the awesome work going on in Discourse. It has helped me to build three communities so far, and received universal praise from people who use it. :smile:

(Alessio Fattorini) #22

Agree, seem a good proposal. I like it

Very sad :-\