Publisher does not support the Fluid field type. Please do not contact asking when support will be available.
If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.
Ticket: Tag entries with {entry_id} for static cache?
| Status | Resolved |
| Add-on / Version | Speedy 1.1.1 |
| Severity | |
| EE Version | 5.3.2 |
James Brown
Jul 28, 2020This may be a dumb question so please forgive me. This question is on the Static cache option. I’m coming from using static caching with CE Cache. With that I’d create a tag that would get set on every page with the {entry_id}. Then have a cache clearing rule for all channels that cleared the tag {entry_id}. Is that needed with Speedy? Or will it already automatically clear based on entry_id?
BoldMinded (Brian)
Comment has been marked private.
James Brown
Hi Brian- So this is what I have as my cache tag {exp:speedy:static ttl=”{tp-cache}” tags=”{entry_id}”}. {tp-cache} is just a template partial containing the TTL value I want to use. This is placed with an {exp:channel:entries} tag. From this point everything seems to be functioning as expected. I see the pages being cached, and in the tags section I see tags for each of the entry_ids.
On the Cache Clearing Rules, I have a rule setup for Any Channel for Clear Tags that just has {entry_id}.
When updating an entry, I don’t see the cache being cleared for that entry. This is the setup I had under CE Cache, so not sure if the same options are available with Speedy. Definitely the first half is working. It’s just the cache clearing that I’m struggling a bit on.
In a separate case I was trying to do a straightforward Clear Items rule for a channel. In this case I wanted everything under /partners removed. So I put in /static/partners/ as it says in the directions. On publishing/updating entries in the channel those caches are’t cleared either.
Not sure if this is an issue with my rules or something going on with Speedy. I can confirm that manually clearing the cache via the UI does work.
BoldMinded (Brian)
This is 99% an issue with the cache busting rules you’ve defined, but I’m not sure what it is off hand. I say this b/c all the cache busting code is unit tested, so I know it works as intended. Can you share screenshots of your rules as defined in Speedy’s config?
I don’t know how you feel about digging around in php code, but if you go to the Service/CacheBreaker.php file, at line 143 in the _breakEntryCache method, you can add break points or var_dumps in that method to maybe see why it isn’t breaking the cache. Later in that file, at line 265, is where I’m guessing the issue is. The item key is not matching a found item to delete.
BoldMinded (Brian)
To clarify previous message, I don’t think this is a bug, just a mis-configured cache breaking rule, but without seeing the settings or environment first hand I can’t really tell what is incorrect about it.
James Brown
Ok, I updated the ticket with screenshots.
Yea, I doubt it is a bug as well. I’m likely missing something obvious, or trying to do something Speedy can’t do.
BoldMinded (Brian)
Does the user php is running as on your server have permissions to delete files? The first test I did locally with the same rules you defined deleted the cached file when I saved the entry.
James Brown
I’ll need to confirm with my host. I can confirm that I can delete cache pages via the control panel UI. I’m assuming that’s the same user.
James Brown
After some monkeying around we found that making the cache clear synchronously seems to have done the trick. We applied $config[‘speedy_break_async’] = ‘no’; and it seems to work now. Any idea why there’d be any difference here?
BoldMinded (Brian)
An async request uses curl or a socket connection to an ?ACT=X url in EE (which calls another Speedy function). For some reason those requests aren’t working. Unfortunately I don’t have a debug page in Speedy to see easily see what the error is (I’m going to add this to my todo list). If the synchronous cache clearing is working I’d just stick with that, it’s actually more straight forward and simple.