Today, I’m happy to announce the official 1.0 release of our first two feature projects.
If you haven’t been following along, the team decided to build out some features that many themes build in very different ways. The idea is to bring some standardization for these features for authors, reviewers, and end users in the case of packages with a UI. It also means that all theme authors will have access to these tools and not have to worry about building them in-house.
Note: PHP 5.6+ is a requirement for the current packages. This means your theme must be built for WordPress 5.2+ or that you’ll need to gracefully fail if supporting older versions.
Customize Section Button
This project provides a method of adding a link/button in the customizer. The primary use case for it will likely be to add an upsell link, but I could see it being used for something like pointing a user to documentation. It’s pretty straightforward to use and works like any other customizer section.
Autoload
The Autoload project is a package for autoloading any classes that we create, such as the above-mentioned Customize Section Button project. It allows you to define namespaces and the directory path(s) of where to find classes.
We view this project as a stepping stone toward getting theme authors to use a proper dependency manager such as Composer and its autoloading feature. We also strongly recommend following the Composer Autoloading Optimization Guide. Seriously, use Composer if you’re ready for it or already using it.
I think we should also view this project as call for the core developers to implement a proper autoloading feature into WordPress itself. Such a feature would be far more efficient and provide a standard for both theme and plugin authors to follow.
Are these packages required?
This question has come up a few times, so I wanted to go ahead and address it now. The short answer is that, no, they are not currently required.
The long answer is that I don’t know what the team may decide in the future. There may be projects where the team will say, “If you want to implement this feature, use this particular package.” It’d certainly help streamline some of the review process, but there are things to consider other than the review process.
My goal is to get the TRT and theme authors working together to build solutions. If we build good solutions, I’d hope that theme authors would naturally move toward using them because it ultimately saves them time and resources. I still think the question of whether a particular package should be required is premature. Let’s build the solutions together first.
Next projects
The next projects are likely going to be a set of standard theme template hooks and something to tackle admin notices. These are a little bigger than the first two projects and will likely need more community involvement. We’ll try to get repos up for them soon so that we can begin discussions.