Caching problems

I am having a similiar problem- Even though my filter's 'Cache' checkbox is unchecked, it is cached anyway. Since this returns user-specific value, It returns a value for one user that should apply to another user.

If I clear the cache, either through the admin menu, or by navigating to admin/settings/performance -> 'clear cached data' button, then it rebuilds the value correctly, for the first visit to a page; then its broken again for subsequent uses.

I am using one filter with one rule ... as simple as it can get.

D6.20 , custom filter 6.x-1.0-rc2

It is possible that this is due to drupal not respecting the cache settings on filters. I will explore that possibility as well.

Additionally, I checked this:

Within the filter.module, I looked at filter_format_allowcache($format) function. Whether to use cached data or new data is done on a per input format basis, and in this case I was using the 'Filtered HTML' input format. My custom filter was one of several others, don't know if they allow caching or not but it doesn't matter- mine did not.

Anyway, the filter_format_allowcache function looks at the cache column in the filter_formats table in the DB. I looked there, and it was still set to 1 , TRUE, yes, 'cache this input filter'. So I manually set that to 0, i.e. 'Nope, don't use the input filter for 'Filtered HTML'' and now my filter works great.

This is meant more to help others solve their problem. For debugging, I don't understand enough about the filter.module . The problem could be 1) that the custom filter module isn't passing the information on to the filter.module "hey, if any input formats use this filter, then don't let that input format cache.' or 2) The filter.module is not respecting that request, or writing to the database that a certain input format shouldn't be cached.

HTH.

I see that since jimurl's post there were no changes in the 1.x-dev, meaning this bug is still around. No way I could upgrade to D7 yet, so please, whoever, readdress this. No clue how to fix this.

This is a brutal problem for me. I have a couple of simple text replacement filters and on long threads stuff like this happens:

Executed 4490 queries in 3534.63 milliseconds.

Disabling the module gives:

Executed 2869 queries in 336.4 milliseconds.

Perhaps this is a naive question but shouldn't this module run on node/comment save and make the modification once instead of apparently doing it on every comment every load?

In case it's any help, Filter Check shows whether filters and formats are cacheable or not.

"Perhaps this is a naive question but shouldn't this module run on node/comment save and make the modification once instead of apparently doing it on every comment every load?"

If the module does this, you will not be able to edit the original content.

Subscribing. Geez, I was the one banging my head against the brick wall trying to get the problem fixed for 5.x. http://drupal.org/node/427080

I assumed it had been fixed in 6.x but given the cluelessness of the previous maintainer I am not surprised it hasn't (see the carnage in the nodewords module for reference, same ex-maintainer).

Things can be improved by statically caching the filter definitions and rules in memory during the page load instead of fetching them every time from the cache tables in the database.

Note that I have forked the module to do some stuff that a client needed (link filter rules to a specific node id, limit to 1 replacement per rule per page + other things), and also due to difficulties with the previous maintainer, so my version is different all over the shop and the line numbers in the patches won't match up. But they are fairly straightforward and only affect two functions - _customfilter_get_filters and _customfilter_get_rules.

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -339,6 +339,10 @@
  *   An array of filters.
  */
 function _customfilter_get_filters() {
+  static $filters;
+  if (is_array($filters)) {
+    return $filters;
+  }
   if ($cache = cache_get('filters', 'cache_customfilter')) {
     $filters = $cache->data;
   }
@@ -371,6 +375,12 @@
  *   An array of rules, which include any subrules.
  */
 function _customfilter_get_rules($fid, $root = 0, $nocache = FALSE) {
+  static $allRules;
+  $cache_id = "$fid:$root";
+  if (is_array($allRules) && isset($allRules[$cache_id])) {
+    return $allRules[$cache_id];
+  }
+  
   if (!$nocache && ($cache = cache_get("rules:{$fid}:{$root}", 'cache_customfilter'))) {
     $rules = $cache->data;
   }
@@ -394,6 +404,12 @@
     }
   }
 
+  if (!$nocache && is_array($rules)) {
+    if (!is_array($allRules)) {
+      $allRules = array();
+    }
+    $allRules[$cache_id] = $rules;
+  }
   return $rules;
 }

So now it caches the filter definitions and rules in memory per page load as well as in the database using the regular cache tables. It will therefore fetch from the database cache tables only the first time on each page load, and keep the result in memory until the page is processed. Note that this has nothing to do with caching the filtered output of a node, comment, or whatever like jimurl was having problems with. I believe that is handled by the core filter module, not this one.

I got these results on my dev box:

Homepage Before: Executed 2258 queries in 3679.34 milliseconds. Memory used at: devel_init()=0.56 MB, devel_shutdown()=21.33 MB.
Homepage After: Executed 1976 queries in 3237.94 milliseconds. Memory used at: devel_init()=0.56 MB, devel_shutdown()=20.26 MB.

Forum thread Before: Executed 3109 queries in 2813.39 milliseconds. Memory used at: devel_init()=0.56 MB, devel_shutdown()=21.48 MB.
Forum thread After: Executed 2562 queries in 2040.13 milliseconds. Memory used at: devel_init()=0.56 MB, devel_shutdown()=20.15 MB.

Significantly less database queries and less memory usage too.

1.) Make sure you claim functionality working nicely together with the "caching" of Drupals default text filters, which slidely differs(!) from the other caching to prevent re-rendering of text to markup incore. Check the behaviour of Drupal text filter caching and compare it to Custom Filters behaviour, which you dislike. It both should work the same way. If so then make sure that this is issue here isn't a "works as designed" thing.

2.) Drupal 6 core development has stopped and is no longer supported. Let me close this issue to prevent confusion in the number of open issues. Feel free to reopen it if you still need a work around for D6 and can bring up some ideas for a solution where we all can come to patch soon to commit and close again. Thanks for understanding.