Hi Roi,
would it be possible to restrict the usage of fields per input filter. I do not want any user to use any field in linodef tags, for example the node's body text.
I have the following input filter configuration:
- html-filter: disallow all html tags (mask them)
- linodef (that may insert certain html-tags from computed fields)
- texy filter to format the text
You can imagine what happens if a user embeds a body text with disallowed html-tags (according to the filter for that node)? Either I have to configure texy to strip off all disallowed tags (currently not possible due to restrictions in texy user interface) or disallow to embed body fields.
Another approach would be to use the embedded nodes input filter, if applicable, before embedding the body text. That might require to restrict the recursion depth on embedding fields (another new option for linodef?).
So I would like to have added following options:
- checkbox: allow/disallow fields
- comma separated list of field to allow/disallow
Comments
Comment #1
Roi Danton commentedThe recommended filter sequence is
so all the other filters are applied to the embedded objects.
However if for certain reasons you don't want to keep that sequence then the proposal
seems sufficient as an admin option. As tag option this would be confusing since the user don't know the filter sequence.
Allowing/disallowing certain fields is possible, too. However the taglists attached to the editor/input format won't be able to recognize those restrictions and list also the restricted fields by the input format (even in WYSIWYG the current input format isn't forwarded to editor plugins).
When the user embeds a restricted field he will see a message "You're not allowed to embed field %fieldname.".
Both settings should be added to the linodef input format settings introduced in #637662: Configurable title text. So one input format with linodef can have those restrictions while other input formats with linodef are not affected.
I won't start working on this before the joker issue is finished. However patches are welcome. :)
Comment #2
pepe roni commentedUnless other filters do not provide a html-filter, you're right to provide html-filter as last filter. But I decided to put html-filter as first filter to strip off or mask all html-tags the user enters. Classes and attributes are always stripped of by that module. Then linodef does its job (and may enter additional html-tags, classes, and attributes not to strip off). Then texy comes up which has its own html-filter and must be correctly set up to accept html-tags, classes, and attributes added by (eg. linodef) filter modules. Texy also enters its own html-tags and classes and attributes (that the purpose of this filter!). So my configuration is correct (at least for the current node).
I do not want a user to enter his/her own html-tags but to use texy syntax. So I have to use html-filter on first position. It's a pity that you can use html-filter only once and that this filter always strips off classes and attributes.
So in my configuration the recommended filter sequence is as I posted!
Comment #3
Roi Danton commentedWhile working on joker I've tested functions to retrieve the recursion depth again. Since the way Drupal 6 handles nodes and filters there is no chance to detect the recursion depth with 100% guarantee (e.g. when several nodes are on one page). So the feature to set a recursion depth or the support for several recursions won't make it into a release.
Comment #4
pepe roni commented:(
Comment #5
Roi Danton commentedFurthermore already at a depth of 1 an infinite recursion can occur if two fields embed each other.