Tags not updated in Tagadelic
huayen - March 7, 2008 - 04:45
| Project: | Tagadelic |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
I edited a node, added a new tag to that node, then save it. Now a new free tag exists in the system, but it is not reflected in Tagadelic (not shown in Tagadelic block, nor in the page of ***/tagadelic).

#1
Sorry the problem is solved, just need to clear cache.
#2
However, it is really inconvenient that the cache has to be cleared manually each time there is change of vocabulary terms.......
Is there any way to overcome this inconvenience?
#3
bah someone branched tagadelic wrong. Have to fix that first.
#4
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.
#5
#6
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.
#7
So will you add this fix to your next release? I don't like patch, prefer waiting for next release.
#8
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?
#9
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.
#10
New patch attached.
#11
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.
#12
Committed to HEAD, without the cache_block argument.
#13
The only practical difference between using the
cache_blocktable and thecachetable is that whencache_block(orcache_page) is used, the cache is cleared immediately upon saving a node or term (they both runcache_clear_allwith no arguments, which removes theCACHE_TEMPORARYrows fromcache_blockandcache_page, but notcache). The schema forcache,cache_block, andcache_pageare identical, so there's not a practical reason that we couldn't use any of them for this purpose. I agree that usingcache_blockdoesn'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.
#14
Automatically closed -- issue fixed for two weeks with no activity.
#15
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