hRecipe 0.6.1 imminent

hRecipe 0.6.1 has just released.

The fine folks at WordPress are hard in pursuit of WordPress version 3.3, scheduled for a late November or early December 2011 release. At the time of this writing, version 3.3, beta 4 has been tagged, and is intended as Release Candidate 1 (RC1).

This matters to hRecipe users because the programming interface for using Quicktags has changed.

On the one hand, the new interface is much easier to program. On the other hand, it doesn’t appear to be backwards compatible “out-of-the-box.”

For hRecipe 0.6.1, both interfaces are supported. The code is written, it’s being tested now, and should be uploaded to WordPress some time in the next few hours.

Backwards compatibility will probably be maintained through the 0.6.x series of releases, possibly longer.

Note: if you use the visual editor, there were no changes.

Thickbox may be retiring

One of the changes proposed, as you can see on the WP Developers blog, is future removal of the Javascript thickbox interface from WordPress.

If this happens, it will result in a pretty big change in how hRecipe is used. For example, it might make sense to use a custom post type instead of a regular blog post for recipes. That’s much easier said than done: there are more moving parts there than seem obvious.

Also, custom post types aren’t really posts, they are more like pages. While they can be added to your blog feed very easily, leveraging the WordPress postmeta system for structuring data entry would require writing a custom loop to serve your recipes into your blog. (Which is one reason the Thickbox interface is so handy, no need for customizing WordPress.)

But nothing is set, yet. We’ll see how it all plays out.

What hRecipe 0.6.2 holds


  1. Full test harness for the Javascript code driving the formatting.
  2. Improvements in how the styling is handled.

Likely, both of these will started, then one will driven to completion by popular demand, the other forming the 0.6.2 release.

Future proofing hRecipe (version 0.6 on the way)

I’m happy to report that the just being released hRecipe Version 0.6.0 runs very nicely the in the current 3.2.1 version of WordPress, as well as on the cutting edge 3.3 version of WordPress I have running on my Macbook.

It’s been tested on a WordPress installation with dozens of plugins, including several other recipe plugins. Runs fine for me.

The 0.6.0 release is an engineering release. You should not notice anything different when using the plugin.


Here’s from the Changelog:

  • Recipe entry form now routed through native WP media box functions, resulting in less code for hrecipe and better future proofing. An annoying undefined index problem was solved with this as well.
  • Many small code cleanups committed.
  • Application layout restructuring to put files in appropriate places. It would be nice for the WordPress core team to promote an “official” standard for plugin structure. Until then I’m using general software engineering best practice, and following conventions used in other frameworks such as Ruby on Rails.

As usual, if you have any problems, please leave a comment here, or even better, file an issue on Github.

hRecipe Microformatting Nutrition: fat, protein and calories (v0.5.9)

Problem with hRecipe is resolved; please use hRecipe 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 mealtype to 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…

Unobtrusive Javascript

All the Javascript in hRecipe is getting moved. Currently, and this is very common in both WordPress and most plugins, small (or not so small) fragments of Javascript are interleaved with the webpage. This isn’t necessarily a bad thing, but I need all the Javascript into its own files.

Having all the Javascript (unobtrusively) in its own files is more difficult in the short term. It’s a little like swimming against the current.

But the engineering rationale is bulletproof. So I’m doing it.

hRecipe users tend to be smarter than the average bear (it’s true, and it’s by design), so if you have any Javascript chops at all (or looking for an excuse to learn), what I’m doing, you will like. A lot.

Expect to see more on unobtrusive Javascript later.

CSS reorganization

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.

Upcoming features

Most of what’s coming in the short term is more of the same: extending nutrition, extending custom CSS, continuing the movement to unobtrusive Javascript, and moving as much of the administrative CSS back to default WordPress.

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!