What is the best way to prevent one filter running for output from one plugin?

What is the best way to prevent one filter running for output from one plugin?

by Tim Hunt -
Number of replies: 5
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

We have one plugin (mod_oucontent, not shared with the community) where HTML is output through format_text, including filtering, except that we don't want filter_urltolink to run. (Or rather, we want to be able to turn on filter_urltolink for our site, but we can't do that until we ensure that it does not affect mod_oucontent.) For added complexity, we currently use filter_glossary here, and we want that to go on working, which prevents fixes involving no-link tags.

So, how to do that? We can think of several ways, which either involve core changes, or are nasty. I was hoping that either someone would think of a better way that we have overlooked, or enough people would think that our core changes sounded useful that we could get away with making them.

A. Make our own filter plugin

We could make filter_urltolinkwithstrangeextraoulogic, which subclasses filter_urltolink, and adds some extra hacky if statements, probably based on global $PAGE or something. [We don't want to do this.]

B. Get mod_oucontent to automatically set up configuration in filter_active for each instance

So, when you add a new instance of our module, we automatically turn off the urltolink filter in that context. [We really don't want to do this.]

C. In mod_oucontent mess with the HTML so that the urltolink filter does not match

E.g. replace http with http before calling format_text. [This seems like a really bad idea too!]

D. Add a new option disablefilters to format_text

format_text takes a $options array with many options. We could add a new optional one 'disablefilters', and then when mod_oucontent calls format_text, it could pass 'disablefilters' => 'filter_urltolink'. [Does anyone else have a use case for this change?]

E. Pass more options from format_text to each filter, and change filter_urltolink to respond to a new option

At the moment, where format_text calls filters, it passes on two things: 

        'originalformat' => $format,
        'noclean' => $options['noclean']

We could pass through more options (e.g., anything in pas in to $options where the array key starts with filteroption?) Then change the standard filter_urltolink respect some option like that, and then we can set that option in our calls to format_text. [Again, Does anyone else have a use case for this change?]



So, what do you think?

Average of ratings: -
In reply to Tim Hunt

Re: What is the best way to prevent one filter running for output from one plugin?

by Dan Poltawski -

Funnily enough, I was discussing this problem earlier today for local_chatlogs, the problem being we don't have a context to be able to adjust filtering on.

I like option D, it would help us with local_chatlogs, though I am not completely sold if its the best idea - I think E is going quite a step too far.

Average of ratings: -
In reply to Tim Hunt

Re: What is the best way to prevent one filter running for output from one plugin?

by Justin Hunt -
Picture of Particularly helpful Moodlers Picture of Plugin developers

I think D. It is a better solution for the whole world. 

It would not stop a 3rd party filter that chose to link URLs in the text of course.  I suppose thats not a big problem if you are not releasing the plugin. But if it were, I guess you could add an admin settings component to (de)select filters from.

Average of ratings: -
In reply to Justin Hunt

Re: What is the best way to prevent one filter running for output from one plugin?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Exactly. If we did D. (which is looking favourite so far) we would make the list of filters to disable a mod_oucontent admin setting. Thanks for the feedback.

Average of ratings: -
In reply to Tim Hunt

Re: What is the best way to prevent one filter running for output from one plugin?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

OK, so I did an implementation of option D. See MDL-50491. (Peer reviews welcome.)

Average of ratings: -
In reply to Tim Hunt

Re: What is the best way to prevent one filter running for output from one plugin?

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

As an update on this, Tim is now looking at another way to solve this problem without adding this functionality to format_text, which Damyon suggested. The new approach is to turn off all filters in the call to format_text (which you can already do), then apply the filters afterward. This will still involve a (smaller) core change as there is currently no easy way to apply all the filters in a context except x, but it'll be at a lower level in the API.

Damyon also pointed out that it wasn't very clear what our use case was for this requirement. To explain that, basically the 'URL to link' filter is great because it means people e.g. students can just type in a link in any forum post and it will work, so we'd like to turn it on. However, we have a system (a custom module) for staff to create formal study material using an XML-based authoring approach. In this system staff have full control over what is, and what isn't, linked. For example, if they are writing a course about web programming, they might refer to www.example.org in some text - in this case they do not wish that to become a link.

While staff could potentially mark that particular piece of text as not being linked, we have approximately 60,000 existing instances of this and we don't want to go through all of these either adding custom filter configuration (and presumably then having to make our system also automatically do this for each one in future) or adding in nolink markers around everything that looks like a link, etc.

We do want to apply other filters such as to turn video links into embedded players, because our system is already expecting that filter to be in use.

In the past we also had a similar requirement to turn off the emoticon filter within this same module, because that was applying unintended emoticons.

--sam

Average of ratings: -