B
Wouldn't it be nicer for plugin authors to always show 'compatible' with the last release that the plugin was compatible with?
I think I would be reluctant to add a badge to my READMEs that tells my potential users that this plugin doesn't (yet) work with a NodeBB version that has just been released.
Just a thought 
I think this would help:
A RESTful JSON-speaking API allowing you to write things to NodeBB - NodeBB/nodebb-plugin-write-api
GitHub (github.com)
For a large part this is an architectural issue.
It would extremely useful if it were possible to test a plugin on the production database in a development or staging environment.
That's not possible when NodeBB gets the list of activated modules from the database.
We have a similar problem like this with Drupal7. It's close to impossible to test something on the production data without making a copy (which is extremely unpractical with a large DB) because of the tight coupling between configuration and content.
Haven't used it yet but Drupal 8 has improved on that issue quite a bit:
https://www.drupal.org/docs/8/configuration-management/managing-your-sites-configuration
Wow, impressive work!
The no-JS version looks almost exactly identical to the 'full' page.
Would this also enable NodeBB to use progressive enhancement? I'm a bit obsessed with speed, a large part of our revenue is generated by users that visit one or two pages on our forum through a search engine. These users want to see content fast.
If you are a regular user downloading several 100kb worth of CSS and JS is not a problem. You only do that once, after that all you download is some JSON.
The inverse is true for one time visitors. They need to load a LOT of extra data for functionality that they will never use. Another drawback of this is that ads will load slower because they compete with all the 'app' javascript for network and CPU.
Therefor it would be fantastic if the HTML could load and render, then the ads are initialized and then all the NodeBB Javascript is pulled in and executed.
It's not an IPv6 address, it's a block of IPs in CIDR notation:
https://www.ultratools.com/tools/ipv6CIDRToRangeResult?ipAddress=2001%3Adb8%3A%3A%2F64
Blocking a single IPv6 address isn't very effective.
https://community.nodebb.org/topic/11127/block-ipv6 I was trying to blacklist a block of IPv6 adresses (an IPv6 prefix actually) but that results in a 'rule is invalid' message when I try to enter something like: 2001:db8::/64 This with ...
GitHub (github.com)
Re: Biggest nodebb Community forum?
Kind of related to this previous discussion.
I was also under the impression that the exo.do error was caused by an extension but today I ran into a similar situation on nodebb.org
I've replied in this topic:
https://community.nodebb.org/post/62242
When I visit that page I'm redirected to:
A community to talk about development and ask questions about NodeBB modern forum software
NodeBB Community (community.nodebb.org)
with 'Access Denied | NodeBB' as the page title and:
Access Denied
You seem to have stumbled upon a page that you do not have access to.
as the text.
event:15 does but eventtime:15 doesn't as far as I can see?
SQL is not faster because it's SQL, far from it. SQL can suck hard from a performance point of view.
A large part of my worries stem from the fact that I'm not that familiar with the strengths and weaknesses of MongoDB and I am really familiar with the challenges that MySQL can pose when it comes to forums and big boards.
In the MySQL case the DB can be really slow if proper indices are missing. And that's with database tables which are highly structured where it's trivial for the DB to do a table scan on a certain field.
I view MongoDB as one large bucket of JSON objects that are hardly related or structured. It's possible to index them to some extent but as far as I know that's not really efficient when everything is part of one large collection.
But most I guess most of it is 'fear of the unknown' I guess I should just fire up a conversion or fixtures script and see what happens...
I notices that what.thedailywtf.com is working on a PostGres implementation, but they are just storing JSON objects in one huge table. I was talking about a properly normalized implementation of the datastore
Or is there another effort in the Postgres department?
And thanks on the explanation about the sorted sets. I really need to read up on NoSQL again. Although in this case the events:time objects seem redundant, the timestamp is already available in event:15?
Do you have an idea what to expect of the current MongoDB implementation when the database gets to a nontrivial size? Is there a fixtures script somewhere?
The easiest solution (and probably also the best for SEO purposes) is to put your forum on a subdomain, i.e. forum.example.com
If you want everything on the same server it really depends on the rest of your site. Are these real files that you want to serve? Are these files generated by a CMS? Etc.
I just browsed the MongoDB database of my tiny test forum and it's quite apparent that dropping Redis support could mean a HUGE win for the cleanness and (I think) performance of MongoDB. There is a lot of redundancy at the moment, there are lots of strangely linked items. Small example:
{
"_id" : ObjectId("5989ba5986d1235ea0696381"),
"_key" : "event:15",
"type" : "plugin-activate",
"text" : "nodebb-plugin-calendar",
"timestamp" : 1502198361021.0,
"eid" : NumberInt(15)
}
is linked to:
{
"_id" : ObjectId("5989ba5986d1235ea0696380"),
"_key" : "events:time",
"value" : "15",
"score" : 1502198361021.0
}
That doesn't really make sense to me
I'm not exactly an expert on NoSQL databases, but it's hard for me to see how MongoDB can perform with a non-trivial amount of data. What would happen if I would dump 100MM posts in there?
The current use of the DB also looks a lot like a relational database:
A post:
{
"_id" : ObjectId("598999cf86d1235ea06962af"),
"_key" : "post:1",
"pid" : NumberInt(1),
"uid" : NumberInt(1),
"tid" : NumberInt(1),
"content" : "# Welcome to your brand new NodeBB forum!\n\n[blabla]",
"timestamp" : 1502190031774.0,
"deleted" : NumberInt(0)
}
A topic:
{
"_id" : ObjectId("598999cf86d1235ea06962a9"),
"_key" : "topic:1",
"tid" : NumberInt(1),
"uid" : NumberInt(1),
"cid" : NumberInt(2),
"mainPid" : NumberInt(1),
"title" : "Welcome to your NodeBB!",
"slug" : "1/welcome-to-your-nodebb",
"timestamp" : 1502190031763.0,
"lastposttime" : 1502199185012.0,
"postcount" : NumberInt(4),
"viewcount" : NumberInt(30),
"locked" : NumberInt(0),
"deleted" : NumberInt(0),
"pinned" : NumberInt(0),
"teaserPid" : "4"
}
These two are linked through 'tid' which makes a lot of sense in an RDBM context. In MongoDB I would have expected one document per topic or something like that?
In mongodb single collection? a 'delete' example is given as a reason for going with NoSQL. But you can't just do: db.delete('topic:1'); because that would miss all posts, read indicators, subscriptions, etc, etc. (If I'm not missing something)
All this:
https://github.com/NodeBB/NodeBB/blob/master/src/topics/delete.js
is needed to delete a topic.
But, as I said, my NoSQL experience is really very limited. Could be that my expectations of NoSQL are too high (or too low when it comes to performance).
I'm curious though what the plans are for the NodeBB datastore(s) for the future. Is Redis support going to be dropped? Have there been tests regarding the scalability of the current schema(lessness)? Are there plans to support RDBMSes?
Also curious why NoSQL was picked as the datastore. A forum doesn't seem like a very natural fit for NoSQL? The schema is fixed, there are lots and lots of relationships between tables/collections/objects.
In short:
@rfc2822 My guess is that the NodeBB project gains the most when nodebb-plugin-dbsearch is improved. I did a quick check of the MongoDB docs and it seems like there is quite a bit of room for improvement when it comes to the implementation of MongoDB fulltext search in NodeBB.
Performance is not really the issue here, I'm guessing that normal MongoDB operations will come crashing down before MonogDB gives up on fulltext-search on really big boards. Which leaves search quality.
As far as I can tell things would already be quite a bit better if by default all searches use an AND operator between al terms and if a term like 'site.com' won't be broken up into 'site' and 'com'. And while you're at it it would be nice if relevance would take age into account
@baris I understand that, but aren't the measures in the registration process enough for this? Since we added a (custom) registration question to our registration form the number of spammers we see dropped to almost zero.
Limiting the post rate of new users is sending a strong "Don't be very active on this site" signal. I don't think most forum admins are after that sentiment I know it's temporary, but still it kind of sets the tone.
</offtopic>
But a normal user would expect a post with both http and 403 to rank much higher than a post with only one of those terms. Actually I would only expect results with both terms.
It would also be nice if age was taken into account when calculating relevancy. I'm currently only searching with sort set to 'last reply time'. The state of the world in 2014 isn't that relevant to me if there are newer search results.
Good point
First Google hit:
https://serverfault.com/questions/500650/how-can-i-enable-mod-proxy-http