Is there any straightforward way to determine what versions of NodeBB a particular version of a plugin is compatible with? Or vice-versa?

I'm still running a roughly v0.3.2 version of NodeBB and when I do a clean "npm install" I get a version of the nodebb-widget-essentials plugin that crashes the process.

@baris

That does appear to resolve the issue. One issue it brings up, though, is that I have customizations to the lavender theme and the version I've been using appears incompatible with Edge.

Is there any way to identify which versions of the lavender theme are compatible with which versions of NodeBB?

@baris

I'm currently running a patched version of 0.3.2 I think.

I'll try to upgrade and see if it fixes it.

Looking for some input/feedback.

I'm running NodeBB on Heroku and RedisToGo. After a large data import (tens of thousands of posts) when I log in as any user and click into "Unread" and "Mark all as read" the memory usage on both the server and Redis instance spikes. In my case I'm still running in test mode with just 512MB in redis (it usually sits at 309 used or so) and 512MB of memory on a basic Heroku dyno.

Basically the dyno grinds to a halt from swapping and the redis sends an alert about being over quota. Once I kill the dyno memory in Redis drops back down, and of course the restarted dyno doesn't resume the operation.

Is this behavior expected? Do I just need to allocate more memory to allow the operation to complete without blowing out my resource quotas? Is there any way to just flag all posts as read by all users as a starting point since I'm guessing it's trying to mark tens of thousands of posts as read all in one operation?

Thanks!

Sorry for the late reply.

So it sounds like it's not really intended for the HTML Entities to ever make it into the database. I was able to pull a node module "html-entities" and feed the titles through that on the way in through the importer. The post contents were rendering okay so I just left those as is, didn't want to mess around with what order to apply conversions and whether they'd screw each other up.

One of these days I'll get around to contributing back some changes to nodebb-plugin-import. Things have just been crazy around here lately.

Thanks for all your help.

I'm running a data import using @bentael 's importer.

It looks like posts that have escape sequences render correctly as part of a posts content, but display the literal escape sequence in the post title. Screenshot:

And looking at the data via redis on the backend:

127.0.0.1:6379> hget topic:3369 title
"Исчезли деньги ?!"
127.0.0.1:6379> hget post:3369 content
"Всем привет, буквально 5.06 поменял реквизиты с помощью своего мененжера, сегодня захожу в dashboard, а на баллансе 2 доллара, было до этого почти 50 долларов, в разделе Royalties нету выплат, где тогда деньги?"
127.0.0.1:6379> 

It looks like the content and title are being encoded the same way, but for some reason it renders properly in the post content but not the title.

I also tried copying and pasting some of the properly rendered characters as the title of a new post. This appears to work but produces a different encoding within the database:

127.0.0.1:6379> hget topic:3472 title
"\xd0\x92\xd1\x81\xd0\xb5\xd0\xbc \xd0\xbf\xd1\x80\xd0\xb8\xd0\xb2\xd0\xb5\xd1\x82"
127.0.0.1:6379>

Any suggestions? I suppose I could try to perform the conversion between encodings during the import... any idea the specific names of these two encoding types?

@julian So I forked and installed @seti123 's plugin. I had to make a few changes to the way it calls topics.getTopicsByTids() - it looks like the function signature may have changed.

At this point I appear to be getting legitimate search results from the long-form search url that's being installed:

http://localhost:8252/nodebb-plugins-elasticsearch/search/:term

I believe the standing question is:

Is there some way to override the built-in /api/search/:term route so the UI will process the elasticsearch results instead of the built-in REDS results?

I'll dive in and see if I can figure it out... let me know if you have any input.

Thanks!

@julian That was it.

I had an older version of the Lavender theme with the old style admin template.

Thanks!

Are templates cached in some special way that doesn't get cleared on a standard browser refresh? Local storage or something?

I've tried refreshing and restarting the server and the admin cog is still showing up for every user. I can see that I'm loading a stale version of header.tpl because the cog <li> looks like:

<li class="{adminDisplay}">

And I can see the commit that removed that.

Hmm. I guess I can't delete the thread and now having deleted the anchor post leaves this thread pretty garbled.

For anyone else reading this was a silly browser caching thing, not relevant.

@julian doh. I've done that so many times today, not sure how I missed it this time.

Yes, I swapped branches from an older version and my browser didn't keep up.

Thanks.

EDIT: just a browser cache thing... delete this to avoid clutter, maybe?

I just upgraded to 0.3.1 plus some custom stuff. When I click themes it spins on "Checking for installed themes" but never loads it.

I checked the log and see

warn: [socket.io] Unrecognized message: api:admin.themes.getInstalled

I checked the commit history and see this:

I don't think I messed with anything that could have caused this...

@baris So I believe this relatively smaller refactor would solve my problem.

https://github.com/MakerStudios/NodeBB/commit/5f93f7c6202bcbbaa5d26a653a28c6c8eb4e0c1e

I hesitated to do more since I'm not 100% sure what drove the initial decision to do some of that initialization at require() time. I see a few database round-trips but most of those calls could be run synchronously if I understand express correctly.

Thoughts?

Hey @baris ,

I started on the refactoring of our authentication code, but ran into some issues. I'm somewhat new to express but I think the problem is the plugins "action:app.load" method doesn't get invoked until after the app.use(app.router) call in webserver.js line 308 which prevents it from actually intercepting requests before they are routed by the application.

From what I can see it looks like much of the webserver.js initialization is actually launched asynchronously when that file is included by app.js, not when it's init method is invoked. I tried firing the same hook just before the app.use(app.router) call to see if that would work, but it appears that plugins aren't yet initialized by that point - not surprising since the init call is a bit further down in app.js.

I think to accomplish what I'm after might require a bit of refactoring of the timing of the init code to postpone the webserver initialization, or at least part of it, until after the plugins have loaded. I'd be happy to take a crack at this if there's a chance the code might make it back upstream, but I wanted to ask if this was something you guys might want in the core codebase or not before investing the time.

@bentael Just a few (business) days late:

Build software better, together

GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.

GitHub (github.com)

I'll ask about renaming it now that I've looked a little closer and understand your naming convention.

I see what you mean in the commit log. Based on this:

@julian said:

@bentael @medwards For the most part, we're limiting refactors to minor version bumps, and as the next version is 0.3.1, you should be fine if @bentael fixes up the importer for edge, even if 0.3.1 isn't released by then.

I was running the data import using the version he specified, but then launching the web app with v0.3.0 expecting them to be data compatible. I'll have to upgrade the code I'm using to launch the web server - my mistake.

@bentael Sorry for the delayed reply.

I understand everything you said, but I don't think that is my problem. I am using the "admin" user that is uid:1.

After digging into the code I was able to figure this out. It looks like the group that grants admin access has changed from "administrators" to "Administrators" which is case sensitive. I was able to solve my problem with

hset group:gid Administrators 2

I based this on line 752 in user.js

groups.getGidFromName('Administrators', function(err, gid) {

which sort of just creates another name for the same group... I think. Not sure if this would work throughout the codebase or not.

@bentael I think the database is already in the state you are trying to get me to put it in:

redis> hgetall group:gid

1. "registered-users"
2. "1"
3. "administrators"
4. "2"

redis> smembers gid:2:members

1. "1"

redis> hget user:1 username
"admin"

redis>

The user "admin" (uid:1) is already in the gid:2:members set (which is the "administrators" group).

Are we sure the latest version didn't change the way privileges are allocated?
@psychobunny

@bentael @psychobunny @julian

So I have approval to open source the vb exporter. It's rough at the moment and I won't have time to improve it a for a few weeks, but at least it'll be out there. I'll post a link later today.

Quick question, also. After the most recent run of the importer my "admin" user (uid:1) does not appear to be an admin user. He's in the gid:2:members set which is the administrators group. I found an old post that said to add the id to the "administrators" global key in redis, but that doesn't appear to exist anymore.

Any pointers?

@bentael quick update: first draft of the vbexporter has been submitted for open-sourcing approval.

It needs a bit more cleanup for general consumption ( it's my first node_module "release" ) but it's a decent starting point.

Also I'm going to go ahead and fork your importer. Once I've got anything worth contributing back I'll figure out how to issue a pull request ( first time for that, too ).

Thanks for all your work (and the node team too)! I'm excited to be able to contribute something back.