@rbeer said:

Views shouldn't be use for measuring popularity, whatsoever. At least as it is now. You can keep spamming the refresh button or even write a tiny script to request a topic. There is really no checks in place. It is too easily manipulated.

If that was changed to #views/#users, then it might become a good tool for measuring e.g. how many users have been reached with an announcement topic.

Perhaps retention rate would be more appropriate: the mean or median % of the topic read.

though I'd be careful pulling the image from the Docker Hub at all right now, since nothing is tagged right now, so you're pretty much stuck always pulling the latest master or whatever commit the buildid you've specified corresponds to.

@MichaelM said:

I've noticed in the Dockerfile contains this stanza: CMD node app --setup && npm start which seems to me like it would run setup by default no matter what. Is that the expected behavior? It seems to me that Docker users would want to create a container that could be restarted any time without requiring any other interaction other than docker start <container>.

Quick explanation (prolly more behind it, very very tired right now though so I can't really remember):

By default the Docker image requires all environment variables to be specified because having to deal with data that isn't in the image itself can be a pain, so this keeps the image stateless.

node app --setup is always run before starting the image because any files this creates is deterministically based on the data passed to the -e arguments, so it can just be thrown away and you don't need to deal with moving it around between different machines in HA scenarios.

You could also address all this by simply putting the environment variables in the Dockerfile when building it, but you can't really use the public Docker Hub for this as it'd post your DB info - and also the session secret, which you should specify if loadbalancing across multiple containers.

@MichaelM said:

I've tried adding connect-redis to the package.json file, but this seems to have no effect.

Is there a way around this?

npm install runs when you build the image (thus version-locking all dependencies without something like npm shrinkwrap), anything you do afterwards just behaves normally - i.e. adding things to the package.json using a text editor (or sed, etc. you get the idea) doesn't automagically install them.

@MichaelM said:

Would pre-configuring NodeBB before building the docker container be a better and is this even an option?

It's definitely possible! You could base your image on our image and specify all the configuration stuffs using ENV, use a RUN directive to run node app --setup at build-time and optionally add a CMD directive that's just npm start. (the CMD is the default command ran if you start the container without supplying any, also your CMD would override ours )

Good luck, hope this helps a bit and sorry if you knew more than I cautiously assumed you might when writing this post - well, at least that'd make it also useful to any stray Googlers out there looking for help...

@yariplus said:

Hmm, tried on a fresh install, but lwip wouldn't build for me.

Most likely this would be because all native modules need to be updated for 4.0.

Quoting from a blog post:

Recent changes to V8 which are included in io.js v3 are much more profound and require not only a newer version of NAN but a breaking API change in NAN itself which requires code changes in all dependent native modules.

(NAN = Native Abstractions for Node)

Some modules are already compatible though, as the same version of NAN is used by both io.js v3 and Node.js v4 and io.js v3 has been out for a while, so module authors had some time in advance of v4 to upgrade.

@julian said:

Concurrent with this release, I'm also releasing a Two-Factor Authentication plugin for NodeBB. To my knowledge, this is a feature unique to forum softwares, and one that is definitely in-demand. In fact, we're already seeing downloads of the plugin, and it hasn't even been formally announced yet!

completely unique, though it's also seen some use on niche sites such as Google, Twitter, et al.

@Nicolas did another fresh install and updated to the latest 0.7.x branch (not the 0.7.0 tag), all the pages are showing now

Though to be able to actually grant awards I need to tab to the user in the autocomplete form. Clicking on it just causes the autocomplete thingy to disappear and doesn't actually select the user. The trick with the tabbing only works in Chrome, so I cannot grant awards at all from Firefox.

Just a friendly reminder about using Google's SMTP:
You can only send email to a maximum of:

• 500 recipients a day (for Gmail)
• 130 times the number of user licences in your account per day
  9 times the number of user licences in your account per 10 minutes (for Google Apps)

Did a clean npm install again and re-installed/activated the plugin. /admin/plugins/awards still empty. Changed the plugin load order to load this plugin first instead of last. Still nothing.

The network tab in the inspector shows a file with the URL /src/admin/plugins/awards.js is requested but completely empty (not 404, just empty and 200 OK), does that have anything to do with it?

Update: /awards does have the <div id="awards"> in it, but its only child is the breadcrumb.

@Nicolas The ACP page being empty may be a result of the script in https://github.com/NicolasSiver/nodebb-plugin-ns-awards/blob/master/public/templates/admin/plugins/awards.tpl being commented out?

@Nicolas said:

Did you activate it?
I have developed this plugin on 0.7-dev

I have activated it and the routes are there. Aside from the header, sidebar, breadcrumb etc. there's just nothing there. Not a single error showing up in the logs or the browser's console.

I'm currently running 0.7 Stable.

Is this compatible with 0.7? Both /admin/plugins/awards and /awards are empty pages.

Using Bootswatch skins the chat bar looks kinda funky now: http://i.imgur.com/cb0fM3v.png it only covers about half of the screen and just looks weird in general =/

Also the vertical bar next to the topics in /unread and /recent is always grey even if the topic hasn't been read yet, makes it look kinda boring.

@psychobunny said:

@Nicolas said:

@psychobunny Also I'm going to create another plugin, and I need this space in user's profile. Do you have any suggestions how I can reach it without manual editing also?

Sorry I missed this. We should add more hooks (or widget areas) in the profile section. This is way better than requiring people to edit the template for sure. If you make a PR to add that functionality I'm sure we would accept it

How about giving plugins a way to specify some markup that'd added before/after every partial?
i.e. nodebb-theme-persona/templates/partials/topic/post.tpl existing would add a hooks/widget areas/whatevs. like before:topic-post and after:topic-post?

@julian Objection! When setting settings through env variables, they are always strings. Currently NodeBB doesn't seem to take this into account. i.e. running ./nodebb start (or npm start) with the env variables daemon and silent both set to false, NodeBB still starts both daemonized and silent.
(false does not equal "false" )

Also, slightly unrelated, but when doing the setup thingy with a redis password provided, i.e. like

 $ database=redis redis__password=CorrectHorseBatteryStaple node app --setup`

the password provided is used during the install but not actually saved to config.json.

@Dim said:

".modal-backdrop {
z-index: 0;
} "

.modal-backdrop { z-index: auto; }

Would probably be preferable, since auto makes it behave like no z-index property has been specified (as is the case in the default Bootstrap theme used in lavender and persona) which makes the element inherit the z-index of its parent, whereas z-index: 0 forces the z-index to be, well, 0.

I was having the same problems with Bootswatch skins.
Reverting to the default seems to fix it.

To get modals to work again I had to manually add .modal-backdrop { z-index: auto; }.

Since they're global, it doesn't seem to make sense that they're reloaded every time you navigate to a different page.
Would save a few reflows if they were persistent like the navbar.

Since 0.7, you can pass a db option to LevelUP to swap out the default LevelDOWN with anything LevelDOWN-API compliant, allowing you to seamlessly (save an npm install) store your data in all of these.

It'd be pretty awesome if NodeBB could do that

@julian said:

I still call str.toLowerCase(); on the title, although I have no clue whether it actually lowercases unicode text. It seemed to work (sort of) for Turkish, in that İ turned into i...

str.toLocaleLowerCase()?

@shady2k said:

@Xiph, I can't make it work with subdomain. Websocket's querys gets error with Invalid uid = 0. Could you describe your config?

Supposing your site is example.com and the subdomain you used for websocket is websockets.example.com:
Go into the admin control panel on your NodeBB site, then go to Settings > Advanced and ensure that underneath the "Set domain for session cookie" you've written .example.com (note the first dot). Click "Save Changes", clear your cookies and log in again. That's what solved it for me.