I want to upgrade to the latest version, but I have some issues with some theme components.
They’re all my own components and I moved them from GitHub to GitLab. Now if I want to upgrade discourse (not from within discourse), I get errors because they are not available anymore. I tried to delete them inside of discourse but they won’t get deleted.
Now my question is: where is the path to delete them directly on the server? I can’t find them.
I tried the safe-mode but I can’t access the forum in safe-mode.
EDIT:
Is there a file like the app.yml where all themes and components are stored so I can delete the list and rebuild discourse without them?
I think this is the problem you need to solve. The correct way to approach this is to delete all themes and theme components that come from the old location, and import new ones from their new locations.
This isn’t possible because then discourse is in an infinity loop. That’s the reason why I asked how to delete them in an other way.
I can’t even get into safe-mode.
A reinstall isn’t also possible because the backup is too old.
After ./launcher rebuild app I have seen that the forum isn’t available for guests.
I think disabling components by hand in the database is the kind of solution that could be the last resort here. It is highly risky but doable if there are no options.
Disabled components at least will let the rebuild succeed which will in turn allow access to the admin interface to remove & reinstall components from gitlab.
They’re not stored in the DB, however, their activation/deactivation state is stored in the DB itself.
I don’t exactly recall the steps but I recently fixed a similarly broken install.
The most important thing here is to know if your container is still running. If it is running, I may be able to advice on how to try to disable offending components from database.
Well, ok, that’s a problem.
Isn’t it possible to use something like pgAdmin to get access to the db directly?
I don’t know the ID of the theme and the components because I haven’t access to the admin area anymore.
Edit:
I have figured out the theme and components.
Disabling them doesn’t work, so how to delete them with rails c?
I even tried to get rid of them with rake, but rake can’t delete them too.
rake themes:uninstall https://github.com/link/to/git.git
rake aborted!
Don't know how to build task 'themes:uninstall' (See the list of available tasks with `rake --tasks`)
Did you mean? themes:install
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
(See full trace by running task with --trace)
Or what is the right command to delete things with rake?
I get a list with commands with rake --tasks and rake -AT but there’s not a command to delete a theme or a component.
With rails c I can disable a theme but with a reload it’s still the old corrupted theme.
I think this fix here addresses only “build broken because github URL is broken”, right?
For builds that are broken because there’s an error in the javascript, is there a similar way to disable or remove themes from the command line that we should put in a howto?
EDIT: like the fail when “Alternative Logos” is included. . . .
I’ve been thinking about this for a while as well, and my opinion is that this makes sense for some communities but not all. Some communities treat their customizations/themes as a fundamental part of the site’s identity and they would really want to know if there are problems with their customizations when their site is deployed, and other communities use a vanilla Discourse install with a few customizations/component sprinkled on top and they could easily live a few days without them.
Maybe the Auto update when Discourse is updated checkbox should off by default when installing a new theme/component? It’s currently on by default and I think it should be off by default, but this needs a wider discussion…
No, the code snippet above (the 2nd line in particular) disables auto-update-on-deploy for all themes/components that are currently installed, so it should fix any builds that are broken due to themes auto-update including JS/CSS errors. The howto should only include the 2nd line.
I just ran into this problem too. If you have a component linked to a public repo and then you make that repo private, rebuilds fail. It’s unpleasant because users can make changes that can break the site for sysadmins months later.