Wednesday 05 January 2011 2:09:16 pm

I hope some of you #ezcommunity will have installed bases where such locks happened where you can test-proof this (and get blown) !

I can think of a few where this should come in handy :D

Great job Bertrand, sounds great to me and can't wait to test this one out!

eZ Publish certified developer

http://ez.no/certification/verify/350658

Thursday 06 January 2011 12:23:55 am

This sounds very good. It will be nice to get rid of the locks, but the real nice thing I read is that approval processes will receive a message rather than just returning to the parent object. It will be nice that editors can receive a visual notification that their object won't be published immediately.

This seems a great idea :-) You should open an issue for that !

Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish

Thursday 06 January 2011 1:17:22 am

Yes of course ;-)

I was talking about the fact that currently (and without the queue publishing system in the future I've really read correctly :)), when an object goes in an after publish workflow that do not return eZWorkflowType::STATUS_ACCEPTED it is not directly published, but the editor has no info on that because it is redirected to the parent node without any message.

Cheers

Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish

Thursday 06 January 2011 2:44:11 am

My main concern is that interrupted operations don't return as much infos as I'd like them to. It is a bit hard to figure out why the interruption occured. We'll have to improve that.

Yes it would be nice to be able to customise return messages based on the type/status of workflow events or interruptions. Especially where you have conditional workflow events which may or may not be triggered during a given publish operation.

My goal exactly. AJAX will make it a bit harder to use real overrides here, we're gonna have to figure out another way, while maintaining flexibility.

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Monday 24 January 2011 5:42:20 am

I have been looking at the code, that looks like very good and I love the deamon mode with signal handling.

Just something I have on my mind (Maybe for a future realease) :

publishingqueueprocessor and classes/contentpublishingqueueprocessor are almost not related with the "publish" task. I would be awesome to have them compatible with an handler in the run() method so that we can call every task handler we want.

This way we would be able to deal with asynchronous tasks in general (and not only asynchronous publication). This asynchronous task manager could be very usefull to deal with for example synchronisation of content (push content everywhere else).

Just idea :)

Anyway cheers for this awesome feature !

--
eZ certified developer: http://ez.no/certification/verify/346216

Tuesday 25 January 2011 3:02:28 am

The current iteration on this feature really aims at resolving the immediate issue with content/publish generating locks. We intend to merge this with eZScriptMonitor, so that pretty much any task can be deferred this way, but it clearly won't fit in the current release.

Yes ! That's pretty cool :)

--
eZ certified developer: http://ez.no/certification/verify/346216