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.
Running it with ./nodebb dev should give you a more detailed output.
@a_5mith said:
But mod status may be a bit much for some admins to just give out without fully looking into who it should go to.
An alternative would be to move the user to an arbitrary group when a certain level of reputation has been acquired. This arbitrary group could still be Mod, but it would also allow for the relatively common "New Members" group that has several restrictions which users are placed in until they have at least a certain amount of something. (usually posts or likes or in this case reputation). Alternatively, you could also require an admin/existing mod to review the promotion before it is executed.
@julian: Having multiple margins for pro/demotion would also be neat. For example, > x rep = "Assistant" rank, > y rep = Mod rank, < z rep = the "Enjoy your increased flood delay timer" rank
@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.
@Jelena said:
Is there a way to separate first post from others on post page? I want to move their positions, like on facebook for example. First post will be main post and others for example to be listed on it's right side as comments. I couldn't understand how to do that cause it seems like they all have the same code.
You can either just address the first post separately with a more specific css selector (i.e. .topic .posts > li.post-row[data-index="0"]), or if you'd like to go one step further you can check for @first while looping through the posts array in the topic.tpl template.
Right before running ./nodebb setup, you're supposed to run npm install, which also fetched the Lavender theme.
If, for some godforsaken reason, you remove stuff between these two commands, you should run npm install again because it installs all the packages that are needed to get NodeBB to initially work and install. Because Lavender is the default theme and is guaranteed to be installed if you actually follow every setup guide that's around, this fails without Lavender installed, just like it would fail without the bcryptjs and gravatar packages installed.
If you want to modify database settings on an already existing installation, just modify config.json instead of running the installer all over again. The installer is for just that: installing. Not for modifying any other settings on an existing installation.
@a_5mith said:
No registration process can tell if a human is a spammer or not. It's not possible.
You are right here. Eventually, all human processes can be simulated and replicated and thus verification of humanity will eventually be impossible.
I do wonder if AIs will just spam us to death instead of outright revolting and murdering us, or maybe just doing things like mass-committing something like identity fraud on their own accord. Plus, if they're really clever, they'll have seen the movies. Murdering us directly will inevitably invoke the wrath of a gun-wielding ex-con with a mullet who will be their demise.
Also:
Checking against external blacklists and APIs has a couple of disadvantages, mainly:
From personal experience, when one of these external blacklists actually triggers, some other method of spam prevention my forum (Not NodeBB. Yet.) has installed generally does as well. Although maybe if they decentralized the concept, bitcoin-style (or bitmessage, or bitsomething, or bitanotherthing, you get the deal, there's thousands of there projects now) it might become a bit more interesting, as it'd invalidate two out of my three main complaints. To negate the third, there's always the possibility of clever stuff. Don't underestimate some people when it comes to coming up with clever stuff.
In order to prevent people from registering loads of accounts just to get someone to Mod status, you might also want prevent people with < x reputation from giving others reputation. Or, maybe a bit more elegant, not count their upvotes and downvotes towards people's reputation until they have at least x reputation themselves.
@Scuzz said:
Can someone explain to me what exactly the local login is?
Local login is the user/password authentication mechanism NodeBB uses by default. Disabling it removes the ability to login unless you have a plugin installed that provides an alternate method of authentication (i.e. logging in with your Google or GitHub account).
It should be in the Thread Tools menu, which is generally located (depending on your theme) above and/or below the first post in a thread.
@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.
