I have been doing a lot of Symfony recently and enjoying working with Webpack Encore. The integration is very easy while bringing several benefits to your project, namely compiling and versioning.
There is no excuse (other than lazyness) for not compiling your assets. The benefits are clear and a numerous tools and techniques available for compiling.
Versioning assets can be a little more difficult to manage, especially if you are trying to do it manually using query strings and incrementing version numbers. It can be easy to forget to update your version number and your client ends up seeing cached content. Webpack Encore makes asset versioning easy and automated.
I wanted to try and bring those benefits of Webpack Encore into a WordPress theme and make the integration as seamless as it is in Symfony.
Having been building WordPress themes for a number of years, I have got it baked into me that all theme assets should be inside the theme folder – seems obvious doesn’t it!? You should be able to pick up a theme folder and dump it into another WordPress installation with no problems.
Configuring Webpack Encore to use relative URLs however, while not impossible did have the sniff of a “hack”. I did not want to configure absolute URLs a) due to wanting to keep that theme portable and b) so it worked within my development environment.
Since then my thoughts on WordPress have somewhat matured (at least I like to think so). I like to think of WordPress site as the sum of its parts rather than lots of little components glued together. So next time you build a WordPress site, don’t think you are delivering a theme and a couple of plugins. Instead, think of it as delivering an ecosystem with hand-picked components that are designed to work together.
I just want to preempt the comments at this stage. Yes, plugins should absolutely be reusable and self-contained. I do however think a theme is a bit of a different beast. I am happy to lose the ease of portability of my themes in order to gain other benefits such as optimisation and performance. And let’s be real for a moment – if you are building a WordPress theme for a client – how likely is it you will be reusing those assets in another project?
I use Composer with all of my WordPress builds – a topic for another post but this has numerous benefits. I feel this approach also helps to reinforce the mantra of delivering a handcrafted application rather than a number of components. Because I use Composer, this means I have the entire application is in a single Git repository (dependencies defined in Composer of course). I can happily place my theme assets (CSS & JS) in the root of my project, keep them under version control, and create an easier to use integration with Webpack Encore.
I ended up creating a WordPress plugin that will look for the Webpack Encore build files in the root of your public directory. I then created a function in the global namespace asset($file) to provide the seamless integration of which Symfony provides via its Twig functions.
This plugin can be found on my Github (https://github.com/PhatKoala/asset) and can be loaded in via Composer and Packagist.
