Rewrite this field: use input formats rather than filter_xss_admin()

javascript embedded in tags is considered bad form in Drupal, insecure and unmaintainable. Your .js file should attach javascript via selectors and jQuery handlers (for example, $('#id).bind('mouseover', function () { ... }).

I'm having a similar problem with "Rewrite output of this field".

I'm trying to rewrite a "price" field as a PayPal button (a form). However, Views deletes form tags entirely when you "Rewrite this field as...". Thus, rewriting [title] as

**<form>**[title]**</form>**

produces

****[title]****

I think this is a problem because the help text says you can enter html, so presumably users will be surprised that they can enter html, but not any html -- It is not immediately clear what filtering Views uses for these rewritten fields.

As mentioned above, "javascript embedded in tags is considered bad form in Drupal". True, but it is not Views's role to enforce that standard. Rather, as when users create block, nodes, or indeed even headers and footers in Views themselves, they may select any input format to which they have access.

Thanks,

Albert.

I am having the same trouble rewriting a field to be an embedded youtube video. The object, embed, and param tags are being ommitted from the output.

Switching this to a bug report, since the help text does say "You may include HTML".

I am having the same trouble rewriting a field to be an embedded youtube video. The object, embed, and param tags are being ommitted from the output.

That's the design here. It uses filter_xss_admin to ensure that the output is secure.

If you need tags like object/embed you better use theming of a single field.

If this feature will make it in, perhaps 7.x-3.x is the appropriate branch.

No 7.x-3.x doesn't get new features only.

@dereine thanks. Just to confirm: new features go into 6.x-3.x, then are carried over to 7.x-3.x, right?

@alberto56
Correct. 6.x-3.x and 7.x-3.x are kept in sync.

What is the use case for forms if you can't have fapi, because the form isn't dynamic.

Alternative you can extend views to embed a full form, there is no reason to hack this into the rewrite output field.

@dereine the form usecase is to add a form from an external source like PayPal (displaying a paypal button requires inserting form code generated by PayPal which doesn't go through the FAPI), but it is just an example. If a user has the permission to use the full HTML input format, it seems arbitrary to filter his or her "rewrite this field as..." content for security purposes.

I'm in the same case.
I created input format for automation of jquery tooltip, and it would be really convenient to just add [tooltip target="mytitle-id"]My content in tooltip[/tooltip] in the " rewrite output" text area.

I tried to modify the textarea in views_handler_field.inc to accept input formats, but when i save it, nothing is displayed and the textarea is blank on the next edit.
I understood the filter is first processed by the token module, then processed by filter_xss_admin. And i don't know what to do to send it to the chosen input format filter.

Perhaps views custom field will provide a field that can be run through an input filter?

Yes that would be somthing like that but it's not ported to D7...
I'll see what would be the best solution and try to commit a patch when i found one...

Ok, i managed to transform the "Rewrite output" textarea into a text_format textarea.
Merlinofchaos i think you're right. Even if i can do what i wanted to do with my modifications, i actually understood while i was doing it that what i wanted is a field with both custom filter formats and tokens functionnality.
Unfortunately, Views Custom Field's D7 successor Views PHP doesn't seem to implements any of these.
I'll post a patch here when i come with something clean enough.

Here is the patch.
Please note that :
- this patch add some D7-specific syntax & functionnalities (text_format and #states), so D6 users might want to take a look at it and backport it to D6 version.
- The text_format field & #states don't react well, the [temporary] fix for this is simple and is discussed here : #997826: #states doesn't work correctly with type text_format

+++ views_handler_field.inc	30 Jan 2011 00:52:36 -0000
@@ -435,13 +435,16 @@ class views_handler_field extends views_
+        '#format' => isset($this->options['alter']['text']['format']) ? $this->options['alter']['text']['format'] : NULL,

If this value is not defined in option_definition, never will be saved.

+++ views_handler_field.inc	30 Jan 2011 00:52:36 -0000
@@ -435,13 +435,16 @@ class views_handler_field extends views_
+        /*'#process' => array('ctools_dependent_process'),
         '#dependency' => array(
           'edit-options-alter-alter-text' => array(1)
-        ),
+        ),*/

Patches should remove lines, not comment them.

+++ views_handler_field.inc	30 Jan 2011 00:52:36 -0000
@@ -435,13 +435,16 @@ class views_handler_field extends views_
+        '#states' => array(          'invisible' => array(':input[name="options[alter][alter_text]"]' => array('checked' => FALSE))        ),

Even for D7, this is not respecting the Coding Standards

+++ views_handler_field.inc	30 Jan 2011 00:52:36 -0000
@@ -776,7 +779,14 @@ If you would like to have the characters
+        ¶

Trailing spaces

I'm not sure if this 'idea' should be considered at all. Include a text format at this level is really bad, a lot of fields don't need text formats and should be managed by other custom fields as @merlinofchaos said in #14

Powered by Dreditor.

Yes thanks for the corrections.
Indeed, i think the the D7 port Views PHP of Custom Field module should keep the Custom Input format field integration.

I'm not sure if this 'idea' should be considered at all. Include a text format at this level is really bad, a lot of fields don't need text formats and should be managed by other custom fields as @merlinofchaos said in #14

Not sure I agree with you completely: using filter_xss_admin() seems a bit arbitrary to me; moreover, entering text for output to the screen seems to be exactly what input formats are designed for.

However, security implications can be imagined for this approach, but the same goes for "filter_xss_admin()". Why should a user with access only to Filtered HTML have access to create output via filter_xss_admin() in views? Conversely, why should a user with access to Full HTML be limited to filter_xss_admin() in views?

Custom fields seems like a good idea though, thanks for pointing me in that direction.

Cheers!

Albert

I agree with dagmar. Attempting to add the filter system to the rewrite is very risky and will almost certainly break a lot of sites.

Views custom field is the answer. If it's not yet ported to D7, then I recommend you focus efforts on helping port.