Are there any plugins to allow file download management? I wanted to create a similar structure to Box within NodeBB where I can upload files to it, and users can easily access different categories of download.

Thanks.

We have all Popular Social authentication and have not APPLE,

Wll be fine!

I need this so that I can test my Helm chart

I'm trying to understand how google indexes my Nodebb forum, maybe one of you could help me ?…
Obviously i'd like to get as many clicks on links to my forum as possible, but from what i'm gathering, whenever people search for words that do appear on my forum, they get different links (to the last post that's been published in a thread , or to a random page within the thread).
e.g. there's a thread about a specific movie on my forum, the thread holds the same title as the movie itself, but when people google the name of the movie + forum, they get results pointing to a post in the middle of the thread, not to the first page.
So no matter how successful a topic of discussion is on my site, it never really gets the recognition i wish it had on google, not because it's not indexed but because it is indexed several times, via multiple links, some of which hold no specific interest.
How can i send clear instructions to google on which pages are relevant / important to index ?
(sorry if this is a silly question, i'm clearly no expert… 😕)

Is there any CSS suggestion for the main categories page, to change the colors of the icons showing sub-categories according to the color of main category?

Right now, by default they are all blue, but we do color code our main categories depending on the topic, so we would like to change them accordingly.

Screen Shot 2023-11-09 at 18.52.39.png

User Modes

Is design thinking for user group behaviour or market segment patterns, inspired by mobile.

First there is the Lurk metric concept - https://community.nodebb.org/topic/17643/the-lurk-metric

This then leads me to the User Mode concept and approach to tailoring the NodeBB UX

It struck me, post composer reconfigured fun exchange here that it is probably mostly true, that more users consume on mobile than they they ever contribute-create content, and by a much larger factor.

Then it stands to reason, that the NodeBB mobile UX should actually endeavour to offer first the best READ Mode out there, matching user behaviour with the most fitting UX mode, serving the trend-pattern-behaviour correctly.

This means thinking of the mobile experience as a Read Mode in the first, instead of trying to replicate Desktop in the hand functionality.

A user mode where no creation tools are required, a stripped and stepped back mobile UX and UI allows more content to be seen and consumed with less clutter and distraction. This may engender an increase in stickiness and longer read times, let's be optimistic!

What does that mean in NodeBB Harmony terms.

READ MODE looks like:

Top menu BAR is gone. Login to post is on the bottom bar.

All a READ Mode user really needs is access to read content and ability to navigate. No reply, no watching, no sorting, etc. etc.

READ mode in terms of UI needs only

Home Button Login / To post

"Nothing else! Not even timeline. No timeline? No Navigator?! Are you mad Omega?"

Yes.

This then leads me to mention another older concept, that I didn't articulate very well some years back to the devs, but in this context make IMHO more profound sense.

READ Next Post Mode

Pagination is on a post by post basis. Scrolling is reduced to a minimum (only posts longer than viewport would require scrolling to read more)

A post is treated like next-page on mobile, so instead of scrolling you simply next post to read, well the next post!

Since then, it just so happens to have been developed circuitously, for another element, being the timeline navigator and so this capability is located in the timeline navigator (on mobile at least), for searching on a post by post basis.

If we elevate that style with some modifications of next-post reading as a default in READ Mode, then we might solve things like scrolling-fatigue or doom-scrolling-fatigue, or at least can offer either scroll or next-post as a UXUI in the best READ mode on the market! 😉

In the hierarchy of Modes, I'm only thinking of two right now, who knows, but think of a Mode equalling an aggregate user behaviour, there could be more, maybe one more.

READ Mode (new, different, engaging) USER Mode (existing experience and UI)

In conclusion, throwing all the USER mode functions at people who only want to exist in a READ Mode, may solve a bounce for-whatever-reason problem and help to increase engagement.

So stepping things right back and looking at the MVP for a READ Mode, as a universal default for all unlogged in users, may solve unrealised issues, as written, improve engagement, maybe countering general "sign-up" fatigue or reticence and so on.

we ave a requirement were we want to create public groups and allow user to request to join te group.
Also we want to make group discussion readable to non registered users
is it possible?

I write a sso plugin,but when user loading their sso avatar,the error occurred
屏幕截图 2023-10-14 162931.png
And the server can get this url.
This is code screenshot:
屏幕截图 2023-10-14 154845.png
How could i fix it?

(a development post by a contributor, not a team member 🙂 )

NodeBB currently works with docker... technically.
I mean, the default image is fine if you set it up correctly - but that's a pretty big if and there wasn't any good documentation. The existing docker-compose file had some tiny pain points like:

not exposing any ports by default it recommends setting up a reverse proxy like traefik, which can be a good idea and avoids a small docker security footgun (ports exposed by containers can bypass some firewall configurations, e.g. ufw) but also means that running docker compose up just starts up a container you can't connect to by default! You'll need to modify the config, whether you want to expose a port or set up Traefik... not setting up volumes I hope you like redoing all your configuration when updating the image! also, hope you installed some plugin for storing uploads remotely, since even they'll be gone when you delete and recreate the container you can also, again, edit it to resolve that issue not creating any database in the mongodb container using admin works, but is really not intuitive!

And when I said the image was fine, I mean that it's acceptable, not that it's great. It always builds NodeBB before startup, installing and activating plugins in a way that will persist properly requires using arcane configuration options that are not mentioned in the docs (and it results in not being able to install or remove any plugins at runtime), and - again - setting up volumes is entirely up to the user.

However, quite some time ago, @stevefan1999-personal made a pull request that addressed many of these issues, and over time came to address almost everything I mentioned here. And finally we're getting close to landing these changes, and some other small improvements, in NodeBB/NodeBB#12031

So what will change?

Running docker compose --profile mongo up is now all you need to start a working instance of NodeBB in a container. Initially it'll launch the web installer, with already populated database configuration, leaving you just to set up the NodeBB URL and admin account. Then just waiting a bit for setup to finish and you're done - NodeBB is running under port 4567. You can now use some reverse proxy on host, modify the compose file to expose it under port 80 or add a containerized reverse proxy and remove the default port binding. If you use the default compose file you'll notice that configuration and - more importantly - uploads are now mounted in .docker directory, so they'll persist when recreating the container There are some additional env variables that can affect the image startup behavior - e.g. you can now choose if NodeBB will run a build before starting.

There's another nice change that you might've thought of if you saw the initial PR title - docker image size. And it's a fairly large difference. Some numbers:

current image: 601MiB compressed/1.62GiB uncompressed original alpine PR: 315MiB compressed/986MiB uncompressed new PR (slim debian build): 211MiB compressed/674MiB uncompressed

For reference, now the official MongoDB image is actually larger than NodeBB, and combined (even with redis added to the mix) they're still e.g. almost 2x smaller than Discourse slim image (747MiB compressed/2.02GiB uncompressed).
And MongoDB is the largest of the supported databases - Postgres clocks at only 150MiB compressed and offers a 94MiB compressed alpine version, and Redis clocks in at 49MiB compressed for a debian image and just 15MiB for alpine.

The result is that when running NodeBB with postgres the images will end up taking less than 1GB of disk space, basically half of what they do currently. All while offering much better user experience and configurability.

And finally, Docker is graduating to being mentioned in official docs with NodeBB/docs#78 🙂

I want to upload images to S3 or CF,but there isn't plugins I found,so I store the picture locally
How do I set images to be cleared automatically, or how do I set posts to expire and be cleared,please help me..
The follows are not working .
5decafad-0415-4078-b5a7-19dfe13d6b93-image.png
39f03afc-d960-4f44-9e09-aaf5a5551c2a-image.png

I use nginx proxy manager to proxy the ip and port of the Docker container, which is started from GitHub's Docker-Compose, but it doesn't seem to work.

e7504928-fb47-47d0-a9c3-ea03ce9fade8-image.png
da6af99b-0e0a-4c7c-b632-34018168a69b-image.png
b6ffee8d-0840-4380-b395-9ed6f0d27c0f-image.png
c3f487eb-9485-4679-92f1-29a3778cf5c1-image.png