In October 2019, we released Granola, a WordPress starter theme built for efficiency and performance. Since its initial release, we have continued to fix bugs and make improvements to all aspects of the code base. If you haven’t had a chance to learn about Granola yet, you can find out more here. If you’re already familiar with Granola though, this blog will take you through some of the more substantial updates since then.
Including deeper Gutenberg integration, a rewrite of the framework to an Object-oriented structure supporting PSR-4 autoloading and documentation for starting a project with Granola, Granola 2.0 represents a step forward in the development of WordPress sites.
When we sat down as a team at Wholegrain Digital to discuss what we should focus on in improving Granola, we discussed the pain points that we were feeling in not just developing, but also in managing a project, including scoping, designing, developing and testing. What we identified is that, even though we were capable of accurately estimating the cost of a piece of work, it was always under the premise of building from scratch each time. Ultimately, this facilitates the greatest flexibility but not the most efficiency, accessibility, best practice, performance or value for money. So many websites reuse the same components, whether it’s something as small as a burger, or as large as a map with pins that supports searching, we have done it before, so why not find a way to support this in a more streamlined manner?
Before we get into how we made the changes, it’s important to understand why it’s not the most straightforward task to reuse code from one project in another. In Granola 1.0, and most development of custom themes, the code that represents a component will be located in multiple places, and could be dependent on other components that also have files in multiple places. For example, a file/folder structure in Granola 1.0 compared to Granola 2.0 for a map and list component would most likely look like the following:
|Markup and PHP
|Custom PHP functionality
What we see in the Granola 2.0 column in the table above is the collocation of all files related to the map component. All the styling, all the functionality, one location. While I could go on and on about the technical and development benefits of such an approach, I’ll simply touch on the fact that there is now much less open to interpretation, and therefore much less opportunity for complications to arise. From a management perspective, we can now, with confidence, have an understanding of components that are available, what it costs to integrate them, and what flexibility there is to customise them, all without worrying about whether efficiency, accessibility, best practice and performance have been accounted for.
Since we were upheaving a large chunk of the development workflow (which required a large amount of under-the-hood code to change), we took the opportunity as a development team to discuss pain points and improvements that we could make to improve developer quality of life. Some of what resulted from the conversations lead to changes that won’t be noticed in day to day use, such as updated tooling. However, the changes that will be noticed move Granola forward in industry standards.
When we were building and when we launched the first version of Granola, we focussed on keeping the public PHP API close to what developers of WordPress themes were used to. In that sense, we simply used prefixed function names with underscores (in place of spaces for joining words) in a similar manner to what WordPress itself does. Not content with what we had, and looking to implement more industry accepted standards, we opted for a rewrite to a namespaced object-oriented codebase. Whilst this might raise the learning curve for anyone getting started with PHP, and feel like a simple semantic change, it does allow for more powerful functionality such as autoloading and removal of the reliance on manual prefixing. As an example, Granola contains three PHP functions that are generally used more than any other during development. Previously these functions were prefixed with granola_, they are now namespaced.
When starting a project with Granola, the easiest approach was to clone the repository, copy the files into the new theme, and begin development. As part of Granola 2.0, we added support for packagist, a tool for adding php packages to your projects. Now beginning a project with granola is as simple as running the following on the command line:
$ composer create-project wholegrain/granola your-theme-name
Gutenberg was introduced into WordPress core in December 2018 and brought a visually rich way to write content and create pages that previously has been relegated to custom implementations like Divi and Avada. Whilst a divisive topic amongst the WordPress community at the time, the technology itself is now more than capable. Almost a year and a half on, we now use Gutenberg as our default editor. Simply put, Gutenberg has replaced (but is also capable of working alongside) our “flexible content” approach to editing sites; it has standardised the WordPress communities approach to providing a rich editing experience.
Granola 2.0 contains two pivotal integrations with Gutenberg. One, an override for the styling of core blocks to be inline with the theme styling, and two, a simple approach for creating blocks for Gutenberg that is in line with the components based structure we discussed earlier.
We know that at the heart of every great piece of software, is even better documentation. When we open-sourced Granola, the documentation wasn’t quite there, and we apologise for that. While the documentation will be an ongoing process as the code evolves, we have created documentation for how to get started, explained the suggested way for working with Granola, and listed a few core pieces of functionality that will be used frequently.
You can read the documentation here.
What it all means
Granola will always strive for a standards compliant approach. As we consolidate and standardise our approach further, we write better code, reduce the time it takes to understand a project, and increase the reusability of not just a few lines of code, but entire components.
Open-sourcing a project is one thing. Maintaining, improving and documenting it is another entirely. As much as it is part of the process for increasing adoption outside Wholegrain Digital, we also know it’s an integral part of knowledge sharing internally. As the code for Granola evolves, so too will its documentation, and our communication around it.