I didn’t receive this prompt. But I followed the error log and removed the lines. Rebuilding again now.
Edit: Other than introducing breakage and 20 mins offline, if these plugins lines are not removed prior to upgrading; Why do we really need this added bloat of preinstalled plugins?
I’m curious about the bigger picture. What is the reasoning for bundling these plugins by default?
Personally, it feels a bit like the direction Windows, mobile OSes, and some software have taken adding more preinstalled components by default (BLOAT) which many of us generally try to avoid.
I’m sure this change was probably discussed with the community before being implemented. If so, no need for a repetitive reply, just include a link to the relevant discussion or announcement so I can read how and why this decision was made.
Bundling in more common plugins also allows more sites to take advantage of not needing to compile their own JS, reducing build times and resource costs.
So I haven’t tapped the upgrade button yet because I use some of the plugins that are now bundled. I’m not scared, I survived the DB upgrade few months back.
Is it better to update my app.yml from the list in op (backed up first duh) or will I get a meaningful error message in the UI which will tell me which ones to remove and halt to do so?
That is kind of answered in the topic title. Popular is often mean commonly installed and used. Bundling them for Self Hipsters means you don’t need to take time to install them. Many plugins and TC eventually were merged with the core program.
The benefit of having these start our as plugins allows for development time to test consumers preferences and fully fletch them out.
Sure there will be a variety of communities that don’t use any of the newly bundled with core. But the larger metric likely shows these are often ones that are installed after setup. Then if course they also have the metrics from their paid hosting of plugins used and not used in the base tier.
I missed 2 plugins before my rebuild. The error log though was much better improved to identify this easily compared to before where you had to scroll up and identify the issue
I think the prompt David mentioned is either the rebuild error or might be on your plugin page for web updating.
No worries it is not always easy to see an answer before posting the question.
I myself Updated my app.yml
Using comments I made mine organized by plugin providers for easier sorting. That being said it was still a bit of a pain. A few posts up I believe someone posted a method to check prior to rebuilding.
No, to be honest as this was an announcement thread I came here and started a comment since the update failed as I didn’t get a notification about having to edit first.
Then once that was resolved I edited post and inquired . But if this is it sole public discussion, thanks will read through.
I can understand the pros but there are definitely cons. So I think not every Discouse forum owner is going to be big on plugins. So it would have been nice maybe to offer it as an option. Maybe during the update a single prompt (yes or no, to installing that list of plugins with update), or…maybe in the admin area a setting or notification that reminds you to set your preference before the next update if you would like to or not.
Is there a page which lists what plugins have been incorporated by date. I don’t like upgrading through the web admin only to fail. I am on 3.5.0.beta9-dev (04dbc622ab).
Maybe I missed the page with dates / versions that have the updates installed. Thanks.
The idea is probably that they’re the most popular plugins, and most people are using some combination of them already (as you yourself are). It’s not really “bloat” because they have pretty much no footprint, and you don’t have to use any of them for anything. This is a lot different than having 20 programs I don’t want installed on Windows, these are on/off toggles (most people won’t see, and you as an admin will have in a list of 300 other things you already aren’t using/changing) not something that is constantly coming up/taking up actual space/set to do things by default. Having a note program installed by default that I don’t want means I’ll end up having two. Having a plugin I don’t want means there’s just an option sitting in a panel
It’s also a lot easier to have on/off switches then having to search through a third-party forum (or endless githubs) looking for something you don’t even know exists in the first place. This was actually the first time I was even aware of a handful of these
I edited my app.yml to remove the plugin lines (per Dan’s advice above) then proceeded to start the update process. I had to update docker manager before everything else as usual and that went normally. Once docker manager was updated I was greeted by a new (to me) message.
I had done a rebuild previously so I knew how and since putty was still open to my server it wasn’t an inconvenience but I was a little surprised I couldn’t use the UI to do the update. I’m just posting this as a heads up to other self hosting noobs like myself. Other then that the update went well, everything runs and works. Thanks team and community
For solved, topic-voting, and templates, you’re right that the plugins themselves are enabled. But those plugins don’t do anything until the features are enabled for a particular category.
I wish you guys would care more about maintaining compatibility and not making us waste half a day every time we update our sites. Tidying up your code slightly isn’t worth breaking people’s sites and wasting their time.
Frankly, I’m starting to look for alternatives to Discourse as I’m sick of my entire site breaking every few months and having to work out how to fix it when none of this is in my wheelhouse.
Sorry to hear about your frustration - though I’m not sure what issues you ran into with bundled plugins specifically here?
We attempt to make upgrades as easy/straightforward as possible, but with big shifts like this, sometimes it’s inevitably going to cause some friction. In this case, we added specific error outputs of how to modify your site’s configuration to make it as simple as possible to fixup.
One issue that I think is at play is that Discourse_docker is not very good at knowing when a command line rebuild is required. And that makes it easy to break your site by clicking upgrade on the admin panel. (at least that’s what I think I’m seeing people complaining about)
I think that I used to see commits that said they did that and I think I don’t see them as much now. I don’t use discourse_docker (much?) myself, so I haven’t paid close attention.
If this user had run a rebuild and not the upgrade from the ux then they could have just done a
./launcher start app
And waited to deal with the upgrade when it was convenient.
