@rongcuid said in Possibility to change post URL/routing?:
My motivation is that I think for a forum, a topic is a better "resource" than posts, and it might improve SEO.
Hmmm.... Maybe....
I am thinking I would prefer the search bots to be indexing posts, however, as threads evolve there can be quite a bit of "drift" from the OP's original topic. Having individual posts indexed seems like it would help search engine end users to discover these tidbits, which can be real gems, but also way off topic. About the only effective way to handle such is with LOTS of moderation, e.g. StackExchange. Which tends to put many forum users off with cries of "censorship" and such. At least w/my crowd.
Just some food for thought/discussion here - I am not arguing strongly either way.
@rongcuid the SEO capabilities of NodeBB by far exceed that of flarum. And as an ex flarum user myself, I'll warn you now that literally everything you want to change will require an extension.
Flarum uses Mithril and you cannot even execute simple JS without having to write an extension, whereas in NodeBB it's a simple affair. Flarum has multiple issues relating to SEO and there are plenty of stories I can tell you where frustrated users all mention the same issues - only to be told that if you want to change the behaviour, you'll have to write an extension.
NodeBB and it's development team are much more open in their approach, and have a regular release cycle. Let me tell you that SEO on my instance has gone though the roof and by far exceeds any previous forum I created in flarum.
As a final note, flarum has no proper GDPR capabilities per se (and that also needs an extension) whereas NodeBB offers this out of the box included in the core package. I know of at least three ex Flarum users who departed their eco system for WordPress and there is also an exporter for this.
Flarum will also be much slower over time owing to the need for multiple extensions just to get anywhere near the capabilities of NodeBB, which makes use of MongoDB and no PHP in sight. NodeBB also outstrips flarum in the performance category. Being as there is no PHP, it is inherently faster out of the box.
I don't want to come across as bashing Flarum, but it's ecosystem is very much like Hotel California - "You can checkout anytime you like, but you can never leave" in terms of portability and flexibility. To be clear, I'm not anti Flarum - quite the opposite in fact. I invested heavily in its development whilst still in beta, donated monthly to the project, and also purchased a number of "premium" extensions - all of which had their own issues. And in some cases, extensions are released "for the benefit of the community" but are under minimal development meaning that if you need additional features, you have to "sponsor" further development. So not "free", but essentially "freemium".
I'll leave it for you to decide which platform to choose, and I'm not trying to influence your decision - rather warn you that all is not what it seems with Flarum having experienced and attempted to work within their framework. I eventually left their ecosystem owing to their lack of commitment around a decent GDPR extension which should have been in the core, but (no surprise) needed an extension just to provide the same capabilities as NodeBB has in its core.
What's also bizarre is that those who in fact know nothing about GDPR suddenly become "experts". For clarity, I'm an information security and infrastructure expert by trade and their approach to GDPR in general is woefully inadequate to say the least, given that their flagship "paid flarum" (Blomstra) is based in Europe!
You'd think they'd have this as a priority, but clearly not.
Ultimately, up to you, but I feel obliged to advise you of the issues I'm aware of in relation to Flarum. None of which I've experienced using NodeBB.
@phenomlab Thank you for sharing your experience. It is very helpful to hear from people with experience of both platform.
I am aware that Flarum needs a plugin for everything, but on the other hand, NodeBB has a few critical things lacking for me, so I have to write quite a few plugins too:
S3 should be easy, as I might consider forking the ancient S3 nodebb-s3 plugin, though I would hope this support is built in core. BBCode is more problematic, as it might amount to the same effort of writing every plugin I need for Flarum combined. This actually makes NodeBB's set up effort tied with Flarum, for me right now.
Plus, I am not sure if PostgreSQL support is first class in NodeBB, as it is not documented very well. On the other hand, Flarum's DB schema is very clean, so I would say I can always migrate away from Flarum if I really want to, but NodeBB's schema is kind of unique... as it is document based and everything is in jsonb. The reason I am mentioning this is that I don't really want to use Mongo.
nodebb-# \dt
List of relations
Schema | Name | Type | Owner
--------+---------------+-------+--------
public | legacy_hash | table | nodebb
public | legacy_list | table | nodebb
public | legacy_object | table | nodebb
public | legacy_set | table | nodebb
public | legacy_string | table | nodebb
public | legacy_zset | table | nodebb
public | searchpost | table | nodebb
public | searchtopic | table | nodebb
public | session | table | nodebb
(9 rows)
MariaDB [flarum]> SHOW TABLES;
+----------------------+
| Tables_in_flarum |
+----------------------+
| access_tokens |
| api_keys |
| discussion_tag |
| discussion_user |
| discussions |
| email_tokens |
| flags |
| fof_upload_downloads |
| fof_upload_files |
| group_permission |
| group_user |
| groups |
| login_providers |
| migrations |
| notifications |
| password_tokens |
| post_likes |
| post_mentions_post |
| post_mentions_user |
| post_user |
| posts |
| recipients |
| registration_tokens |
| settings |
| tag_user |
| tags |
| users |
+----------------------+
27 rows in set (0.004 sec)
@rongcuid agree. MongoDB was something of a learning curve for be also, but seeing as it's NoSQL, it's inherently better in terms of the plethora of injection attacks against traditional RDBMS.
Another nail in the Flarum coffin is it's use of PHP. This language is antiquated by today's more modern standards such as NodeJS and given that PHP has to load an entire page before actually rendering anything makes it so much slower, and less a viable competitor in today's market. Flarum also has abnormally high TTFB in even the most performant of hosts, this makes the mobile experience lacklustre to say the least.
Flarum's logic in terms of what a core application should look like is so lean it's impossible to make any of it work out of the box without even a minimum of extensions to get anywhere a basic forum experience.
I still use Flarum for a work related project, but that's moving to NodeBB soon. Flarum's appeal is mostly because it can run on cheap hosting consisting of PHP, MySQL, and Apache, which makes it easily accessible to the masses when you compare it do Discord and it's close, NodeBB.
However, NodeBB is clearly superior in my view.
@phenomlab I am wary that MongoDB is not fixing its Ubuntu 22.04 install, and in general its support on Community Edition. That's why I would like to use Postgres instead.
Redis might work too, though it might require a heck lot of memory.
@phenomlab The last thing would be... I wish the build process is faster. On my Pi 4 test server it takes a few minutes to build and redeploy, and I would assume on a tiny cloud VM it would be even slower.
@phenomlab Webpack has always been slow for me. I have used some newer build systems that use ES6, and man they are blazing fast.
Also glad to see build process optimization seems to be on roadmap, though looks like NodeBB will stay with untyped JS for a long time.
Now, with PHP there is zero build time and some support of static typing, of course.
@rongcuid I could "+1" most of what @phenomlab uttered up post, sans the plugin dev experience but as a community rep did not want to be seen as "bashing the competition" so I let this aspect "percolate" fer' a bit. 
Now that the cat is out of the bag, I will point you to a pretty well developed thread comparing NodeBB to Discourse that may provide a few additional insights of interest:
https://community.nodebb.org/topic/1835/which-is-better-nodebb-or-discourse
Were I not using NodeBB, I would likely look next at Xenforo. But then you are once again embracing all the PHP downsides. PHP based stuff can run pretty fast. If you do it "right" and "know" what you are doing. But it is going to take more work to get there, comparatively, and, imho, still never going to be as performant as NodeBB.
I see this often: Folks are exploring and/or transitioning to a new platform for a reason - likely several reasons. They discover NodeBB. Looks good. Damn good. But.... then they start wishing for "features" in efforts to morph the new into that which they left. Intriguing phenomenon for the social anthropologists.
I encourage such folks to take a step back. Install a default install. Stay away from any non bundled plugins. Then just USE NodeBB for a while and experience what it offers. You may find that much of what you wished for is based on old baggage that you no longer need to lug around. Only then, begin tweaking and tuning. Leverage the hidden gems first.
As for DB's. Yes, PostgreSQL is a first class supported DB. And yes, NodeBB was also developed under NoSQL "page" rather than relational paradigm. Hence, you are storing json blobs.
I have done testing w/all the supported DB's at one time or another. My conclusions:
The mongo/redis combo is VERY good. And, truth be told, likely far less of a management pita than any RDBMS, presuming your are not deploying more complex fault tolerant and sharded MongoDB configurations. Those can be a bit hairy. But then same is also true of RDBMS in such cases.
Here are a few PostgreSQL threads:
https://community.nodebb.org/topic/13982/mongodb-or-postgresql-ah-that-is-the-question
A +/- scripted postgresql backed NodeBB install here, courtesy @JaredBusch here: https://www.mangolassi.it/topic/22497/setup-nodebb-on-fedora-33-with-postgresql-and-nginx-with-https-only
https://community.nodebb.org/topic/16535/how-can-i-migrate-from-redis-to-postgresql-mongodb
A forum "search" for Postgresql will return a few more.
Now that performance concerns 'twixt mongo and postgres seem minimal (I need to test more to confirm) they can take a back seat to other important concerns.
I personally have issues with MongoDB, Inc.'s licensing gamesmanship. Typical of too many modern day FOSS (Fake Open Source Software) project. I favor ROSS (Real Open Source Software) from folks like @julian et.al. that provides "the full monty" to anyone willing and able to use it rather than some feature crippled "community" version whose primary purpose is free beta testing.
Hence, in all probability I will be using PostgreSQL for future deployments. 
@gotwf I have tried NodeBB (multiple ports) + Postgres + Redis. It is a bit tricky to set up (because I have Nginx serving a bunch of other stuff under subpaths). I don't know if Redis is used for caching in this case, though.
Now, I would really like better systemd integration and S3 uploads...
@rongcuid Iirc, mangolassi.it, which sports a fairly large user base, just uses mongodb solo, no redis. Community Rep @scottalanmiller runs that site. He does not pop in here very often anymore but would be another good one to query w.r.t. db experiences, and indeed, NodeBB experiences generally. Very seasoned and knowledgeable guy.
@rongcuid said in Possibility to change post URL/routing?:
The last thing would be... I wish the build process is faster.
That'd be webpack, yes... it does a lot of voodoo black magic behind the scenes to make things smaller.
But if it's just a test server, then just build in dev mode. Pass the -d flag into ./nodebb build
@rongcuid said in Possibility to change post URL/routing?:
- BBCode support
I unfortunately don't have the time right now to participate in this discussion more, but I might be able to help with thais part: there is actually a fairly ancient but still functional plugin for BBCode support already 
https://github.com/psychobunny/nodebb-plugin-vbcode-to-markdown
The only issue I noticed is that it doesn't show in preview (which I think should be fairly simple to fix)
Note that it's support, not first-class support - the default with it would still be markdown, but most BBCode will just work too by being translated to md before it's displayed.
Scaling - NodeBB Documentation
