Please don't use Chrome to workaround this.

It's just that html.composing body.page-topic.page-topic-13568.page-topic-dark-theme.page-topic-category-10.page-topic-category-nodebb-themes.page-status-200.skin-paper div.composer.resizable.reply div.composer-container div.row.write-preview-container div.write-container textarea.write doesn't have background: white, as you can see in the excellent Firefox DOM inspector. In the NodeBB stylesheet, textarea has color: inherit, but no background: inherit. So the browser stylesheet for textarea's 'background' is used, which is the theme background by default, which is dark in this case.

Some digging shows that these values come from normalize.css 3.0.2. Seems like this is the same problem as this one: https://github.com/necolas/normalize.css/issues/469

This has been fixed in normalize.css in Jan 2016 by removing color: inherit. In the case of a dark background (coming from the Gtk theme), the text should now be white (or whatever the Gtk theme says) instead of dark, which makes the text readable.

Suggested fix: use a version of normalize.css later than Jan 2016

PS: Maybe Chrome is just not able to show the dark Gtk theme? Could be an enhancement request

clottes created this issue in necolas/normalize.css

closed Input text not visible in cases due to color:inherit #469

For our NodeBB installation, I have made a Github issue importer (Github issues → NodeBB). However, I don't have the time to maintain it and it's not perfect code (although all NodeJS and relatively clean, I think).

Is there anyone who wants to take over and maintain it?

Hello,

I suggest to (may be as an option?) replace CDN (at the first glance, there's bootstrapcdn.com and cdnjs.cloudflare.com) and Google dependencies (fonts.googleapis.com in the CSS) by local files because

1. I don't think it's good practice to spread our visitors' data (maybe including referrer etc.) all over the world for privacy reasons (for instance, Google Fonts are a free visitor counter for Google, and I don't want Google to track [probably with Google cookie, i.e. bound to a specific user] which users visit our site),
2. it would make us independent of these services. If a CDN chooses to take down the .js because it doesn't meet their requirements or for whatever reason, all NodeBB instances will be unusable,
3. site loading may even be faster because there are no additional DNS lookups and some gzipped JS and font files should be transferred quickly by any server.

It would be a really good feeling to get back control over the whole forum and not having to trust CDNs and Google.

Thanks for your awesome work!

@Jacob-Moen said:

CDNs will make the site load faster - that's what they're for - so that users around the world does not have to go all the way to your server to fetch resources, but can fetch them closer to their location.

Thanks, I know what CDNs are used for And I want our users to fetch our resources, and not the resources of Google (or Akamai, or Amazon, or whoever else), and get tracked at the same time.

Ok,. I have just thought every gcc48 version would crash for you. – So everything is OK

Really love NodeBB & FreeBSD

Hi,

I have some questions about full-text search and how it's intended to work with NodeBB.

Default search: I have had NodeBB running with the default search plugin (db-search-plugin), but search results were of very bad quality. I really tried to use it, but I can't tell users to "use the forum search" to find the answer for a question, because it just doesn't work. It shows a huge bunch of unrelated postings etc.

Solr: So I decided to set up a Solr instance and install "the" Solr plugin. However, it was not easy to find a working Solr plugin. There were several ones, some basically working, some not. Also, the only working Solr plugin reported that the Solr collection works; re-indexing and searching were also working (with high-quality search results :)). However, new postings were not indexed, although the option is on. So, using Solr is also very cumbersome and not really useable currently.

Redirecting to a search engine: On the public forum, I have just disabled forum search and used a search bar which redirects to a search engine (with site:forum.domain appended). However, I'd like to start a private forum, too (with sensitive information), and that's not an option there.

Your opinion: importance of search? My personal opinion is that good full-text search is a very importang thing for a forum. Whats your opinion on that? Isn't it one of the most important features of a forum? Most people recommend to use the forum search before asking the same question again and again. In my opinion, good full-text search makes the difference between a volatile social network discussion and a knowledge database.

Suggestions: I know that good full-text search is a very complex topic and can't be done as a "side project". So I wonder whether the default NodeBB installation could be improved by providing

• a working and officially supported Solr plugin for those who need self-hosted search (for instance because the forum is private), and
• a working and officially supported "redirect to $search-engine" plugin (when the forum is public and the human/computing resources for self-hosting Solr are not available)

instead of activating the db-search-plugin by default.

What to do? Can you suggest what I can do to get good full-text search working on a private forum? Shall I use the Solr plugin? Which one? Is there an officially supported plugin that's actually being maintained? I'd have to dig into the problem that new postings are not indexed automatically first.

What search plugins do hosted NodeBB installations use?

PS: Thanks for providing NodeBB as free and open-source software! I really love it and I'd also be motivated to contribute to NodeBB in this matter. I just don't know where to start, so I decided to start it by asking and discussing

What would be really cool (and it's not available yet, as far as I understand): if there was a privilege for tagging posts. I use tagging for purposes like marking a topic as solved or as assigned to a specific component. This should not be allowed for normal users, but only for admins.

At the moment, I just remove all tags set by users (most people don't set a tag anyway) and set them manually. But it would be great if there was a setting for that

Problem identified and fixed: it was the direct transport, which is not a good choice (should be sendmail or smtp instead). See https://github.com/NodeBB/NodeBB/issues/4034#issuecomment-170894390

rfc2822 created this issue in NodeBB/NodeBB

closed Validation/password reset emails are not sent to some email addresses #4034

@artesea Currently, the Apache Solr plugin is working here very well. It requires a Solr server, which quite large and runs in a VM here, but it's really worth it.

@PitaJ Done: https://github.com/NodeBB/NodeBB/issues/5127

rfc2822 created this issue in NodeBB/NodeBB

closed Tagging privilege (feature) #5127

Got it working https://github.com/rfc2822/nodebb-plugin-sso-gitlab

1. Create a Gitlab application with scopes openid and read_user.
2. Set the application ID/secret in config.json: "oauth": { "id": "yyyyooouuurrr iiiidddd", "secret": "sssseeeccrreeetttt" }
3. Install & activate the gitlab-sso-gitlab plugin (I used npm link).

Is there a Gitlab SSO plugin? Would be really cool

I have tried forking OAuth SSO and adapting it for Gitlab: https://github.com/rfc2822/nodebb-plugin-sso-gitlab but it didn't work well …

Please don't use Chrome to workaround this.

It's just that html.composing body.page-topic.page-topic-13568.page-topic-dark-theme.page-topic-category-10.page-topic-category-nodebb-themes.page-status-200.skin-paper div.composer.resizable.reply div.composer-container div.row.write-preview-container div.write-container textarea.write doesn't have background: white, as you can see in the excellent Firefox DOM inspector. In the NodeBB stylesheet, textarea has color: inherit, but no background: inherit. So the browser stylesheet for textarea's 'background' is used, which is the theme background by default, which is dark in this case.

Some digging shows that these values come from normalize.css 3.0.2. Seems like this is the same problem as this one: https://github.com/necolas/normalize.css/issues/469

This has been fixed in normalize.css in Jan 2016 by removing color: inherit. In the case of a dark background (coming from the Gtk theme), the text should now be white (or whatever the Gtk theme says) instead of dark, which makes the text readable.

Suggested fix: use a version of normalize.css later than Jan 2016

PS: Maybe Chrome is just not able to show the dark Gtk theme? Could be an enhancement request

clottes created this issue in necolas/normalize.css

closed Input text not visible in cases due to color:inherit #469

@PitaJ Was the sharp dependency added in 1.10.2? sharp requires libvips, and the FreeBSD libvips port wants to install X11 here…

Hello,

When I just wanted to update 1.10.1 to 1.10.2 with the same procedure as always, it failed and NodeBB told me that I should manually install libvips (FreeBSD). So I tried to build libvips, but it wanted to install ~ 100 packages for an X server, which I don't want to have on my server. Is it really required to have X server code now just to install the dependencies for NodeBB and has this requirement been introduced in 1.10.2? Is there a reason for that?

Can I help making this dependency optional?

@artesea Currently, the Apache Solr plugin is working here very well. It requires a Solr server, which quite large and runs in a VM here, but it's really worth it.

@bri Searching a manageable number of postings (which should contain real text content, mostly without markup and all about a certain topic) should still be easier than indexing the whole Internet (and rank an endless number of pages which are highly "optimized" with SEO to be shown first etc.) Also, things like PageRank are not really applicable to a forum because a posting doesn't have to be linked often to be valuable.

Just had an idea: with Solr, even attachments (of postings) could be indexed

@bartvb said in Default search, Solr, importance of full-text search?:

@rfc2822 My guess is that the NodeBB project gains the most when nodebb-plugin-dbsearch is improved. I did a quick check of the MongoDB docs and it seems like there is quite a bit of room for improvement when it comes to the implementation of MongoDB fulltext search in NodeBB.

My experience with database full-text indices is bad. MySQL has a full-text index, too, and I have used it for several projects. It's OK, but the results are not as good as from specialized search engines as Solr. It confirms my prejudices when looking at what the default NodeBB Mongo-based full-text search produces. I also remember what happens when other projects (CMS like Typo3) try to build their own full-text search. It's just horrible and at the end, you still have to use a public search engine with site:.... to find what you're looking for.

Good full-text searching is an extremely complicated task. Why not leave it to specialized projects? I just don't understand why every project needs its own unusable low-quality full-text search instead of

• making use of public search engines (in the end, this is what most people do – redirect to Google), and
• making use of already available, specialized open-source search engines like Solr and Elastic Search if this is not an option?

Of course, the MongoDB full-text index could still be available, but not as only officially supported and advertised solution.

In my opinion, a side project of a database ("oh yes, full-text index would be cool, let's add it quickly") can never provide acceptable results because the topic is too complex. I also guess that the people who have developed Solr are not idiots who like to waste their time for nothing. (Ok, this applies to MongoDB people, too, but maybe the MongoDB full-text index is for use cases where high-quality full-text search is not as important as for a forum.)

For reference: https://github.com/julianlam/nodebb-plugin-solr/issues/34

rfc2822 created this issue in julianlam/nodebb-plugin-solr

closed New postings are not indexed #34

@bartvb I have just tried Elasticsearch. The default Elasticsearch plugin included by NodeBB doesn't even allow to (re-)index all posts … which means manual importing. No …

The question is: shall I try to improve the Elasticsearch plugin, creating the 10-th unmaintained fork which is then working on a single instance (mine) until the next major NodeBB update, while overall search is still horrible for 99% of NodeBB users? That's what I wanted to avoid. But it seems like interest in working full-text search is quite low