What to achieve

In the days of Magnolia 4.5 the publication dialog did contain both the fields for scheduled publication and un-publication. This way, publishers could define in advance to remove a specific page or page tree at a predefined date and time.

Though the un-publication feature still exists in the Magnolia 5.x series, some publishers don’t like the complete visual separation of the publish/un-publish actions, because this way it can happen easily to forget about un-publication of a specific page if you have many tasks to handle as editor/publisher.

The “problem”

Unfortunately, in Magnolia 5.x both the publish and the unpublish dialogs use the same field name publicationDate for entering a scheduled date/time for the action. This might be one of the rare use cases where re-use of configuration and code is not ideal because you cannot just add an unpublicationDate field to the publish dialog because internally for un-publishing also the name publicationDate is used.

In this case, we also really don’t want to mess around with the full workflow monster by creating new jBPM workflow.

The following sections will provide you with a hands-on tutorial on how to restore the same publish dialog functionality as provided with Magnolia 4.5.

The code and configuration have been tested with Magnolia 5.5.6 - sorry enterprise only: Use it at your own risk and backup the configuration before applying changes like these. Also be aware that you have to do proper tests for your custom projects because often other backend functionality might have been adjusted, eg for automatic publishing depending on the permissions the current user has.

The solution for Magnolia 5.5.x

The following changes have to be applied in the Magnolia JCR configuration.

Adjust the dialogs

unpublish dialog


By default, the unpublish dialog is the same as the publish dialog as “extends” is used in the configuration to completely duplicate the publish dialog.

Because we will change the publish dialog, we need to provide configuration details within the un-publish dialog configuration.

publish dialog


Next we extend the publish dialog with a field to enter the scheduled depublication date and a hidden field used as internal marker for dialogs where a depublication date can be scheduled.

Adjust generic form types


Add the form types for the fields we added to the publish dialog.

Adjust the tasks

publish task


We need to adjust the parameterResolver property for the publish task in the workflow-jbpm module. This class needs to be able to read the newly added properties in the publish dialog for creating new tasks.

unpublish task


We also need to adjust the value for the parameterResolver property in the unpublish task.

Adjust the work item handler for the human task

The class that actually creates the task needs to be adjusted to be able to create a scheduled unpublication task and so we need to modify the JCR configuration.


Restart the Magnolia server for changes in the workflow configuration to take place!

Check the result

After restarting Magnolia, try to use thew new unpublication field in the publish dialog:

We fill in the scheduled time for publication and un-publication. After clicking on the “publish” button, two tasks are created automatically.

After assigning and confirming the tasks manually two scheduled tasks are created and then are waiting to be executed at the specified time.

If all goes well, the page is first published and then un-published automatically. If not, check your configuration and that your server has been restarted after the adjustments to the workflow :-)

Example code

I have created an example module for Magnolia 5.5.6 and placed it on GitHub:

Hopefully this module can help you solve a problem or serve as inspiration but of course I will not guarantee it will work - use at your own risk.

Note: This module automatically changes the configuration of Magnolia as needed for showing the complete functionality. So please use a test-/development instance of Magnolia if you want to use the module as-is.

Example configuration

As an alternative to using the module as a whole to prevent unwanted configuration changes I placed the bootstrap files of the JCR configuration of this article in a separate directory called “etc”.