Removal confirmation dialog.
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 filesystem. 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.
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" checkbox is checked, the objects will be moved to the trash instead of being permanently deleted.
Note that it is not recommended to remove large subtrees 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.
You can remove the node that is being viewed by simply clicking the "Remove" button in the preview window.
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".
The "Sub items" window makes it possible to remove several nodes within the same operation. Use the checkboxes to select the nodes that you wish to remove and click the "Remove selected" button.
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" checkbox 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.
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.
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:
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.
Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2013 eZ Systems AS (except where otherwise noted). All rights reserved.