Timeline for Cache invalidation to automatically update all cached template content?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 25, 2014 at 19:33 | comment | added | narration_sd | For Brad: 'acerbic' ;) And very true...! | |
| Jun 25, 2014 at 19:27 | comment | added | narration_sd | Hallo Christian, 'shake sth. out of tree' is an idiomatic expression, means trying to get sth. to appear ;). Actually my idea was like yours, not taking the site down but using un-busy intervals to catch up on cache update. You're quite correct I think that this doesn't have to wait, but can be a continuous low-priority activity to get best results. That way could be most rapid and most smooth; just most complicated. Bestimmt gemütlich ;) | |
| Jun 25, 2014 at 14:11 | comment | added | carlcs | @narration I didn't imagine this to be such a complicate topic when I first asked the question, so thanks for your thoughts on it (that's why I started that bounty – to get answers like yours! Btw. what's with that tree?). But may I ask why you would take the site down while a cache recreation is executed? You expect it to have greater impact on site performance or because of conflicts with site requests? Couldn't sth. like this be a low priority task running in the background, gemütlich replacing old cache files in the db with new ones. | |
| Jun 25, 2014 at 2:03 | comment | added | narration_sd | Not sure why you put a 200 pt. bounty on it unless hoping to shake something out of a tree. I would think such a plugin would need to be intelligent, possibly holding_off changes to avoid load during busy hours, and updates all in the middle of the night if you have one for span of site visitors. You see this reverses what you ask for, but may be a better strategy. I would hope for no naive plugins on a thing like this. Maybe another approach would be to put up an auto-takedown alert 'Site refreshing, will show in a moment' if you can afford busy-time update delays at all? | |
| Jun 24, 2014 at 22:55 | comment | added | carlcs | @Brad Yeah, I am really looking forward to the app store! I probably worded this wrong, as I only wanted to know the reasons why this shouldn't be considered useful core functionality. | |
| Jun 24, 2014 at 21:45 | comment | added | Brad Bell♦ | "If you can imagine this being a plugin, why do you think this shouldn't go into Craft core?" - I can imagine a lot of things in a plugin and 99.999% of them shouldn't be in core. | |
| Jun 24, 2014 at 13:35 | comment | added | Bryan Redeagle | As a plugin, you could read through the entry controller file and see if the onSaveEntry event is called before or after the caches are wiped. You would still need set your cache expiry to a far off date. | |
| Jun 24, 2014 at 13:33 | comment | added | Bryan Redeagle | I don't see this working in the core because P&T can't predict how many caches reference a particular element. It could be a few or a few hundred. There have been a few sites toting thousands of entries. If it were to go into the Core, it would have to be optional. | |
| Jun 24, 2014 at 10:53 | comment | added | carlcs | If you can imagine this being a plugin, why do you think this shouldn't go into Craft core? | |
| Jun 24, 2014 at 10:45 | comment | added | carlcs | That task to run fake page requests you are talking, is this something that could be done with yiiframework.com/extension/runactions @WesRice mentioned? Wouldn't something like this, run automatically after each saveEntry solve my problem? Admittedly I don't know if craft would know what caches need to be recreated. Maybe this better has to be set manually (ie. in the sections settings). | |
| Jun 24, 2014 at 10:24 | comment | added | carlcs | I definitely don't want P+T to change how the complete cache system works. Just looking for an answer on how to get rid of any delays site visitors may encounter because of invalidated caches. | |
| Jun 22, 2014 at 23:10 | comment | added | Bryan Redeagle | This is true. If you look at TemplateCacheService.php it shows the functions that wipes caches base on Element Type and Element ID. It also runs it on each request. To rebuild caches, you would need to create a task that runs a pretend page request for each cached path. But that wouldn't change how the rest of the cache system works. It would still refresh based on his config, because their cache system is base on Yii's cache system. I can point out the files if you want to look at how it's all put together. I welcome a correction from P&T because they would clearly know better than I. | |
| Jun 22, 2014 at 22:38 | comment | added | carlcs | "this happens each time new content is created or edits are made" != "because I set my cache duration to 1 day" | |
| Jun 22, 2014 at 19:01 | history | answered | Bryan Redeagle | CC BY-SA 3.0 |