Closed corneliusio closed 2 months ago
Looks like our fix wasn't actually applied after all, but after further thought, there's really no need for this process to happen on staging/production sites. It's useful for development where you might be adding icons as you go, and this mechanism checks if the folder has been modified, but in all other cases, there's no reason to continually check if there are new icons.
It's really only during deployment that new icons would be added. In that case, you can use the ./craft clear-caches/icon-picker
console command during deployment to ensure that icons are updated.
Fixed for the next release. To get this early, run composer require verbb/icon-picker:"dev-craft-4 as 2.0.18"
.
@engram-design Ha, it happens. And yeah, that's a really good point.
I will note as a potential edge case that a few years back I worked on a project where we setup an asset volume where the client could upload SVGs and pointed the icon picker to this volumes directory for its source. In that instance, we needed the cache to be updated when they added new icons. But it sounds like that's still perfectly doable with the clear-caches/icon-picker
command—even if it was called from PHP.
Have applied this update to our project and everything's looking good! Thanks for the quick fix.
Yeah, I think that was the only reason I had this setup, but I'm sure that I can come up with a better way than having a check on every request to Craft! That'd be either training the client to clear the caches through the utility, triggering the console command in a module that detects changes in a volume, or doing that ourselves in the plugin.
Updated in 2.0.19
Describe the bug
We seem to be experiencing this issue, https://github.com/verbb/icon-picker/issues/38. Is it possible the fix in
2.0.0
was reverted at some point?I couldn't find a specific commit that appears to relate to this fix.
Steps to reproduce
Craft CMS version
4.11.5
Plugin version
2.0.18
Multi-site?
Yes
Additional context
We currently have this project deploying the exact same code with the same database content to two environments. One is a single server instance on DigitalOcean and the other is behind an auto-scaling group on AWS. We are only seeing this behavior on AWS.