The discussion revolves around upgrading Discourse from version 1.6.1 to the latest release, primarily to integrate the Babble chat plugin. anil explains that their customizations—modifying core JS files and adding models—are not encapsulated in plugins, making upgrades risky. pfaffman suggests setting up a test site and using git pull and merge, though nicatronTg and sam warn that direct modifications are unsupported and will require significant developer effort to reconcile. jomaxro shares a cautionary tale of a similar situation causing instability, urging users to refactor customizations into plugins before upgrading. Regarding multi-version upgrades, jomaxro confirms it’s generally safe to jump multiple versions (e.g., 2.1 to 2.3), as Rails migrations handle schema changes, but stresses taking full backups first. s-moon asks about backing up a Docker-based install; jomaxro reassures that persistent storage (like S3 for uploads) remains intact, and rebuild failures won’t corrupt data—only downtime may occur. The consensus is: refactor custom code into plugins, backup thoroughly, and proceed with caution.
On Discourse version 1.6.1 we have customised as per our requirement and added multiple models both on rails and javascript side and some customisations in Javascript libraries as well.
Now we are trying to integrate Babble chat plugin for which we are facing many issues like manually placing the missing JS files and updating relative path of libraries imported. So we are planning to upgrade the discourse version to latest with which we can easily integrate babble chat plugin. Below mentioned points are my concern.
- Easy way to integrate babble chat plugin with discourse 1.6.1. - Upgrade discourse with out effecting the existing functionality(created by us).
I really hope you modified Discourse in some way other than modifying the Docker container directly. Assuming you have these modifications stored in source control, pull and merge is your best route. If you didn’t you’re going to be in a rough time trying to find your modifications, transfer them, and test them.
No, there is no command, you performed your customization in an unsupportable way. You are going to need a very skilled developer with lots of time to get you upgraded to latest, something I strongly recommend doing cause there are may public security vulnerabilities that have since been patched.
Wanted to chime in here with a personal anecdote: A few months ago I took over managing a Discourse forum where I work. The forum is used seasonally, for about 5 months, then not touched for 7. When I took over we were having all sorts of intermittent issues. After the forum went “partially down” 3 times in 4 days, it was decided that I’d work with our IT staff to figure out what was wrong. Almost 6 hours later, we found that a former dev modified Discourse files, set them to overwrite the existing Discoures files each update, and this was the cause of our issues. 4 days of nearly full-time work later, we’d managed to stop the files from being overwritten, develop a plugin, and get everything working again.
Why am I sharing this? I just want to emphasize that modifying Discourse is unsupported (read: not a plugin) ways is bad. While we only had a few files modified, it caused us major issues that fortunately were caught before our forums went live again for the season. Please take the time to un-modify your install, put the changes into a plugin, and only then attempt an update.
Yes, it is generally safe to upgrade multiple major releases at once. Rails migrations handle that for you.
However, it is always a good idea to take a full backup before major changes like this, so you have the ability to restore to a known working state in the unlikely event something goes very wrong.
I am in the exciting position of needing to upgrade from v2.1.0.beta2 +119 to 2.4.0.beta4.
Naturally, I am a little nervous about this so wondered if you could tell me how I could take a full backup?
We’re running this in a docker container. We also do backups from within the admin panel, daily, but if I try to upgrade with ./launcher rebuild app and it falls over, how do I go back to the previous (working) version? From what I can see, the backups simply contain the SQL for the Postgres db. All images are stored elsewhere in S3.
If you can provide any guidance, I would be really grateful.
Yes, that should work without issue. A rebuild is highly unlikely to fail, and if it does nothing should break. Your site will be down, but the data is safe in a persistent storage location (not in a docker container).
Taking a backup is a great idea (always backup) and yes, your uploads are not downloaded into the backup. Your database references the uploads on S3, and will continue to do so in the backup and if restored. As such, downloading them isn’t needed, they’re safe already in S3.
If anything goes wrong with the rebuild, post the log output here!