Drupal - Input Filters and their quirks

We faced a really wierd issue for a client, whose maintenance we have just started. They had a section of page which worked perfectly just after cache clear, but then it stopped working. We started debugging the issue, and realized that the particular section of the page was fed off by using an input filter AND in the input filter itself, the old dev had put in several drupal_add_js  (one of which was of the type "setting").

If you check this blog http://pingv.com/blog/drupal-text-formats-102-developing-custom-filters - and check the section under "Caching Caveat", it says:

Perhaps you were expecting Drupal to not be able to tell when you changed your module code and re-filter the text, but how come it didn't re-filter it when you re-saved the node? The truth is that Drupal's filter system caches quite strictly the value of all bits of text which are run through an input filter. When you re-saved the node without changing the contents of the "Body" field, Drupal just saw that it had already filtered that exact text with that exact input filter, so it just went and grabbed the result of that filtering from its cache and used it again. If we want the text to be re-filtered, we need to change it a little. Edit the node again, and change the content of the "Body" field somehow; good old "asdf" works fine. After saving the node, you should see that "Every dog has its dayasdf" has now become "Every bear has its dayasdf" as expected.You need to be aware of this behavior of Drupal's core as you're testing any input filters you're developing. It's tempting to just go to the node editing form and use repeated clicks of the "Preview" button to see your filter code in action as you ahck on it, but that's not going to work unless you remember to alter the "Body" field in between clicks.

As you can see, this meant that we had to get rid of the drupal_add_js from the input filter processing. So as a workaround, we added the scripts in the TPL (using <script> tags and not drupal_add_js)Even the setting JS addition was done in a script tag - using something like this:

<code>

<script type="text/javascript"> 
(function ($) {
if(!Drupal.settings.setting_name)
{Drupal.settings.setting_name = new Object();}  
Drupal.settings.setting_name['<?php print $key_name; ?>']=<?php print json_encode($value); ?>;
})(jQuery);
</script> 

</code>

Whew!!! 

 

Tags