Not all of the recipe fields are exposed to be used as fields in views. The description and the ingredients are missing, you can't add these to your own view.

I added the following to line 143 of recipe.veiws.inc 

<?php
  $data['recipe']['description'] = array(
    'title' => t('Description'),
    'help' => t("The description for this recipe."),
    'field' => array(
      'handler' => 'views_handler_field',
    ),
    'argument' => array(
      'handler' => 'views_handler_argument_string',
    ),
    'filter' => array(
      'handler' => 'views_handler_filter_string',
    ),
    'sort' => array(
      'handler' => 'views_handler_sort',
    ),
  );

?>

This means the description can be used as a field in a view but the output of the description doesn't get filtered, so it shows html output.

What am I missing?

PS
On a similar note, it would be nice if the recipe fields also showed the option to hide the label's at admin/structure/types/manage/recipe/display.

Thanks

Comments

drew reece’s picture

drew reece commented

I can't seem to crack this. The description refuses to get converted to correct markup when rendered in a view. It always shows rendered html.
Changing the field handler to 'views_handler_field_xss' allows the html to be parsed correctly, but it skips other filters I need, such as image_resize & media filters.

I suspect it has something to do with this comment… in the recipe.module.

<?php
function recipe_node_sanitize(&$node) {
  // NOTE: This is a kludge because we should be saving each field's format is a table.
  // Drupal7 no longer does this for us.
…
?>

Is that what is the issue here, is the 'recipe_description' field not really able to be used in views like a standard field.

…is there any way to make this work? Do all the fields need to be converted to use the field api? Is this planned?

drew reece’s picture

drew reece commented
Version: 7.x-1.0 » 7.x-1.0-alpha4

The above errors were all occurring in 7.x-1.alpha4. The 7.x-1.1 release fixes the selecting of the other fields within views.

I am still seeing html in the output of the recipe description, notes…etc fields when they are shown in a view.
Any ideas why?

jvandervort’s picture

jvandervort commented
Status: Active » Fixed

I applied a temporary fix.
Try the latest dev release dated today or after.

drew reece’s picture

drew reece commented
Category: feature » bug

Thanks,
Using views_handler_field_xss sorta fixes it but doesn't really address the main problem, which is only becoming clear now.
As it currently stands the description, notes and instructions fields don't save the selected filter format. So when saving the recipe the 'field format' is never saved, it always reverts back to the default format, when you edit the node

I'm changing this to a bug report, because of the loss of formatting causes unexpected behaviour.

I suspect recipe needs to define it's own views_handler_field function & process the fields according to the filter format used on each instance.

Is there any reason that this module needs to store these fields inside the recipe table? Can they be turned into normal 'fields api' fields, I realise the migration path may be a major limiting factor. Sorry, the module is promising, but certain parts confuse me.

jvandervort’s picture

jvandervort commented

Yep, the main problem is clear, but I'm not going to fix it in this branch (at least I don't think so.)
I plan to start a -2 branch and convert recipe to fields and ingredients as nodes, but that is going to take quite a while to get stable and provide and upgrade path (I'm not sure I'll have any help). As a module consumer, I always hated when module maintainers did their massive upgrades during a Drupal core migration.

drew reece’s picture

drew reece commented

I've not used Recipe for D6 & see all this stuff that seems to have changed within core, so I don't envy the position you are in.
I think people will realise the reasons for the migration path (or lack of one) once they see the changes within D7.

I'm tempted to begin fleshing out a module, using views & fields to do most of the work, but I can't see how it would integrate the existing migration, does this sound like a bad idea to you?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.