One of the issues with loving to code is that often it’s all you want to do; you want to immerse yourself in it, to absorb as much information as possible.
Sometimes, though, a knowledge gap appears: a project requires you to implement a feature that you’ve not had to build before, and suddenly you’re spending your time trying to find a solution amongst the thousands of guides or snippets of information that litter the web. One step forward and two steps back.
We were developing an exciting project with WordPress, packed full of features and original design, but trying to build one particular plugin had us frustrated. Problem-solving is what we do as developers; it’s always more satisfying to create your own solution — to walk your own path — than it is to try to follow in someone else’s footsteps. That was the inspiration for our latest open-source project: Herbert.
Reading the WordPress plugin API documentation left us thinking that there must be a better way to write a plugin. What we needed was a standardised and modern approach, and so we spent time sifting through Stack Overflow questions until we stumbled upon The WordPress Plugin Boilerplate project. After excitedly reading the documentation, we came to the realisation that, although WPPB would be a great starting point, it seemed best suited to the quick development of smaller plugins. We needed something more suited to scale.
Assuming that some of the most popular plugins would have found a semantic, structured method of plugin construction, we delved into the source. To our surprise, there wasn’t any sense of uniformity or consistency of implementation among them. We wondered how they could be so unstructured, before grumbling that it would be quicker to just write our own WordPress plugin framework than to do each plugin the old-fashioned way. So we called ourselves on it, sat down, and we did what good developers do — we built it.
Finding Our Feet
The old approach to building plugins for WordPress always seemed disorganised and difficult to understand for newer developers. We work in teams here at Big Bite, building the best possible web projects from the ground up, but taking over a build from another developer or collaborating on a plugin with another team member was just too time consuming. There were too many limitations, too many compromises.
Mixing business logic with template code can be hard to maintain and leaves developers (back and front) tripping over each other. Herbert is designed to offer a step back. To allow developers the freedom to zero in on the target of their build in the most efficient and easy way possible. That’s why it offers a file structure to keep your code organised, with a solution as simple as all your routes belonging in the plugin/routes.php file. It no longer ties you or your development team to the WordPress Database Object ($wpdb), allowing you to use the power and effectiveness of Laravel’s Eloquent ORM to handle your database queries. And the improvements don’t stop there. For example, template code belongs in views which are delivered with the concise template-oriented syntax of Twig, so that it’s easy to read for your front-end devs and speeds up collaboration with your back-end team.
We haven’t reinvented the wheel, revolutionised PHP, or totally transformed WordPress, but — with Herbert — we have expanded its borders and its potential scope. In fact, the source for Herbert is deliberately simple in order to lower the bottleneck for contributing. We’ve made sure that there isn’t anything too advanced. It’s just straight-forward, down to earth PHP for everybody.
At this point, if you’re still wondering what you should be using Herbert for, the truth is that — as it requires PHP5.4+ and WordPress 3.4+ — it’s better suited for developers looking to add that unique feature to their client projects where they control the environment of the live site. If you’re looking for ideas, you can check out the docs at getherbert.com.
The Path Ahead
This is just the beginning. Herbert may be alive and kicking, currently being used for all of our WordPress projects, but we’re also excited to see it grow and evolve. We’ll be updating the website and adding plugin examples in the near future, and we plan to introduce an interface to the WordPress Post Object for Eloquent, along with Tests for your code. We’re also discussing the addition of a front-end framework to work with Herbert, or even independently, offering Bootstrap-style solutions that have the style and look of WordPress, but without all of the extra work.
Although we’re going to keep improving Herbert, the beauty of open-source is that anyone can. If you find an innovative new use for it, or have used it to help build something amazing, then get in touch: we’d love to see and share it. Or, if you’re up for a challenge and want to go one better, you can start contributing and submit a PR. Herbert isn’t just our framework any more, it’s taking its first steps out into the world so that you can try it too.
Go to Github to download Herbert now, or read more at getherbert.com
