Herbert: A New WordPress Plugin Framework

herbert

WordPress plugin authors have a great deal of liberty when it comes to structuring and organizing their code. There’s no prescribed file structure, so when you look under the hood of a plugin, you often need to poke around a bit to find out how the author is organizing things.

Jason Agnew found this to be confusing when he went to build his first WordPress plugin. Agnew is the technical director at Big Bite Creative, located in Middlesbrough, England. He often collaborates with both front and back end developers on projects, which drove him to find a better way to write plugins that are organized for multiple team members.

This week Agnew introduced Herbert, a new open source framework for building WordPress plugins. “We believe the current approach to building plugins is unorganized and difficult to understand,” Agnew said. “It makes working in teams or taking over from a previous developer time consuming. Its early days for Herbert but our aim is to solve this.”

Prior to creating Herbert with his team, Agnew did his homework to see if there was an existing tool to solve this problem. He discovered the WordPress Plugin Boilerplate project, but determined that it wouldn’t work for his agency’s needs. “Although WPPB would be a great starting point, it seemed best suited to the quick development of smaller plugins,” Agnew said. “We needed something more suited to scale.”

He checked out some of the most popular WordPress plugins, hoping to find a common thread among them for a semantic, structured method of plugin creation. “To our surprise, there wasn’t any sense of uniformity or consistency of implementation among them,” he said. At that point, he rallied his team to write their own WordPress plugin framework.

The open source Herbert project was born out of this effort. The framework aims to keep business logic separate from template code, so that back and frontend developers aren’t tripping over each other. “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,” Agnew said. “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.”

Herbert utilizes Composer to handle the framework’s dependencies. Template code is stored in views, which uses the Twig PHP templating engine. The framework may not be everyone’s cup of tea. However, if you like separating your code into routes, views, and controllers, then Herbert may save you some time when spinning up new plugins.

The Big Bite Creative team plans to maintain the framework and will add plugin examples in the future. “We plan to introduce an interface to the WordPress post object for Eloquent, along with tests for your code,” Agnew said. They are also considering adding a WordPress-specific frontend framework to work alongside Herbert. The project is open to contribution, so feel free to fork Herbert on GitHub and send code back to the team.

20 Comments


  1. This framework is kind of hybrid of WordPress code and normal PHP code. It has a lot of interesting things like route and good API. Hope it attracts more attention of developers.

    Report


    1. Can you please provide some resources on Herbert beside its documentation , I am unable to create a section using it.
      using this inside a function :-
      add_settings_field(
      ‘authenticationCode’,
      ‘Authentication Code’,
      array( $this, ‘authenticationCodeCallback’ ),
      ‘analyticaAuthenticationSetting’,
      ‘authenticationSection’
      ); or

      add_settings_field(
      ‘authenticationCode’,
      ‘Authentication Code’,
      array( __CLASS__, ‘authenticationCodeCallback’ ),
      ‘analyticaAuthenticationSetting’,
      ‘authenticationSection’
      );

      in both case callback function is not called :( .

      Report


  2. Lol. How funny that days ago I was fantasizing what WordPress would look like if someone forked it, drop php 5.3 support, depr acted functions, used TwIg for templates and Eloqount (didn’t mentionlaravel at the time, but did think about it).

    WPPB has been a noble effort but it never fit well for me either, looking forward to checking this out.

    Report


    1. Then again this was only for plugins, but If you want something similar for WP (themes) you could check out Themosis!

      Report


  3. Seems uncalled for. Each plugin should only do one thing. If so the code base of each plugin should be small.

    Report


  4. Thats why I love WordPress, lots and lots of people, working and sharing, with one common goal in mind, to improve WordPress, for the benefit of everybody.

    Greatest community in the world!

    Report


  5. Very cool idea. I agree that for small plugins this would be overkill but as they said, it’s designed for teams and scaling easily.

    Looking forward to checking this out.

    Report


  6. How interesting.. They’ve taken the whole MVC model and built a plugin framework around it. It’s like writing Joomla plugins for WordPress. The structured approach will be great for development houses who want to turn out a series of plugins for their clients.

    For putting out short quick plugins for diverse purposes. I don’t think I’d use it. It seems a little heavy. (That said I’ve not downloaded the source and done a line count).

    Report


  7. I’m glad to see more projects like cropping up because there complexity of the types of plugins that we build varies greatly.

    Sure, some are simple and aren’t going to require as much overhead; others are more like small-ish applications running within the context of WordPress itself. Bringing a bit of order to the potential chaos is a good move.

    If you don’t dig it, don’t use it, but if you’re working on something large-ish, then maybe this fits the bill.

    Props to the team.

    Report


  8. IMO there should never be a reason to build a large plugin.

    Every plugin should just do one thing and if you need to build something big build a plugin of plugins.

    Report


    1. For the most part, I agree. Most plugins should serve a single purpose and serve it well. Nothing more. Nothing less.

      However, there are many times when a larger plugin is warranted. e-Commerce, forums, and event calendars are just a few examples of when a large plugin is what is needed. Even if just building the most basic, foundational layer for those types of plugins, they can get fairly large. These are complete systems in and of themselves and are large by their very nature.

      Report


      1. Justin, would you consider using a framework like this for a large plugin? I’m assuming not, but just wondering since you responded to this post.

        Report


      2. No, I wouldn’t. I already have my own workflow and organizational structure that I’m continually building and improving on. However, I will look over the project to see if there are techniques that I could borrow and integrate into my own code.

        Report


  9. This seems really great, but there is only a tiny thing I’m wondering about.

    And that is, say I create/use several plugins on a site (that use this framework), how much extra code, resources, etc, am I using because of it. Say I have 5 plugins with Herbert, isn’t that like having 5 mini-laravel projects + WordPress + Theme Framework?
    What I mean is that it could be nice if plugins could share the base of Herbert :)

    Report


  10. WordPress was created over 12 years ago before Php 5. Its still using its old code base, so most of the WordPress code is procedural instead of Object oriented.

    Pak Php is a Php micro framework that among other features provides an object oriented interface for developing WordPress plugins

    Report

Comments are closed.