Hybrid Core version 2.0

Hybrid Core screenshot

Hybrid Core 2.0 has been a long time coming. This is only the second time that we’ve had a major release of the framework, which is one of the reasons it took a while to get things ironed out.

I feel like I could’ve worked on 2.0 for another few months, adding more awesomeness here and there. But, at a certain point, you just have to stop building and say, “This is where the code is at. Let’s release it.”

This version of the framework has been at a stable point for a long while now, as evidenced by the many people who have been using it (including myself) for a few months.

Frankly, it’s time to ship the thing and start work on the ideas that didn’t quite make the cut for this release.

Why version 2.0?

If you’re wondering why version 1.7 was skipped, it’s because Hybrid Core doesn’t follow WordPress’ versioning system, which technically doesn’t have major releases. Rather, the framework follows Semantic Versioning.

Because this version of Hybrid Core is dropping a lot of backwards compatibility, the version number was changed to 2.0 (or 2.0.0).

What has changed in 2.0?

If I listed every detail, or even most details, this might be one of the longest blog posts ever written. This version had over 200 code commits by several people, so it’d be a lot of ground to cover. If you’re interested in looking through them all, check out the commit log.

What I’m going to do is tell you all about the things that interest me the most.

Composer support

Composer is a PHP dependency manager. As far as I know, Hybrid Core is the first theme framework to include support for it (there may be others though). I’m not particularly familiar with working with Composer, but Andrey Savchenko, better known as Rarst, is. He pioneered this feature for Hybrid Core.

For many of you, this might not be a big deal, but this will be helpful for those of you who need it now or in the future. Plus, I wanted to make sure Rarst got a bit of acknowledgment for his work on this and for teaching me a thing or two.

Here’s the package link on Packagist for those of you who need it.

Out with the old

Like I wrote earlier, Hybrid Core 2.0 dropped a lot of legacy code. I didn’t want us to continue building bloat like other frameworks. One of the goals of the Hybrid Core framework has always been to remain lean.

A couple of the major things that were dropped were things that we already had in plugin form. All widgets were removed in favor of the Widgets Reloaded plugin. Please encourage your users to download this plugin if they want to keep the widgets. The Entry Views extension was also converted into a plugin.

The Custom Field Series, Theme Fonts, and Color Palette extensions were dropped. Custom Field Series has long been deprecated. I encourage those of you who have still been using it to check out my Series plugin. The Theme Fonts and Color Palette extensions never panned out. I’ll most likely be setting up separate projects for these for anyone who still needs them or wants to help improve the code.

All deprecated functions prior to 2.0 have been permanently removed.

Post and comment-related template shortcodes were also removed. For some theme developers, this may present a bigger hurdle to jump than some of the other items if you were making use of them. I’ll be more than happy to help with anything you need to do to transition your code.

Attributes system

Hybrid Core had body, post, and comment classes long before these were added to WordPress core. When WP added these, they didn’t really innovate and push the feature where it needed to go. Therefore, I decided to build us a new HTML attribute system directly in the framework. Rather than using body_class(), for example, you’d use something like this:

hybrid_attr( 'body' );

This allows us to tack on any number of attributes to the <body> element and not just classes. This is a major improvement because it helps us on a number of fronts:

  • Infinitely flexible. It can be used for any HTML element and any attributes.
  • Built-in support for Schema.org microdata.
  • Built-in support for Accessible Rich Internet Applications (ARIA).
  • Compatibility with the WordPress body_class, post_class, and comment_class hooks to keep plugin authors happy.

Hybrid Core has a number of predefined elements plus attributes in this system, but you can also create your own.

Hat tip to Andrew Norcross and Ryan Van Etten for the original ideas on what would eventually become this feature.

Template tags

The framework has always had template tags, but they were a bit scattered throughout the files. Version 2.0 introduced new files in the /functions folder for template tags. You’ll quickly notice them because each file has a name of template-*.php.

There are many new template tags for you to use. Most of them are on my WordPress “wish list,” so I hope to eventually see them added to core WordPress. They are functions that I believe are hugely beneficial to theme authors.

Even better global support

We’ve made great strides in beefing up support for developing translation-friendly themes. The first major improvement was to re-code a nasty hack to get the framework translations into the theme. This issue has been solved, which also has the benefit of huge speed increases for everyone.

There are also a couple of extra functions for getting the language and region of a user’s WP install. You could do some cool things with these.

My favorite new feature though has to be the new locale stylesheet system, which improves upon what WordPress already has in place. Now, there’s a clear hierarchy for custom stylesheets. For example, the hierarchy for Korean would be (loaded in addition to the theme’s style.css):

  • Locale: css/ko-kr.css
  • Language: css/kr.css
  • Region: css/ko.css
  • Text Direction: css/ltr.css

The tip of the iceberg

I wish I had the time to write about all the new features and changes within the framework. I’m excited about each of them because it represents a major shift in how we’ll be coding themes in the future.

If you’d like to check out some themes that are already running on version 2.0 to see how they work, check out:

I’ll be working on updating documentation as soon as I can, but it’s going to take a little time to document everything fully with this change. Don’t hesitate to open a new support topic in the meantime. Support topics actually help me write better documentation because I learn what it is you all need to know.

Download version 2.0

You can grab the latest version from the following links:


  1. thatryan

    Awesome work Justing and contributors! I am new to this framework and have been puttering around with it for a new project I am on, will update to official 2.0 now.

    I absolutely love this code, very helpful, well written and commented.

    Will Hybrid Base be updated as well?

    Thanks again!

    1. Yes, I’ll be updating Hybrid Base soon. I think it’s important to go ahead and get it transitioned over as quick as I can.

      1. thatryan In reply to Justin Tadlock

        Totally, I am excited to build off of it using all this new hawtness 😉

  2. I’m glad the major changes are about slimming down the framework. Even though not everything is loaded, for a time, it felt a little bit bloated.

    1. I knocked 66 KB off the ZIP file while still packing in a ton of new stuff. That’s not bad at all. 🙂

      I know what you mean though about some things feeling a bit bloated. There were a lot of features that just weren’t being used anymore. Removing all the widgets really helped too.

  3. Jason


  4. mp

    Sweet. Still leading the pack.

  5. Awesome job. Kudos to you, Justin, and to Rarst. Great job improving and slimming down the framework. 🙂

  6. agusmu

    Finally… It is time to make my Hybrid Core 2.0 powered wordpress theme…

  7. Are you planning to update older themes like Prototype to version 2.0?

    1. I’m not entirely sure yet. The first thing I want to do is gauge users’ interest in older themes (most people are using the newer themes). I might end up retiring some themes and keeping some, which would be upgraded over time.

  8. Hi Justin, apologies if this is a newb question.

    I’ve been using Stargazer for 6+ months now and love it. However, I am unfamiliar with frameworks. Is this something that needs to be “enabled,” or does it come with it out of the box?

    I saw you mention something about putting a bit of code in the header. Wondering if you could direct me on what to do (if I have to do anything).

    Thanks, and keep up the great work.

    1. Hi Riz, you can see how to “enable” framework in here.


      But there are features that needs to be enabled separately in themes functions.php. I suggest that you join themehybrid.com club and you’ll not be disappointed.

    2. The framework is what I used to build Stargazer, so it’s already packaged in the theme. Our goal is for users to never have to worry about what framework they’re using. Frameworks are for developers. All users need to know is that they’re using a theme.

      1. In reply to Justin Tadlock

        Great, thanks!

    3. Aaa sorry I didn’t noticed you were talking about Stargazer theme. Just install, activate and enjoy!

  9. iVideoWeb

    Nice work Justin,

    Thanks for finally releasing 2.0 :), been using beta(s) for a long time ;), glad to see the final release.


    Fonts extension,

    I have been using Fonts Extension since its v. first inclusion into the framework, and really liked it.

    Not sure what factors caused the removal decision, if you don’t want to re-include in core, I would appreciate if you could host the project separate, as being a core contributor if you host it, will really appreciate it.

    Also could you please provide pluggable or backward compatibility for prefix. You just suddenly removed it before final launch, and I wasn’t prepared for this.

    So will appreciate if you can provide temporary work around, so I can use 2.0 with my theme as is without re-writing the “prefix” logic or remove the prefixed functions etc :(.


    Keep up the good work ;), CHEERS 😀

    1. For the Theme Fonts extension, I will be putting together a separate project on GitHub. I feel like it has a lot of potential, but it just got added way too early to the framework. I think it needs to go through a few rounds of refinement.

      As for use of the theme prefix in the atomic hook functions, that’s going to be no. One of the reasons I linked to Semantic Versioning in the post and wrote the “Why version 2.0?” section was to explain that this was a major version of the framework, which wouldn’t support backwards compatibility. Plus, you can simply add the prefix yourself when using the functions.

  10. iVideoWeb


    I would like that. I use it on all my projects, so I would not want it to get lost in the midst of new major release hype :D.

    Sure, I use it v. often, so I can suggest some refinements frequently but because of your strict standards, I find myself not suggesting one :), as I am afraid they will not be entertained.

    Yeah I understand that, and I don’t any backwards compatibility (deprecated code), I was just interested in keeping prefix logic for little while (I never saw you deprecate it in any previous releases not till you merged beta 2 release to master branch, so I suggest you deprecate it for some releases and than you remove it completely in next major release), and provide alternative for users who want it, so they can just use alternative.

    As I have been using it heavily, and its not gonna be a quick code refactoring / cleanup / redo, specific to prefix feature, so I am refraining from upgrading to final release 2.0, and using 2.0 beta 1 (been using it since its release).

    So please re-consider your decision about prefix logic for hooks, and provide alternative for new users. Or set no prefix logic as default and provide alternative for users like me so I can utilize it, unless I completely rewrite my code.

  11. The prefix stuff for the hybrid_*() hook functions was something used in the dev version. It was never officially added, so there’s nothing to even deprecate. There was a GitHub issue to discuss this though. Plus, I’ve already provided you with an alternative in my previous reply. Hop on over to the support forums if you need help implementing it.

    I also think there may be some confusion about what a “major” release is, which is understandable coming from the WordPress world. The next major release of Hybrid Core might be 5 years from now (version 3.0.0). It’s been years since the last major release (version 1.0.0).

    See, WordPress doesn’t follow semantic versioning. Technically, they have “minor” and “patch” releases. When you do minor releases, you preserve backwards compatibility (Version 3.9). When you do patch releases, you fix bugs (version 3.9.1).

    Hybrid Core follows semantic versioning, which has major, minor, and patch releases. The difference between a major release (2.0.0) and a minor release (1.6.0) is that major releases break backwards compatibility. You know it’s a major release when the first number changes (e.g., the “2” in 2.0.0). So, you have major.minor.patch. Often, you can think of it like using a new piece of software.

  12. iVideoWeb

    Hi Justin,

    Plus, I’ve already provided you with an alternative in my previous reply.

    I don’t see you comment which provides me alternative?

    Point me to right direction.

    Note: I am waiting for wordpress 4.0 release, and than I will rewrite my Parent Theme and than I would like to incorporate HC 2.0 in my theme.

    No I don’t need implementation, I just need guideline from you point how it can work (with 2.0) and which code / functions will be affected,

    as you have the deep understanding of the code (HC), so I prefer your guidance.

    Also I didn’t knew that major release must / should / would be breaking things for sure. Its a rule of thumb? & should we not provide backward compatibility in major releases? (Plugin or Themes)?


Comments are closed.