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 
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:
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.
I hope that you do realise that allowing all file extensions is rather dangerous without extra precautions.
Leaving the allowed extensions list empty is something I would strongly advise against.
It's not an IPv6 address, it's a block of IPs in CIDR notation:
Blocking a single IPv6 address isn't very effective.
https://github.com/NodeBB/NodeBB/issues/5879
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:
IPv6 CIDR Calculator | UltraTools
2001:db8::/64
Any ideas?
@julian Nope. Found the post in my notifications.
But the link also could have been in Google or my mailbox.
@baris thank you for the fixing this extremely quickly!
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:
https://community.nodebb.org/topic/11108/injecting-code-right-after-body-tag/2
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...