Gotchas for v0.4.0

NodeBB Development
  • It's that time again!! ๐Ÿ˜„

    Enclosed are the "gotchas" that will be introduced for v0.4.0. They are breaking changes that may affect plugins, themes, or functionality.

    • The preferred way to start and stop NodeBB is now: ./nodebb start and ./nodebb stop. NodeBB will continue to support usage with forever/supervisor, but it is no longer a requirement for production builds.
      • Alternatively, you can use npm start or npm stop
      • Development mode will more verbose logging: ./nodebb dev
    • Reds Search will no longer be included with NodeBB -- this is to make way for third-party search plugins such as ElasticSearch, MongoDB search (if any), and of course, Reds, if you still wish to use it
      • nodebb-plugin-dbsearch will be installed by default, and will use Reds if on Redis, and MongoDB fulltext search if using MongoDB
    • The MOTD is now a widget, you can access it in the "Widgets" tab of the "Themes" page. This is more of a workflow change.
      • Your NodeBB's MOTD should be automatically migrated into a widget.
    • CSS and JS loading has changed -- compilation and minification will no longer occur on NodeBB start, but on the first invocation (i.e. first load), and be cached for all future loads until NodeBB is topped. Every time you restart NodeBB, it will need to re-compile the assets, so the first page load after a restart will always be the slowest (~ 7s).
    • The css property in a plugin's plugin.json now refers to its relative path from its plugin root, not from its static directory. This matches the handling of LESS files.
    • Groups are now no longer referenced by their gid. All byName methods have been removed. The upgrade script should migrate all groups properly, but you are still advised to back up your database (as you should already be doing!) before upgrading.
    • The following hooks have been deprecated:
      • filter:category.build_sidebars
      • filter:footer.build

    API Changes

    • The returned data signature for Topics.getTopicsByTids has changed
      • User data is now inside of the user property, instead of userslug, username, and picture

    Deprecation Notices (currently backwards compatible)

    • In plugins, the staticDir property in plugin.json is deprecated, and will be removed for v0.5.0
      • Define a staticDirs Object property instead. It will be mapped thusly: /path/to/your/nodebb/plugin/{value} => http://forum.example.org/plugins/{pluginID}/{key}
    • Defining client-side js files by listening for the filter:scripts.get hook will be deprecated as of v0.5.0, it will continue to be supported until then.
      • Instead, define your scripts in a "script" Array in your plugin.json. It contains a relative path to your script, and no longer relies on having a static directory mapped.
      • filter:scripts.get is still supported (until v0.5.0)
    • You are advised to deprecate CSS in favour of LESS in your plugins. Define a property less in your plugin.json (type Array), this array will contain relative paths to the LESS files you'd like to be used.
      • LESS files do not need a corresponding static directory

    This list will be updated when breaking changes are committed.

  • @julian

    Are you saying that aside from the Themes and Customize tabs on the Themes page, that there will be a widgets tab? Is that going to be the same as in WP?

  • @mr_waffle Best course of action is to use the passed in pid or tid to get the data by executing module.parent.require('./posts').getPostData() (or .getTopicData).

    Just not sure if I should be keeping the current hooks as-is, or creating new ones (i.e. action:search.index, action:search.remove, action:search.reindex)...

  • I think @mr_waffle is looking for the pid and tid to be passed in, which it doesn't currently. Yeah we'll make sure we get that in for 0.4x ๐Ÿ˜‰

  • Updated the notes for 0.4.0 ๐Ÿ™‚

  • I forgot to mention this earlier but

    $('body').trigger('action:ajaxifying', {url: url});
    

    event hooks are no longer fired on body, but on window instead, like so:

    $(window).trigger('action:ajaxify.start', {url: url});
    
  • The preferred way to start and stop NodeBB is now: ./nodebb start and ./nodebb stop. NodeBB will continue to support usage with forever/supervisor, but it is no longer a requirement for production builds.

    Hi @julian
    Does it mean if node process crash, it will re-start process automatically?

    Currently, I was trying to use naught with nodebb, what I want achieve is: Resuscitation - when a worker dies it is restarted & Zero downtime code deployment (optional)
    Do I still need to use naught with nodebb 4.x, or I don't need to use naught anymore?

  • Defining client-side js files by listening for the filter:scripts.get hook will be deprecated as of v0.5.0, it will continue to be supported until then.

    @julian As I mentioned here I'd prefer the filter not beeing deprecated since it can be nice in some cases to decide server-side which scripts to include (e.g. by admin-config). This would need web-socket communication without the filter. You may think about this once more ๐Ÿ™‚

  • Do I still need to use naught with nodebb 4.x, or I don't need to use naught anymore?

    I saw the loader.js, it looks like I don't need to use naught, Nice ~~

  • ๐Ÿ‘ No need for a program like nodemon, forever, or.. naught ๐Ÿ™‚

  • are we far from the release?

  • Scheduled for 11 days from now, but sooner if we can make it.


Suggested Topics


  • 6 Votes
    10 Posts
    914 Views
  • Nodebb v1.3.0

    NodeBB Development
    3 Votes
    1 Posts
    1179 Views
  • NodeJS 4.0 released

    NodeBB Development
    0 Votes
    17 Posts
    7209 Views
  • Gotchas for v0.5.0

    NodeBB Development
    2 Votes
    18 Posts
    4499 Views
  • NodeBB v0.2.0 released

    Moved NodeBB Development
    2 Votes
    27 Posts
    10684 Views