Jump to:
| Project: | Recipe |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | jvandervort |
| Status: | closed (fixed) |
Issue Summary
Hi there,
It should be usefull for some recipe to have a yield field more flexible.
Sometimes recipes are made for Jar of jam, Cocktails or watever, not only for people amount. That's why I suggest to transform the yield field in varchar instead of int in the database and display for who or what the quantity is made exactly.
I have tweaked a lot the recipe module so I cannot make a patch, but the modifications are very simple
In recipe_custom_yield_form($node) function :
Add at the begining of the function
<?php
$node->yield_type = trim(substr($node->yield, 1, -1));
$node->yield = (int)$node->yield;
?>In theme_node_recipe($node, $yield_form = TRUE) function
Replace
<?php
$summary .= '<tr><th>'.t('Yield').'</th><td>'.$yield.'</td></tr>';
?>By :
<?php
$summary .= '<tr><th>'.t('Yield').'<br />'.$node->yield_type.'</th><td>'.$yield.'</td></tr>';
?>And don't forget to change the type of the yield field to a varchar in the databaseALTER TABLE `recipe` CHANGE `preptime` `preptime` VARCHAR( 64 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL
That's all, I think it's more flexible than before...
Comments
#1
#2
I'm not opposed to adding units to the yield, but I think the yield field needs to remain an int so that it can be multiplied up and down. Have you disabled the double/halve buttons on your site?
#3
For sur no, with the patch I propose you still canmake operation with the yield.
For the example of a cocktail :
When you enter your recipe, you enter "4 glasses" instead of just "4".
But when you show the node, the "4" number is extracted from the "4 glasses" string, so the operation like halve or double are still effective.
And the "glasses" string is displayed just under the "Yield" string to bring more details.
#4
I imagine this would not be fool-proof to the end-users however, as they might type "Three Jars of Jam" or "About 50 cookies".
What I have done is to add a plain text field called "Serving Size" or "Yield Size" (in my case I just used a CCK field) and displayed the content of that field right after the yield value in the theme file. So people have to type "3" in the yield field, and "Jars of Jam" (or "jars" or whatever yield description they want) in the "serving size" field. Now I just have to figure out how to template the recipe submission form so that the CCK field shows up right after the Yield field in the form (or I could just learn how to add the field to the module, but I'm new to drupal programming so I haven't got that far yet)
Drupal 6.12, Recipe 6.x-1.x-dev
#5
regarding the above instructions, could someone please elaborate on the first set of additions?
specifically . . .
In recipe_custom_yield_form($node) function :
Add at the begining of the function
<?php$node->yield_type = trim(substr($node->yield, 1, -1));
$node->yield = (int)$node->yield;
?>
where EXACTLY should this go and in what file.
THANKS!
#6
This needs more work. First, any such feature needs to automatically migrate the database field, and there's no solution here for that.
Second, not all users would want such a change made in the module. Making this an option is too complicated.
So how to please everybody? #3 seems to be the most practical solution --
That would 1) ADD "serving size" (good to have...), and then 2) the yield is a multiple of that.
This also gives yield more meaning.. what does "5" mean on a cake recipe (5 people? 5 cakes?). Serving size + Yield would answer that.
Anyone up to make a patch?
#7
#8
#9
Added a yield unit text field to the recipe table per @marble in #2. Left the int yield field alone so the yield calculations will work without
text parsing.
#10
I updated the Issue title because the other part of the discussion -- what IS Yield -- got lost in the solution (#2).
I'll enter the Yield ambiguity issue as a new one, because it hasn't gone away (the USDA issue makes it apparent that Yield needs to be better defined).
#11
Automatically closed -- issue fixed for 2 weeks with no activity.