It's an optimization, an opportunity to handle more traffic on less hardware.

Thanks @phenomlab @julian said in User journal: I think the idea behind a user journal is that it doesn't necessarily fit within the pre-defined categories in the forum, so you post it in your own personal bucket of... stuff? I think that's right, imagine a health forum that wanted to give someone a journal space to track their progress with notes and photos. Or house remodeling. Or your works in an art school. Or anything else time bound or progress oriented. In these cases, I would expect: 1. at least one canonical thread for each user that was discoverable in their profile, 2. they have control over visibility, 3. they are the only one posting content there, by default. This use case is also interesting to me because I don't think most other products are doing a good job at it, and nodebb already has all of the UX/I to do this well. I guess the other way to do this would be to have one topic per entry, which might be better with use cases like allowing others to comment on every entry?

Yeah that should work, options object is spread into the redis constructor.

It was showing successful builds in the pretty-printed list (sorry, I lost the screen), then I believe this is the minification step, the webpack step, was failing based on not finding different node_modules, which turned out to be child modules like highlight.js, which are included by other packages. The child modules are apparently implicitly required and then included in client scripts. pnpm, which I'm using, nests its modules by default, as in: node_modules/parent_module/node_module/child_module so all of the child modules need to be hoisted by putting this in .npmrc node-linker=hoisted so now the node_modules tree is node_modules/parent_module node_module/child_module Why this wasn't triggered before, I have no idea. My last question now is how can I ensure that the build exits with a failure code in any cases like this? This may have all been designed with prioritizing getting the server back up, but this is not ideal behavior for builds like docker, where it only replaces the running instance when the new instance builds correctly. I'm probably going to put in something terrible like this into Dockerfile, but this is pretty hacky: RUN for file in admin.min.js etc etc; do \ if [ ! -f "$file" ]; then \ echo "$file not found!" && exit 1; \ fi; \ done

Yeah thanks guys, the key was copying the package.json file out of the install folder (copying, not moving, because install/package.json is then checked during build). Now everything can be installed in one command.

As in client side fetch? This is critical HTML that would block renders so that would be pretty bad. It's the header and has some search functionality in it, for example. On the other hand, if there was something like a remote-html convention for the widgets that fetched on server and expired the cache automatically, never blocked render, etc... that would be cool but I'm not sure how or where to see how caching works in these kind of cases.

Thanks @baris. It was an obscure permission issue between Docker and DigitalOcean. Does nodebb not error out when it can't write files as expected?