content-type-standards
content-type-standards copied to clipboard
justintadlock
Recipe standard
This is the standards discussion for recipes. I'm a huge fan of recipe sites and am always trying out new dishes, so this project is something I'd enjoy being involved in.
I wanted to go ahead and get started talking about a standard for recipes. Because this can get quite a bit complex, I created the Wiki page for recipes ahead of time. This should save us some of the initial discussion. https://github.com/justintadlock/content-type-standards/wiki/Content-Type:-Recipe
Now, we can discuss what needs to be changed, removed, or added to the proposed standard.
Hey Justin,
I've been working on Recipe Hero for a little while now and it's great to see you taking the lead on this. I plan on switching over meta data to the finally agreed-upon fields (it would be great to put together a wiki article on a function that will copy metadata over to new fields, to make transitioning a little bit easier for plugin devs).
I find it may be useful to have a Course taxonomy, for sorting by desserts, entrees, etc.
I'm not sure about an Ingredients taxonomy. It makes sense as it allows for easy sorting, etc. but most likely a recipe will have amounts / units for each ingredient, so a user would have to enter the ingredients twice, both through taxonomies and metadata. Personally, I think this may be better suited to metadata. You can still do queries for it and a lot more user-friendly to add recipes. Three related fields would be the ingredient name (eg. sugar), the amount of that recipe (eg. 20.5) and the unit used to count the recipe (eg. gm / grams).
Personally I handle instructions as post meta too, which is of course disputable but I chose to as it allows more control over how instructions are displayed, makes it a little more 'user-friendly' to add (although some people like just copy/pasting the instructions, so I'm still working on a way to make this possible) and in general just allows more customization with them (in themes, too).
Great start and looking forward to hearing the opinions of others with Recipe plugins! Mine still has a lot of work to go but I would like to keep it inline with others, so will be closely following the discussion.
Also, agreed about prep / cook time being saved in minutes. Quite easy to use a function that displays it as hours / minutes for the schema.org recipe standards but having it in integers allows for more flexibility in extensions / themes.
Equipment is also a metadata I use. I may switch this over to taxonomies soon. I think it's a useful field to have.
It would be great if something like this generated output that works with services like MyFitnessPal - in case you are not aware you can paste the URL of a page with a recipe in to MFP and it will search the page for servings and ingredients/quantities and generate the carb/fat/protein values based on the MFP database and you can add it to your own tracking
@ChromeOrange Didn't know that but that's quite cool. Also opens up the possibility of working with the MFP API (private at the moment) to classify recipes based on the MFP food database etc.
I tried to find more info on how MFP pulls recipe data but couldn't find much help on their site.
I find it may be useful to have a Course taxonomy, for sorting by desserts, entrees, etc.
+1
I'm not sure about an Ingredients taxonomy. It makes sense as it allows for easy sorting, etc. but most likely a recipe will have amounts / units for each ingredient, so a user would have to enter the ingredients twice, both through taxonomies and metadata. Personally, I think this may be better suited to metadata. You can still do queries for it and a lot more user-friendly to add recipes. Three related fields would be the ingredient name (eg. sugar), the amount of that recipe (eg. 20.5) and the unit used to count the recipe (eg. gm / grams).
It's not necessarily true that a user would have to enter data twice. If that's the case, it's a limitation of the plugin rather than the standard. This project is implementation agnostic.
With that said, the ingredients feature is probably going to be our biggest hurdle. I've went back and forth between several different methods for handling this myself. I'd like to hear a number of different ideas on how to handle ingredients.
For those that are following along, here's what we definitely have to figure out:
- How to store individual ingredients for a recipe.
- How to tie the amount of each ingredient to its ingredient.
Personally I handle instructions as post meta too, which is of course disputable but I chose to as it allows more control over how instructions are displayed, makes it a little more 'user-friendly' to add (although some people like just copy/pasting the instructions, so I'm still working on a way to make this possible) and in general just allows more customization with them (in themes, too).
Remember, we're simply talking about how the data is stored rather than the implementation the plugin chooses to use. Your UI could be 1,000 times better than mine, but the data is stored in the same way.
One of the best things about saving the instructions in post_content is that at least plugins will work (to some degree) with any theme. This is something we discussed with some of the other post types. It's best to use the existing post fields if possible.
It would be great if something like this generated output that works with services like MyFitnessPal...
The generated output and/or working with third-party APIs is outside the scope of this project. This project is about standard conventions for storing data.
However, if there are particular fields that we should consider from MyFitnessPal, that's something that would be good for this project.
Good points Justin. Still really interested in your thoughts on maybe a wiki article containing a function or class that we can include in plugin updates to copy metadata previously stored under different IDs into the new proposed IDs. I will share what I come up with regardless.
Good points Justin. Still really interested in your thoughts on maybe a wiki article containing a function or class that we can include in plugin updates to copy metadata previously stored under different IDs into the new proposed IDs. I will share what I come up with regardless.
We can open up a separate ticket for that if we need to. It's something I'll need for my portfolio plugin.
I'm also excited to see this as one of the standards!
I am actively developing a recipe plugin and hope to have a first release within the next month. Our team will definitely keep an eye on this and take these ideas into account as we finalize our methods for storing meta.
Yes, ingredients have been among the trickiest items to implement for us as well. I'll add our chosen method to the discussion
- A recipe's ingredients are saved as an array inside a single
_recipe_ingredientspostmeta value. We had originally wanted each ingredient to have it's own meta entry as_recipe_ingredient, but we were unable to find a reliable way to store the ordering as our admin UI is drag-and-drop. - The
_recipe_ingredientsmeta is saved as:
array(
array(
'amount' => 2,
'measure' => 'tsp.'
'description' => 'butter'
),
array(
'amount' => 1,
'measure' => null
'description' => 'can tomato soup'
),
// etc...
)
I normally shy away from using arrays as meta values because of the MySQL search & replace issues I'm sure we're all aware of, but since recipe ingredients are very unlikely to house the site URL we didn't think it would be a problem.
I hope this helps!
I recently did a meal planner for a client, and the solution that worked there was to have ingredients as a post type, linked to the recipe post type with Posts 2 Posts. (The recipe post type was then also linked to a meal plan post type in the same way).
The advantage for my client was that entering ingredients' title, description, featured image and so on just used the standard post screen for familiarity. In the admin, this then became a autocomplete / dropdown field on the recipe post type screen, and that included P2P meta data for units and amount.
Rest of the Recipe proposal looks sensible, but I'd like to see if the choice between ingredient taxonomy and ingredient post type could be added in a compatible way.
Quick thoughts after a read of the wiki and a quick skim above. Pardon me if some of this off-target.
Off the top of my head...
- Total time as a taxonomy? e.g. 15 mins of less, 15 - 30 mins, etc. I guess you could query prep time + cook time but perhaps a tax makes a bit more sense?
- Other > Recipe video(s)
- Expertise - that is, what kinda cook / chef are you.
- Perhaps, per the comment above, instead of Ingredient it could be Main Ingredient.
- If something was Vegetarian / Vegan, how would that be handled?
- Aside from Prep tme and Cook time, what about clean up time? Some recipes take 2 pans, some it seems 200. I might be nice to get a feel for that somewhere. Minor but still kinda cool.
- Serve Warm / Sever cold - not sure if this is spot on but the idea being, it's Sunday and I wanna cook some stuff for the week, for lunch let's say. I don't want to see things that might need to be reheated.
- Season / Seasonal. Similar to the above but it's summer and there are things I can / can't get at the market. Again, splitting hairs but in a slow food / farm to table sense it's cool to know what's using seasonal ingredients.
- Some reference to cost is probably helpful but unfortunately it feels undoable in the sense that costs are going to vary quite a bit.
That's all I have in 15 mins or less. Time to make dinner ;)
I'd like to strongly oppose the idea of just dumping the instructions as one huge blob of text in the post_content.
This is the chance to enforce some more structure on this. For starters separate steps. That way a theme can decide to show an interactive step-by-step guide instead of just dumping the whole instructions.
We could even improve this by having times, ingredients and alike spilt up into chunks of steps. Maybe even declare dependencies between steps that result in variations of display later on. (Carrots need to be peeled before boiled, but it doesn't matter if this is done before everything else or while you are waiting for the water to boil)
All this metadata for the steps isn't mandatory of course, but without structuring steps in the very first place we make everything that could build on top of that impossible.
@kraftner - How would you propose instructions are stored?
Could you not use post_content and then multiple <!--nextpage--> for your interactive steps (manually added, or filtered in, in between each paragraph or bullet point)?
@GaryJones Well that could work...but it is very fragile and only caters to the very basic use case of splitting steps, but not really to anything further like adding metadata to each step. I'm thinking of everything that kind of goes in that direction:
Source: http://www.cookbookfornerds.com/
Source: http://matthewwettergreen.com/2010/01/05/how-to-cook-like-an-engineer/
Re: post content / instructions
It's important that we design standards for the 80%. It's probably a good idea to look around at the majority of people who have recipe blogs. This is not the 80%:
When I propose that everything gets put back into post_content, what I mean is that is where the final data is stored for the instructions. It doesn't mean that you can't set up a really cool UI with extra metadata. You just put all that back into post_content in the end. Your plugin doesn't even have to use the post_content with its output. But, other plugins will be able to in the chance that a user switches to another recipe plugin. That data will exist there.
I recently did a meal planner for a client, and the solution that worked there was to have ingredients as a post type, linked to the recipe post type with Posts 2 Posts...
I lean toward ingredients being a taxonomy because WordPress creates the archive pages right out of the box. The relationships are easy too. I like how you've set up things with the CPT, but I'd like to see if we can do that with a taxonomy instead.
Total time as a taxonomy? e.g. 15 mins of less, 15 - 30 mins, etc. I guess you could query prep time + cook time but perhaps a tax makes a bit more sense?
If something was Vegetarian / Vegan, how would that be handled?
Serve Warm / Sever cold - not sure if this is spot on but the idea being, it's Sunday and I wanna cook some stuff for the week, for lunch let's say. I don't want to see things that might need to be reheated. ...
These things sound like a good use of the "recipe category" taxonomy. I added this general-purpose taxonomy to the proposal because I knew there were going to be things that would be useful to some people but not others.
@justintadlock I see your point about the 80%. I'm just proposing to at least define a standard for how to store instructions in a way that makes it easy and standardized to take them apart in steps even if they are stored in post_content additionally as I do not believe that this alone is a sub 20% feature. The rest can then indeed be handled independently by a plugin.
Would a taxonomy of key "tools" be worth considering? I mean, if a recipe needs ____ and I don't have a _____ would that be helpful to know without reading too deep?
Would a taxonomy of key "tools" be worth considering? I mean, if a recipe needs ____ and I don't have a _____ would that be helpful to know without reading too deep?
I think someone may have mentioned it, but recipe_equipment sounds like a good taxonomy. This would be for something like frying pans, boiler, whisk, etc.
It's a shame there's not an easy-ish way to "rate" a taxonomy. In the case of recipes some stuff feels required while other stuff might be substitute-able. This applies to ingredients and equipment, perhaps even to prep. too.
re: "When I propose that everything gets put back into post_content, what I mean is that is where the final data is stored for the instructions."
If you're thinking what I'm thinking then I'm not so sure I see it that way. I think once you blob it into post_content magic will be lost. If the CPT has the data then it's just a matter of an "interface" so to speak to bring the data from the back and present it to the front. If everyone stay granular in sorting the interfacing can be an on the fly event at the plugin / theme level.
Or perhaps I'm just not following this thread close enough? Sorry? :)
It's a shame there's not an easy-ish way to "rate" a taxonomy. In the case of recipes some stuff feels required while other stuff might be substitute-able. This applies to ingredients and equipment, perhaps even to prep. too.
Not all plugins must use a specific taxonomy. We're just defining the standards for the taxonomies that they might use.
If you're thinking what I'm thinking then I'm not so sure I see it that way. I think once you blob it into post_content magic will be lost. If the CPT has the data then it's just a matter of an "interface" so to speak to bring the data from the back and present it to the front. If everyone stay granular in sorting the interfacing can be an on the fly event at the plugin / theme level.
Nothing is set in stone with this yet. I'm open to proposals on how to store the "instruction" data. From the vast majority of use cases I've seen with recipe blogs, it's pretty easy to handle this by storing the data into post_content. That's obviously not the only way, which is what this topic is for.
We're looking for real solutions here for data storage/retrieval. If you have a good proposal, we'd love to hear it.
On one hand, the thinking behind storing the instructions in post_content makes sense to me as on the front-end they often do appear as part of "the content." On the other hand, I understand the desire to keep them separate just like ingredients so that they can be manipulated more easily.
One perspective to consider is that a lot of the food blogs I've seen lately will have blog posts that explain the recipe steps with long-form descriptions, photos, techniques, etc... and then attach the actual "to-the-point" recipe attached at the end. In that case, wouldn't it make more sense to dedicate the recipe content type to cataloging concise ingredients and instructions, and a recipe's post_content would simply be its short description.
@ChaseWiseman This sounds like a great idea. This way we could have the post_content as a basic mandatory field for instructions while having another standard for how separate steps are stored. A plugin could then choose to handle those separately or just auto-generate post_content from the separate steps. You could even decide this on a per-recipe basis if the post_content is auto-generated or handcrafted. A little bit like the excerpt works.
One perspective to consider is that a lot of the food blogs I've seen lately will have blog posts that explain the recipe steps with long-form descriptions, photos, techniques, etc... and then attach the actual "to-the-point" recipe attached at the end.
Yes, the "to-the-point recipe" at the end is what we're primarily concerned about. If I were building a plugin, I'd definitely have a method allowing users to stick their recipes inside a blog post.
In that case, wouldn't it make more sense to dedicate the recipe content type to cataloging concise ingredients and instructions, and a recipe's
post_contentwould simply be its short description.
The recipe content type's sole purpose is to catalog this stuff. In particular, we're looking for solutions on storing both ingredients and instructions.
As for the short description, that's traditionally saved as the post_excerpt.
@justintadlock Well but there is a difference between short summary post_excerpt, recipe in plain text post_content and structured step-by-step instructions ?
Well but there is a difference between short summary
post_excerpt, recipe in plain textpost_contentand structured step-by-step instruction?
Step-by-step instructions are no different than the recipe in plain text. Instructions are the "content" of recipes. Right now, the only solution proposed for this is to store that data in the post_content field. This topic is open to alternative methods.
If you need a short description of the recipe, it's best saved in the post_excerpt field if for no other reason than themes traditionally displaying the excerpt on archive-type pages.
Okay we are going 'round in circles here as I do believe that there is a difference between plain text instructions and a step-by-step guide trough a recipe. But I'll step back for now until I can support this claim with a better example and maybe even a proposed solution.
I put together two images to describe what I think the differences are that everyone is having. Each image represents a different way that recipes could be handled. In order to proceed with this topic, I believe it's best that we're all on the same page. So, we need to decide which method is what we're ultimately shooting for with this standard.
As for the short description, that's traditionally saved as the
post_excerpt.
Ah yes, good point. I should have said "recipe description" and not "short description." I think we're on the same page there.
Thanks for putting those images together! I think the Recipe Method is what I've been trying to focus on, where recipes live completely on their own by default (archive-recipe.php, single-recipe.php, etc...). Then if a plugin/theme developer wants to build post-to-recipe relationships, they determine how to display the recipe's content within the blog post context, a la the first Blog Method image.
@justintadlock Can you put the source file somewhere? My issue is a completely different one and it would be great to use the same image to simplify the process and make it easier to compare.
I'm flexible. I've just been offering opinions / insights as they've hit me and time as allowed to share. I trust the broader process. That said, I tend to lean towards granularity - which can always be aggregated - if that matters anywhere.
I'd just like to chime in her briefly. It's been my experience that very few food bloggers use a custom post type for recipes. Most of the time they're standard posts in a particular category. The recipes are inserted into standard posts and there are often quite a few of them. Most of the existing recipe plugins are pretty insane and store the recipe data in all kinds of crazy ways. Custom DB tables seems to be the most popular choice... :\
A lot of these blogs are immensely popular and high-traffic. Making any kind of drastic change like switching over all recipes to a CPT is not going to be well received unless there's an obvious benefit for the food bloggers from a user point of view. They would also need a way to port existing data over to the new format or there's no way they'll ever switch. Just my .02.
