.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

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.

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

@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.

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

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.

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.

Masz na pewno dobry url strony w config.json?
Musi on zawierać także http:// lub https:// z tego co pamiętam.

It's funny to me that the biggest performance hit to the main page of my NodeBB instance isn't JS, but images There are a lot of categories with image as an icon there with their number increasing with time and I don't think all images are correctly resized and optimized, so I'll have to start doing it automatically...

So yeah, it's an example of how being JS heavy doesn't make a website slow - it's only bad code that makes a website slow

https://github.com/julianlam/nodebb-plugin-session-sharing

It's funny to me that the biggest performance hit to the main page of my NodeBB instance isn't JS, but images There are a lot of categories with image as an icon there with their number increasing with time and I don't think all images are correctly resized and optimized, so I'll have to start doing it automatically...

So yeah, it's an example of how being JS heavy doesn't make a website slow - it's only bad code that makes a website slow

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.

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.

Masz na pewno dobry url strony w config.json?
Musi on zawierać także http:// lub https:// z tego co pamiętam.

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

So... You just want a filter for weather or not user can delete/Purge the topic?

If not, then how would that filter work?
Deleting just changes one attribute of a topic, and purging deletes it from database.

The delete and purge functions for topics only take tid and uid (of the caller), so I don't really know what a filter could do here. Unlike on deleting a post there is no equivalent to postData there, so unless you want to delete different topic than you were trying to or make it seem like a different user did it, I don't know in what way that would be useful.

Before the actual delete function is called, there is a check for wether or not user has the right privileges, but I think a more general privileges.can filter (or probably 2: one for category and one for global privileges) would be better than a dedicated filter for topic deletion privileges.

Edit: Ah, I misunderstood. You want a filter that will allow you to reject topic deletion and I didn't even think of that. This post isn't really relevant here then, but I'll still leave it for the part with privileges.can hook

It should happen automatically. At least that's how it works for me:

Could you try it with an url instead of uploading a file?

You should be able to do that from the composer. It looks like this for me (the one on the right):

It will give you an option to add an image from url or select a file from your computer.

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