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;
}

The taskbar holds items such as post edits/creations. So if you for instance open a new reply to this post, the taskbar will contain a red circle with a white plus. If you click on that, the composer will be minimized until you click again.
This way NodeBB gets you the possibility of editing/creating multiple posts in parallel.

The taskbar also contains chats for example; those can be minimized too...

Hey folks!

First off, some links:

• oddlog - repository: https://gitlab.com/frissdiegurke/oddlog
• oddlog-cli - repository: https://gitlab.com/frissdiegurke/oddlog-cli

I've been working on a project called oddlog, object driven data logging, lately. It's still in early development (as of now version 0.1.3, first code written about two weeks ago), but I'd like to present it to you anyways.

If you know a logging library called bunyan, oddlog will probably look pretty familiar to you. It's because bunyan has been the main inspiration, but also the reason why I needed to come up with a new project.

If you know bunyan:

At first I tried to get bunyan working the way I wanted it to

• Have several output streams for the same messages - yes, bunyan is pretty good at this (even so the overuse of the name "stream" is pretty confusing)
• Have some backtrack-logging as soon as a messages level exceeds a specified threshold - I ended up with a half-working solution for bunyan that had to wrap and use some of bunyans internal functions; an ugly hack
• Have a reliable logging system - bunyan has a commented-out function called Logger#close which never got finished or even close to working. Thus when your application breaks or you call process.exit, you have no way to ensure the logging messages have been flushed to the files
• Have good code quality.
• Perform well

After taking a deeper look into the source-code of bunyan I decided not to fork and modify it but to create a very own logging library from scratch that provides similar functionality but better maintainability and more abstract transports.
As of today, I've managed to implement the basic logging system with most features bunyan provides, but in addition the possibility of nested transports (e.g. the backtracking transport allows you to specify sub-transports to deliver messages to) and advanced options for deferred transports (e.g. the backtracking transport). Since the backtracking transport does not deliver messages as soon they arrive, we have the question how to handle payload in the mean time. A deep clone would be optimal to prevent future modification by the user, but performs very bad. Thus I decided to give the control to the user application via some immediate* options for such transports.
In my opinion the maintainability is great and code quality pretty good (including jsdoc for relevant parts) - The same does not hold for the command-line interface yet; I'll have to tidy that up soon.
Performance wise I haven't completed all necessary benchmarks yet, but overall it looks pretty promising and outperforms bunyan in most tests.

If you don't know bunyan:

I'm not going to repeat, what I've already written within the project overview Just check it out.

Now to the purpose of this post...

As the project is growing more mature every day I'm in need of some real-world applications using it to detect any bugs and get some feedback about the experience. So if you're developing a non-professional node.js project that is in its early stages, so it's not too bad if something with the logging system goes wrong, it would be great if you could help me simply by using oddlog. I will definitely use it in all of my future projects since I'm confident it's better than all other logging libraries I know of. But of course it needs some proper testing and application yet. If you would use it while I'm improving it (and hence not working on applications that actually use it), it would probably get more stable faster.
However, keep in mind that it's in early development and may show up a bunch of bugs. Although my simple-by-design example applications work well.

Besides the default oddlog and oddlog-cli packages (written in ES6, but CommonJS module system), there are babel transpiled versions oddlog-legacy and oddlog-cli-legacy available for non-bleeding-edge versions of node.js - I'm not sure how they perform thought.

Feel free to contribute in any way, that would be highly appreciated

Please share any comments and thoughts

Many thanks, frissdiegurke