eZ Community » Forums » Setup & design » workflow stops because of...
expandshrink

workflow stops because of non-exisiting version

workflow stops because of non-exisiting version

Wednesday 12 December 2012 12:59:47 pm - 8 replies

In an article-class I have an attribute "publish" (Datatype: Date and time). If a date is added when writing an article the object is hidden until it reaches that date.

A workflow then waits (ezwaituntildate) for the date and an unhide-event unhides the article when it's time.

The workflow-cronjob runs every 5 minutes.

This is all fine and dandy but not in the following scenario:

  • An article is made with a publish-date one week from now.
  • My editorial staff edits the article 11+ times the next days.
  • In content.ini we have: DefaultVersionHistoryLimit=10

Every time the article is edited, and a new version is made, it gets added to the "ezworkflow_process"-table in the DB.
When the week has gone, and it's time to unhide the article, the workflow fails:

 PHP Fatal error:  Call to a member function attribute() on a non-object in 
/kernel/classes/workflowtypes/event/ezwaituntildate/ezwaituntildatetype.php on line 63
Fatal error: eZ Publish did not finish its request

ezwaituntildatetype.php:

line 62: $version = $object->version( $parameters['version'] );
line 63: $objectAttributes = $version->attribute( 'contentobject_attributes' );

The "ezworkflow_process"-table has a record of version 1 but that version is no longer available because the article has been edited 11+ times...

PS: I'm (sadly) still on eZ Publish 4.4.

Anyone experienced and/or have any suggestions to solve this?

Wednesday 12 December 2012 1:42:46 pm

Kernel hacking ezwaituntildatetype.php and replacing

$version = $object->version( $parameters['version'] );
$objectAttributes = $version->attribute( 'contentobject_attributes' );

with

$version = $object->version( $parameters['version'] );
if($version){ 
$objectAttributes = $version->attribute( 'contentobject_attributes' );
}
else{ 
$version = $object->version( $object->attribute('current_version') ); 
$objectAttributes = $version->attribute( 'contentobject_attributes' );
}

in my DEV-version seems to do the trick. 

Is making my own, slightly different, ezwaituntildate-event the long term solution?
I'm not happy about it, can anyone shed some light?

Modified on Wednesday 12 December 2012 1:43:28 pm by Jon Arvid Ludviksen

Friday 14 December 2012 10:31:11 am

Looks like a good candidate for a jira issue and a pull request. Go!

Saturday 15 December 2012 9:55:35 pm

I have found a similar (not quite the same) but a similar problem because of versioning issues, same "abruptly ended process and multiple same object with multiple published versions at the same time.

http://share.ez.no/forums/develop...ared%21-kernel-error-3/(offset)/last

 

Think there has to be some work to do in the versioning system...

Monday 17 December 2012 2:25:09 pm

Quote from Gaetano Giunta :

Looks like a good candidate for a jira issue and a pull request. Go!

Posted a jira issue:

https://jira.ez.no/browse/EZP-20234

Thursday 31 January 2013 9:20:43 am

Quote from Jon Arvid Ludviksen :
Quote from Gaetano Giunta :

Looks like a good candidate for a jira issue and a pull request. Go!

Posted a jira issue:

https://jira.ez.no/browse/EZP-20234

Bump. Anyone?

Thursday 31 January 2013 9:38:58 am

Hi Jon Arvid, 

Quick question: did you have a quick-fix yourself to this? Or a seed thereof?

Cheers,

Thursday 31 January 2013 10:38:51 am

Quote from Nicolas Pastorino :

Hi Jon Arvid, 

Quick question: did you have a quick-fix yourself to this? Or a seed thereof?

Cheers,

The kernel-hacking above is the only quick-fix I've done. But so far I've only done it on my DEV-installation..
I was hoping someone could shed some light or try to reproduce it before I put it on my LIVE-installation. 

Thursday 31 January 2013 11:20:27 pm

On every subsequent edit, is a new entry added to the workflow processes list? If that's the case, then you can force old workflow processes to be deleted, similar to this code:

https://github.com/mugoweb/hideuntildate/blob/master/eventtypes/event/hideuntildate/hideuntildatetype.php#L33

I agree -- if that's the type of fix that's needed, it should go into the kernel.

I didn't write this to plug the "hideuntildate" extension, but if you're wondering what that's about, it takes a very similar approach to "waituntildate" except that it publishes the article hidden, so that it's part of the content tree and visible to other editors in the Administration Interface.

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from