An Introduction to Sage
After a fantastic experience of working with Warner Brothers Entertainment Group (WBEG) earlier this year, I’ve made some changes to my WordPress production process. Also, since that time, I’ve been investigating some potential new processes and tools and I’ll cover those findings in this post.
In the course of my investigation I discovered Roots, a suite of tools to enhance WordPress production. The suite consists of Sage: WordPress starter theme with improved development tools, Bedrock: a WordPress boilerplate theme that improves organization, configuration and plugins, and Trellis: a tool to manage development and production servers. I haven’t had enough time to evaluate Bedrock and Trellis fully so I will reserve those tools for future posts. For this post, I want to briefly introduce Sage and report on my (limited) experience with the tool.
Sage, similar to Understrap, is a bare bones starter theme that employs SASS and Bootstrap and also streamlines front-end workflow through the use of Node.js, yarn and Webpack. Unlike Understrap, Sage can also use other front-end frameworks such as Bulma, Foundation, Tachyons, Tailwind, or just a blank slate approach. Personally, I have not used Sage with anything other than Bootstrap. (I don’t care much for Foundation, have not tried Bulma or Tachyons, but I do hear good things about Tailwind.) Webpack performs pretty much the same duty as Gulp does with Understrap however it the Sage implementation requires that you install yarn rather than npm – which is a plus in my estimation as yarn has a superior module caching scheme and security.
The primary difference between Sage and other WordPress theme creation workflows is that Sage is based on the Model-View-Controller (MVC) software paradigm used in most modern front end development schemes such as React and Angular. Sage accomplishes this by employing the Laravel Blade templating engine for PHP. Blade templates allow the developer to utilize much more concise, reusable code that streamlines the development process. This can lead to incredible productivity enhancements but only after a considerable learning curve is surmounted.
Which leads me to a few potential pitfalls with Sage. For one, someone who comes into an existing theme development project to “pick up the baton” needs to already understand MVC and be conversant with Blade templates or a quick study of the same. This is not a huge hurdle but it is something to consider. Another slight concern is that Sage requires that Composer be installed as a PHP dependency manager. Once again, this is only a slight concern and I was able to get Composer and all other required modules installed with relative ease. However, requiring a PHP dependency manager is a step beyond what many WordPress developers are used to.
Finally, I want to mention that Sage has a method of registering and managing Advance Custom Fields field groups programmatically via a library called ACF Builder. This library is ideal for the WordPress developer who prefers to stay within the code editor and provide Version control to fields without resorting to ACF’s JSON exports. I have not dug into this library too deeply yet, but I am eager to as I am not of fan of flipping back and forth between Visual Studio Code and the WordPress interface each time I need to add a field.
Well, that’s it for my recent WordPress workflow enhancements. As I learn more about Sage and ACF Builder, I’ll be sure to post more in this space.