If a noderef field is configured using a view, the "list of referenceable nodes" can contain HTML tags coming from the view's fields (like images).

Those tags are presented in the autocomplete suggestions when using the "autocomplete" widgets, but we filter them out in _node_reference_options() before handing them to the "select" or "radios / checkboxes" widgets.
--> no HTML in "radios / checkboxes" options, while the widget could theoretically support them.

CommentFileSizeAuthor
#11 html-in-checkboxes-1155946-11.patch3.22 KByched
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

I totally agree with this.

In fact, I just hacked my references.module because I want an image on a radio and can't have it.

My recommendation is to an an option to the display somewhere that controls whether or not HTML should be stripped. Default it to TRUE.

Related to this, this code is painful:


  // If not set, make all fields inline and define a separator.
  $row_options = $view->display_handler->get_option('row_options');
  if (empty($row_options['inline'])) {
    $row_options['inline'] = drupal_map_assoc(array_keys($view->get_items('field', $display_name)));
  }
  if (empty($row_options['separator'])) {
    $row_options['separator'] = '-';
  }
  $view->display_handler->set_option('row_options', $row_options);

This method makes this changes not show up in the preview, and it's very difficult to get it to do what you want. As much as possible, all of this should be done within the view somewhere so that the preview will show you as close to the same results as you actually get on the page.

tim.plunkett’s picture

sub

yched’s picture

@merlinofchaos : I'm glad that you chime in here :-)
Actually, the main reason why _node_reference_options() does a strip_tags() is because this function is also the one that hands the list of options to views_handler_filter_in_operator (through the 'options callback') - other than that, the other consumer is core's options.module widgets, and we made sure that those are smart enough to filter out html from #options when needed (select), or leave it alone when the widget supports it (radios / checkboxes).
(BTW, that's also the reason why this can't be controlled from some setting in the view's display IMO : stripping or not stripping is a matter of destination, not an inherent yes or no)

It seems that currently views_handler_filter_in_operator always runs with $this->value_form_type = 'checkboxes', but that doesn't really feel 100% set in stone (and I think I remember some kind of "smart switch to 'select' when count(options) > N" in the past ?).

Do you think views_handler_filter_in_operator::value_form() could / should massage html stripping and special chars encoding of get_value_options() depending on the final FAPI type (select vs. checkboxes) ?

Of course, easy solution on the references.module side would be to just assume 'checkboxes' and stop doing a strip_tags() in our 'options callback'.

About separators / preview : you're probably right, but I must admit I didn't give much thought about how we could make that better - inlined fields and separators sound like something most users wouldn't even think of configuring, and yet the both the 'radios / checkboxes' and 'autocomplete' widgets would look pretty broken unless the fields are inlined.
[edit: I guess we could "just" use a dedicated subclassed flavour of views_plugin_row_fields, with an overriden render() method that force-inlines everything with a configurable separator ?]

yched’s picture

@merlinofchaos : about inline fields and preview : see #1157538: Enhance previews for 'References' views displays

webadpro’s picture

I'm looking for the same.

I need HTML in a radio/checkbox option.

Drupal6 worked just great with node reference -> views with HTML.

tbeauchemin’s picture

I also need this because my reference views are getting awful, it would be a great way to make column of I could use the content type as a class...
[subscribing]

tbeauchemin’s picture

Hi Merlinofchaos,
Not sure this is the right place to ask, but would it be possible for you to share your "hack reference module', while we are waiting for a cleaner official update ?
Thanks you all for all the work, Drupal rocks !

tbeauchemin’s picture

-duplicated-

michaelfavia’s picture

Subscribe

kobolt’s picture

Subscribe

yched’s picture

Status: Active » Fixed
FileSize
3.22 KB

Went ahead and committed the attached patch.
"Checkboxes / radios" widgets receive the Views-generated HTML, they take care of filtering it through field_filter_xss() (a little more permissive than filter_xss_admin() )

views_handler_filter_in_operator currently displays possible values in checkboxes, so be it.
We pass it the HTML options filtered by field_filter_xss() as well. If one day the handler uses a select instead of an option, the tags and encoded entities will look awful, but we'll see by then.

Committed the attached patch.

Status: Fixed » Closed (fixed)

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

seattlehimay’s picture

This is a very old issue, but I bumped into it today. Commenting in case this helps others.

While it says this patch was committed for this issue, as far as I can tell the changes were rolled back in issue #1391814: ampersands in select lists shown as & instead of &.. Unless I'm doing something wrong, the text on the references project page that reads "The HTML generated by the view is no longer stripped out before being handed to "checkboxes / radios" widgets..." is not accurate.