.category-children-item {
  display: flex;
  float: none !important;
}

seems to do the trick.

EDIT:
after looking a bit at the topic @crazycells linked and looking at this for a few more minutes I think the better solution would be:

.categories .category-children {
  display: flex;
  flex-direction: column;
}

It doesn't affect how it works, but not using !important is the improvement here

Oh, and if you want some distance between the items just add margin-top or margin-bottom to .categories .category-children-item.

It's already been added some time ago and will be in 1.13.0:
https://github.com/NodeBB/NodeBB/commit/1796b65d34e5762e95e1bd305d3bc90983059811
The original issue on GitHub:
https://github.com/NodeBB/NodeBB/issues/7770

alfazaz created this issue in NodeBB/NodeBB

closed Disable user to quit a group (permission) #7770

0 julianlam committed to NodeBB/NodeBB

feat: option to restrict group leaving, closes #7770

v3 is not just "a better reCAPTCHA" and it is not replacing v2.

v3 only offers "invisible" reCAPTCHA, but even if Spam Be Gone supported that (it doesn't yet) it still wouldn't work because it passes different data.
reCAPTCHA v2 is binary - either user is a robot or not.
v3 doesn't just pass "true||false" but instead passes a score from 0.0 to 1.0 and it's up to the application to determine what score is a success. It also never shows user a challenge as it's not supposed to interrupt the user in any way.

So to sum it up: for Spam Be Gone to support v3 would mean changing the way it handles reCAPTCHA and I'm not even sure if it's a good idea. v3 is supposed to continuously chceck if user is a bot without interruptions, so it's best used for frequent user actions like posting or login, not for things like registration that happen once per user and it's not a big deal if it interrupts user with a challenge. So I'd say it'd be better for Spam Be Gone to extend its functionally to use v3 on login and posting, and leave v2 on the registration page.

The only current milestone on GitHub is 1.13.0, so I'd assume that it will wait for that release.

If you need it now you can manually modify some NodeBB files:

• in src/middleware/user.js modify line 135 from

					user.isModeratorOfAnyCategory(req.uid, next);

to

					user.isAdminOrGlobalMod(req.uid, next);

• In src/socket.io/posts/tools.js change line 75 from

				if (!results.isAdmin && !results.isGlobalMod && !results.isModerator) {

to

				if (!results.isAdmin && !results.isGlobalMod) {

• in src/controllers/accounts/helpers.js change line 144 from

			if (isAdmin || isSelf || ((isGlobalModerator || isModerator) && !results.isTargetAdmin)) {

to

			if (isAdmin || isSelf || (isGlobalModerator && !results.isTargetAdmin)) {

That should remove all privileges from category moderators while leaving them for administrators and global moderators.

I'm really looking forward to 1.13.0 though, as I've not only added two things that will be useful for me (not to mention useful changes by NodeBB staff and other contributors. And the refactor), but also because I use the master branch for my dev enviroment the plugin I'm currently writing uses async/await where 1.12.x doesn't support it yet, so to avoid rewriting it twice I had to use util.promisify to make current callback based functions work like async ones

EDIT: btw. It seems like 1.13.0 might be close as there are no issues left assigned to this milestone. So while I'm not NodeBB staff and can't tell you when the refactor will be finished and when they think there are enough changes for an update to 1.13 I doubt it's really far away

If you want two columns try this:

.categories .category-children {
  display: flex;
  flex-wrap: wrap;
  flex-direction: row;
}
.categories .category-children-item {
  flex: 1 1 45%;
  margin-top: 1vh;
}

You can increase the number of columns by changing that 45% to some lower number (it actually can be a little higher, but it seemed to go to 1 column on above 48% for me. 45% was just more "round" number close by
That margin-top is there because otherwise the items were touching at the top and bottom and it didn't look good for me

The only problem here is with longer subcategories - especially with mobile devices. I think if I wanted to do something like this I would try to change it to just one column if the screen width is too small.

There is a global chat plugin: https://github.com/NodeBB/nodebb-plugin-global-chat

@crazycells
Responding from a phone, so I can't make a full solution right now, but I think the best way would be to select it from correct <li> element using cid. Like this:

.categories li[data-cid=x] .category-children {
...
}
.categories li[data-cid=x] .category-children-item {
...
}

Where x should be replaced with the cid of the category you want to style.

I didn't check this, but it should work

You could also use :nth-child, but I think that's worse because reordering categories or adding subcategories to one that didn't have them might break it.

Admin>Manage>Privileges
Just select a category you want to apply this restriction to (if you want it to work globally, you can select any category and just copy its settings to all) and remove "create topics" privilege from everyone but Global Moderators.

And actually I'm not entirely sure, but I think cookies that are needed for the service to work (like session cookie that would cause some problems when disabled by an anonymous user and make logging in impossible) don't actually need to be opt-in.
Still - it would be nice to have a uniform cookie opt-in banner that could be expanded in plugins. Even if you couldn't opt-out of session cookie due to the way NodeBB works. Because plugins that add analytics, or even some social media buttons might need that kind of a banner.

NodeBB by default doesn't do anything when a lot of categories are present. There is no pagination on categories page, no sorting or filtering and no searching for a category.
If you want to handle a lot of categories, you have to do it yourself. I started working on a plugin for filtering and sorting categories some time ago, but it's far from being finished (basic sorting works, but there is no acp for setting up filtering and sorting rules - you just have to modify them in code. And you have to manually add the sorting as a widget to categories page). I'll probably publish it somewhere here when it's ready, but for now and for other functions you want - you unfortunately have to make them yourself.

If you just want to make it work - try changing the port number in config.json.

But it definitely seems like there are some leftovers from a running instance that make the system think 4567 port is taken.

You can check what process that might be using netstat command (or more specifically, netstat -tapen will show you tcp connections and processes that utilize them). And then try to kill it.

@azeus said in Exifs missing in the resized uploaded photos.:

Thank you but I don't see anything about stripping the exif data in /admin/settings/uploads (v1.12.2) What am I missing?

You're missing 0.01.0 - this option was added with 1.13.0.

See this
There are 3 elements to a theme (but only the first two are required): page templates, styles and scripts.
If you copied an existing theme, templates will be found in templates folder. They are html documents with additional benchpress templating syntax and they define the bare layout and contents of the page. You can find some basic information on templates here and there is also benchpress documentation that will probably be useful.

Styles are just less css files (located in less folder usually) and define the look of the page (and can also define layout). You can learn more about less here or just by googling some tutorials

As for JavaScript - unless you want to do something specific with the way the style behaves, whatever you copied will probably be fine. Server-side you've got mostly widget area definitions, while client-side there usually is just the loading bar. But if you want to you probably can extend that further easily

Did you rebuild assets after installing it? There is a "rebuild and restart" button in ACP.

While I don't know Redis syntax (mogodb user here), so I can't give you specific commands, I can assure you that most of what you want is possible to do in the database (I don't know about groups here).
The database structure is explained here, and as you can see user objects contains the website, postcount, topiccount etc. You can get the chat messages from message objects and get users that did send at least one message from there to exclude them from the deletion.

@baris said in Issue since upgrading to v1.13.1 from v1.12.1:

@Brophy said in Issue since upgrading to v1.13.1 from v1.12.1:

Someone tried to update their group yesterday and managed to break it,

This sounds like a serious issue, let us know if you can reproduce this.

There are some issues with group functions that lead to more serious vulnerabilities than just invalid names. I'm in the process of describing at least some of them and should send it to security@nodebb.org today. I haven't tested the lack of name altogether, although I think I know how one might go around doing this.

On what social media network does it work like that?

On Facebook a block prevents the blocked person from seeing posts on your timeline, your profile or mentioning you, but it doesn't prevent them from seeing your comments to posts in groups.
NodeBB doesn't have your timeline, and basically all posts in categories both people have access to are closer to a common facebook group in nature. So while the blocked person can see you profile, unlike Facebook you won't see their posts in a "group"

On Twitter, unless your account is private a blocked person will still see your tweets. NodeBB doesn't have private accounts, so no difference there.

Reddit works like NodeBB - you don't see any content by a blocked person, they can see everything that you wrote. Additionally, you will see their content on a subreddit you moderate...

On Discord you even see when there is a message from a blocked user on a common server. And I think you even have the option to show it. So even less blocking than here.

So: from these 4 services, only on Facebook a block is actually mutual (that is, blocked person doesn't see your content) and even then the exception to this rule is close to how NodeBB functions, as there are no individual feeds here.

Nope, you will also have to switch to master branch from 1.13.x - at least until 1.13.2 or whatever the next version will be is released.

IMO it's a feature for a separate plugin - not this one. This plugin, as the description suggests, is using Notification API, and not Push API.
A Push API-based notification plugin would be great, but it's not just an upgrade to this one as Push API works in fundamentally different way by using a service worker.