This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Developer » publish objects from script without...
expandshrink

publish objects from script without cache clear

publish objects from script without cache clear

Wednesday 05 January 2011 1:34:00 pm - 8 replies

I'd like to create and publish an object from a PHP script but without clearing the cache.

What's the best way to do it?

P.S. I tried using the "content, publish" operation via eZOperationHandler::execute(), but it always clears the cache and it seems like there's no way to avoid it.

Wednesday 05 January 2011 3:13:12 pm

Hi Marko !

The brute-force approach would be to duplicate the $OperationList['publish'] operation (from kernel/content/operation_definition.php) in a custom module, and comment out the part related to cache clearing :

array( 'type' => 'method',
                                                           'name' => 'clear-object-view-cache',
                                                           'frequency' => 'once',
                                                           'method' => 'clearObjectViewCache',
                                                           'parameters' => array(  array( 'name' => 'object_id',
                                                                                          'type' => 'integer',
                                                                                          'required' => true ),
                                                                                   array( 'name' => 'version',
                                                                                          'type' => 'integer',
                                                                                          'required' => true ) ) ),
                                                    // PreGeneration: This generates view cache for a given set of users if enabled
                                                    array( 'type' => 'method',
                                                           'name' => 'generate-object-view-cache',
                                                           'frequency' => 'once',
                                                           'method' => 'generateObjectViewCache',
                                                           'parameters' => array(  array( 'name' => 'object_id',
                                                                                          'type' => 'integer',
                                                                                          'required' => true ) ) ),

You can then call your module's custom 'publish' operation from PHP.

I must confess i never tried this myself, so i'll be glad to hear about your experiment happy.gif Emoticon

Cheers !

Wednesday 05 January 2011 5:19:17 pm

You could also play with the setVariable (eZINI) method to temporary unset some ini (like the smart view cache)

@Nicolas : I found today another method in Kaliop's code (@g4vroche copyright)

private function disablePublishOperation( $index )
    {
        if( !isset( $GLOBALS['eZGlobalModuleOperationList']['content'] ) )
        {
            $moduleOperationInfo = new eZModuleOperationInfo( 'content', false );
            $moduleOperationInfo->loadDefinition();
 
            $GLOBALS['eZGlobalModuleOperationList']['content'] = $moduleOperationInfo;
        }
 
        unset(  $GLOBALS['eZGlobalModuleOperationList']['content']->OperationList['publish']['body'][$index] );
 
    }

So, to disable cache cleaning :

self::disablePublishOperation( 13 );
 self::disablePublishOperation( 14 );

Wednesday 05 January 2011 5:40:56 pm

As far as I remember, cache won't be cleared if ViewCache is disabled.

eZINI::instance()->setVariable( 'ContentSettings', 'ViewCaching', 'disabled' );

Try this before running the import.

Wednesday 05 January 2011 5:51:03 pm

@Nicolas : I found today another method in Kaliop's code (@g4vroche copyright)

private function disablePublishOperation( $index )
    {
        if( !isset( $GLOBALS['eZGlobalModuleOperationList']['content'] ) )
        {
            $moduleOperationInfo = new eZModuleOperationInfo( 'content', false );
            $moduleOperationInfo->loadDefinition();
 
            $GLOBALS['eZGlobalModuleOperationList']['content'] = $moduleOperationInfo;
        }
 
        unset(  $GLOBALS['eZGlobalModuleOperationList']['content']->OperationList['publish']['body'][$index] );
 
    }

So, to disable cache cleaning :

self::disablePublishOperation( 13 );
 self::disablePublishOperation( 14 );

Nifty trick, well done @g4vroche

Wednesday 05 January 2011 6:15:10 pm

@gilles: It's a really nice trick, but I'm looking for a more "clean" way. Because if the order of operations for "content,publish" changes this trick won't work unless you change the index in the disablePublishOperation() call

@Bertrand: This looks like the right way to do it. But shouldn't I also disable the TemplateCache in order to disable clearing of template cache blocks? Are there any other settings that should be disabled in order to fully disable the cache clearing?

Thursday 06 January 2011 9:48:38 pm

OK, after further investigation I came to this conclusions...

The solution Bertrand suggested should be extended to disable other caching mechanisms, so it should be like this:

eZINI::instance()->setVariable( 'ContentSettings', 'ViewCaching', 'disabled' );
eZINI::instance()->setVariable( 'ContentSettings', 'StaticCache', 'disabled' );
eZINI::instance()->setVariable( 'ContentSettings', 'PreViewCache', 'disabled' );

The solution gilles suggested can be enhanced a little bit by finding the array value to unset via its name. When set this way works even better that disabling the cache via ini settings.

So I made a better function:

function disableModuleOperation( $moduleName, $operationName, $operationPartName )
{
        if( !isset( $GLOBALS['eZGlobalModuleOperationList'][$moduleName] ) )
        {
                $moduleOperationInfo = new eZModuleOperationInfo( $moduleName, false );
                $moduleOperationInfo->loadDefinition();
 
                $GLOBALS['eZGlobalModuleOperationList'][$moduleName] = $moduleOperationInfo;
        }
 
        if (!isset($GLOBALS['eZGlobalModuleOperationList'][$moduleName]->OperationList[$operationName]))
                return;
 
        $index = -1;
 
        foreach ($GLOBALS['eZGlobalModuleOperationList'][$moduleName]->OperationList[$operationName]['body'] as $key => $operationPart)
        {
                if ($operationPart['name'] == $operationPartName)
                {
                        $index = $key;
                        break;
                }
        }
 
        if ($index >= 0)
                unset( $GLOBALS['eZGlobalModuleOperationList'][$moduleName]->OperationList[$operationName]['body'][$index] );
}

which would then be used like this:

disableModuleOperation('content', 'publish', 'clear-object-view-cache');

This is a more safer way to unset a part of the module operation because it relies on the name of the part which is less likely to change than the index.

I also found that there are several other parts that can be excluded when importing objects in a script:

  • pre_publish - if you don't want pre publish triggers to be executed
  • post_publish - if you don't want post publish triggers to be executedh
  • generate-object-view-cache - no preview cache generation
  • create-notification - if you don't want to generate notifications for the imported objects
  • register-search-object - to disable the search indexing (the reindexing can be done after the import)

Furthermore, I found that disabling "register-search-object" gives you the biggest speedup, especially if you're using ezfind. In my case the import went 100 times faster (without exaggeration). And you can always do the complete reindexing after the import.

Friday 07 January 2011 12:00:34 pm

The stuff in this thread is really cool !

Being able to disable parts of an operation is actually one of our plans for the Asynchronous publishing feature. The goal is partially implement the ezpContentPublishingStategy concept introduced when presenting the future PHP API skeletons. The default strategy would run everything, while custom strategies could be created, and set as the default one in order to skip some operation methods.

Chances are big that i'll work on that today, I'll let you know.

Also note that Asynchronous publishing should make import MUCH faster as well... the content/publish operation executed in the script will be asynchronous, and will be actually executed by the daemon. If you don't need your items details (you can still use the content object ids, etc, but the object might not be published), it should make imports much faster.

Tuesday 31 May 2011 10:57:37 am

The stuff in this thread is really cool !

Being able to disable parts of an operation is actually one of our plans for the Asynchronous publishing feature. The goal is partially implement the ezpContentPublishingStategy concept introduced when presenting the future PHP API skeletons. The default strategy would run everything, while custom strategies could be created, and set as the default one in order to skip some operation methods.

Now that the async publishing feature is out, could you shed some light about this one?

Do we have the way to disable parts of publish operation?

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from