So I was wondering if anyone knew how to setup NodeBB to have zero down time. When something goes wrong, and NodeBB gets rebooted with Forever, there is a window of time that the site is down. Are there steps to having 2 NodeBBs running at the same time sharing the same database? (Database redundancy is a separate project for later.)

I have been working on a Solaris Installation Guide. I just got the first public draft up on the wiki. Feel free to give me feedback, I am hoping to have a windows guide soon as it is the biggest pain to setup a development station.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security - Wikipedia

When typing in:
./nodebb reset
NodeBB needs to display a help message saying more info is required and not hang without exiting.
It should also list "plugins" as an option:
./nodebb reset plugins

When I try and use:
./nodebb reset
It returns:
warn: [reset] Nothing reset.
But does not exit, it just hangs with this as the last message.
Then when I try to run my site it says to contact the developers of some 3rd party plugin (plugins who probably have not been updated since the last breaking change.) It is an easy fix if reset would just disable those plugins but it does not seam to be working.

• Not that I consider NodeBB a CMS, but who am I to argue when people use NodeBB that way?

-julian

I am planning on using NodeBB as a full node platform

Thanks for the info, I will have to checkout readthedocs.org when I have some free time. I am glad that the docs are getting translated, that is great for the future of NodeBB.

So one of the big reasons to use NodeBB is that you can use JavaScript as your only programming language, both on the server and on the client. NodeBB is also free and open source. A part of that is so that others, if they wanted to, could fork your project. But now there seams to be programming language creep. For NodeBB to be truly open source in spirit, then the documentation needs to be open source as well. And for it to be the go to BB framework for JavaScript then shouldn't the documentation only require JavaScript as well. For a developer to fork your project (or to just fully understand NodeBB's software stack) they would now need to learn python. Is there any better solution for NodeBB's documentation?

I am using Windows 7 64bit with the Comodo Dragon browser. I just opened up Opera Next browser and it is displaying correctly except for zoom 67%:

Anyone else having this issue of NodeBB not using the right most column?

When "community.nodebb.org" was updating, nginx servered a "502 Bad Gateway" text error page instead of a custom page displaying something like: "We will be back soon". I recommend that NodeBB creates a static page that is directly servered by nginx when NodeBB is down. This page should use the exact same theme as you currently have selected for your site. I think the link to nginx should be automated as much as possible (maybe ask [yes]/no permission in setup). But if it can't be there needs to be an easy tutorial on how to link nginx to this static page. The static page should be able to be overridden. It should be updated every time the theme changes. Thoughts?

This bug report is not for NodeBB itself but for your instance of it at "community.nodebb.org".
So nginx is setup wrong serving a "502 Bad Gateway" text error page instead of a custom page displaying something like: "We will be back soon".

So it looks like requestjs and browserify solve some of the same problems but in different ways. There are a few features that browserify seams to have that requestjs does not. For example, browserify can bundle all your dependencies into a single file (which you are already doing for most of your browser dependencies but for some reason using requestjs for others). But here is the kicker, browserify allows you to use nodejs core modules in the browser with its shims that give you access to the modules below. So would browserify be a good or bad fit for NodeBB?

• assert
• buffer
• console
• constants
• crypto
• domain
• events
• http
• https
• os
• path
• punycode
• querystring
• stream
• string_decoder
• timers
• tty
• url
• util
• vm
• zlib