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:

https://github.com/NodeBB/nodebb-plugin-write-api

Is there a list of the most popular (currently installed/functioning) plugins out there?

contains a list of the 5 most downloaded plugins in the last 7 days. But a downloaded plugin can be deactivated and deleted 2 minutes later because it doesn't meet expectations (or doesn't work at all).

(BTW this 1 post every 5 minutes limit for new users is really annoying

We are currently on phpBB, works great but it's old. No mentions, mediocre mobile support, no notifications, no updates between pageloads, etc, etc.

I think future users would really like NodeBB but our current users are extremely accustomed to the current look and feel of the site.

Because of that I'm really very curious about your experiences with moving from an 'old' forum platform to NodeBB. How did you prepare your users? How did they react to the plans and to the actual move?

What happened to your pageviews/sessions/bouncerate/session time/etc after the change? And what happened to your organic traffic? Did you setup proper 301s from the old locations?

Any hints and tips for a prospective convert?

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.

Good point

First Google hit:

Should be easy to figure out.

was posted today
was posted September 23th 2016
I.e. 100.000 posts in 320 days = 312 posts/day

was posted today
October 27th 2016
I.e. 100.000 posts in 286 days = 350 posts/day

BTW this led me to an interesting bug in NodeBB. This URL:

Shows me an error that I can't view this topic but the topic title is shown in the URL.
Edit: This seems to be a bug in a plugin that @exodo installed/created? Can't replicate this on a clean install.

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:

https://github.com/NodeBB/nodebb-plugin-write-api

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.

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:

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