Since publishing means adding an object (by the way of a node) to the content tree, un-publishing would imply the removal of the object from the tree. Once an object is published, it can not be unpublished because eZ Publish does not provide such a feature. Instead, the system provides a hiding mechanism which can be used to change the visibility of nodes. The hide feature makes it possible to prevent the system from displaying the contents of published objects. This is achieved by denying access to the nodes. A single node or a subtree of nodes can be hidden either by a user or by the system. A node can have one of the following visibility statuses:

•  Visible
•  Hidden
•  Hidden by superior

All nodes are visible by default and thus the objects they reference can be accessed. A user can hide or un-hide a node using the administration interface. Once a node is hidden, all its descendants will automatically be marked "Hidden by superior" and thus the descendants will also become hidden. A node can not become visible if its parent is hidden.

A hidden node will not be available unless the "ShowHiddenNodes" directive within the "[SiteAccessSettings]" block of a configuration override for "site.ini" is set to true. The most common way to use this setting is to disallow all but the administration interface to show hidden nodes.

Implementation

Each node has two flags: "H" and "X". While "H" means "hidden", "X" means "invisible". The hidden flag reveals whether the node has been hidden by a user or not. A raised invisibility flag means that the node is invisible either because it was hidden by a user or by the system. Together, the flags represent the three visibility statuses that were described above:

If a user tries to hide an already invisible node then the node's hidden flag will be set in addition to the invisible flag. If a node is hidden and its parent becomes visible, the node will remain hidden while the descendants will remain invisible. The following illustrations show how the node hiding algorithm works.

Case 1: Hiding a visible node

The following illustration shows what happens when a visible node is hidden by a user. The node will be marked hidden. Underlying nodes will be marked invisible (hidden by superior). The visibility status of underlying nodes already marked hidden or invisible will not be changed.
 

Hiding a visible node

Case 2: Hiding an invisible node

The following illustration shows what happens when an invisible node (hidden by superior) is explicitly hidden by a user. The node will be marked as hidden. Since the underlying nodes are already either hidden or invisible, their visibility status will not be changed.
 

Hiding an invisible node

Case 3: Un-hiding a node with a visible ancestor

The following illustration shows what happens when a user un-hides a node that has a visible ancestor. Underlying invisible nodes will become visible. An underlying node that was explicitly hidden by a user will remain hidden (and its children will be remain invisible).
 

Unhiding a node with a visible ancestor

Case 4: Un-hiding a node with an invisible ancestor

The following illustration shows what happens when a user un-hides a node that has an invisible ancestor. Since the target node is un-hided in a subtree that is currently invisible (because a node further up in the hierarchy has been explicitly hidden), the node will not become visible. Instead, it will be marked as invisible and will become visible when the hidden superior node is un-hided.
 

Unhiding a node with an invisible ancestor

Note: If you are using eZ Find, after hiding a node the search index isn't updated instantly as it normally happens on eZ Publish. For the changes to take effect the "frequent" cronjob needs to be executed, and Solr's search index needs to be updated.