I hope I don't get accused of super bumping multiple threads tonight (really not so old threads or well not so old last post!)

On first impression, nodeBB was the ticket - without any of the technicals. It's all that matters.

It truly is all that matters. Since the majority of fourm users are not going to be technical and forum have there work cut out to drag people away from the twitters and face books of the world.

A forum can be deployed to any user base so it's application and audience is potentially as wide as you like and varied as you like, that you have to think about simple but not dumb Ui/UX and rely on the beauty of tradition, i.e. established and solid universal conventions that are universal but not afraid to push the envelope to enhance convention to the point it's at least feels innovate if not actually is.

Speed.

It's silky response. The fade out fade in transition was a genius choice, let me type that again GENIUS!

The Composer.

• It looks and is weighed better i.e. it's styled better, simple.
• It's not perfect, but it's one of the best out there.

The composer is the window to all content creation, the crucible of an entire forums everyday lifeforce. It's got to be good, it's got to always be trying to be better, by trying to be great. This is the interface that makes or breaks the user experience and thus a forum.

My UI/UX 2c:

Please consider making the composers upper top line a drag focus draggable area so it is not restricted to the black circle aligned to the left, that should really be centered (it took me too long to figure out) - it breaks a basic UI/UX expectation burned into our retinas at this point!

@julian Cool thanks, yea poor ns-embed is not happy in 1.12.2 - I and others already flagged in that thread, still, A Great plugin!

Ok SMTP/EMAIL is fixed!

Some deeper DNS/MX work seems to have made the difference and using "encrypted" setting - initially I was using StartTLS as per email provider SMTP guide, which specified TLS - tested it again and StartTLS broke it.

Encrypted works.

Yes!

As outlined in the second part to this post here - I have created this dedicated topic for the purposes of pitching this new feature and functionality for composer.

A composer that can align in one click to the right of the screen - creating a split view.

I guess if people want left they can have it but the concept is being able to easily reference posts on the right and compose on the left, keeping an unobstructed view of the entire flow of the topic posts without having to minimize the compose editor.

Meet the new contextual button that would toggle between positions.

Click to toggle horizontal position:
Click to toggle right-aligned position (split view):

As an evolution of composer core feature & function, I believe the case for, is incredibly self evident.

• I'm waiting for someone to tell me this feature is already available...
• I will edit an addition this OP with summary points and extra info if required.

Please Upvote - If you want to see this as a core feature in standard nodeBB deployment.

I've never really seen or understood the true value of a shout box but I'm open to other views - to me it seems to be an ambiguous duplication of forum function and often as an interface element in a forum, it always feels squeezed in.

That's my experience on other platforms.

Obviously, if nodeBB has a shout box it will be the best in the world!

Q: Is it possible for Logged in users to post also posts as guests?

Reason this would be useful is to allow guest posting, that can only be viewed when logged in.

Currently guest post would be wide to the world.

Sometimes existing users and newbies on certain types of forums would like to be able to revert to guest posting where anonymity is important, "asking for a friend..." type questions!

I also have a vague sense this might have already been covered before but I didn't find the exact thread - Please point me in the right direction id this is duplication! Tx!

This is a feature I wouldn't expect in forum software, since traditionally such systems like phpBB don't have it out of the box. It also seems wrong on a base trust level even before we got to the modern era of GDPR etc. etc.

Yet Discourse has this out of the box much to my own surprise and I thought but why would you need it?

Other than tracking abuseive PM's between waring users, which could easily be stopped by the recipient being able to ban PM's form a user. I didn't initially see the valid use case.

The point was made by Atwood, Discourse creator, that for example certain types of nefarious rings might use your PM system to share illicit material undetected. Think the worst kind.

• That is a very valid point and one worth exploring.

However it's still strange being able to read anyones private messages and that users also may simply assume that their messages are private. Few think about databases and that once a person has access to a database they can in theory access any of the info but it's not frictionless access. Discourses implementation is as simple as reading your own PM.

What I felt would be a better solution, more admin friendly and simply effective at addressing the problem , would be to have a system that monitors the PM activity and volume of user accounts.

For e.g. -Perhaps a threshold is set with some other criteria - then imagine a 0 post or very low post count user has more than 2 pm's a day it's reported and flagged in stats. Imagine another users has 100's of PM's per day or hour, it's flagged with more force, because such activity would be highly very suspicious. A whitelist system would handle the good guys and magybenot flag (like mods) but still report their activity too, if required.

So of my 10,000 imaginary forums users how of you find the 4 or 5 who are abusing the system, with little effort but with pinpoint accuracy fast?

Second to that there could also be threshold limits set that users can only read and send x pm's per day until they clock up some rep, which would act as a massive disincentive to abuse the PM system for nefarious and illegal activities. (apologies if such a feature is already there, I'm not 100% familiar yet with all of nodeBB functionality and feature set but getting there).

Open access for admins to PM's does not mean you will easily find and therefore stop the problem. Access only help you determine if it is a problem or not.

You need analytics as an admin in the first instance - therefore it's not an access issue!

I find the Discourse implementation a good example of solving a real but very niche problem but with a wrong solution or at least the wrong 50% of the solution.

I would really like to see a PM report system in nodeBB natively, as a core security feature to tackle this issue.

Warning and notices to users easily administered by default, that PM's are not publicly viewable but admin viewable if x. y and z occurs.

The crazy thing is Discourse team originally implemented this and gave moderators access. That's just insane IMHO, even as an Admin I am not really comfortable with that once click power - it's clearly open to I would say more abuse that what it tries to solve.

@Velocification Well I can't find the exact post now but if I remember correctly @Julian recently indicated a one-click installer was being reviewed right now over at DigitalOcean and it sounds very much like the ball was in their park.

Something I noticed when looking for a nodeBB installer in the DO marketplace, before @Julian revelled this insight, I was using Ctrl/CMD + F for the term "nodeBB" (because there are so many one clicks now) it appears to highlight hidden text in a few places. Weird. I dunno if this is a bug but maybe there is a invisible placeholder waiting to be sprung. I should have looked at the pages source code to see what it was.

I don't know if anyone has any hosted images out there either than might make a difference.

I've done some work playing around with this because it's too chaotic, in fact visually it's bad, very bad but I digress - I found it tricky to achieve but I got it to a point that it was workable, almost to my spec of 3 column, I managed 2 column that appear to be stable enough in an responsive context.

For example:

This is the CSS I used to achieve the above result 2 column layout:

.category-children .pull-left {
    column-width: 15em;
}

I'd like to post the entire custom CSS as I'd like to make it a theme for everyone but I'm not at a theme dev and upload to GitHub level yet, so if anyone would like to help me out, please message me.

I may post entire CSS set sometime, to catch any tips for tidy up - it would be nice to see it reviewed by the pro-pros

I love the composer in nodeBB. However, it's rare to find anything in life that can not be pushed toward greater perfection and since composer is pushing toward perfection already - let's push a little bit more to make the difference!

On community.nodebb.org - I noticed a few extra buttons that seemed to related to the same function or kind of, then I noticed even more - why have 3 image related buttons when you can have one?

Why?

Ok, first lets strip the overlapping icons and rearrange into more logical groups:

Post Edit Tools | Link Tools | Image Tools | Custom Tool | Zen Mode

Space

Super and look at all the new found space, minimal overload is not far off, time to look at the sequential order.

Less is More in the New Order

If there ever was a more graceful flow from left to right in perfect order I have yet to see it, with less buttons in a more logical, sequential and grouped order we are pitching for less visual cognitive load.

Summary:

• Minimal without losing functionality
• Clear left to right flow and back again
• Grouping of icons by contextual function
• Establishes a logical sequence to icon groups
• Creates more space for other icons
• Sets logical order and positioning for future icon inclusion

Naturally it flows that the 3 image button functions need to be folded into a pop-up menu.

Why this is probably a better outcome is that it creates a clear focus and display of the image options to the user using one click, all on a single menu.

Currently there are 3 buttons one of which is visually ambiguous as it presents as cloud up arrow icon, which could be construed as being actionable with any file for upload.

If you wanted to push the logic of this approach further, then even the smilies icon could considered a valid target (hypothetically!) to also fold into the single image button - creating a hybrid single image button, a hybrid pop-up menu with all the visual/image elements in one place.

Please note, I am not proposing it for now but I present it to tease out the natural evolution of where this route might go and is perhaps one reduction too far for broader nodeBB deployments.

Please upvote - If you woudl like to see this in standard nodeBB.

In any dark theme WHITE needs to be handled carefully, HAZMAT Suit and all!

This is continually peculiar and I really like getting myself into a bind...

I have started redis-server /with/path/to/redis.conf after deleting the old dump and replacing with the new one.

Then I restart nodeBB but it loads up with the old data! HUH?

Where is nodeBB picking up the old DB from memory or is there a snapshot conflict or something I have no awareness of, this is a simple enough process

I did a thing to test my curiosity - I shutdown redis twice in a row via redis-cli, after the first shutdown command it dumped the older dump file and then I deleted it.

Then I ran the same shutdown command a second time with save and lo and behold it dumped an identical db in /var/lib/redis - so is it really shutdown or is it pulling the older db that I am trying to flush out from somewhere else?

My initial thought was redis is not really shutting down.

Check the credit card!!!

@Julian Thanks for that... Doh!

I have found a config file in /etc/redis/redis.config

This is a good guide but I ran into a problem (surprise surprise) which may stem from original setup running Redis-server command run from a different dir, but I am not sure or how to find that out, but the Redis config file does point ot the /var/lib/redis dir so maybe my assumption is wrong.

This is what happens once I have successfully switched out the dump.rdb file into the /var/lib/redis

Clustering enabled: Spinning up 1 process(es).

2020-01-17T21:22:19.558Z [4567/1372] - info: Initializing NodeBB v1.12.2 https://www......
[benchpressjs] Unable to build or find a suitable native module, falling back to JS version
2020-01-17T21:22:22.799Z [4567/1372] - error: Your NodeBB schema is out-of-date. Please run the following command to bring your dataset up to spec:
2020-01-17T21:22:22.799Z [4567/1372] - error:     ./nodebb upgrade
[cluster] Child Process (1372) has exited (code: 0, signal: null)

I ran the upgrade to see what might happen and I hit the same problem of a nodebb with empty menu bar at the top and more or less blank everything else.

I used the SHUTDOWN NOSAVE in Redis-cli

I guess there is the possibility the dump.rdb is corrupted or missing some data.

OMG If I ever ask this question again. Please tell me to check that the domain is active!!!!!!!

Right I restored a few month older snapshot of this nodebb install that is borked, and while it worked at the time of the snapshot, it was a good snapshot point, but yet same result. Nada.

It's behaving the same way, No server found - but the server it is up, nginx, nodebb, reds, they're all up and running, Hmmm... I'm at a bit of a loss where to start teasing this out. I could try another snapshot and repurpose but I've used a historical snapshot of this install and still same problem... btw this is on Digitalocean but that been fine for this and other light nodeBB installs.

If anyone can point to the one thing to check first that might shine a light I would as always be truly grateful.

@PitaJ said in node install borked itself or I think it did... maybe nginx, any hunting tips?:

EADDRINUSE means nodebb is already running

I fixed the PID error in nginx, but that wasn't it.

Here is a section from the dev output, I think it's our old friend, EADDRINUSE error:

[4567/1345] - error: NodeBB address in use, exiting...listen **EADDRINUSE: address already in use 0.0.0.0:4567** {"code":"EADDRINUSE","errno":"EADDRINUSE","syscall":"listen","address":"0.0.0.0","port":4567,"stack":"Error: listen EADDRINUSE: address already in use 0.0.0.0:4567\n    at Server.setupListenHandle [as _listen2] (net.js:1259:14)\n    at listenInCluster (net.js:1307:12)\n    at doListen (net.js:1446:7)\n    at processTicksAndRejections (internal/process/task_queues.js:81:17)"}
>2020-01-15T23:08:48.753Z [4567/1345] - error: uncaughtException: listen EADDRINUSE: address already in use 0.0.0.0:4567
>Error: listen EADDRINUSE: address already in use 0.0.0.0:4567
>    at Server.setupListenHandle [as _listen2] (net.js:1259:14)
>    at listenInCluster (net.js:1307:12)
>    at doListen (net.js:1446:7)
>    at processTicksAndRejections (internal/process/task_queues.js:81:17) {"error":{"code":"EADDRINUSE","errno":"EADDRINUSE","syscall":"listen","address":"0.0.0.0","port":4567},"stack":"Error: listen EADDRINUSE: address already in use 0.0.0.0:4567\n    at Server.setupListenHandle [as _listen2] (net.js:1259:14)\n    at listenInCluster (net.js:1307:12)\n    at doListen (net.js:1446:7)\n    at processTicksAndRejections (internal/process/task_queues.js:81:17)","exception":true,"date":"Wed Jan 15 2020 23:08:48 GMT+0000 (Coordinated Universal Time)","process":{"pid":1345,"uid":1000,"gid":1000,"cwd":"/home/node/nodebb","execPath":"/usr/bin/node","version":"v11.15.0","argv":["/usr/bin/node","/home/node/nodebb/app.js"],"memoryUsage":{"rss":148332544,"heapTotal":110985216,"heapUsed":85905376,"external":692996}},"os":{"loadavg":[0.666015625,0.30126953125,0.10986328125],"uptime":410},"trace":[{"column":14,"file":"net.js","function":"Server.setupListenHandle [as _listen2]","line":1259,"method":"setupListenHandle [as _listen2]","native":false},{"column":12,"file":"net.js","function":"listenInCluster","line":1307,"method":null,"native":false},{"column":7,"file":"net.js","function":"doListen","line":1446,"method":null,"native":false},{"column":17,"file":"internal/process/task_queues.js","function":"processTicksAndRejections","line":81,"method":null,"native":false}]}
>2020-01-15T23:08:48.754Z [4567/1345] - error: listen EADDRINUSE: address already in use 0.0.0.0:4567 {"code":"EADDRINUSE","errno":"EADDRINUSE","syscall":"listen","address":"0.0.0.0","port":4567}
>2020-01-15T23:08:48.754Z [4567/1345] - info: [app] Shutdown (SIGTERM/SIGINT) Initialised

I ran ps aux | grep node output:

root      1188  0.0  0.3  63476  3716 pts/0    S    23:05   0:00 su node
node      1189  0.0  0.4  23020  4972 pts/0    S    23:05   0:00 bash
node      1272  0.1  4.1 605244 41980 ?        Ssl  23:08   0:00 /usr/bin/node /home/node/nodebb/loader.js
node      1283  1.7 11.0 893076 111140 ?       Sl   23:08   0:05 /usr/bin/node /home/node/nodebb/app.js
node      1369  0.0  0.3  40096  3536 pts/0    R+   23:13   0:00 ps aux
node      1370  0.0  0.0  14856  1004 pts/0    S+   23:13   0:00 grep --color=auto node

I thought maybe I could kill a process but that doesn't seem to work - Any ideas folks?

Altnernativley I guess I could possibly dump the redis DB and reload an known working snapshot as a workaround, learning something new in the process... can this be done with redis?

A nodebb install went down on me - everything looks fine, server is running, nginx is running, nodes is running, but the URL is not resolving - cannot find server - which first thought is nginx... systemctl status nginx and it's up and running... - I did check the log and there was. a message about ns-embed plugin, I disabled that and rebuilt nodebb via cmd line but still no show, even though it's boots up and runs running according to terminal output.

I'll have a look at dev, but on quick look the vitals seem fine but now show... first for me. Maybe redis is the problem, but no errors on node startup, I haven't checked that, any tips there much appreciated.

Still think it's nginx... hmmm

nodebb v1.12.x

I've borked something in the custom CSS - lists of topics, popular, recent etc. etc. are NOT using the full width available - say 75-80% of the width available is being used - I have unused space to the right size of the recent post preview. - it's lie there is a blank column.

The primary nav menu fixed at the top is fine, this is what I am comparing it to.

Any idea what is the controlling element here in the CSS?

Could a conflict somewhere too but I'll look at this later... when I turn off the custom CSS to see if it reverts.