@togan Cool. Glad you got it working. 😎
Have fun and enjoy NodeBB! 🌻
P.S.; For future reference, the Technical Support Category is a better fit for queries such as this, as the "bug" was configuration side, not NodeBB itself. ✌
I don't know what kind of issues you're having. I don't know your setup. I don't visit Mongolassi, I listen and help with issues here. By default, a NodeBB upgrade will not upgrade the emoji-one pack to the new version.
The upgrade process we use, the only one that we know works, does upgrade it to the latest version during the upgrade process. If we don't do that, things aren't compatible and it breaks. It's "always" been part of a basic upgrade AFAIK. I've been on NodeBB since 0.3, I think. We've never had an upgrade process that didn't keep all plugins at the latest.
I had already posted that this was the latest on GitHub as requested.
Sorry if I sounded gruff, I've been asked this same thing like four times as if I'm an idiot. I had just been assuming that emoji were not really being addressed and had been ignoring it. But people kept prodding me saying that the latest update was significant and it was expected to maybe work again.
I can't uninstall it because of the "undefined" problem that NodeBB appears to have without it (also on GitHub). Maybe that's the underlying issue, that NodeBB has a syntax error in the core install and some quotes or something are getting consumed from the emoji code that compete it but leave something broken in the emoji plugin as a result?
So during the upgrade, you were prompted to upgrade nodebb-plugin-emoji-one to the lastest version and did. Got it. I was referring to that not being done automatically by the upgrade utility.
Not prompted, per se. AFAIK, and I know people use different processes, the upgrades are only reliable if a full npm update is run during the process. If we try to start NodeBB without doing that, we often get breaks and it can't start. We always update automatically as it is all scripted, so if this changed at some point, we'd not know. We've used the same upgrade script for a few years and, like I said, all I know is that it was required when it was first made and I was unaware of any changes to that requirement.
@scottalanmiller all that should be necessary to upgrade NodeBB these days:
git fetch git checkout v1.7.x git pull ./nodebb upgrade
git pull ./nodebb upgrade
Would you mind sharing your script? If there are other steps they might be causing these issues.
Edit: this doesn't include restarting nodebb
Not much of a script but here it is...
git fetch; git pull; ./nodebb stop; npm i; ./nodebb upgrade; npm i; ./nodebb start; ./nodebb log
And for the 1.7.0 to 1.7.1 release we had to switch to this...
git fetch; git pull; ./nodebb stop; npm i; rm -rf ./node_modules/eslint* ; npm i commander; ./nodebb upgrade; npm i; ./nodebb start; ./nodebb log
Obviously our backups are not in that script, we do that manually (not sure why, actually.) Probably because we backup up to ten minutes ahead of doing the actual update as we can do that without impact and ensure we are at a lull before going down for a few seconds. So we keep it manual. We don't have a copy of the main database that we use for testing, but we have a series of separate sites that run the same code that range from pure test (their own data, but no live users) to insanely low use (users less than once a week) to moderate use but non-business before getting to the big main site. So we use that as our testing profile.
I don't know why the eslint issue occurred, it seems to have happened for a couple people. There are a few issues I can see with your script:
git fetch; git pullis redundant,
git pullis just shorthand for
git fetch && git merge origin/[current branch]
&&will ignore errors in previous steps
npm imay have errored out when you upgraded to
v1.7.0where we changed how plugins get installed
package.jsonin our repository, instead using a default
package.jsonwhich is used to update the locally held
package.json. This allows for
yarndefault install behaviors to be compatible
npm ianyways, so you don't need
./nodebb start -lor
./nodebb sloginstead of start then log