blog

archives

Discourse 2.0 released!

Jeff Atwood May 31, 2018

We released Discourse 2.0 on May 31st, building on Discourse 1.9 from January.

New Admin Dashboard

We’ve completely redesigned the admin dashboard to show off your most relevant and essential community health metrics right at the top, as well as trending searches.

Shared Drafts

Staff can designate a category for shared drafts, and pre-compose topics that only other staff can see for review prior to posting. After posting, all logged edits are removed so the history is clean, and the timestamp is reset, too.

Reply mode toggle

While composing a reply, you can now click or tap the reply arrow to quickly toggle between replying as a new topic, replying to the overall topic, replying to an individual post, replying as a personal message, or even replying as a staff whisper.

Two Factor Authentication

We’re proud to now offer fully integrated Two Factor Authentication as a standard Discourse feature! Enable it in your user preferences, and take advantage of the free Android or iOS authenticator apps on your smartphone for enhanced account security.

Login via Email Link

To make logging in a little more convenient for your community, you can enable logging in via an emailed link in your site settings.

Local Dates

Coordinating meetings or events in Discourse is now easier — insert a local date that will automatically appear localized to the reader’s correct time zone, so nobody gets confused about when to show up.

Tag PMs and Required Tags

Tags are a great lightweight complement to categories, and now to make them even more useful they can be mandatory on topics, per category.

Discourse 2.0 required tags

In order to better organize incoming messages, staff can now tag PMs to group them, too.

Discourse 2.0 tag PMs

Categories and Top Layout

There’s a new homepage layout style that combines the best of both worlds — a list of categories, as well as a list of top posts in the selected time interval, side by side. You can select this layout as your site default via your setup wizard.

Discourse 2.0 categories and top layout

Theme settings

Discourse themes can now have settings of their own.

Discourse 2.0 theme settings

Merging Users and Granting Badges

Looking to give your community members a little extra encouragement? Staff can now grant arbitrary badges to users via the admin wrench action on any post.

Discourse 2.0 grant badge

And, via the command line, merge duplicate users, too.

Improved Full Page Search

We’ve improved the wide search page layout for tablets, laptops, and desktop to make better use of larger screens. We’ve also dramatically improved search relevancy for direct title matches, and added a highly requested “search only in topic titles” option.

Discourse 2.0 improved full page search

GDPR Enhancements

Discourse has offered download of all user content and a user anonymization facility since version 1.0. In this release, we’ve improved these features to make them even more reliable and easy to use, as well as removed a number of places where we were storing IP addresses internally that we didn’t need to be.

Discourse 2.0 GDPR improvements

Discourse has always prioritized empowering communities, and we’ll continue to improve in this area to give your users the control they deserve over their online footprint.

And More!

These are just highlights of 2.0 — there are literally hundreds of other tiny improvements, refinements, and bugfixes in the full release notes.

Easy One Click Upgrade

We launched a public exploit bounty program at Hacker One as a part of our security policy one year ago. We strive to be secure by default, even in the case of sophisticated social engineering attacks, and we always follow up on any security concerns. There are several important security fixes in 2.0, so we urge everyone to upgrade to it as soon as possible.

If you are on our hosting, you’re already upgraded. Otherwise, upgrading is as easy as clicking the Update button in our built in one click updater linked right from your dashboard:

In some upgrade scenarios, you may need to SSH in to update your server. It’s just 3 commands:

cd /var/discourse
git pull
./launcher rebuild app

If you don’t have a Discourse to upgrade, why not? Install it yourself in under 30 minutes, or get a free 14 day hosting trial!

Thank You

Let’s first thank our customers for their direct financial support, without which there would be no Discourse project at all.

Any open source project is only as good as its code contributions. Thanks for the pull request contributions in this release from:

davidtaylorhq
majakomel
notriddle
aviat
pfaffman
peterbourgon
TheBestPessimist
mbobin
ezkl
Toxu-ru
SidVal
xrav3nz
AhmadFCheema
cataphract
davidmh
timdiggins
sudaraka94
nbianca
rohitsden
mikechristopher
DrOpossum
michieriffic
lmpablo
jsuchal
ckeboss
LeoMcA
angusmcleod
yanokwa
misaka4e21
duranmla
jongallion
304
mrnugget
siebertm
yosiat
mcmcclur

rewphus
ibnesayeed
Swarnava Sengupta
Mark Walkom
attritionorg
dmitry-fedyuk
fefrei
vikaskedia
Tiagojdferreira
mtawil
pacharanero
bperel
OriPekelman
muhlisbc
fantasticfears
zjwhitehead
gchallen
fwolfst
wjordan
BadAllOff
tshenry
neerajmalve
dbnicholson
VarunDevPro
kevinelliott
mdoyle13
miromichalicka
Apecengo
jose-hms
caugner
dependabot-bot
rizka10
joebuhlig
barryvan
orlando
ryantm

We had a remarkable number of translators in 2018 who contributed their time and effort translating Discourse into dozens of languages. It’s because of you that so many people around the world can benefit from great free, open source discussion software, and we appreciate your hard work.

Thanks to the greater Discourse community for posting support / bug request / feedback topics on meta.discourse. All your suggestions make Discourse better, not only for your community, but all of us.

It’s hard to believe that version 1.0 was released less than four years ago, and we’ve delivered ten major releases since then! We don’t plan to slow down, either. Check out the releases category to see what’s next in Discourse 2.1 — and beyond.

0 comments

HTTPS by Default

Matt Palmer April 18, 2018

Here at Discourse World HQ, we’re firm believers in the value of security. We fund a public bug bounty program, and we document our security policy and procedures right in the repo. Securing traffic between a forum’s server and its users is important, too, and we’ve had first-class support for integrating Let’s Encrypt into a self-hosted Discourse server since virtually day one of their being generally available.

All of this is to explain why we’re so very proud to be able to announce that every new hosted Discourse instance now comes with HTTPS configured (and enforced via HSTS policy) by default, and the majority of our existing customers have been transparently migrated to enforced HTTPS. Some of our customers can’t be automatically HTTPS enforced; if you see your site is still loading over HTTP, please contact our support team so we can walk you through the changes that need to be made.

The Story So Far

image

HTTPS has always been supported by our hosting, but for a long time it wasn’t feasible to automatically roll it out to everyone. Back in the Dark Times (up to 2015 or so), SSL was a headache to do at scale, unless you were big enough to be able to wangle a special deal with a CA. Sure, certificates cost money, but that wasn’t the biggest hassle. The thing that stopped us, honestly, was the painful story around automation. Basically, there wasn’t any – not end-to-end, anyway.

It’s fun to track the evolution of our SSL procedures by looking at the titles of our runbooks over time. In the Dark Times, we went through several iterations – there was “How to install a customer’s SSL certificate”, then “Customer SSL workflow (Manual Edition)”, “Semi-Automated Customer SSL workflow”, and finally, “Customer SSL workflow (99.5% Automated Edition)”. Whilst we tried very hard to automate as much of the process as we could, getting an SSL certificate always seemed to involve a human in the loop somewhere, and when you provide automated trial signups, you can’t put a human in the middle of that process without making everything terrible.

Thankfully, Let’s Encrypt came along to bring us into the age of certificate Enlightenment. We’ve been big supporters of Let’s Encrypt for a long time; we’ve been donating the hosting for the Let’s Encrypt community forums practically since the initial public announcement, and we donate what we would have otherwise spent on certificates in cash, as well. When Let’s Encrypt became generally available, we re-implemented our SSL certificate issuance pipeline on top of that, and everything was reasonably peachy.

Reality Ensues

image

So, Let’s Encrypt made it easy for us to fully-automate getting SSL certificates for our customers, as they asked for it. Except, there’s a big difference between requesting a certificate for a running site, when a customer asks for it, and making sure you’re getting a certificate issued as soon as the site’s DNS is configured. Even detecting that DNS is correctly configured, given the wide variety of, shall we say, “interesting” configuration choices some people make, can be a challenge. This took a lot more time and ingenuity than getting issuance working. Requesting a certificate from Let’s Encrypt and dealing with validation is about 10 lines of Ruby (with the help of the acme-client gem) and a bit of HAProxy magic. Dealing with all the special cases and exceptions in people’s DNS and proxy setups is quite a bit more code.

As an added challenge, a large part of our team has been hard at work since mid last year building out a completely custom, hyper-scale AWS-based hosting environment for a large game company. That work, which has now borne fruit, diverted time and attention away from building out universal SSL as quickly as we would have liked.

The Final Hurdle

The final hurdle is the problem of migration. We want all our existing customers to automatically have the benefits of our SSL labours. There’s a few things that get in the way of just flicking the switch for customers who have been with us for some time.

First off, forcing everyone to use HTTPS, via redirects and HSTS config, breaks some things. The biggest issue is the lack of a universally-supported way to say to a HTTP client, “transparently make this exact request again, but to this other URL”. There are newly-standardised HTTP response codes for “redirect with the same HTTP verb”, but they’re not supported by all browsers and HTTP libraries, and they sometimes prompt “do you want to do this again?”, which isn’t what you want for a smooth transition.

External authentication providers get in the way, too. They often whitelist the return URLs they’ll accept. When you call out to an authentication service, you typically send along a link which the browser should be redirected back to after authentication is complete. Sending an HTTPS link, when the authentication provider expects an HTTP one, results in authentication errors. Very not cool. We can’t fix this ourselves, either – we don’t have access to our customers’ Google, Facebook, and Twitter applications to update the whitelisted URL.

Finally, there’s the age-old problem of mixed-content warnings, which pretty much everyone who has stood up a HTTPS site has dealt with at one time or another. Thankfully, the vast majority of those we can fix on our customers’ behalf, by making sure the site being linked to supports HTTPS, and modifying the site config to add a strategically-placed “s”.

Security is no longer optional

Our deployment of HTTPS by default is coming at just the right time. Popular browsers such as Chrome and Firefox are in the process of rolling out changes to mark HTTP-only sites as “Not Secure”, like so:

google_chrome_http

It’s reasonable to assume that this trend will continue, with other browsers following suit, and the warnings getting more and more scary over time. So, regardless of where you’re hosted, now would be a good time to start making sure all your web properties are being served over HTTPS.

Full of win

It has been a bit of a journey, but in the end, we’ve gotten to where we want to be: new customers get HTTPS enforced by default, most existing customers have HTTPS enforced by default without their even noticing, and for the remainder, we know exactly what they need to do to complete the upgrade.

successkid

2 comments

Effectively using Discourse together with group chat

Erlend Sogge Heggen April 10, 2018

Courtesy of Claudio Nichele and Jon Worth - https://www.flickr.com/photos/cnichele65/14060880832/in/photostream/
Most modern businesses and organisations today are using some kind of team chat application. The usual suspects are Slack, HipChat, Discord, Mattermost, Rocket Chat, Riot, and Gitter, to name a few.

While chat is immediate and primarily synchronous, communication in Discourse is gradual and asynchronous. We’ve seen far too many community managers treat these two modes of communication as competitors. Quite on the contrary, chat and forum communities can complement one another beautifully, and we aim to show exactly how by breaking it down into three different levels of understanding.

  1. Ephemeral vs Permanent
    What is the difference between a chat and a forum community
  2. Strengths and Weaknesses
    When to use which tool
  3. Complementary Workflows
    How to use both tools together most effectively

Ephemeral vs Permanent

The discussion that takes place in a chatroom is best described as ephemeral, meaning:

Something which lasts for a short period of time.

While a chat platform might keep a searchable record of all your conversations, the highly unstructured nature of chat makes it unsuitable as a long-term storage of knowledge.

In direct contrast to the inherently ephemeral nature of chat, forum discussions are permanent:

  1. Without end, eternal. Nothing in this world is truly permanent.
  2. Lasting for an indefinitely long time. The countries are now locked in a permanent state of conflict.

One mode of discussion is not better than the other. They both have unique benefits that go hand in hand with best-practice use cases.

Strengths and weaknesses

Chat is an essential communication tool, but when used excessively it can have a negative influence on community health. Whereas with forum communities, perhaps the most common misstep is to start one before your project has the necessary momentum, and you end up with a ghost town.

At Discourse we like to think of chat and forum as your extended team’s collective “short term” and “long term” memory, respectively.

Group chat is great for…

 

  1. Minimum viable communities
    Get two people in a chat room together and you’ve got yourself the beginnings of a healthy community. As long as there’s some chatter on a regular basis, the room will come off as lively and inviting to other prospective participants. This is a great onboarding strategy in the early days of a community, but there is a hard limit on how far it can scale. Doing things that don’t scale can be a winning strategy for startups and burgeoning communities alike; the key is knowing when you’ve outgrown your initial growth strategy.
  2. Real-time resolutions
    “where’s our invoice template again?”
    “I need fresh eyes on this weird query”
    “welp, I think I just broke something”
  3. Urgent notifications
    Servers are on fire!
    An urgent email was just received!
  4. Socialising
    While social chatter is a rare occurrence on a forum, this is the norm in chat, and it happens in every room, not just a designated #off-topic channel. Give it a little time and you won’t be able to avoid it: it’s about to get personal.There’s something about being present together in the same slice of time, the here and now, that lends itself to Getting Real. Getting personal on a forum feels more like broadcasting, made even weirder by metrics (Likes, Replies, View) that can unintentionally imply that Bob’s piece of personal news didn’t “perform” as well as someone else’s. Chat imposes much less scrutiny on your shared content.

You’ll find this list to be nearly identical with that of Jason Fried’s excellent writeup on group chat on behalf of Basecamp. While eerily similar, we really did come upon these findings independently! The proof happens to be permanently recorded on meta.discourse.org and in many other communities where we discussed this.

Forum discussion is great for…

 

  1. All-inclusive dialogue

    The asynchronous nature of a forum community effectively lowers the bar about as far down as it can go. You’ll get a much greater diversity of input if you solicit feedback from anyone who’s available some time in the next 24, 72 or 168 hours as opposed to right now.

    Another little discussed benefit of “slow” asynchronous conversations (fun fact: very few things in life, especially in business, are actually URGENT) is that it encourages walking away from the discussion for a while, which is scientifically proven to improve critical thinking.

  2. Communities of scale

    Similar to what version control did for code and wikis did for encyclopaedias, community platforms like Discourse have long since solved the “too many chefs” problem for discussion at scale. Hundreds or even thousands of people can discuss an equal amount of topics simultaneously on Discourse because (1) discussions are broken up into logical topic blobs and (2) long-form input is strongly encouraged over rapid-fire back-and-forth debating.

  3. Knowledge storage & distribution

    The permanence of a Discourse topic makes it an excellent storage of knowledge. Some will argue that forum posts become outdated, but we’ve found that when a particular solution stops working then users will promptly resume the topic discussion until it arrives at a satisfactory solution once more.

    This is further helped by

    • Search-friendly content
    • Discoverable content, helped by Categories, Titles, Participants, Top rankings and strictly linear discussions with minimal digressions and noice.
    • Extra exposure for content with many Likes
    • Marking solutions as the official answer
    • Collaborative editing with full revision history
  4. Civilized discussion

    Most current group chats have very limited moderation controls. And while they may eventually catch up, the experience will always be sub-par simply because it’s real-time. If you hold someone’s comment for moderation in chat, that’s incredibly frustrating because you’re expecting live discussion. On a forum on the other hand the expectation is that you’ll get a reply within a few hours or even days after posting, so if your post gets flagged? No biggie, you can wait.

Complementary workflows

So let’s assume you’ve already made the wise decision to use both chat and Discourse for your community and you understand when to use which tool. But how do you best use them together?

Continually enforce your communication policies

It’s important that your project’s community leaders (which should ideally translate to every major contributor to your project) actively enforce the norms that you’re striving for. Lead by example and politely nudge newcomers in the right direction when they’re asking for guidance in the wrong place or in the wrong way.

New user: How can I do X?
Helpful user: Good question. Please re-post this to our public forum so that any answers you receive can be searched for and read by anyone else who might be asking the same thing.

We’ve heard of some communities utilising bots with some success for this type of best-practice enforcement. If anyone has any such stories to share with us, please send us a mail at team@discourse.org!

Feed highlights from Discourse into chat

Important discussions in Discourse should be fed into your chat for extra exposure. There are many ways to do this:

It’s important to note that you shouldn’t be mindlessly feeding all of your Discourse discussions into your chat. Make sure you only cross-post the major highlights, i.e. just a few select categories or tags and the occasional manual curation.

Let chat conversations run their course, then post a summary

When a conversation takes place in chat that is related to an existing thread on Discourse, point out the link to the Discourse thread in chat. Don’t try to move the conversation over while it’s in flight though – that’s often disruptive. Instead, if anything new came out of the chat, encourage the primary chat participants to summarize it in a follow-up post on the Discourse topic.

Similarly, any chat content with lasting value to other community members should be exported over to Discourse once the initial burst of chatter comes to an end. Examples include:

  • team members walking through a problem together and arriving at a solution
  • deep conversation that is sure to continue for multiple days
  • new user who asked a simple yet frequently asked question
  • minutes of a meeting

Specifically for Slack, we have a very handy tool to help with this.

/discourse post 20 will create a draft topic containing the last 20 slack messages. See this how-to for more info.

This is currently only possible with our Slack integration. We welcome other group chat services to talk to us about how to make this possible for their platform. Please contact team@discourse.org


For some further reading, check these out.

Must-reads:

Also interesting:

3 comments

For more blog posts, visit the archives