@pichalite Thank you for the response.
That was most peculiar, but I reset the config.json to be how it was and it stopped having this error.
Besides I still think it's best to check data.config, before extracting data.config.loggedin anyway.
I know I should probably cool off before posting but I am getting really fed up with this project. Every single time I do an upgrade I end up having to wipe everything and start over. Thankfully I get to keep my redis database and the user posts and stuff but half the damn plugins dont work anymore, the templates are broken, things are randomly missing settings... Like why should I even bother. Once I get it working I'm never EVER upgrading again. I'd switch to a different platform if it wasn't too late
To add some specific complaints instead of just ranting:
This all seems very shoddy. The cynic in me thinks this is an effort to drive people toward the paid version of nodebb but I refuse to believe that. I've interacted with some of the main devs here on the forums and they always seemed very helpful and open. But this application is an absolute minefield to maintain. At this point I need to make a full backup of the entire directory in addition to the database to be safe while upgrading (which is not the recommended process, they recommend you use the nodebb git repo, check out a new tag and run the ./nodebb upgrade script). I'm going to have to treat nodebb like it's nitroglycerin from now on.
If I'm doing something wrong or there's a new accepted way please enlighten me but for now I'm going to return to smashing my face into my keyboard while I figure out a way to recover this disaster.
Why is there no way to roll back once you upgrade?
Well, it is mostly possible. The only time it isn't is when we make a database change that isn't backwards compatible. Writing a second version of upgrade scripts for every database change we make would be twice as much maintenance for something most people wouldn't use.
Why is there no way to record what version of plugins you have installed besides copying the entire node_modules directory (that is ignored from source control btw)?
./nodebb plugins will list out all active plugins on your forum
Why do half the plugins and all my templates break when I upgrade?
We try to avoid breaking changes but NodeBB is still under heavy active development. We try to warn people to always check their site setup in a staging instance before upgrading, especially if that upgrade is marked as breaking. We also tell people to backup their NodeBB install and database before upgrading. Our versions are kinda weird and don't really follow the conventions but we're working on that. For now, our versioning works like this:
In the future we plan on moving to Semver where
Breaking changes are a part of life, and while we try to minimize them, sometimes they are necessary to implement features that people want. Other times, they slip in accidentally.
We have a very large API surface and imperfect tests and documentation, which we are working on to improve.
I'm not sure. Please share how you normally upgrade. Also, if you'll share what version you upgraded from and to I'd appreciate it.
Sorry for the necropost but I'm just now getting back into this. I was so upset I had to take some time to cool off. I was upgrading from 1.1.x to 1.5.1 and I guess that was what the issue was. If i could just go back to the old way it was and forgo upgrading I would. I did backup the database but not the node_modules so I have no idea what was installed and what version.
Is there any way to tell what version of nodebb was installed by looking in the database somewhere? It's a redis DB btw if that matters. I opened the dump file on my workstation and poked around looking for some info but the current nodebb version didn't seem to be included anywhere.
One tip. This depends on your service provider or your infrastructure.
Take a snapshot of your server before updating.
those are 3 ways of having a rollback plan. One can create more elaborate ones, if the need arises
@kingcat You can see what version you were on by running
git reflog, since it will show you a log of changes (pulls, checkouts, etc). From there you can see individual commits (on github) and determine what version you were on.
@julian Unfortunately I ended up nuking the repostory and rechecking it out mulitple times trying to fix it.
In the future I know I can't trust the database entirely. I'll have to backup all the files (that I thought were ephemeral).