Good morning.

I just defined a widget area in the menu.tpl (partial used in header.tpl) called navbarsearch with a global scope (all pages). That area is visible in the admin panel, I assigned a dummy html widget to it.

theme.js

{
	name: 'NavBar Search Area',
	template: 'global',
	location: 'navbarsearch',
}

partial template:

<div widget-area="navbarsearch" style="background-color: red; flex-grow: 1;"></div>

api output:

"widgets": {
    "navbarsearch": [ {
        "html": "<div class=\"well\">Test</div>"
    } ], ...

The api-output of any page shows the widget contents, but it doesn't get rendered into the widget-area... Did I miss anything?

Best,
Flo

Good morning.

First of all, I'm not a developer, and I'm sorry for every noob question that comes up here.

Right now I'm playing around with the plugin/widget development. My goal is to have a widget which includes a search bar and a result div. Every change in the search input field fires a jquery request against a foreign api. Result is a big json object, containing an array of objects (example fields: image, name, uuid, type).

I was able to put the plain results into the div. Now I want to process these results (splitting them up by type) and render them into beautiful partials.

For your imagination:
<search box>
<box for type A with a list of entries> <box for type B with a list of entries>...

Can anyone please give me a headstart?

Thanks in advance.

@julian Do you see an easy/nice way how to solve this problem?

Good morning,

I'm looking for a way of banning a single user from one specific category.
So far it looks like the permission system only has two states, allowed or undefined, but no forbidden.

I tried different things:

• Adding that user on the category permissions directly, removing everything except Find/Access, but then the permissions for registered-users kick in and allow writing again.
• Adding a second group with that user to that category with limited permissions - see above, same problem
• Same as previous option, but with removing that user from registered-users - works but...

... we have round about 150 categories, adding a new group to all of them is a lot of work. Also I'm not sure if removing a user from registered-users is a good idea.

Is there a nicer way to reach my goal?

Just for your comparison: We use nodebb with ~3 Million users and the same amount of posts... Running in a redis cluster (we wrote our own layer for that, because the node-redis doesn't support clustering). We tried mongo first, but it was not fast enough for our needs.

@julian Company decided that we are not going to support IE8 anymore, hurray!

So, Websocket connections are not bound to a specific process, als long as the session data is available everywhere? One single request as I assumed above?

We're using google cloud as our hoster, so we should be safe here
Even the routing nginx for the websockets is separated from the other routing systems.

I'm not a developer, so I don't have a real clue how it works. When we used long-polling and websockets in the beginning, nodebb tried long-polling first, ending up in endless loops because the handshakes failed. This problem disappeared immediately when we removed long-polling from the transports. In my web console I can see a single websocket-request in pending state, with frames being sent over.

You're right, websockets don't work through akamai (we're using akamai) yet. So we're using a separate subdomain for the websocket-connections pointing to the datacenter directly. The page itself is protected, and the websockets are accepted by an nginx where we can use stuff like rate limiting.

I'm not sure wheres the difference in the handshake between long polling and websockets, but websockets simply work with one single request, as long as the session is available on all instances - via redis in our case. I guess the handshake (auth) and the connection upgrade happen in the same request.

Good morning.

We stumbled across this problem as well some time ago, and found a good solution for that.

Our system consists of an nginx routing server as a gatekeeper, a mesos environment for running multiple containers and an ha-proxy to access these containers easily. So basically we're enforced to run nodebb in single instances, and we can't use sticky sessions because the containers change all the time.

Our solution: All nodebb-instances share the same redis session store, and we disabled long-polling transport for socket.io -> works like a charm. No need to hassle around with any kind of clustering or request routing.

I don't see any problems by disabling long-polling requests (the even messed up our statistics), because every modern browser supports websockets. And they are working very well. Maybe I've overseen something here?

Best,
Flo