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

eZ Community » Forums » Suggestions » Siteaccess information in cronjobs

Siteaccess information in cronjobs

Siteaccess information in cronjobs

Saturday 07 June 2008 6:39:36 pm - 5 replies


In my cronjob PHP script I'm trying to reach current siteaccess setting, unfortunately, to success. The only thing I've reached is a bool(false) value, no matter if the cronjob is run explicitly for specific siteaccess, or for a default one without siteaccess declaration.

Is there any reliable method of retrieving that information?

Also, when I use cronjob to generate URL's, the siteaccess information (as well as the dir/index.php) is missing from them...:

$href = $node->urlAlias();
eZURI::transformURI( $href );

What do I do wrong? If it would be impossible to retrieve the siteaccess info, isn't that a huge problem?



Modified on Thursday 07 August 2008 9:29:55 pm by Piotr Karaś

Sunday 08 June 2008 12:50:48 am

Hi Piotrek

How are you running your cronjobs? What eZ version? How are you accessing the siteaccess setting?


Sunday 08 June 2008 7:00:19 am

Hi Bruce,

Thanks for your intrest!

I've tried all combinations know to me, just like, for what initially was an extension job:

php runcronjobs.php partname
php runcronjobs.php partname -s defaultsiteaccess
php runcronjobs.php partname -s adminsiteaccess
php runcronjobs.php partname -siteaccess defaultsiteaccess
php runcronjobs.php partname -siteaccess adminsiteaccess

Then I moved it around, including the main cronjobs directory, both putting it as a part OR global cronjob list. The job is always found, but:

1) never seems to respond to siteaccess declaration
2) never was siteaccess-aware (not to mention being able to retrieve that information):

$href = 'user/login';
eZURI::transformURI( $href, false, 'full' );
$cli->output( $href );

keeps returning:


3) the weird thing: when I have this as an extension cronjob that is siteaccess dedicated, any of the above call will find it, no matter how I call. Here's the ini structure within extension:


This seems also weird, I would expect that adminsiteaccess cronjob call should never find it, but it keeps finding it... Now, after some tests, this seems to work as I have expected, only with reversed syntax:

php runcronjobs.php -s defaultsiteaccess partname
php runcronjobs.php -s adminsiteaccess partname

The first one finds the extension cronjob, the second one not. It's just not the syntax I found here:
This particular problem looks to be related to this part of runcronjobs.php:

for ( $i = 1; $i < count( $argv ); ++$i )
    $arg = $argv[$i];
    if ( $readOptions and strlen( $arg ) > 0 and $arg[0] == '-' )
        // It seems like $readOptions will never reach siteaccess declaration if cronjob part is declared as the first argument...:
        if ( $cronPart === false )
            $readOptions = false;
            $cronPart = $arg;

This is eZ Publish 4.0.0 and it seems to behave the same with or without this patch:[]=732&rm=1&column=8&sortOrder=4
I run all my tests directly with PHP CLI - I assumed I do not have to run real CRON to confirm...

To summarize, even when I made my runcronjobs.php find only the cronjob parts it should, still I'm nowhere near getting the siteaccess information or at least making eZURI::transformURI() method notice it ;(
I have no much experience with 3.x cronjobs, so I'm not sure what to expect...


Modified on Sunday 08 June 2008 7:05:52 am by Piotr Karaś

Friday 13 June 2008 5:52:48 am

So, does anyone know if I'm making some silly mistake, or if there is something really wrong with the runcronjobs.php tool in eZP 4.0.0? It would be great to have that fixed before 4.0.1 becomes stable...

I remember asking this question about running cronjobs months ago... I didn't quite understand why I had to call the jobs for different siteaccesses. So, if there's actually no siteaccess information available or no distinction between siteaccess, what would be the point?


Tuesday 12 August 2008 8:40:29 am

Have you reported this Piotrek?
I think it has been like this for a while so might be a doc bug.

Tuesday 12 August 2008 9:24:42 am

Yup, it's here:


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

36 542 Users on board!

Forums menu

Proudly Developed with from