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 ( http://projects.ez.no/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 );
Yields:
> 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; const STATUS_PUBLISHED = 1; const STATUS_ARCHIVED = 3; (…) /** * 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 ); } else { 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 ); } else { $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:54:42 pm
I ran into something that sounds very much the same and created this issue for it:
https://jira.ez.no/browse/EZP-22782
Description:
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:
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' );
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: https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Repository/DomainMapper.php#L145-157
You must be logged in to post messages in this topic!