EZP-14306 Refresh eZExpiryHandler instance after change siteaccess. #1240
Conversation
Opencontent
changed the title
| { | ||
| unset( $GLOBALS['eZExpiryHandlerInstance'] ); | ||
| } | ||
| return self::instance(); |
There was a problem hiding this comment.
Why does it return an instance ?
|
Thank you for your contribution.
I don't really understand where this change is done, to be honest. |
|
@bdunogier yes my comment is a bit cryptic :) |
|
To further explain the issue: in a multisite (multidatabase) environment what happens is that, when an editor of website A clears the cache, the system writes the global expiry.php. That "invalidates" the cache for website B, C, D and so on, issuing a massive cache regeneration. |
|
@Opencontent but are there any caches which are in fact supposed to be cleared across all sites, which do not get cleared any more because of your change? (sorry, did not look at the code, only thinking about the description) |
|
i have to agree with @gggeek . at least this should be configured somehow. Maybe someone wants indeed clear all of the sites cache. i can think in, at least, one our multisites projects needing this... |
|
Yes, sure there are caches that needs to be cleared across all sites, but this operation should be triggered by the developer (& not done that often), shouldn't be? : a great advantage (hard disk performance-wise, especially) is sure gained if editors of site A cannot clear cache of site B. |
…red in each var dir rather than globally. Useful in multisite-multidb installations. See ezsystems/ezpublish-legacy#1240
This pull requeste is needed in multisite-multidb installations.
We don't want to expire the cache of all instances when we need to expire the cache just of a single instance.
With this patch the expiry values are stored in each var dir rather than globally.