Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#11 | html-in-checkboxes-1155946-11.patch | 3.22 KB | yched |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedI 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:
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.
Comment #2
tim.plunkettsub
Comment #3
yched CreditAttribution: yched commented@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 ?]
Comment #4
yched CreditAttribution: yched commented@merlinofchaos : about inline fields and preview : see #1157538: Enhance previews for 'References' views displays
Comment #5
webadpro CreditAttribution: webadpro commentedI'm looking for the same.
I need HTML in a radio/checkbox option.
Drupal6 worked just great with node reference -> views with HTML.
Comment #6
tbeauchemin CreditAttribution: tbeauchemin commentedI 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]
Comment #7
tbeauchemin CreditAttribution: tbeauchemin commentedHi 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 !
Comment #8
tbeauchemin CreditAttribution: tbeauchemin commented-duplicated-
Comment #9
michaelfavia CreditAttribution: michaelfavia commentedSubscribe
Comment #10
kobolt CreditAttribution: kobolt commentedSubscribe
Comment #11
yched CreditAttribution: yched commentedWent 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.
Comment #13
seattlehimay CreditAttribution: seattlehimay commentedThis 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.