Over the next few weeks, we’ll be moving a number of popular Discourse plugins into the core repository. That means that Discourse will come with a larger number of plugins by default, and it’ll be easier for us to keep them all tested & up-to-date.
All these plugins will remain disabled by default, so this won’t have any visible impact on existing communities. If you use a managed hosting service like discourse.org, you don’t need to do anything.
Self-hosted communities
If you self-host Discourse, and are already using one of these plugins, you’ll be prompted to remove the relevant line from your app.yml file before your next rebuild.
Development Environment
If you already have one of the plugins installed locally, and then pull the latest version of Discourse core, one of two things will happen.
If you use symlinks for your plugins, then you’ll get an error during git pull. To resolve the issue, delete the symlink, then run git pull again
If you clone plugins directly, then the git pull of core will succeed, but you will have some surprising ‘unstaged changes’ caused by the nested git repositories. The best way to proceed is to delete the affected directory, and then restore it from main. For example:
Bedankt. Met mijn beperkte kennis van ontwikkeling en programmering wil ik u toch een vraag stellen. Kunnen deze plug-ins, die oorspronkelijk componenten zijn die aan een basisinstallatie worden toegevoegd, op een dag hun plug-in-karakter verliezen en een volledig onderdeel van een basisinstallatie worden, zonder dat ze überhaupt plug-ins worden genoemd?
Dat zou kunnen, ja. Met name de authenticatie-plugins (bijv. apple-auth) zullen waarschijnlijk uiteindelijk in de kern worden opgenomen, net als onze andere ingebouwde authenticatiemethoden (bijv. Google, Facebook, etc.).
If I recall correctly from my experience, you will only be able to update docker at first. Once you’ve updated docker, you will be shown a message in the update UI explaining that you have to update via the command line, and how to do it.
Then when you update on the ocmmand line you’ll see the HINT for each plugin you need to remove from app.yml as explained in the first post above.
This is a good update but was this really necessary? Giving a rebuild failure seems a little bit harsh to me.. a UI warning or automated update (or just ignoring them entirely) would have been nicer than putting a gun to my head and saying “remove these now”
This caught me out last week when I tried to update via cmd line and it failed (reactions plugin).
It caught me out again when my cmd line update failed again this morning (data explorer plugin).
I would very much welcome a warning on the cmd line before the update process starts, and then inevitably fails.
Twice in two weeks now my updates have failed and this has meant my Discourse is offline for the duration of time it takes me to debug the issue, edit configs, try again, etc - all while in a mild state of panic because everything is broken.
Ik ben benieuwd, heb je deze lijst met plugins verkregen uit Discourse-installaties in het wild? Het komt bijna overeen met 50% van mijn eigen hoofdinstallatie!
Ik vraag me af, zou het bundelen van al deze plugins in de kern de forums opblazen? Er zullen waarschijnlijk een paar plugins zijn die beheerders niet op hun forum willen hebben (bijv. Discourse AI), maar geen andere keuze hebben dan deze toe te voegen. Het kan natuurlijk worden uitgeschakeld, maar ik vraag me af of de toegevoegde bestanden en dergelijke de forums zullen vertragen?
On the client side, Discourse does not serve any javascript assets for disabled plugins, so there won’t be any impact there.
On the server side, for properly implemented plugins (which all of these are), customizations from plugins are bypassed when they’re disabled. So yes technically there might be a slight overhead to check for enabled/disabled state, but it should be miniscule.
The plugins we’re merging here are the ones which we run on every single instance of Discourse on our discourse.org hosting. So they’re all very well-tested at scale.
Is er een reden waarom jullie dit allemaal tegelijk doen kort voor de release? Voor vertalers die dit in hun vrije tijd doen, is 3.000 extra strings binnen twee weken veel. En zelfs in talen waar de plugins eerder vertaald waren, moeten alle 3.000 teksten opnieuw worden proefgelezen. Af en toe zou 300 waarschijnlijk beter beheersbaar zijn dan 1.500 per week.
For self-hosted communities already running one or more of these plugins, will the plugins lose config data when removed from app.yml and folded into core?
I’ve got the AI plugin set up exactly how I want it; if I need to reconfigure it (or at least write down the config options so I can re-add them), it’d be nice to know now.
We’ve been trying to make this as smooth as possible for translators by making use of the translation memory in crowdin, so that translations don’t have to be re-made from scratch. But still, I agree, there are a lot to proofread.
I wonder if there’s more we can automate here, e.g. maybe we can “auto approve” any strings from these plugins, instead of requiring a proofread
