Before you go on

The changes described in this article are primarily for educational and learning purposes. The current logic used when renaming websites and assets in Magnolia is not a bug, it’s wanted behavior. There still might be cases when a customer requests pre-existing functionality, so the solution described here might be helpful for you - but as always: Do extensive testing when changing core Magnolia configuration and use the samples at your own risk!

The “problem”: Status changes are propagated to child nodes

When an editor is renaming websites or folders in the assets app, all existing child nodes are marked as changed - this is a behavior that was different in Magnolia 4.5.x and was changed in Magnolia 5.x..

While this is technically not a problem, it can be confusing for (some) editors to actually see which of the node names actually were changed, escpecially if there is a tree with many objects. You also might find customers who are not willing to accept “fundamental” behavior changes.

The solution for Magnolia 5.6.x

Provide a new action class for renaming dialogs

First, a new action class used within the dialogs for renaming pages and asset folders has to be created. To change the default logic we overwrite the execute method. After the name of the node was change, we first unwrap it before we apply the changes to the status.

public class ChangeNodeNameDialogAction extends SaveDialogAction {


    public void execute() throws ActionExecutionException {
        if (validateForm()) {
            final JcrNodeAdapter item = (JcrNodeAdapter) this.item;
            try {
                Node node = item.applyChanges();
                setNodeName(node, item);

                if (!node.isNew() && isNewNodeName(item)) {
                    node = setNodeProperties(node);
            } catch (final Exception e) {
                log.error("Problem while setting node properties.", e);
                throw new ActionExecutionException(e);

    private Node setNodeProperties(Node node) throws Exception {
        Node updatedNode = NodeUtil.deepUnwrap(node, MgnlPropertySettingNodeWrapper.class);
        PropertyUtil.updateOrCreate(node, NodeTypes.LastModified.LAST_MODIFIED, new GregorianCalendar());
        PropertyUtil.setProperty(node, NodeTypes.LastModified.LAST_MODIFIED_BY, MgnlContext.getUser().getName());

        return updatedNode;

    private boolean isNewNodeName(JcrNodeAdapter item) {
        String original = StringUtils.defaultString(item.getNodeName(), "");
        String current = StringUtils.defaultString(item.getItemProperty(ModelConstants.JCR_NAME).toString(), "");
        return !StringUtils.equals(original, current);


By using the NodeUtil.deepUnwrap method, we prevent the action code to update statuses of the child nodes.

Adjust the configuration

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

Create a rename folder dialog in the DAM app


Extend the existing dialog in “ui-framework” and set the implementation class according to our changes:

Change the dialog for editing a folder in the DAM app


Use the previously defined dialog in the action for editing a page:

Change the class for editing a page in the PAGES app


Again set the implementation class according to our changes:

Check the result

After applying all the changes, (re-)open the PAGES app and rename a page that at least has one child node.

The only status flag that should be changed now is the flag of the page itself.

Example code

I have created an example module for Magnolia 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.

Warning: Be aware of indexing and search configuration impact!

Quite a few Magnolia customers use custom code for pushing indexing changes to their preferred search solution / appliance. Changing the logic of object statuses combined with the publication process can have a serious impact on the search index, depending on the existing implementation logic.