NodeBB Blog

Very Nice!

Occasionally, we will get asked whether there are any differences between our hosted service and the open source project. It is as though we are holding back some great features and only allowing our paying customers access them! Conversely, it could be assumed that because we are hosting the software for others, that we would somehow out of self-interest or for economic reasons, deliver an inferior version with limitations. I'd like to say upfront that this is not the case for NodeBB. When you use our hosted service, you receive the same great NodeBB software that you can get for free off of our GitHub repository. What we're selling is support, maintenance, upgrades, and peace of mind delivered by our world-class† support team. You definitely can host NodeBB on your own! We've strived for years to deliver a piece of software that runs lean and fast on minimal hardware, great docs (some contributed by other admins!) that help you get up to speed quickly, and a fantastic community that will help you if you get stuck. The reason I take this principled stand is simple — I think it's unfair when artificial limitations are placed on software just for the purpose of getting customers to pay more. We've seen all this time and time again: You can't install any plugin you want, just a select few from a small list You can only have X units (tickets, posts, etc) of whatever you're using You can only have X admins/owners You can't see any messages older than X days These limitations are all artificial, and serve to restrict the use of something to the bare minimum. Anything extra is — of course — available for the right price. We don't do that. We tell everybody that NodeBB is powerful enough to run huge communities, and we stand by it. We tell everybody that NodeBB is flexible enough to look and function however you want, and we stand by it. These are the real limitations we impose on our hosting service: Hard drive space for uploads are imposed by our upstream provider and are set, though we are happy to add additional drive volumes for a fee) We have soft "pageview" limits that any user on our hosting can exceed (in fact, many do). We set them purely as a benchmark for the point at which your NodeBB may slow down depending on the type of load that you get, and encourage dialogue to make sure that you're on the right plan (server resources, etc.) We do not allow shell access for security reasons (and if you needed it, you probably could self-host) So please do rest assured when I and others tell you that what you see is what you get. No more, no less. I'd rather everybody get to use the best of NodeBB, instead of serving a special feature-reduced version for others. † I'm going to go out on limb here and say that we're probably the most qualified people to maintain NodeBB. Feel free to disagree

pls upgrade your npm if others are okey

@crazycells seems Tenor gif started sending back larger gifs which caused the camo proxy to fail (the default max size is 5mb. I upped it to 10mb now). Stop linking to huge GIFs people [image: kramer-seinfeld.gif]

@julian Thanks for the heads up.

@pramariena What would you like to know? What they've shared is what's in the blog post, but I am happy to answer questions. @omega I missed your questions, but it's a quick one. The whole moz project took only a couple months, and most of that was building out their custom theme and some custom functionality. Getting their forum imported into NodeBB was straightforward when using nodebb-plugin-import. We worked with @bentael for that one. One tricky bit was getting their URL redirections working. Their topic slugs were not easy to parse since they were at the root level (e.g. /community/q/this-is-the-topic-slug). This meant we had to create a redirect map for every one of their existing topics, and ensure they correctly routed to the new topic ID.

great job

What is this? Version 2 of NodeBB using the Persona theme (and many child themes based off of Persona) used Bootstrap 3 as its front-end CSS framework. As part of the upgrade to version 3, we are upgrading to Bootstrap 5, whose migration comes with a number of updates and changes, many of which are incompatible with previous versions of Bootstrap. […] Click here to see the full blog post

@gotwf The themes are from Bootswatch, so I suspect you should contact them with suggestions

@julian All my theme with persona is just CSS. if I update to V3, I recreate all my themes but it's a lot of work

Ah, the dark art of release engineering... Good to know. Rock on!

@julian said in Optimizing Benchpress: Are you saying we should build RustBB? Looks like lemmy developers are trying to do it based on their platform https://github.com/Nutomic/lemmyBB

@julian v3 (SASS, front-end framework decoupling)... @baris So when's V3 coming round the mountain?

Sounds just dandy to me. Future's looking rosy for NodeBB. Rock on!

Imagine, you walk into library, you hardly have both feet in the door when all of a sudden twenty people run at you holding books aloft crying, “we thought you’d like to read this!” Terrible bums rush and puts the book angel out of a job. Caveat: Extroverts might enjoy the attention

Nice! A few things: I, too, have long favored Brother printers. Excellent bang for the buck. Suggest you never lay a flat screen flat on its back. Better to keep stresses in the vertical plane so stand on edge leaning up against a wall somewhere out of the way. Plus, you just know that somewhere there is someone wanting to trip over their shoe laces and.... I, too, favor quality over cheap. Nice Lenovo gear. Rock on NodeBB!

@gotwf In vino veritas Pumping the collective psyche with the truth wrapped in tuneful gaiety... Precession Of The Ages

In advance of the release of v2, we are releasing this migration guide in order to give third-party developers a chance to bring their plugins and themes up-to-date. In the successive sections below, we will outline the breaking change or new best-practice, and the steps to migrate, along with a live example. Click here to see the full blog post

I think @volanar loved the addition so much, so he upvoted if he downvotes, it should be -5

@julian One may hope not. Leastwise.... what is special about those dates? I know not. Mayhaps were you referencing the 2038 Unix Epochalypse? I think this has potential to be far more problematic. I have been aware of this since the great Y2K "crisis" but kind of forgot about it until this thread since 2038 was a "long ways off yet". I also thought this would be no big deal in future modern times due to the prevalence of 64 bit processors and os platforms. Alas, I seem to be in error: There is no universal solution for the Year 2038 problem. For example, in the C language, any change to the definition of the time_t data type would result in code-compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to 2106 (specifically, 06:28:15 UTC on Sunday, 7 February 2106), would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64 bits in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions. [emphasis added] Could be in for some interesting times, eh?