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 » eZ Publish 5 Platform » Seeing a strange version info status...

Seeing a strange version info status in the Symfony stack

Seeing a strange version info status in the Symfony stack

Friday 02 May 2014 11:12:10 am - 3 replies

TL; DR: I am getting a strange content version info status (6) in the Symfony stack - how do I fix this?

I am having an issue with the legacy extension GWUtils ( ) on an eZ 5.2 enterprise edition site.

In brief, the extension allows content to be "published" at a future date, by using a datetime content attribute.
The content locations are set as hidden through a workflow event run by the after publish trigger.
A cron runs the same worklow, which on the chosen publish date will set the locations as visible.

Backend everything seems to be working:
The locations are set to hidden on publish and then to visible when I run runcronjobs.php through the console legacy script wrapper. Though when I try to view the location in the frontend, I get "403 Access Denied".

I trackied this down to eZ\Publish\Core\Repository\ContentService->loadContent(), where:

if (
    $content->getVersionInfo()->status !== APIVersionInfo::STATUS_PUBLISHED
    && !$this->repository->canUser( 'content', 'versionread', $content )
    throw new UnauthorizedException( 'content', 'versionread' );

It seems that the content version info status is wrong.
The following:

var_dump( APIVersionInfo::STATUS_PUBLISHED );
var_dump( $content->getVersionInfo()->status );


    > 1
    > 6

This is bewildering, as it seems status should never be anything but (eZ\Publish\API\Repository\Values\Content\VersionInfo):

const STATUS_DRAFT = 0;
 * One of VersionInfo::STATUS_DRAFT, VersionInfo::STATUS_PUBLISHED, VersionInfo::STATUS_ARCHIVED
 * @var int Constant.
protected $status;

Could it be a problem in the workflow?

In the workflow type's execute function, the following yields "1":

 var_dump( $object->attribute( 'status' ) );

This seems to be correct in the legacy stack, where

class eZContentObject extends eZPersistentObject
    const STATUS_DRAFT = 0;
    const STATUS_PUBLISHED = 1;
    const STATUS_ARCHIVED = 2;

Thinking that it might have something to do with the legacy stack, I switched this (in the workflow):

if ( $doUnhide )
    eZContentObjectTreeNode::unhideSubTree( $node, true );
    eZContentObjectTreeNode::hideSubTree( $node, true );

With this:

$container = ezpKernel::instance()->getServiceContainer();
$repository = $container->get( 'ezpublish.api.repository' );
$userService = $repository->getUserService();
$administratorUser = $userService->loadUser( 14 );
$repository->setCurrentUser( $administratorUser );
$locationService = $repository->getLocationService();
$location = $locationService->loadLocation( $nodeId );
if ( (boolean) $location )
    if ( $doUnhide )
        $locationService->unhideLocation( $location );
        $locationService->hideLocation( $location );

But this too results in the same ominous status "6".

Any idea as to what this status means and where it is set as such?
Is it a problem in the Symfony stack, as the status in the legacy stack seems to be correct?

Modified on Friday 02 May 2014 11:12:56 am by Jon-Morten Kristiansen

Friday 02 May 2014 4:19:19 pm

maybe status 6 is used/added by gwutils?

Friday 02 May 2014 4:54:42 pm

I ran into something that sounds very much the same and created this issue for it:


If you have a custom workflow event that returns eZWorkflowType::STATUS_REDIRECT, the status won't be correctly set and the items will disappear from admin interface because of that.

Steps to reproduce:

  1. Create a custom workflow event according to the following code
    class myTest extends eZWorkflowEventType
        const WORKFLOW_TYPE_STRING = 'mytest';
        function __construct(){
            parent::__construct(self::WORKFLOW_TYPE_STRING, 'My Test');
        function execute( $process, $event ){
            $process->RedirectUrl = '/';
            return eZWorkflowType::STATUS_REDIRECT_REPEAT;
    eZWorkflowEventType::registerEventType( myTest::WORKFLOW_TYPE_STRING, 'myTest' );
  2. Create a new workflow and set it to before\publish trigger
  3. Create a new article
  4. The item won't be displayed at pending items

Note: This was working in all versions before eZP 5.2

Modified on Friday 02 May 2014 4:55:28 pm by Peter Keung

Thursday 15 May 2014 2:55:37 pm

Version status 6 is eZ\Publish\SPI\Persistence\Content\VersionInfo::STATUS_REPEAT. As you can see from the namespace, it is an SPI (persistence) level value, and shouldn't be exposed by the API. It was a bug, that was recently fixed by mapping versions explicitly:


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

36 542 Users on board!

Forums menu

Proudly Developed with from