We've set up a number of tasks to help automate the build process, depending on what environment is being targeted.
grunt-contrib-sass – fairly self-explanatory, this compiles the sass. We added a little flag into the mix so it conditionally compresses the output.
grunt-cdnify – This is quite a critical one, since all assets need to be referenced from the the hubspot cdn url that is provided when the uploader is uploading files. This not only includes css/js/img refs but also background image urls in css.
grunt-string-replace – This one is used to modify the hubspot meta data so that assets can be uploaded into the right area.
I'll just go through a couple of the more critical tasks here – cdnify and string-replace, but first, there's a bit of config that needs to be done.
env – The current environment, defaults to 'flat.' So when running the grunt task, an environment flag can be set to conditionally target either the 'dev' or 'prod' environments.
This is a pretty useful one, since without it, you'd need to go through every single url ref and change it to the hubspot cdn reference (which you're provided with when the files are uploaded). With this plugin, you can specify a rewriter function that will get every url in the list of files you select, passed into it. Then, you can conditionally update it or just return the original.
Regular expressions are used to match the urls that come into the function. If the urls don't match, the original url is returned (3). matchUrl1 matches anything that starts with 'assets' or '../' or a reference to an old hubspot cdn (see hubspot grunt config above) in either the dev or prod environments. The call to 'escapeRegExp' is a little function that escapes any characters reserved in regular expressions like dots, forward slashes etc.
The joy of regular expressions, eh?
This is another automation tool that does what it says on the tin – replaces strings based on matched patterns. We used this one to replace references to the 'dev' environment when transferring content between 'dev' and 'prod.' I realise now that we could probably have done the 'cdnifying' using this plugin, but by the time I realised we needed it, I'd already got cdnify working.
This pattern matches the 'id' line of the metadata, stripping it out, since files that live in the dev and prod environments of hubspot will have different id's.
saveUnchanged is a flag, if true, will save out every file it analyses regardless of whether any matches were found or not.
If the environment is not flat, determine where files should be copied from.
If the cos_uploader tool is running while the grunt tasks are being executed, resultant file will automatically be uploaded.
With this setup, we have a solution that allows designers to work on their flat sites, allows developers to integrate into hubspot without too much copying and pasting and goes some way to make the site easier to integrate. I know that there are bits that need work here but for a first attempt at devising a workable workflow process, I think it ticks a few boxes. I think the next thing to look at is the local hubspot server that can be downloaded from hubspot. In theory this would mean we could develop and test hubspot integration without having to upload to a real site.
If you've got any suggestions, or lessons you've learnt about working with hubspot, please add a comment.