Tags not updated in Tagadelic

bah someone branched tagadelic wrong. Have to fix that first.

Right, now that that is done on to this issue.

The cache expiration was left to PERMANENT, which IMO is wrong. We want the cache to be updated when content changes. This patch fixes that. Please test and review.

Looks good.

BTW, this was brought up in the Drupal 6 Branch discussion: http://drupal.org/node/198672#comment-738652

We decided against it because we were just trying to reproduce the behavior of the 5-x version. So if we make this fix, we should do it in the 5-x branch as well.

A patch for caching with a system-wide option is available in this issue. I guess we should mark this (or that issue) as duplicate?

The only potential problem I can think of with the patch in #5 is that the temporary items in the 'cache' table are only emptied during cron runs, i.e. not when a taxonomy term/vocab or node is inserted/saved/deleted.

The easiest/safest thing to do would be to use either the 'cache_block' or 'cache_page' table in conjunction with CACHE_TEMPORARY to ensure that the cache gets cleared when a node or taxonomy is changed AND when cron runs. That would also make it necessary to change each of the cache_get calls to reference the correct cache table.

I'll submit a new patch for this shortly for you all to review.

New patch attached.

Why cache_block? Tagadelic does more then blocks.

And reg. the cron-wipe issues? I don't see that as an issue. All of drupal suffers that, it is a design choice made in Drupal itself, let's not try to build our own cache system for a small module such as tagadelic.

Committed to HEAD, without the cache_block argument.

The only practical difference between using the cache_block table and the cache table is that when cache_block (or cache_page) is used, the cache is cleared immediately upon saving a node or term (they both run cache_clear_all with no arguments, which removes the CACHE_TEMPORARY rows from cache_block and cache_page, but not cache). The schema for cache, cache_block, and cache_page are identical, so there's not a practical reason that we couldn't use any of them for this purpose. I agree that using cache_block doesn't make perfect sense in this situation semantically.

To be honest, I'm not dissatisfied with the cache being cleared only by cron (as it is now). Any changes one might make between cron runs likely won't significantly change the cloud unless the number of nodes or terms is very small. It might confuse some new users of the module though, so I wanted to post an explanation.

Was this ever fixed? On my site, which uses tagadelic 6.x-1.2, the tag cloud was sticking, and I had to click "Clear cached data" at /admin/settings/performance
Doing so caused the tag cloud to update, but I would like the tag cloud to update with no need to manually clear the cache.
I should mention that I am not using page or block caching on this site... so I'm not sure why clicking on "Clear cached data" would have an effect on the tag cloud.
Thanks,
Ryan

Confirmed - I have caching disabled and I still had to clear it to get the tags to display properly after editing. Running Drupal 6.16.

Confirmed - Issue still outstanding even though all caching is turned off. Requires clear cache to update

I am also experiencing this same problem on Drupal 6.16. I have not yet enabled any caching as this is a development environment.

Right now, I have my production servers run the cron tab only once a day. So, this could present a major headache for my users. While I could change the cron tab to run more frequently, I would prefer to see the cloud automatically updated when a content type that uses taxonomy is created/updated/deleted.

I applied the patch from comment #1 located at http://drupal.org/node/391930 and it fixed my problem. It appears that the maintainer has committed the patch to the .dev version. Now it's just a matter of the .dev version being rolled into the next release.

It's really simple to apply the patch manually; you just change a couple of lines of code.

Looks like the new release is coming in June. See: http://drupal.org/node/757994. I have checked the .dev version and the patch has been applied to it.

please do not reopen closed bugs. Make new ones if your are *absolutely sure* it was not committed, or re-introduced or whatever.