@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 startwhich 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 thandocker 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:
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.