If the error says that reactions, data explorer and solved are still in your yml file, then they likely are. If you believe you commented them out could they have been entered twice?
It’s definitely worth reviewing the config and make sure you edited the yml file which corresponds to your site.
Hi
I have successfully upgraded my forum to the latest 3.4.6 stable version. Prior to this, I was using the standalone discourse-oauth2-basic plugin for authentication.
There is no Oauth2 Basic login in the /admin/plugins.
My discourse version is 3.4.6.
HINT: The plugin ‘discourse-oauth2-basic’ is now bundled with Discourse and should not be included in your container configuration.
Remove the line ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ from your containers/app.yml file, then try again.
For more information, see Bundling more popular plugins with Discourse core
I have to remove plugin discourse-oauth2-basic plugin before upgrade to 3.4.6
Could you please help me understand what might have gone wrong?
Thank you!
Hmm… could it be the fact that you’re on stable?
Following the system prompt, I removed the discourse-oauth2-basic plugin before successfully upgrading to the 3.4.6 stable version.
However, I’ve now discovered that the configuration options for OAuth 2 Basic are missing from the admin dashboard.
If you’re on stable, then none of this topic will apply until after the next stable release in early August. So you should add oauth2-basic back to your app.yml. The original failure must have been for some other reason.
Unfortunately the ‘hint’ logic is not very smart, and isn’t aware of stable vs. tests-passed.
Me too but What we can do about this right? lol I think that more native resources aka plugins even disabled it’s not a good solution to help beginners to there will self-host.
@nat Look this, my quote translation and my reply
No matter how I tried to comment out the clone lines in the plugins sections but it was reading that lines as I wanted to install the plugins. What did I do? Remove the line and finally worked.
When you upgrade you need to check the list of plugins included in the core of Discourse to don’t add it in the plugins section to install or remove that line if you have it in your app.yml file.
I think as these are Pre Installed. There should be options that seperate these 
from the installed List. As the Installed list are removable vs only being abled to be disabled.
Maybe for core merged plugins should be under something like Featured plugins. Or Core Plugins.
With of course maybe an All filter.
Their suggestion is not ideal, but it does work. Example:
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
(Tune as desired)
7 posts were split to a new topic: Troubleshooting bootstrap failures in Discourse
The reality here is that the stable branch is an LTS, and a pretty good one as well. It receives security updates and it’s pretty clear which plugin versions are compatible with it (thanks to the .discourse-compatibility file). I will totally admit that it took a long time before this all started working out, but in the past two years or so, it has - which is a great accomplishment by the team.
Now for the second part of your statement. It’s indeed the case that stable is often represented as something you shouldn’t want. But on Communiteq hosting, we have been giving clients the free choice between stable (“stability first, new updates twice per year, security updates once per month”) and tests-passed (“always on the edge, new features once per month”) for the past 2.5 years and 85% chooses to be on stable.
I get that. But isn’t that a dev issue and not a production issue? I can totally understand that you’re doing this in dev. But adding those plugins in a default production install kind of defeats the idea of having a plugin (which is something not-default by definition).
The only actual production benefit that I see is the very, very edge issue of uninstalling plugins and multisite hosts. (Again, this is a good thing, all other production issues have been resolved over time!)
That could have also been resolved in the setup script by showing a list of plugins that users can check and then adding them to app.yml
But you’re still offering different (sub)sets of plugins for different tiers, right?
I also would have preferred the app.yml uncomment approach.
All these plugins are installed on all our self-serve plans. Some tiers do not have access but they remain installed even if they don’t have access.
We are not changing this decision, so this is simply something people are going to have to live with. I get some people are upset, some people are against this, but this is simply not going to change.
It gives us velocity during development, it defines our preferences, it ensures Discourse as used by the vast majority of people is more stable.
There are other plugins… core plugins are not the only plugins.
A post was split to a new topic: Discourse does not ship an LTS release
I absolutely agree that it makes sense to move popular plugins and their functionality into the core image. Especially if they come from the same coders (CDCK) as the core itself. This is common practice even for other software projects. But we should solve the bootstraping issues - I am still optimistic 
It’s the reason you can’t rebuild.
This definitely would be the better path. It can still be implemented with using the remove plugin code in the previous post.
Adding that to the install script gives a much better options out of the box and is quite common in programs to let you choose whether or not to install certain optional features.
Comparability file is cool. Though Imho a comparability info should be added to topics. With link or instructions for if the TC/plugin is available for both Stable and Tests-passed install instructions.
Thanks for the guide; this works great except for the “automation” plugin, which can’t be removed, as it seems the chat plugin depends on it.
The automation plugin is something that really shouldn’t be removed tbh. It has so many useful potential uses. It needs more time invested imho to get more automations options.
But yeah it is cool there is an option to declutter by removing add-ons that as @RGJ has pointed out that the truly extras recently sort of merged be queried whether these options are desired to install. Maybe even a seperate script for after install just to make things friendlier for self hosted so that some who might want to avoid having to edit the app.yml.