Problem with hRecipe 0.5.9.0 is resolved; please use hRecipe 0.5.9.1. Thanks.
It’s that time again, time for an hRecipe update.
Over the last few months, hRecipe has seen a minor release about monthly. While I’d be delighted to work on this project full time, monthly releases are about right. It usually takes me about two full (8 hour) days to get a minor release done, which is split between programming new features, fixing bugs, plain old software engineering (a lot of testing, really boring), and writing up these blog posts and emails.
This minor release is a good one. I was able to delete a fair bit of code which turned out to be redundant when WordPress native code and styling is properly leveraged.
Nutrition microformatting started
For a huge company, Google is pretty good about playing fair. What they aren’t always so good at is data design from a user’s perspective. I can relate, that’s a hard problem.
To wit, The Big G decided that nutrition information is going to have a slightly different structure than all the rest of the required data for rich snippets.
Theoretically, this is easy. In practice, it’s fiddly.
In any case, the 0.5.9 release of hRecipe now has nutrition information for calories, fat and protein. This is a very simple implementation, but it does pass the rich snippet tester.
And you get a freebie as well: this version of hRecipe changes the unsupported class
recipeType, which is supported by rich snippets.
That’s all for features, let’s get dirty.
Under the hood…
As usual for the 0.5.x series of hRecipe releases, a vast amount of work has been done reengineering the source code.
hRecipe isn’t going to WordPress standards, it’s going beyond WordPress engineering standards.
The goal is making hRecipe seamless with WordPress, such that it looks and feels as much like a truly native WordPress function as possible.
Here’s how it’s happening…
But the engineering rationale is bulletproof. So I’m doing it.
Some significant fraction of the hRecipe CSS has been reverse engineering from WordPress source code, and from plugins with similar behavior and styling.
Here are the highlights:
- Moved css styling into for entry navigation into editor css file.
- Removed custom styling for thickbox tabs in favor of WP-builtin. Looks the same, easier to maintain.
- Fixed a css problem where hrecipe
div.inside was overriding WP native css. Thanks to Tom Coady Web Tart UK for pointing this out and suggesting the fix.
User-derived custom css
In short: the styling box for hRecipe options now allows you to specify your own custom CSS class for use with hRecipe.
Having your own class lets you go wild with hRecipe styling, without any danger that an hRecipe plugin upgrade will overwrite your changes.
This technique is so cool, in the future
hrecipe.css will simply be demo CSS for copying into your own style file.
There is one more big pill to swallow before the 0.6.0 release, not worth writing about yet.
More importantly, expect to see more here on the blog for how to use the new custom CSS capability. Yes, you may need a little geekery, but it won’t be much. In fact, I’m working out the design details on a small product which will let you outsource your hrecipe design very inexpensively. Stay tuned for that.
Questions, comments, suggestions, complaints, etc. please leave a comment. Thanks!