In order to simplify our technology stack, I’m wondering if we shouldn’t be hosting a website and a forum separately, but rather reconfiguring Discourse to be both our website and our forum together.
I see this is how Pavilion by @angus uses Discourse.
Our website needs are more complicated, though! This is our current website.
I’d be curious to know if there are other Discourse only websites out there that I can explore. Or if you have any ideas for how this could be done.
well, it is possible to use publish pages for your non-posting content
Then use a header sub-menu plugin to give you a top menu with sub-menus or another plug-in to just give you a menu with no subs.
It all depends what your requirements are.
Yes! I think those are a great start.
One of our requirements would be around being able to embed things like our newsletter sign-up form and our donations form.
I also don’t know just how powerful custom styling is for page publishing. I’m wondering if there are examples out there of pages that do have much more stylized pages with things like content blocks with different backgrounds.
The question boils down to three things:
You can serve millions of pageviews from a $5 VPS running WordPress with the right caching and CDN in place. The equivalent Discourse instance would be much, much costlier.
If the majority of traffic and activity occurs within Discourse and there’s no risk of traffic surges to static pages, then hosting it all within Discourse might make sense. In other cases a proper CMS is still king.
Discourse is Rails back-end and extenable so you can do anything a Rails app can do i thought, but are you looking for a silver bullet?
While it can certainly be done, and it may make sense for your organization, we at Discourse use different software for our main website.
Our main website is static HTML generated by https://jekyllrb.com/ and our blog is a simple WordPress instance.
It really depends on how your organization engineering is structured and what needs and priorities you have.
Thanks for that, Rafael.
I’m anxious to get WordPress out of my life. I was thinking that I"d go with a Discourse-only solution, but I’m now thinking that I’ll go with jekyll for the static/info stuff currently at www.literatecomputing.com and migrate just the money-getting parts to Discourse and the up-and-coming discourse-subscriptions plugin. I’m feverishly working on a Discourse plugin that will be a front end for my tools that do installations, upgrades, and other maintenance.
As food for thoughts, here are two websites entirely made with Discourse (the first one uses the Docuss plugin, now deprecated, the second one uses the DiscPage plugin):
Thank you for this framework for making the decision!
I have to be honest and say I’m not sure what this means so I’ll now turn this over to our tech folx. 
@pfaffman Could you say more about this? What are the pain points that you have? I’m still considering CMSs and WordPress is up there.
I would be very interested in staying connected on this!
Yes, this is exactly what I needed. Thank you!
To be fair, I learned php before it was called that, and didn’t keep up with the more modern language that it is now, and my needs are very specific (I need to take money, and do stuff to make a Digital Ocean droplet get created and Discourse get installed on it).
But the last couple times I accepted $500-1000 to do some kind of Discourse/WordPress tweak that I was sure was going to be fast, easy money, I was sorry. And the most recent, I spent a bunch of time and gave back someone’s money. Of course, if they were doing easy stuff, they’d likely not have hired me. I’ve also got another client with a WordPress site with a zillion out of date and un-upgradable plugins. It’s a dumpster fire and somewhere along the way got hacked and has a bunch of porn links in it. Easy enough to avoid.
OTOH, I’ve been using Gravity Forms rather than WooCommerce for the past year or so and have been quite happy using that to take people’s money, both for one-time and subscription stuff (though not integrated with Discourse). (But I can’t get it to fire off the Discourse install exactly when I want it to!)
If you’re doing “standard” stuff and stick to well-supported plugins, you probably won’t be sorry (but I’d use discourse-subscriptions to handle, well, Discourse subscriptions). A quarter of the sites on the internet use WordPress and there’s a good reason for that.
Update: It looks like we’ll be going with two separate systems for our website vs our Discourse. The key factor was that the people who need to update our website content are mostly non-technical folks so they really benefit from using a content management system that’s super easy to use. We use Weebly for people to have an easy way to update content but even better, we pay for a platform that handles our donations platform and contacts management system that comes with a dedicated tech team that we can simply email to make more robust changes like to the website theme, organization, embeds, etc. They’ll handle the Weebly site but not Discourse.
Now that we’ve decided on two different sites, we need to figure out how to make the two coherent. I’ll give a shoutout here to @angus , whose company supports the PianoGroove Community and it has THE most beautiful integration I’ve seen yet (and I’ve seen many!)
Screenshot of PianoGroove Community site
@angus I seriously thank you for the amazing work you do for your clients and for your generosity in making the plug-ins and themes you create open-source. We have a long way to go to get our website and Discourse work for us, but time after time I find that the work Pavilion does is exactly what our open-source, grassroots, community organization needs.
Thanks @debryc 
I would add that it’s all Pavilion members, and not just me, who maintain our work. Our cooperative is team effort.
I’d also add that we just open sourced our Landing Pages Plugin, which allows for entirely independent pages, backed by a discourse instance; another way of fulfiling the need discussed in this topic. That plugin seperates the pages frontend from the discourse client (i.e. it doesn’t load the discourse app), while still allowing for easy integration via a common backend (i.e. the Discourse server).
We’re already starting the process of using that plugin with some of our clients to fulfil similar needs to those discussed here. We’re also looking at developing easy-to-use generailized open source packages of pages based on common uses cases for a CMS associated with a community, useable with that plugin.
Here’s the current list of use cases we have in mind to receive this treatment.
Blog (I’m currently working on this one). Compose content in discourse and then present it in an entirely independent blog page, which you can theme like an actual blog (i.e. like Wordpress or Ghost).
Product, service or feature pages (like ours). Display products, services or features that may include content or data (categories, tags, topics, users etc) from your discourse instance.
“Team” pages (like ours). A page for your team, using the membership (and user data) from a Discourse user group.
Event pages, for both listing and displaying event data from your discourse instance in a styled event landing page. “Event data” here could be combination of Discourse Calendar Plugin data, categories, topics, users (e.g. rsvps), and locations (using our Locations Plugin).
We’re interested in other generalizable use cases that people think would benefit from this treatment. I would note now that there are some use cases we’ve already considered which are less likely to recieve this treatment at this stage:
Shop. While there may be page that integrates elements of a store, online stores require a large array of functionality that will always require a dedicated solution such as WooCommerce or Shopify.
Knowledge Base. This need is already well-served by solutions like the Knowledge Explorer Plugin. A landing page may display a subset of a knowledge base, but entirely replicating the functionality of something like the Knowledge Explorer Plugin (or just Discourse topic lists) would be counterproductive.
We’re also interested in working with anyone who wants to develop such pages, either as a development project in-of-itself (e.g. to improve their skills), for their community, or even to sell. We’re looking to release our own free open source packages for each use case in the medium term (4 to 6 months).
The landing pages plugin, Pavilion’s own pages will always be 100% open source and free. However this is a generalizable structure which anyone with knowledge of HTML and CSS could use to develop a “page pack” if they wanted to. I’ll be adding a “developer guide” to the knowledge docs for that plugin soonish.
The Landing Pages plugin already supports hosting pages in private repositories in the same way the Discourse theme system does (indeed, behind the scenes it is based on and extends the Discourse theme system). This means its already possible to sell access to a landing pages pack if you wanted to. Thay may make it worthwhile for other developers to build such packs.
This approach won’t address all needs for content management associated with a forum, but it could serve a subset quite well, particularly those we reguarly see with smaller and independent communities, as it would remove the need for seperate instances and, critically, the need to share data between those instances via authentication protocols (i.e. sharing user data when you login), webhooks or other data sharing methods.
This could reduce costs and administration, particularly for smaller communities looking to manage relatively contained or targeted content, or static pages, alongside their forum. It will never be a direct replacement for Wordpress or other CMS systems, however hopefully it can make certain use cases significantly easier.
Yes! And thank you!
I’ve only been a Discourse-based community for 2.5 months. What I’ve run into is a need for certain tools that require inclusion of a script.
Calendar Example: there are tools for calendaring or events that I could embed in a page. However, a script is needed in the AND it needs to be triggered for the page.
More general SAS: many times an iframe is NOT the ideal. I do not want my members to have to go over to another site to opt-in, for example, but my opt-in service ConvertBox needs a script and a
As I look to enhance the offerings for my community, the one thing that is pretty clear is that until I “solve” the ability to add script-based embeds easier, it feels like I’m stuck with whatever OneBox supports or using iFrames. I could actually dream of retiring my WordPress site if there were enhanced Pages functionality that offered control inclusion and triggering like this.
I couldn’t code it, but I could see myself financially helping to support this kind of development for the community to benefit from. Thanks!
Embeds are actually possible in both the Discourse UI (e.g. above a topic list) using a theme, and the Landing Pages Plugin. For the latter, I’ve made an example using this little version of the Dinosaur Game. You can play here: Pavilion | Dinosaur Game! (desktop only).
No coding involved for that one. All I did was upload those assets to our CDN (drag and dropped the folder into a digitalocean ‘space’), created a page with the path “dinosaur” and copy/pasted this html (both via the admin UI).
<div class="landing page dinosaur">
<div class="container">
<h1>Dinosaur Game!</h1>
<canvas id="game" height="200" width="800"></canvas>
<p class="controls">press space bar to start</p>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/helpers.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/game-object.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/cactus.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/dinosaur.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/background.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/objects/score.js"></script>
<script src="https://pavilion-assets.nyc3.digitaloceanspaces.com/dinosaur/js/game.js"></script>
<script>
new Game({
el: document.getElementById("game")
});
window.onkeydown = function(e) {
return e.keyCode !== 32;
};
</script>
</div>
</div>
The Landing Pages Plugin implements the CSP and CORS settings of Discourse, which I’ve already set up to handle scripts from our CDN (via the relevant site settings).
I’ll post a full “How to host and embed assets” knowledge-base topic for that plugin to cover that use case next week.
