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

Tentatively:

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.

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.

Engineering

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.

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!

Mastering microformats isn’t very difficult if you already have a year or three of web page construction behind you. I picked it up in a few minutes, it’s a simple extension of well-understood technology.

If you don’t have that background, it’s still not that hard to learn, but you may have to invest a few hours over the course of week of evenings to get the gist of it.

The good thing is that most of what you learn isn’t microformats. It’s all that other stuff that goes into making web pages work. Once you learn that, the microformat is pretty simple.

Someone much more famous than I stated “Nothing suits a practical man better than a good theory.” I have found this to true, the difficulty is finding a good theory.

Without going completely overboard, you and I are going build a little bit of theory first, then we’ll fit the practice into the theory. Two main concepts are:

Russian Dolls (flickr.com theranmage) illustrate the concept of nesting.

1. Nesting.

   Nesting means “enclosing.” In this context (microformats), nesting means that something on the outside encloses something within. The hrecipe microformat is, in some real sense, an envelope for data.

   But there’s more: enclosures can have enclosures of their own. Imagine opening an envelope, say, a wedding invitation. Inside might be another envelope. Nesting. Just like a set of Russian dolls.

2. Trees.

   Literally, trees have a root and branches.

   In computer science, and for web pages, “trees” are an abstraction for how various bits of stuff are connected together. The bits in our case are the parts of a web page.

   Technically, a tree is an acyclic graph. This just means none of the branches grow into each other (connect).

I suppose I could find a picture of a tree, but for now, I’m going to assume readers can draw a tree in their mind’s eye. Or draw your own tree on paper. Same difference.

Microformats nest in trees

Your web pages, and mine, are constructed using a document object model (DOM) defined by HTML. The DOM forms a tree, as discussed above.

Let that stew for a moment, then reread it and set aside the DOM part.

Each branch of the web page “tree” is defined by elements such as div, p, span, h1, etc.

These branches can nest, but they can’t overlap. This corresponds to a real (green) tree such that branches can fork (one branch into two), but two branches don’t grow into one branch (in nature).

(This is going to get bumpy, the metaphor is breaking down.)

For the tree in our web page, we can style each branch using cascading style sheets, which you know as CSS.

This is sort of like painting each branch of a real tree. (I’m stretching hard, bear with me.)

For a web page, we may use a CSS class for this “paint”:

• Each class has a name.
• Class names are arbitrary.
• Given we can name a CSS class whatever we want, it’s smart to name them such that they add information to our web page.
• Microformats specify an agreed-upon set of CSS class names which add semantic information along with the usual styling.

Let this steep a bit, I’ll write more shortly. Leave a comment if something existing is unclear, or you want something else explained.

Ok, for some reason, I managed to fat finger this into published, long before it’s finished, and I have another commitment right now. It’s currently May 25, 2011. I’ll finish this up over the next couple of days.

Long time users (bofem) of hRecipe will recall the project started long before Google announced Rich Snippets.

And discerning (or perhaps meticulously obsessive) bloggers might note that Google’s definition for a valid rich snippet doesn’t quite match the proposed hrecipe microformat specification.

For example, one or more durations are specified as optional by the microformat specification, but Google really wants you to specify duration times. Specifically, Google would very much like to have cooking time and preparation time.

In the interest of playing well with others, hRecipe now has both preptime and cooktime as mandatory elements for the hRecipe plugin for WordPress.

Rich Snippets versus SEO

If you’ve been here, to the hrecipe.com website, or to my Website In A Weekend site, you’ll aready know:

I’m big on the notion of “smarten’ you up.”

I hate that dumbing down stuff and I won’t have it. If you’re a blogger and food blogger, you’re by definition smarter than average bear.

Most likely, you’ve already mastered some fundamentals of SEO. Not that hard, right?

Ok, rich snippets aren’t the same as SEO, and rich snippets aren’t any harder than simple SEO, but…

…rich snippets are different than SEO.

Rich snippets are simply a way to package information on the web page you already have.

So what’s the catch?

(There’s always a catch, right?)

The catch is this: understanding rich snippets requires learning about a teaspoon of meta, a swirl of semantic, a small dollop of HTML, and a pinch of CSS.

See, building a web page requires following a recipe for web pages.

In one sense, the microformatting is like seasoning, not really necessary but very nice to have. Think of microformatting as icing the HTML cake which builds your web page. Makes it tastier for search engines.

I’ll be writing a lot more about metadata, microformats, HTML and CSS in the future. And I’m gonna keep it simple. If you can cook, you can understand “meta” and “micro” and “semantic” stuff no problem, I’ll guarantee it.

hRecipe version 0.5.8.x

Welcome to the 0.5.8 series of releases. There has been quite a bit more work done under the hood, resulting in a faster, more elegant, and less buggy hRecipe.

You can find the full changelog on the WordPress hRecipe Plugin page. Here are some highlights:

• As noted above, hRecipe now splits duration into preparation and cooking time for better Google Rich Snippets
• Added some padding before and after the hrecipe div block to help with TinyMCE visual editor to help MS Internet Explorer users.
• Source cleanup, removed superfluous functions, obsolete commented out sections, etc.
• Donations closed for now, and many thanks to those who have donated to date. We’ll reopen donations in the future.
• Saved settings. Extended options handling to save existing user options and merge with newly defined options.
• More UJS cleanups. Started removing custom javascript code in favor of future proofing with WordPress builtin code.
• New screenshots explaining new data entry one per line for ingredients and instructions.

Overall, a more refined hRecipe than ever before.

Another week, another hRecipe release. It feels good. More and more people, such as yourself, are using hRecipe on a regular basis. With more people using the plugin, more issues are found and cleaned up, more search results get nicely formatted into Rich Snippets, and the world become a nicer place.

Ok maybe not quite…

…but it’s true: when you use hRecipe to add microformatting to your WordPress blog’s recipes, you really are making the world of data a better place!

See, computers are stupid. Really stupid. Computers don’t understand “recipes” at all. Using hRecipe allows the computer (in this case a search engine) to understand “recipe.” But it takes your help to make this happen; a human has to “hold the computer’s hand” in a manner of speaking.

When you help the computer to understand recipes, the computer will help everyone find recipes. Everyone wins!

Every little bit helps.

hRecipe release 0.5.6

This release deals with a couple of issues. The first is catching up with donation listing since the last release. Donations can’t support hRecipe financially, but donations do something almost as important: they make me, the author, feel encouraged. When authors feel encouraged, they write Good Stuff.

The second issue is dealing with an “anti-pattern,” which is a bit of code that “looks cool” for whatever reason, but turns out to be a really bad idea in the long term. In this case, the offending code was based on code in a very popular and widely distributed plugin. The rewrite was simple, and the fix is distributed with this release.

Specifically, this Fatal error: Call to undefined method should be considered closed.

Report bugs. Request features.

The WordPress support forums are excellent for many purposes, but tracking bugs isn’t one of those purposes. It’s hard for developers to keep up with issues reported by users on the forums because there isn’t a way for developers to easily monitor bug reports.

In contrast, when you report a bug or request a feature using the github’s hrecipe issue tracker, I get an email right away. This makes it a lot easier for me to respond in a timely manner.

You can also leave comments on the blog posts or pages here.

In any case, the most important thing is to report something, somewhere when you have an itch you need scratched. I’ll find it one way or another.

Wonders. May they never cease.

Long time hRecipe customers (bofem) know development proceeds on-again off-again, with a slight (heh) bias towards the “off.”

Thus, it’s a distinct pleasure to announce hRecipe 0.5.5 so soon after the 0.5.4.5 release. Contrary to most of the releases over the last several months, you will notice a definite improvement in recipe entry. As part of the code (and especially Javascript) cleanup, it just made sense to clean up the user interface in the popup box as well.

Here’s the improved appearance, which is also shown on the hrecipe plugin screenshots, and in your hrecipe plugin directory:

Instructions and ingredients panel for hRecipe

Click on the image to see the full size view and read the annotations.

What’s with these version numbers?

hRecipe version numbers may seem to inch along very slowly compared to other plugins.

This is partly due to where hRecipe stands with respect to the features in the final version, and partly an artifact of programmer culture. Without going into a lot of explanation, low version numbers are traditional in programmer-driven projects. Granular increments are used when when small but important updates are issued.

For example, watch for version 0.5.5.1 very soon, because I forgot to list Theresa S. as a supporter in the plugin data file (readme.txt) for 0.5.5.

That said, watch for version numbers to start increasing at a faster rate, starting with version 0.6.

Version 0.6 “Mr. Clean”

hRecipe was derived from the hReview plugin, which was several years old when hRecipe started.

Since WordPress continually evolves, plugins must evolve as well, and the minor and micro releases marching up to version 0.6 are a result of detailed examination and updating of the hRecipe code base.

Specifically:

1. Out of date PHP code and conventions are being updated.
2. WordPress deprecated code is being replaced.
3. Javascript is moving to jQuery functions wherever possible, and vetted with JSLint for accuracy.

While the average food blogger may not (and need not) care overmuch about this invisible activity, think about this way: the hRecipe kitchen was a disaster area, now is only somewhat messy, and will be sparkly shiny WordPress-approved clean by version 0.6.

Two blog posts in one weekend. That’s enough for now.

hRecipe version 5.4.5 was just released.

Nothing new on the user side, but some large changes on the back end (and more coming).

As several users have noted, there has been an intermittent Javascript conflict between other plugins and between incompatible versions of jQuery. These conflicts should be fixed on the hRecipe side. By all means, please report any conflicts you do have, and if possible, the conflicting plugin. I can’t fix other plugins, but I may be able “route around the damage” if I know what it is.

Starting from this blog post onwards, these posts should be available via email through the newsletter. Sign up in the form if you’re interested.

What’s coming…

In short, more cleanup.

I’ve taken a look at several plugins which do similar things for resumes, custom post types, etc. Some of these plugins are slicker than hRecipe, some aren’t, but it’s interesting to see how people solve similar problems in different ways. Most (hRecipe included) could use a considerable amount of work to bring up to WordPress coding standards.

Once I’m satisfied hRecipe is up-to-par, watch for more front end development. It will go much more quickly once the back end is correct.

Work progresses as the hRecipe code base is brought from the dinosaur days of 2005-2006. That’s the when original hReview code was written for WordPress, and hRecipe is a fork from that.

For this release, you won’t see much on the front end; the changes are invisible being all in the back end.

Questions, comments, bug reports, please leave a note below.

A working copy of the hRecipe source code is now hosted on Github:

• Source code: hRecipe on github. Feel encouraged to fork, fix and issue a pull request. If it makes sense, I’ll merge it. If you aren’t sure, and don’t feel like doing the work ahead of time, message me on github and we’ll discuss.
• Here’s where to post Issues and bugs. This will be far better than emailing me or leaving a comment on an hRecipe web page.

I may add some information on the wiki as well, haven’t decided yet. You, however, are welcome to add material to the wiki.