Hey and welcome on... wait... you've been six months around already as you say
Just Hey then

Here is a list that comes to my mind:

Programming Languages, Frameworks, etc.

Plugins

• GIT - if you want a VCS for your work (you're free to use any other of cause but I highly recommend GIT)
• JavaScript (or any super-language that compiles into javascript)
• JSON - even so it's an essential part of javascript I mention it once more since it gets used a lot for configuration-files, etc.
• Node.js globals - for the very start modules is the most important. Some other important ones ain't important for most NodeBB plugins/themes but for own node.js projects they will be (path, process, file system)
• NPM basics most importantly the Getting started section to be able to use npm on command-line (GNU/Linux). I don't know anything about usage of NPM in MS Windows. The package.json structure is also important.
• Some stuff from the NodeBB docs - especially the Writing Plugins for NodeBB section

Some NPM modules in detail:

• Grunt / Gulp is always a good thing to know about, you only need it for NodeBB module-dev if you're using testing or a super-language that compiles into js thought
• Bower is always a good thing to know about, you don't need it for NodeBB module-dev thought
• socket.io communication basics - for communication between server-side js and client-side js
• winston - server-side logging if you need to, not much to learn thought
• ... depends on targeted functionality

Example: https://github.com/NodeBB/nodebb-plugin-quickstart

Widgets (additionally)

• LESS - it's basically CSS with nested selectors allowed, every valid CSS is valid LESS
• Bootstrap - there has been at least one 3rd-party effort to add support for some other framework alike thought, not sure about the status since I like bootstrap
• psychobunny's templates.js syntax and usage

Example (@julian for consistency a nodebb-widget-quickstart would be great https://github.com/NodeBB/nodebb-widget-essentials

Themes (additionally)

• You can consider using a Bootswatch "skin" before starting customization

Example: https://github.com/NodeBB/nodebb-theme-quickstart

Development Environment

Operating System

I generally recommend GNU/Linux since it's clearly the superior OS with more clean command-line.
Anyways you're free to use any other OS as long as you can install

IDE

Whatever you want.
I prefer Webstorm but it's not freeware (and vim for fast changes )...
Many others seem to prefer Sublime Text.
Search for it here on board, there have been some threads about it...

Workspace

As mentioned above Grunt or Gulp are the tools of choice for task automatization (e.g. compilation of CoffeeScript into JavaScript whenever a .coffee-file changes).

Database

NodeBB has core support for Redis and mongoDB (and levelDB if I'm right, would need to check source to ensure... ...nevermind, dropped support long ago) - even so mongoDB gets used key-value like instead of fully featuring it's power.

These are NoSQL (Not Only SQL) Databases, thus it's not recommended to actually access them using SQL commands.

But in general you won't need to access the databases directly for most plugins since there is a Settings Framework that may store plugin-dependent data and for common storage-additions there is support within the appropriate Hook-definition.

Design / UX Tools

I don't need anything other than chromium development-tools (browser console, DOM manipulation, etc.).
You may consider using a color-selection page (like http://paletton.com/) for neat color-composition.

etc.

• Much practice with JavaScript and Node.js especially
• Learn interaction with NodeBB API by watching how other plugins do it
• If the former is not enough: some reverse-engineering of NodeBB core for better insight and to know which modules you may want to require()
• For themes/widgets prefix any URL with /api to see which template-variables you have access to

Have fun and great that you want to participate

Hey guys,

it's been a while

I've created a plugin for email domain-name filter specification (whitelists, blacklists, both):

GitLab link | npm link

It's possible to specify just any patterns for domain-name matching, like shown within the examples.

It utilizes a matching module (ns-matcher) written by myself because I haven't found any matching modules for order-relevant tasks.

So if you find any bugs, please report them

Examples

Comments (shown with //) are not allowed within the actual syntax (yet).

Simple whitelist:

email.example.com  // Allow email.example.com
email.*.example.com  // Allow email.XYZ.example.com
**.email.abc.example.com  // Allow email.abc.example.com and all (deep) sub-domains
!email.abc.example.com  // Deny email.abc.example.com (sub-domains are still allowed)

Blacklists using negative patterns:

**  // Allow everything
!**.example.com  // Deny example.com and all (deep) sub-domains
email.example.com  // Allow email.example.com

I hope this will be useful, at least I needed it myself

Btw I know the plugin name might be misleading due to the possibility of blacklists/mixtures as well, but I did publish after a long coding session xD sorry.

Pings due to feature requested: @fasterthan @kalihman

Hey this is my first theme for NodeBB.

It's a simple dark theme for NodeBB based on Vanilla theme for NodeBB.

Installation

npm install nodebb-theme-dark-rectangles

Distribution

Github
NPM

Screenshots

Credits

variables.less, static and templates modified from Lavender Theme for NodeBB.

Have Fun!

Hey folks,

I've just released 1.0.0 of my completely reworked grunt setup for NodeBB module development.

See nodebb-grunt.

If you remember this one you'll be happy to hear that I'm not used to CoffeeScript anymore.
The rework allows you to simply define custom compilation steps and guides you on the way to a new plugin/module - currently only a basic plugin setup is shipped.

One important (to me) compilation step is the meta-replace. Means every occurrences of @{...} within certain files get replaced with the respective meta data (either from within package.json or .meta.json or from some pre-defined values, details are planned for the wiki).
So one might write "@{version}" within source code and it gets resolved to sth. like "0.1.0+12".
This is useful for preventing meta-data to be defined on multiple places. Everything only needs to be defined once.

In combination with the pre-defined meta @{env} which resolves to development or distribution, depending on which grunt task got run, this is a powerful feature. You can simply enable debugging for your development workflow without the need to care about disabling it anytime you want to publish.

It might still have a few glitches, but the main functionality is working so far.

I hope (with some more shipped module setups, etc.) it could help many fellows out there developing NodeBB modules.
And maybe I'll get it to be the standard environment for the NodeBB Community Projects
At least it's pretty helpful for myself developing modules (even so it didn't pay off the work I put into it yet ).

Some notes:

• The ./g bash script is undocumented within repository yet, see the source for usage information.
• I'd be happy to merge (I don't add others to the team yet, needs proof of code quality etc.) any PRs regarding module setups (e.g. themes) which should match the structure of the shipped plugin setup (e.g. use of @{...} where appropriate)
  • Some guides are going to get into the wiki soon, so wait for it...
• Since I just use JSHint, I'd be happy to accept PRs regarding rc files (within setups/**/*) of JSLint, ESLint, JSCS, Closure Linter (alias GJSLint) which should be equivalent to the restrictions within the .jshintrc files
• The restrictions within .jshintrc files (within setups/**/*) are open for discussion, so maybe wait a bit with the previous note.
• I plan to try out typescript some time and would definitely add setups for this when I do so
• I'd be happy to receive any kind of feedback

My workflow on nodebb-plugin-shortcuts for example has been minimized to

1. ./g sh d - starts grunt dev:sh and grunt within NodeBB root
2. do my work on the plugin, NodeBB refreshes automatically
3. ./g sh e - triggers defined publish tasks (see config/publish.json)

Simple bash script (needs jq to be installed besides common curl and of course npm

#!/bin/bash

type jq >/dev/null 2>&1 || { echo >&2 "I require \`jq\` but it's not installed.  Aborting."; exit 1; }

nbb_version=$(jq -r -e ".version" < package.json)

echo -e "NodeBB version \033[1m$nbb_version\033[0m"

i=0
packages=()

while [ "$1" ]; do
  package="nodebb-$1"
  version=$(curl -s https://packages.nodebb.org/api/v1/suggest\?package\="$package"\&version\="$nbb_version" | jq -r -e ".version")
  if [ "$version" == "null" ]; then
    echo -e "\033[31;1mNo suggested version of $package for NodeBB $nbb_version. Skipping.\033[0m"
  else
    packages[$i]="$package@$version"
    i=$(($i+1))
  fi
  shift
done

if [ ${#packages[@]} -ge 1 ]; then
  echo "> npm install ${packages[@]}"
  npm install ${packages[@]}
else
  echo "No package to be installed."
  exit 2
fi

syntax: my-script plugin-shortcuts theme-persona [...] (no nodebb- suffix, can be easily changed thought)
needs to be called from within your NodeBB-root

For images you could create your own convention:
For examle you could center all images with alt-tag beginning with _ by adding the following to custom css:

.img-responsive[alt^="_"] {
  margin: auto;
}

Now evey image included like ![_Mine](http://i.imgur.com/z9DWzht.gif) should be centered.

EDIT: For videos you may choose to center all of them, just add margin: auto; into the code I gave you here

1.0.0 finally it's getting serious... xD

In my opinion there are enough easy-to-follow guides for local installation, cloud installation or even docker-setup.

In your case you'll need the local installation guide for windows (I guess you're using windows because of your putty comment).

I agree that the windows-guide is a difficult one to follow since windows doesn't have anything to make your life more easy (like a well-working package-manager, etc.).
But your conclusion of missing guides on NodeBBs side is the wrong direction. You should expect of your OS to give you some hints on how to install software on it.

You simply cannot expect of a software to describe how to install it under all circumstances.
And windows is NOT the most-used OS for web-services. It's just (sadly) one of the most used OS in personal area and surely not optimized for development, network-connections or web-hosting.

Did you expect of your php-scripts to explain how to install them on any OS with any php-environment? Should any php-script come with an explanation how to install apache/lampp/xampp/whatever on any OS?

The only valid reason (from my point of view) for NodeBB itself to keep and manage those installation guides is because it's distributed as a git-repository and has a few dependencies that need to get installed additionally. And this is the most important part of the links above.
But you won't see any non-single-line description how to install those dependencies since it's not within NodeBBs responsibility (and capability since the installation-guide would need to keep up-to-date).

You don't need to run Windows for NodeBB (and I'd highly disadvise) but if you're using Windows you shouldn't expect of a software to describe its own installation as far as it's the default way of installing software.
If you want to use a cloud-service to run your NodeBB you shouldn't expect NodeBB to explain how to use that cloud-service or connect to it from any OS. It's a task of the cloud-service to give you a short introduction how to get a running connection. And even those shouldn't need to explain how to install putty on windows.

Hence that NodeBB delivers some guides on how to connect to a few well-known cloud-services is an overhead that doesn't need to be, it's an additional service of the NodeBB devs/community. But "Real need for better docs for noobs" should be out of question. You should assume that anyone who uses an OS should be "proficient with the system". If they're not they need to learn how to use their favorite search-engine or switch to another system that's more comfortable (and most likely doesn't cost anything ).

In my opinion NodeBB should even have less docs about installation since I don't want users without any clue what they're doing to setup an online service.
This privilege should be dedicated to those who have learned to understand what they're doing since it comes with a great responsibility and a bunch of work (that isn't any-near done after the setup) to run an online service.
To run an easy-to-setup platform like NodeBB doesn't take the responsibility of you to be aware of internet-policy, copyright laws or worst-case-scenarios.
So all in all my opinion contains that "noobs" shouldn't think about running a platform at all before getting familiar with the system and the platform.

But don't take this as an overall opinion of the NodeBB-community, it's my personal one and I expect a broad pool of (different) opinions about that to be present here

I should really learn how to write short answers and how to not make a discussion about windows vs linux within each post xD

@psychobunny

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
—Tom Cargill, Bell Labs

(https://en.wikipedia.org/wiki/Ninety-ninety_rule)

To understand that exports syntax' you need to understand the node.js module structure a bit better:

Node.js (not NodeBB, it's just node.js) gives every module (every file that gets called somewhere using require(...), in this case from inside NodeBB core) a few (very few) global variables.
The relevant ones in this case are module and exports.

They in fact are the same from the beginning of module execution module.exports === exports.
But if you want to export something else than a plain object (such as exports) you can overwrite the exports attribute of module.

module.exports = "hello world";
// module.exports !== exports
// exports is now a meaningless object, not to be used anymore

What the two latter plugins do is to overwrite that module.exports attribute with another object (it's just the decision the dev made) instead of giving the pre-defined module.exports - that can also be referenced by exports - some new attributes.

Just consider a var exports = module.exports = {}; being executed before module-initialization. exports is a nice shortcut if you don't need to overwrite the container you want to export, but only it's attributes.

Documentation link: https://nodejs.org/api/globals.html

The other point regarding parameters for hooks can (mostly(?) at least since 0.8.0 I guess) be generalized to one parameter for action hooks and two parameters for filter or static hooks.

• action: function (data) { ... } - no callback since NodeBB doesn't wait for anything, actions are just to broadcast an event
• filter/static: function (data, callback) { ... } - callback to notify NodeBB back when you're done computing (by convention the callback needs to be called with callback(err, result) where one of both needs to equal null)

The data is most likely an object you can check the values either within NodeBB core code or by simply console.loging them once.

@AccessDenied said:

@frissdiegurke Thank you for you well written response. That clears up a lot on why I'm confused - there just simply ISN'T documentation on anything. If I could ask, how did someone like yourself become familiar with the concepts behind NodeBB? Are they just intuitive or are they related to other forum/CMS style frameworks?

I've been into node.js (self-trained with help of brother) in first place - plain browser-side javascript mainly via userscripts and hobby pages even beforehand - and discovered NodeBB later on.
If you have some experience with any node.js application and know a few different conventions/styles (e.g. callback vs promise-based coding) you kind-of understand all node.js applications (as long they're not too bad written).
And since NodeBB is quite well-written from my point of view it isn't hard to get into it when you know the underlying language.
I've followed NodeBB since early days (not the very beginning, but 0.3.x or so), so I've become familiar with their code-base and never had problems with reverse-engineering any feature I needed to know more about. Of cause I did ask the community a few times, mostly when I thought to have an idea of improvement or I felt like sth. was missing.

You're not a burden, I'm happy to help (besides some other reasons like improving my english knowledge). Otherwise I'd not be active within this community and would just keep writing my plugins within a dark room . If I'd even bother to write the plugins then (since I mostly write them for this very same community...).

I've created a broader solution with pattern matching:
[nodebb-plugin-email-whitelist] Email domain filter plugin

Hey guys,

it's been a while

I've created a plugin for email domain-name filter specification (whitelists, blacklists, both):

GitLab link | npm link

It's possible to specify just any patterns for domain-name matching, like shown within the examples.

It utilizes a matching module (ns-matcher) written by myself because I haven't found any matching modules for order-relevant tasks.

So if you find any bugs, please report them

Examples

Comments (shown with //) are not allowed within the actual syntax (yet).

Simple whitelist:

email.example.com  // Allow email.example.com
email.*.example.com  // Allow email.XYZ.example.com
**.email.abc.example.com  // Allow email.abc.example.com and all (deep) sub-domains
!email.abc.example.com  // Deny email.abc.example.com (sub-domains are still allowed)

Blacklists using negative patterns:

**  // Allow everything
!**.example.com  // Deny example.com and all (deep) sub-domains
email.example.com  // Allow email.example.com

I hope this will be useful, at least I needed it myself

Btw I know the plugin name might be misleading due to the possibility of blacklists/mixtures as well, but I did publish after a long coding session xD sorry.

Pings due to feature requested: @fasterthan @kalihman

To me /api/users returns "userCount":9474

@julian said in how to use own smiley pack:

You'll probably want to check out how emoji packs are installed... but I do believe emoji-extended supports custom uploaded emoji.

@frissdiegurke ?

It's pretty much what @TaLoche said. emoji-static plugin in addition to emoji-extended. This allows you to specify custom emoji sets that need to be activated within emoji-extended plugin page.

Since @MJ upvoted that post, is the question solved for you?

Probably the files are not lost at all - I don't know whether mongod uses a default configuration file or just default configuration if nothing is specified via --config.
Maybe your system uses systemd which means you're supposed to start mongodb with systemctl start mongodb, replace start with restart, stop or status for respective actions.

And if it's not systemd you're using, it might be any other init system with similar structure, in that case we'd need to know more about the system. uname -a would be a start.

@AOKP said in NodeBB and ads - A never ending story:

NodeBB now stopped supporting any DFP code at all

If you're reaching out for help with this, please share some code for sample integration and a version of NodeBB where it worked and one (probably master as of your telling) where it doesn't. Some facts are needed instead of vague "It worked, now it doesn't".

In my opinion the DFP website is shitty as hell, I got trapped within an endless loop between two pages trying to sign up a test account (with checking pricing first). So I'm not doing any further investigation of their service; If you can provide me with some sample code and an API reference I could run further tests as to why the service does not work anymore or how to integrate correctly.
I suspect, the lack of sample code is the main reason, so few people of the community try to help with this. Please tell if it's not possible to provide sample code.

I can't believe this is the fault or a bug on side of NodeBB since NodeBB does provide a reasonable amount of integration hooks within the frontend. It must be either a problem with DFP not being able to integrate well OOTB for single-page applications in general or a problem with your integration code as of my point of view.
The tutorial seems to be out of date and overall dirty hacking the core. I'm sure, with sample code and API reference provided one can set-up a good tutorial or plugin for this.

@zoharm Dependencies are allowed to change within a certain version range. If a package follows the semver specification (and does not introduce breaking bugs) there should never be problems with this for the version ranges NodeBB uses.
But in this case it seems the socket.io-redis (or maybe even one of its dependencies) has introduced such a bug approximately 5 days ago.

I can confirm that the bug is valid - in my experienced opinion - and on the side of NodeBB (or probably a mistake on side of its dependencies).

Reproduced locally with a fresh setup.

@zoharm You can achieve the same circumvention by just using the redis:host property within the config.json (or the setup procedure) for the redis url like

"host": "redis://:my-password@127.0.0.1:6379"

This does not require any code modifications

To keep the reference to the already filed issue: gh#5069

setpixel created this issue in NodeBB/NodeBB

closed NodeBB cannot connect to redis with password #5069

@deiden26 said in Plugin works in development but not in production:

@baris said in Plugin works in development but not in production:

Something looks wrong here https://github.com/myvr/nodebb-plugin-reputation-for-posting/blob/master/library.js#L42-L45. checkConditionAndRewardUser does not send back a callback

Could you explain a bit more about what seems off? From what I can see, checkConditionAndRewardUser takes an optional callback parameter, but I'm not providing one because this is the last task in the waterfall. If you are referring the the callback parameter the the anonomous function I send for the method parameter of checkConditionAndRewardUser, this should be filled by the checkCondition method that checkConditionAndRewardUser calls with its method parameter as an input. Wow, that's a mouth full

I guess he wanted to state that the next callback from line 42 is not called at any time.

You can add this to your custom CSS:

a[component="category/post/guest"] {
  display: none;
}