The whole idea of the reference implementation was to make your life (the life of a SDL Tridion developer) easier. But sometimes people make mistakes, and then the end result can be slightly more difficult than it was intended to be.

This blog post is not so much a confession of what I did wrong, but more intended to help you see how easy things can be changed when the tool you use was designed to be simple and modular.

So lets start at the beginning, the SDL Tridion Reference Implementation has a few prerequisites (you can find these in the documentation), one of those is Node.js which needs to be installed on your Content Manager server (or actually every server where you have a Publisher service running). More specifically, you must use the 64-bit edition of Node.js since else you can’t publish the HTML design.

Now you can of course forget about publishing the HTML design from the CMS and just add the CSS and JavaScript assets directly to your web application, but we thought it would also be a nice feature if you could publish changes to the HTML design this way.

Node.js is required to build the Bootstrap HTML using Grunt, that is just a given fact. But while I included the required Node modules and Bower components in the HTML design zip file, I didn’t think of actually including Node.js itself. The failure to do so became apparent when STRI was released to the public: http://tridion.stackexchange.com/questions/7826/tridion-reference-implementation-couple-of-installation-niggles.

The problem

The issue is not so much that Node.js is missing, most people followed the installation instructions and installed it, but there are a couple of issues with Node.js which are in our way. First of all it seems the 32-bit edition of Node.js doesn’t seem to work at all in our case (most likely because the Node modules in our zip file are 64 bit versions), and the 64-bit version, has an issue creating a temporary folder (https://github.com/npm/npm/issues/5905).

The solution

So this all got me thinking, why don’t we include Node.js itself in the zip file too, that way, nobody has to install it on their servers and nothing can go wrong. I started off with logging an enhancement request for it https://github.com/bkoopman/tri/issues/12, which is something you all can do (equal for defects you find).

The next step is of course to solve it, which I did for the upcoming next release of STRI. But because the source of this next release is not yet public, I figured why not blog about my change and show how simple some solutions can be.

So following the comment I made on the reported enhancement, I did not only remove the dependency for Node.js, but I also decided to split the HTML design and its build files (Node.js, npm, and its components and configuration) in two separate zip files. Here are the steps I took to solve it:

1. Add Schema field

   You will need to add a field to the HTML Design Configuration Schema in 100 Master\Building Blocks\Modules\Core\Site Manager\Schemas. The field is named build, and it is further equal to the HTML design (packaged in zip file) field. You can find a copy of my updated Schema source here https://gist.github.com/bkoopman/80c6a6924bb22736edf3 (mind the TCM URIs in there if you would like to cut and paste).

2. Update TBB code

   The Publish HTML Design TBB now needs to unpack this new zip file which will contain the Node.js executable and npm command. I’ll spare you all the details of which lines of code were changed, and just point you to a link where you can download the entire file https://gist.github.com/bkoopman/987ef712539dd8e669fe (and I’ll let you compare it against the original if you want).
   After changing this code, be sure to compile and upload the changes to your CMS (there is an example of a post build step in the project file).

3. Update Parameters Schema

   While I was busy I also fixed another thing, I added a second parameter in the Parameters Schema of the TBB, so that you can specify on which drive you want the temp folder to be created (this is the location where the zip files will be unpacked and the design will be build). So be sure to update the Parameters Schema in the source, then it will be automatically changed in your CMS when you upload the TBB DLL. You can find the updated Parameters Schema source here https://gist.github.com/bkoopman/9a5d54a05b55a60202d5 (you can safely copy and paste this in the Resources folder).

4. Split HTML design zip

   Last thing to do, is to split the HTML design zip file in two, and make sure you add the Node.js executable and npm command to your build files zip. Again to make things easy for you, I’ve created two zip files which you can download so you don’t have to create these yourself. You can download the HTML Design zip here https://docs.google.com/uc?export=download&id=0B3HC5g1nQ87sSVEyRmRMNHpjQkE, and the Build files zip here https://docs.google.com/uc?export=download&id=0B3HC5g1nQ87sQzFXV2N5Mmw1U3c.

   If you would like to construct the HTML Design zip from scratch, that is easy to do, just zip the contents of the folder \html\design from the reference implementation installation package you downloaded from SDL Tridion World. Since the Gruntfile.js and package.json will be overwritten by the ones in the Build files zip, you can just leave them in there untouched. Which will make building and modifying the HTML design using this (smaller) zip file a lot easier.

When you have followed these few steps (don’t forget to compile and upload the changed TBB to your CMS), you now don’t need Node.js on your server anymore. I hope this showed you how simple some things can be.

If you want more details on how this could have been packed into a redistributable module for the reference implementation, I urge you to inspect the Search module created by Will Price.