According to http://schema.org/Recipe definition, recipe instructions may be either a block of text or a list. Same thing when it comes to ingredients. However Hangry always returns an array of strings for ingredients and string for instructions, therefore it loses important piece of information.

Fortunately when it comes to instructions, the loss is easy to revert. Instructions are typically joined with "\n" and I can split this string to get original list. It doesn't seem right though, it's actually parsing the output of parser, I guess Hangry should do that.

When it comes to ingredients, it's much worse. For recipes which describe the ingredients as a block of text, this field will be usually blank. And modifying Hangry so that it returns one-item-long array doesn't seem right too.

In my opinion, Hangry's #instructions should return an array of strings if given recipe differentiate steps, and string otherwise. Similarly #ingredients should not be guaranteed to be an array. In Ruby it's not uncommon that class of some method's return value depends on situation.

I can implement it tomorrow, but it would be a breaking change, therefore I wanted to consult the interfaces before I start.

Alternatively, another methods #instructions_list, #ingredients_list, #instructions_text and #ingredients_text could be implemented. The "list" methods would return nil when only plain text is available. This approach does not introduce a breaking change, on the other hand provide 6 methods to access these two fields can be pretty confusing I think. Perhaps #instructions and #ingredients should be deprecated then.

Example of recipe that has a "fake" ingredient row:
http://www.foodnetwork.com/recipes/food-network-kitchens/easter-bunny-cake-recipe/index.html

http://www.wholefoodsmarket.com/recipes does this. There is one element with general info and another with ingredients info.

Maybe Hangry could just merge the data from all Recipe elements together?

Example: http://www.bettycrocker.com/recipes/skillet-chicken-nachos/9bf0c3be-09dd-4b1b-8cf4-a9cfa979b232

Google says they use hRecipe.
Example: http://www.bigoven.com/recipe/178920/steves-fish-tacos

I was just using Hangry with a few pages like http://www.jocooks.com/healthy-eating/chicken-fajita-quesadillas/ and http://crockpotgourmet.net/2014/06/30/crockpot-buffalo-chicken-tater-tot-casserole/, and it Hangry is only pulling in the first element with the itemprop of recipeInstructions. The Schema docs say that recipeInstructions can either be an array (one on each step) or a single element (nodes inside it), but Hangry doesn't seem to support the former.

MyRecipes.com uses it. Probably others as well.

Doesn't pull any ingredients from BigOven recipes

Hello! Love this gem. I ran through the example in the readme however the parsed recipe object does not have image_url method.

eg.
require 'open-uri'
require 'hangry'
recipe_url = "http://paleoleap.com/lobster-salad-taro-chips/"
recipe_html_string = open(recipe_url).read
recipe = Hangry.parse(recipe_html_string)
image_url = recipe.image_url

I'm on version 0.0.2
When I use the same recipe_url in the demo, the image_url is found. Is it on a different version?

Thanks.
John

See: https://travis-ci.org/iancanderson/hangry/jobs/111729476

Gem::InstallError: iso8601 requires Ruby version >= 2.0.0.
An error occurred while installing iso8601 (0.9.0), and Bundler cannot continue.
Make sure that `gem install iso8601 -v '0.9.0'` succeeds before bundling.

Ruby 1.9.3 reached its end of life and iso8601 gem no longer works with it. It may be a good idea to drop 1.9.3 support in Hangry's master.

https://github.com/iancanderson/hangry#pieces-of-flair

We had this show up over the weekend. This URL

http://allrecipes.com/recipe/23600/worlds-best-lasagna/

fails in parse_instructions in lib/hangry/parsers/non_standard/all_recipes_parser.rb

Some sites (like NYTimes Cooking: http://cooking.nytimes.com/recipes/1016717-the-best-clam-chowder) use Schema's itemprop value recipeIngredient, but right now Hangry doesn't support those sites.

Is this gem still maintained? If not, I would be happy to take over ownership/maintenance (I am using it for a personal project). I have a branch (lukeasrodgers#4) that has updated all fixtures and fixed all parsers accordingly (except for http://www.cooking.com/ which is currently under maintenance).

cheers, and thanks for the gem

Would give back more useful representations of cook time, prep time, and total time.
Maybe use this gem: https://github.com/arnau/ISO8601