Just wanted to come back and say what a great product Discourse is! This really is a beautifully crafted discussion platform and incredibly well thought out, credit to the whole team. We've been using Discourse now for over 3 months and it's very difficult to find fault.
In 2010 when we launched our company we only had a series of bad options, I think Discourse has transformed the landscape. The way the product has evolved through small iterative changes, backed by empirical evidence and engaging with users is really how software development should be done!
So well done, and please figure out a way for me to pay you
I just had this error while upgrading to 0.9.9. I am using a multisite setup and from the logs it looks like the first site migrates as expected but the second crashes.
Deploying Discourse on Docker is currently our recommended setup. It avoids many pitfalls installations have, such as misconfigured nginx, sub-optimal Ruby defaults and so on.
The Docker based setup ensures we are all on the same page when diagnosing installation issues and completely eradicates a class of support calls.
Today, all sites hosted by Discourse are on Docker.
This is a basic guide on how to move your current Discourse setup to a Docker based setup.
Bind the web to a different port than port 80, if you are on the same box. Eg:
expose:
- "81:80"
Be sure to enter your email in the developer email section, so you get admin:
env:
# your email here
DISCOURSE_DEVELOPER_EMAILS: 'my_email@email.com'
Make sure email is setup and working by visiting /admin/email and sending a test email.
Make sure you have ssh access to your container ./launcher ssh my_container must work.
If any of the above is skipped your migration will fail.
At the end of this process you will have a working website. Carry on.
Exporting and importing the old site
Ensure you are running the absolute latest version of Discourse. We had bugs in the export code in the past, make sure you are on latest before attempting an export.
On your current instance
go to /admin/backups and click on the button.
once the backup is done, you will be able to it.
On your newly installed docker instance
enable the allow_restore site setting
refresh your browser for the change to be taken into account
I'm trying to understand how Discourse efficently generates the topic list page, i.e. the one shown if one clicks the "Latest" button. It lists the most recently replied-to topics, and lists topics sorted by number-of-likes, and by number of posts, among other things. I have not found any database indexes that would make possible e.g. [efficient lookups of topics sorted by number-of-likes, in a certain category]. For example, there is no index on the column topics.like_count. Yet the Latest page quickly finds topics sorted in all possible manners.
How is Discourse able to efficiently generate the Latest page, restricted to certain categories only, sorted in all different manners that Discourse supports?
Hmm, I noticed that on this page: "So, you want to help out with Discourse" (https://meta.discourse.org/t/so-you-want-to-help-out-with-discourse/3823) there's a todo item "Improve performance of the topic list page" — you don't happen to be doing full table scans right now? If so, then I'm wondering if something like ElasticSearch could be the "right thing" when optimizing the Latest page. ElasticSearch is kind of built for that particular purpose, I'm thinking, i.e. faceted search: restrict to this category, find things, sort by these properties.
(Background: I'm asking this because I'm developing forum sofware, as a hobby project, and I like Discourse and I'm copying some ideas. However I hope this question would also be useful for contributors that are into working on Discoure, perhaps people that want to help out with the above-mentioned todo item.)
So you'd like to help us translate Discourse into other languages? Great! Let's get started.
Translators
Translators do all their work in the Transifex project for files listed there. Create an account at Transifex and join a team for one or more languages. You'll be notified when there are new strings that need to be translated, and get emails when there are announcements.
After contributing translations to the Transifex project, there's nothing more to do. The translations will be pulled into the Discourse repo periodically.
There are some files that are not being managed in Transifex yet, but will be added soon. Those still need to be changed manually and submitted with a pull request. The goal is to eliminate pull requests for translations entirely. We'll get there before v1.
Discussions about the translations and how to improve the process should happen in Meta's translations category.
What Discourse team does
We use the Transifex client to push and pull translations, and to manage which files belong in Transifex.
Setup
Installing the client is easy. First, you'll need a Transifex account. Then, install the client.
To get new translations, we run a script that uses the client and does some post-processing to make sure everything is in a format that works.
ruby script/pull_translations.rb
That's it.
If the output shows that everything was skipped and no files were pulled, then you'll need to use the force option.
ruby script/pull_translations.rb force
The client looks at timestamps on your local files to determine if anything needs to be pulled, which can make it think that your files are newer than what's on the server. That's my theory anyway.
Push English file changes
When anyone changes the english translation files, they need to be pushed to Transifex so translators see that there's work to do. This can be done with one command:
tx push -s
You'll need manager privileges on the Transifex project.
Adding new files for translation
To add a new file for translation, you'll need to do two things:
In the Transifex web UI, go to the resource list and upload the new source file (the english version) by clicking the "Add new resource" button.
Edit the .tx/config file to add the file, and any filename mappings for locales like French, where we use fr and Transifex uses fr_FR.
No, that's fine. I got used to PRs taking some time (not only in discourse, but in general) and you have also other things to work on. And clearly, not everything should be merged without discussion. The way the discussion turned on the other hand bothered me. Especially since it is totally unclear what will and what won't get merged into core and what the process is to figure that out.
As this was a discussion at least @codinghorror had participated in and I had before hand mention I'd want to build it. So I assumed I had a blessing for the approach taken. Obviously I was wrong.
Sure, I'm not saying this wasted time is on you. And I do understand the process better now: unless some of you previously stated publicly you want it in and you want it done that way, any time spend on it might very likely be wasted – especially if that is user facing. Fair enough. So the process then is, pinging you guys (I assume over discourse ) and wait for a blessing before putting any time towards it. Slows down progress and isn't very motivating, but sure, fine with me. (btw, I did that here, waiting to hear back .)
On a bigger scale, I (and many others) love to help and work on discourse, but from here, outside the core team, it is really hard to tell what to work on. Unless you take one of the specs you guys started creating and run with it, there is no way of knowing whether something is supposed to be a plugin, won't make it into core ever you or might actually be highly wanted for v1.0. Like the shared-edits, I wrote as a plugin and only learnt later, you'd love to have in the core (too/instead). Same goes the other way round for the email notification options.
Don't get me wrong, I do appreciate the specs and I think it is the right way to move forward, but it is also very slow as it requires a lot of time from you (from what I see, this lies with @sam only at the moment). But at least I am still missing the bigger picture. I'd highly appreciate a super rough list of features you were planning on having in v1, which ones you are working on and maybe also features you'd like to see but aren't working on. And then the community could (help) sketch those specs out together, it wouldn't be only on you and once you are happy with the spec (and gave your blessing), we can implement them without wasting our time. I think it worked quite well with Badges and we can do that with more.
Really, I'd love to help. It is just really hard to know on what to put the time at good use. So I don't even start anything bigger, though I'd love to do that.
That's why I am frustrated. Not because the PR took very long to just get rejected.
I have reservations about outright blocking by IP. But ...
Even though the number of IPs that can be abused is effectively infinite. I have found it extremely helpful using Registration IP to identify possible and probable problem accounts. - I currently have over 180K associated with Banned accounts.
Most often the IP used to register is not the same IP used to post.
Unless I'm wrong, it seems that Discourse uses the Last IP. i.e. if no posts == registration IP else == posting IP
I strongly believe that having both would be of great benefit for moderating.
Any chance of getting this worked into the Core?
My thinking is we'll be writing custom code to enhance moderation anyway, but we can only work with what information is available.
After visiting a member's profile via the avatar pop-up link in a thread, it is not possible to return using the browser "back" button. Keyboard shortcuts also don't work.
I've been looking at different topics here and your docs on github, but I can't seem to find any details on running Discourse on AWS using RDS. I can see you have a "recommended" and pretty straight forward way of running Discourse with Docker and there are community AMIs as well. I am not particularly worried about how the application itself will be running, whether in a container of some sort (docker) or directly on the host. I am more worried about resilience and scalability - I'd like to run the app on stateless EC2 instances within an Autoscaling group and persisting in RDS (as PostgreSQL is supported now). Persisting on locally running PostgreSQL is flakey as instances come and go (we have Chaos Monkey killing them at random as well) and it does not scale.
Do you have an updated view or recommendation on how to go about installing Discourse on AWS using RDS?
Obviously, if there is not an answer to this, I will contribute here as part of my installation journey to achieve the setup we require.
How can I remove docker completely (with all images, etc) and install it from scratch?My docker version is 0.9.0 and I want to upgrade it. I have some problem with docker, so I prefer to have a fresh install.
I've been working on a new cloud management tool for OSX/Linux called Overcast, and I've written a recipe that deploys Discourse to DigitalOcean or Linode. In my tests the install script takes 11 minutes to complete on both hosts.
Instructions
Install Overcast on your own machine (you should have Node.js and Git installed locally):
# Install Overcast:
npm -g install overcast
# Add your DO/Linode API keys to $HOME/.overcast/variables.json
# Clone the repo to use the recipes (or just download the recipe file alone)
git clone https://github.com/andrewchilds/overcast.git overcast-repo
# Add your SMTP settings etc to ./overcast-repo/recipes/discourse
After it finishes your Discourse install should be up and running at the IP address listed at the end of the output (also found by running overcast list).
If you have any trouble or questions, let me know.
I run Discourse version 0.9.8.5 now on some old linux version with old kernel 2.6, not supported by the docker. I cannot update the kernel. I cannot update discourse to latest version on that server, so I have installed the latest discourse version on diffrent server. I want to have the same database I used to have on the old version. How can I achive it ?
This file is 891 MB. And after Vagrant works its magic, it goes to 3GB.
This is basically a Linux Ubuntu image, with the necessary dependencies pre-installed for Discourse development:
Ruby
Rails
Postgres
Redis
.. and so forth.
Is there any way we can compact, resize, or otherwise make this VM image smaller so it is quicker and easier to download for folks that want to get started with Discourse development?
891 MB is a lot of downloading before you can get going on Discourse. Would love to make this VM smaller if possible!
I want to start a discussion about implementing a feature flags system in Discourse.
Note that the meaning of the term implementing can be quite large: from having a set of rules developpers should follow when developing new and large features to actually developing and integrating a full-featured feature flags system.
PROS
Allows dark launches (all the work is done behind the scene but no UI is updated)
Allows staged rollout (features might be enabled for a limited amount of users at first, then an increasing number of users)
Improves uptime/quality of service (should there be a problem with one feature, any admin would be able to temporarily disable it until the issue is fixed)
CONS
Requires a lot of discipline (especially with removing the flags when the feature is stable)
Increases code complexity (adding a lot more of ifs/elses)
For starters, we could base this system on the site settings as they are already available throughout the whole application. The only caveat would be that we're limited to on/off switches.
What do you guys think?
For those who want more information about feature flags, here's a few interesting links:
It happens a lot that when splitting topics, you more-or-less need to select all posts downstream of a certain post to get a proper split.
This is a pain in the ass in the current admin interface:
you have to manually walk down all the posts and click them, though "select+replies" helps a bit.
the selection UI is crazy slow for reasons I don't fully understand. Like absurdly slow, 1 second wait after each click.
So I suggest we add an "above" and "below" button after "select" to make it easier to select all the posts above or below a certain point in the topic stream:
Hi guys I want to add Bulgarian translation, but I can't register into Transifex. No confirmation email after registering, sent email to support still no answer. I can do a pull request with Bulgarian translation, is this ok?
button.
it.
your backup.
button
.)
