I’ve rewritten Hybrid Core version 5.0 almost entirely from scratch.
This meant making some hard choices about how opinionated it should be on some features as well as liberally cutting out unnecessary items from the framework. The new version is much more integral to how you build a theme and not just some mish-mash of various modules that don’t complement each other.
I started 5.0 with a goal of bringing the framework up to date with more modern PHP practices and code. The first iteration of the framework was built in 2008, so it was time to get us ready for the next era of theme building.
I’ve got quite a bit of ground to cover in this release post, so let’s get right down to business.
Hybrid Core + Mythic
HC5 and Mythic 1.0 were built in tandem.
Over the years, I’ve found that theme authors had a tough time understanding how to get started using the framework from scratch. Most would copy over one of my themes and build from there. That’s not great because it means removing things that you don’t need.
With the massive changes in HC5 coming, it can be an even tougher challenge. That’s why starting with Mythic is the officially recommended method of building a theme with Hybrid Core from this point forward. Most docs and tutorials in the future will be centered around the Mythic starter theme. This will make it much easier to get everyone on the same page, so to speak.
If you want to start from scratch and skip Mythic (perhaps even build your own starter), that’s OK too. Hybrid Core has always been pretty flexible.
Version requirement bumps
In April, I officially dropped support of PHP versions older than 5.6 for all of my plugins and themes. This will mark the first release of Hybrid Core where this is the case.
Even PHP 5.6 is nearing EOL (End of Life). At some point, maybe by the HC6 release, PHP 7.0+ will be the minimum.
WordPress 4.9.6 is also a minimum requirement. You can get by with 4.9 if not registering custom post/page templates.
Composer is the standard
Composer is now a requirement.
Technically, you can still download the ZIP and drop it in your theme. You’d need to include a PSR-4 autoloader too (pretty simple). However, that method or similar is no longer recommended and will not be supported in the future.
HC5 was built specifically for management via Composer. It can be loaded up no matter where your Composer
/vendor folder is (site root, theme folder, or even a plugin). Basically, the framework doesn’t care where it’s located. It’s not really running any code until you call its
Application class from your theme.
Composer is the standard in the larger PHP world. I only regret that it took me so long to jump on board.
Using Composer is also important if you want to take advantage of add-ons or other packages unrelated to Hybrid.
Add-ons: All in the Hybrid family
By making Composer a requirement, it meant that I could split off parts of the framework into their own, separate packages. This makes the code more modular — you only have to use the parts that you need. There’s no need to package a breadcrumbs script, for example, if your theme doesn’t need that feature.
Currently, the following add-ons are available, and I hope to have more in the future.
- Hybrid Breadcrumbs – Allows you to implement breadcrumbs for your theme (replaces Breadcrumb Trail).
- Hybrid Carbon – A better featured image script than what WP provides (replaces Get the Image).
- Hybrid Customize – A port of the HC customizer controls and settings.
- Hybrid Font – Set of helper functions for loading Google Fonts.
I’m also considering releasing the old Theme Layouts and Cleaner Gallery extensions as additional add-ons if enough people still want those features that are now removed from HC5.
There are other features in Hybrid Core that I believe would be good candidates as add-ons rather than directly in the framework. However, I wanted to include them in 5.0 while we transitioned over to using Composer. In 6.0, we could be looking at an even leaner core framework.
Cha-cha-changes…everything has changed
When I say I rewrote nearly everything from scratch, I wasn’t exaggerating. I’m not sure if there’s a single line of code that didn’t get edited, deleted, added, or moved in some way.
There’s no way I could accurately cover every change in this post. Even the change log is merely a broad overview. However, I do want to cover some of the major points.
New method of bootstrapping
In the past, bootstrapping Hybrid Core was just one or two lines of code. But, there was no real interaction with the framework during this process. It was more or less a way of loading.
In 5.0, Hybrid Core doesn’t do anything until you create a new instance of the
Application class. Once that’s created, you can add service providers and bindings to the container. Then, you just need to boot whenever you’re ready.
The following is some example code pulled from the Mythic starter theme to show the bootstrapping process:
# Create a new application. $mythic = new \Hybrid\Core\Application(); # Register service providers with the application. $mythic->provider( \Mythic\Providers\AppServiceProvider::class ); # let child themes hook in (optional). do_action( 'mythic/bootstrap', $mythic ); # Bootstrap the application. $mythic->boot();
New service container
HC5 comes with a service container (the
Application class mentioned above is a sub-class for it). The container is used for managing class dependencies and handling dependency injection. This was largely modeled after the containers from Laravel, Symfony, and Pimple.
If you’re new to using containers, I’m working on docs and will gladly help you out.
The container will change how you code. You’ll no longer rely on globals or singletons in your themes. No more God classes.
You’ll be able to build features based on interfaces (contracts) where the implementation can be changed without rewriting code in multiple places. For example, you could completely replace HC5’s new
View class (see below) with your own implementation, and all of the framework’s view-related functions would work with your implementation.
Since 5.6+ is now a requirement, we’re no longer tied to the old-school method of prefixing class/function names with
Hybrid_. Everything is now properly namespaced under
Every feature of the framework also has a sub-namespace which exactly follows the folder name. For example, everything under the
Hybrid\Media namespace is within the
src/Media folder. It should be pretty simple to find things.
Using Composer and making the switch to namespaces also meant that we could switch to the PSR-4: Autoloading Standard for auto-loading classes. No classes from the framework are ever loaded unless they’re actually in use.
New view system
I rewrote how templates are handled. WordPress’ templating system lacked some fundamental features that even the most basic PHP templating systems have. Here’s a quick overview of the view system features:
- Support for passing in custom data.
- Create a hierarchy of possible template parts.
- The ability to return the template output as a string.
- Filter hooks to allow child themes to overwrite things.
I have written a tutorial on the View class already.
Version 4.x: Long-term support
The version 4.x series will be a LTS version of Hybrid Core. Because 5.0 fundamentally changes how the framework functions, theme authors will need time to adjust. Plus, old themes may not be so easy to switch over.
I don’t have a time frame on how long that support will last. It’ll be for at least another year or until I’m no longer seeing support requests for it. When the time comes to start phasing out support, I’ll make an announcement with plenty of time to spare before support is completely dropped.
Grab version 5.0
I recommend heading over to the GitHub repository and reading the docs on using the latest version.
I hope you enjoy this release. I plan for it to be the foundation for many themes in the coming years.