No problem - glad I was able to help you locate the problem.

As long as your SSL certificate is still in place and the iRedMail functionality is all working, I don't think there should be an impact on the security of your system.

@fiag said:

Hi @psychobunny,
would you add an option to enable SSL encryption?
Some SMTP server only support SSL connection.
Many thanks!

Please, please, please do this. I want to use a gmail account to send notices and that requires an SSL connection (or results in massive false-positive spam bin assignments). My only option right now appears to be to install a proxy to translate the request to SSL (e.g., stunnel).

This is definitely at the top of the list of my desirables for NodeBB!

No announcement thread in the announcements section?

Congratulations, guys! NodeBB has come a long way.

I don't really have any problems with bootstrap or the vanilla theme other than this one. If anyone else is experiencing this, putting this into your custom CSS area will fix it as a temporary workaround:

UPDATE: The fix below actually causes the problem in newer versions of NodeBB, so please do not use it. Updating your NodeBB will resolve the basic issue now.

.modal-backdrop {
    z-index: 1039;
}

I have a specific thread on my forum with a post count of 34. There are 33 posts and 1 purged post in the thread (which may be a bug - seems like it should not be showing deleted posts in the count, or it could be the result of a network failure or something). Clicking the double-down-arrow on the menu bar on this thread results in an infinite request loop in your browser (you can see the page "flicker" and the network console goes berserk). Happens in both IE and Chrome (fully locks up the IE process if I let it go on for very long).

The double-down-arrow link, of course goes to /thread/34 and loading this link directly in your browser does duplicate the issue. Going to /thread/35 redirects the browser back to /thread/34, still causes the problem. Going to /thread/33 takes you to the final post on the page, as it should. I assumed that this was the root of the problem and was going to report it as a bug. I purged a post from this thread and I suspect that may be where the thread count got off. I've tried to recreate that with other threads but I am unable to do so.

Going over the post count on another thread (e.g. /otherthread/9001) doesn't cause a problem because it just redirects back down to the correct post count.

How do I fix this?

I'm getting 404 errors from the admin page of the imgur plugin (nodebb-plugin-imgur). I'm running NodeBB 0.4.1 0.4.3. I believe this has something to do with a new method of creating routes, but I'm not sure what I can do about it.

Any guidance?

@julian Ah. I wasn't thinking about avatars.

Pictures pretty much say it all:

Says this when I click upgrade on either one:

Nothing seems to be broken, other than the little red flags here.

@arasbm said:

I am not sure what the right behaviour would be here. Should I limit the whoisin plugin to only the OP? My thinking was that it would be nice if anyone could start one in a discussion, and if someone else attempts to add another one, it will be just a copy of the first one.

I'd say first post only, but you could preserve the option through a configuration setting and let each forum admin decide for themselves.

Can't really explain this, but I was scrolling through the Persona theme announcement thread and got some very strange behaviors. Don't know if this is theme-related or a problem with the engine. Screen shots to explain are below. I'm using Chrome 41.0.2272.118 m which claims it is up to date (and so it probably is). Console was free of errors.

First example:

Second example:

In both cases, I believe there should only be one reply button at the bottom of the page. I think this may be related to using the mouse scroll-wheel to scroll down the page.

@julian said in Session Mismatch:

sort of like nginx captures it and removes it from the url as it proxies it.

That can't be the case, because NodeBB doesn't respond without the /forums. For example, if I put the IP and port into my address bar (http://192.168.0.10:4567/), I get a connection refused error, but http://192.168.0.10:4567/forums responds. Edit: This isn't to say that the sub-folder installation couldn't be the cause of the problem - just that NginX seems to be passing the URL correctly.

I'm kind of wondering if this has something to do with SSL.

@julian Also ... the location block is because I serve the URL from /forums on the reverse proxy. It is included in the proxy pass because NodeBB is also configured to respond to /forums (so, accessing it by the IP and Port directly from my network also requires appending "/forums"). I found that it must be set that way for various resource paths (CSS and script files, I think) to get served correctly.

@PitaJ

{
    "url": "https://www.example.net/forums",
    "secret": "88888888-8888-8888-8888-888888888888",
    "database": "redis",
    "port": 4567,
    "redis": {
        "host": "127.0.0.1",
        "port": "6379",
        "database": "0"
    }
}

@PitaJ I will grab the whole thing for you, tomorrow, if I remember, but the "url" value is "https://www.example.com/forums" and I think that's the only value that should have an impact, here.

@julian it was required to make this configuration work back in 1.0.x. Is there one or another of the two you would recommend removing? My only other option at this point seems to be to revert to the VM snapshot I made of 1.0.3, but that's going to mean losing about a week's worth of new posts, since I didn't notice this was broken after the upgrade.

@julian I'm getting this error. The forums work for people who were logged in before I upgraded (went from 1.0.3 to 1.2.1) but no one who wasn't logged in can do so and no new users can register. And as far as I can tell, I can't even temporarily disable the CSRF token as a work-around, which is pretty frustrating.

1. CONFIG.JSON URL value is correct, but involves a subdomain installation (/forums) and an HTTPS URL.

2. COOKIEDOMAIN was already blank, but I ran the redis script to clear it anyway.

3. This value was not present (because it was not in the original NGINX configuration document), but I added it and nothing changed. The NGINX config I use is given below. It's probably important to note that I use SSL for all incoming connections, and the URL value from my config.json includes https:// at the beginning. NGINX and NodeBB are run on the same server, so SSL is not used between them.

   location /forums {
           client_max_body_size 20M;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;
           proxy_set_header X-NginX-Proxy true;
           proxy_set_header X-Forwarded-Proto $scheme;
   
           proxy_pass http://127.0.0.1:4567/forums;
           proxy_redirect off;
   
           # Socket.IO Support
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";
   }

@julian Yeah, it's minified, obviously, but I figured the "ctrl+f" binding would be enough to locate the function in the full version.

And I thought 1.0.3 was the latest? Do you mean the weekly or master branch or something?

I noticed that threads weren't automatically retrieving new posts, so I checked the console and found these errors:

Uncaught TypeError: Cannot read property 'bind' of undefined (nodebb.min.js). The prettified function causing this error is below and the error occurs on the line with t.bind()

    function p() {
        require(["search", "mousetrap"], function(e, t) {
            $(".topic-search").on("click", ".prev", function() {
                e.topicDOM.prev()
            }).on("click", ".next", function() {
                e.topicDOM.next()
            });
            t.bind("ctrl+f", function(e) {
                if (config.topicSearchEnabled) {
                    var t = ajaxify.currentPage.match(/^topic\/([\d]+)/), n;
                    if (t) {
                        e.preventDefault();
                        n = t[1];
                        $("#search-fields input").val("in:topic-" + n + " ");
                        app.prepareSearch()
                    }
                }
            })
        })
    }

I just did a fresh server rebuild, so maybe I screwed something up, or maybe this has been happening for a while and I didn't notice.

@pichalite Thanks ... I should probably learn to check those.

My forum is installed in /forums and the subcategory links omit the primary directory, resulting in 404 errors.