You can remove nodes from the system using several approaches. This operation works in a similar way as when you remove files and directories from a file system. If you remove a node which has underlying nodes, all the nodes will be removed. For example, if you remove a folder that contains several articles, both the folder itself and the articles in it will be removed.

If the node that is being removed has underlying nodes, the administration interface will warn about this. In most cases, the system will ask for confirmation and if you want to keep the removed objects in the trash. (This default behavior is controlled by the configuration settings located in the [RemoveSettings] section of "content.ini".) The following image shows the removal confirmation dialog.

In the example above, the user is trying to remove a node which contains 4 other nodes (sub items). If the "Move to trash" check-box is checked, the objects will be moved to the trash instead of being permanently deleted.

Note that it is not recommended to remove large sub-trees using the administration interface. The browser might time out in the middle of the operation and thus the database would be left in an inconsistent state. To solve this issue you can either increase the timeout or use the "ezsubtreeremove.php" script located in the "bin/php/" directory (you'll need to have PHP CLI installed and access to the command line).

The following text explains different approaches that can be used in order to remove a single or multiple nodes from the system.

Removing the node which is currently being viewed

You can remove the node that is being viewed by simply clicking the "Remove" button in the preview window.

Removing a single node using the context menu

Another way of removing a single node is by making use of the context menu. Simply click on a node's icon either in the tree menu or in the "Sub items" window and select "Remove".

Removing multiple nodes

The "Sub items" window makes it possible to remove several nodes within the same operation. Use the check-boxes to select the nodes that you wish to remove and click the "Remove selected" button

The trash

It is important to understand that the trash in eZ Publish is a flat structure. This is different from what people are used to from modern operating systems. When a node is deleted and the "Move to trash" check-box is checked, it is only the object itself that will be moved to the trash. From version 3.8, the system also remembers the object's last location in the tree and thus objects in the trash can be recovered to their original locations. However, this is only possible if their original parent nodes have not been deleted. Otherwise, the user must specify new/alternate locations for the objects during recovery. Note that specifying an alternate/new location can be done regardless if the system is able to restore a deleted object at its original location or not.

Furthermore, if a folder containing some news articles is deleted, both the folder and the articles will appear on the same level within the trash. Recovering the folder itself will not bring back the articles since the links between the folder and the articles got lost when the nodes were deleted. In this case, the folder needs to be recovered first. After that, each article has to be recovered and manually given a location.

A note about permissions

In eZ Publish prior to 3.9, objects that were moved to the trash were available to all users regardless of their access rights. From 3.9, objects in the trash are only available to users with sufficient privileges. Users that are granted access to both "restore" and "read" functions of the "content" module without any limitations will be able to access all objects in the trash. In case the user is only granted limited access to the "read" function of the "content" module, the system will select which objects to show based on the user's access rights.

For example, let's say that a folder called "Company" contains two folders called "News" and "About", each with a set of articles inside, and you delete one of the articles from the "News" folder so that it ends up in the trash. If the user's access to the "read" function of the "content" module is limited to the "Company" folder and its sub items (subtree limitation), the user will be allowed to access the removed article. However, if the user's access to the "read" function of the "content" module is limited to the "About" folder and its sub items (subtree limitation), the removed article will not be available for that user.

A note about related objects

Please note that when you remove an object that is embedded in a different object, you will not be able to publish that object unless you remove the embedding reference from the object that embeds the removed object. We strongly recommend the procedure in the example below:

An example:

• A=Embedded link 
• B=Removed object embedded in C
• C=Object with embedded object

In the case where you have an object C, with an embedded object B, related with the embedding link A, and you wish to remove object B, we strongly recommend to remove A=the embedded link, then remove the embedded object B in order to avoid problems with re-publishing object C.

A note about content with images

In multi-lingual cluster, if you create a copy of a content object with ezimage as an attribute, and delete the original copy, the image from the copy will be lost.