Hello,

We recently implemented static cache on eZecosystem.org with great success.

We used a static cache handler class which is supported by default in settings and kernel classes.

The one area in eZ Publish which does not provide support for the static cache handler system was the rssimport.php cronjob file.

The rssimport cronjob part only implements basic static cache support without support for the static cache handler system supported in the kernel.

This inconsistent implementation of support for the static cache handler system creates big problems when content is imported via rss feeds the static cache handler class is used in the kernel during content creation but later when it comes time to store the static cache requests delayed to be processed by the staticcache_cleanup.php via staticcache.ini setting CronjobCacheClear=enabled by the static cache handler method executeActions because the rssimport cronjob part does not support static cache handler system the request to store static cache creation/updates are not stored since the two static class methods are different one can not store the contents of the other.

Meaning eZStaticCache::executeActions(); in rssimport.php cronjob part does not function as desired / expected while this replacement would function as desired / expected:

if ( eZINI::instance( 'site.ini' )->variable( 'ContentSettings', 'StaticCache' ) == 'enabled' )
{
$optionArray = array( 'iniFile' => 'site.ini',
'iniSection' => 'ContentSettings',
'iniVariable' => 'StaticCacheHandler' );

$options = new ezpExtensionOptions( $optionArray );

$staticCacheHandler = eZExtension::getHandlerClass( $options );

$staticCacheHandler::executeActions();
}

For our project (in the short term) we had to create a custom copy of the default rssimport cronjob part with these modifications to properly create static cache requests delayed to be processed by the staticcache_cleanup.php cronojob part.

With this feature request we hope to eliminate the need to create extra variations of default rssimport cronjob part just to properly support the static cache handler system already properly supported in the rest of the kernel.

We write today to respectfully request your review of our code improvements.

Please let us know what you think.

We will place a link to our pull request for your review within the comments section of this issue ticket.

Thank you for your continued support!

Cheers,
Brookins Consulting