For Drupal standards, AFAIK, this may not sound like an issue as I am not aware of constellations like the one I am going to describe, thus I do not raise it as a bug.

Imagine an input filter that not just formats user provided content, but also strips out certain information for whatever reason. (E.g.: Email addresses, in order to preserve privacy or simply keep careless users from exposing their email address to mail harvester bots. Or a filter that encrypts bare email addresses with JS so they cannot be harvested. Or whatever.)

Now what happens with "quote" enabled? Just follow the quote link and, voilà, see all you were longing for although you normally wouldn't be allowed to.

I am raising this as (you know this from my today's private mail) I have lots of reusable code from one of my project's parts of which solve this problem by also applying the same dedicated filters working on node view also to the $quote content. As a textarea is somehow different from rendered content HTML and the effectively configured filters are unknown to us at programming time, we could not recycle my stuff 1:1 but in the end I think this could work.

Not sure if you consider this worth solving, but if we want to give it a try I am ready to help with it.

Cheers,
dave

Comments

Zen’s picture

Zen commented
Version: master » 7.x-1.x-dev

This is certainly true. The initial (and similar) concern back in the day was to do with quoting sensitive content which used the PHP filter. This is pretty much why quoting nodes is an optional feature. Comments were deemed to not really suffer from this issue as much as nodes.

I am happy to see patches, especially against D7 & fields which should provide a bunch of APIs to render the body field independently. I believe the stumbling blocks to this issue are things like nested quotes, HTML overload (via the rendered field) and so on.

Thanks :)
-K

doitDave’s picture

doitDave commented

Okay, as I said the base thing will not be much more than somehow invoking the actual filter set and, in addition, do some form element related escaping (if any).

But before we get to that, we should clarify the item "generic quote callback" (see other context/mail; so we have a centralized source for any eventual addon and as well kind of an API).

I would really favorite _quote_get_quoted_content(...); or something similar.

(see also current _quote_plus_get_content() in quote_plus.module).

Zen’s picture

Zen commented

If you invoke the actual filter set, any quotes present, for e.g., will be converted to mark-up and subsequently be filtered out. I'm not sure what you mean by "form element escaping".

-K

doitDave’s picture

doitDave commented

Good point. Didn't think of that. Whew. The filtering in my existing old project differs from Drupal, there are rendering filter classes and "cleanup" filter classes, both separately invokable so that the problem you mention never occured.

Will have to re-think that, also perhaps postpone it.

However: We need a get_quote API. Regardless of this very issue here. I will check the quote issues later these days, as we discussed by mail. Unless I find this issue there already, I will raise it and make a suggestion.

Maybe such "suppression" filters could be handled inderictly by for now setting up our own hook, something like hook_quote_content_alter(). Let's discuss this in another place.

Zen’s picture

Zen commented
Version: 7.x-1.x-dev » 6.x-2.x-dev
Assigned: Unassigned » kalman.hosszu
Category: task » feature
Status: Active » Patch (to be ported)

I've added an optional format that the quote needs to be run through prior to display.

Needs portage to 6-2.
-K
Edit: Added link to commitdiff.

kalman.hosszu’s picture

kalman.hosszu commented

The D6 version is commited in 909dd72.

Kálmán

kenorb’s picture

kenorb commented
Issue summary: View changes
Status: Patch (to be ported) » Fixed

Status: Fixed » Closed (fixed)

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