Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.
For 5.x documentation covering Platform see eZ Documentation Center, for difference between legacy and Platform see 5.x Architecture overview.


A section is a number that can be assigned to an object. The section ID of an object denotes which section the object belongs to. Each object can belong to one section. By assigning different sections to objects, it is possible to have different groups of objects. Although the sectioning mechanism is implemented at the object level, it is more likely to be used in conjunction with the content node tree. This is why the administration interface makes it possible to manage sections on the node level. Using sections makes it possible to:

  • Segment the node tree into different subtrees
  • Set up custom template override rules
  • Limit and control access to content
  • Assign discount rules to a group of products

A default eZ publish installation comes with the following sections:






The "Standard" section is the default section. The "Content" top level node makes use of this section.



The "Users" section is dedicated for user accounts and user groups that exist on the system. The "Users" top level node makes use of this section.



The "Media" section is used by the "Media" top level node.



The "Setup" section is used by the "Setup" top level node.

Section definitions can be added, modified and removed using the administration interface. The following illustration shows an example of how the section feature can be used to segment the content node tree.

Example of sections.

Example of sections.


When a new object is created, its section ID will be set to the default section (which is usually the standard section). When the object is published, it will automatically inherit the section that is assigned to the object encapsulated by the parent node. For example, if an object is created in a folder that belongs to section 13, the section ID of the newly created object will be set to 13. If an object has multiple node assignments then it is always the section ID of the object referenced by the parent of the main node that will be used. In addition, if the main node of an object with multiple node assignments is changed then the section ID of that object will be updated.

The administration interface makes it possible to assign sections to objects using the node tree. When a section is assigned to a node, the section ID of the object referenced by that node will be updated. In addition, the section assignment of all subsequent children of that node will also be changed. For example, if the section ID of a folder containing news articles is changed, then the section ID of the articles in that folder will also be changed.

The removal of sections may corrupt permission settings, template output and other things in the system. In other words, a section should only be removed if it is completely unused. When a section is removed, it is only the section definition itself that will be removed. Other references to the section will remain and thus the system will most likely be in an inconsistent state. The section ID numbers are not recycled. If a section is removed, the ID number of that section will not be reused when a new section is created.

Balazs Halasy (01/02/2005 8:03 am)

Balazs Halasy (25/04/2005 9:50 am)


  • behavior not clearly described

    Consider an object X with multiple node assignment. What happens

    - if an ancester node with object Y of a node of the object X (not the main node) is assigned another section? The node of X should be changed to the new section, too. Are the other nodes of object X are assigned to this new section, too? (You only wrote that the other nodes of X are updated if the main node of X is changed.)

    - if an ancester node with object Y of the main node of object X is assigned another section. The main node is assigned to this new section, too. I guess this is included in "if the main node of an object with multiple node assignments is changed then the section ID of that object will be updated." Are the children of the other nodes of object X are changed, too?

    I hope my descriptions where clear :-)

    • Re: behavior not clearly described

      It would make more sense to implement sections at the node level, or, to allow objects to belong to more than one section.
  • Beware the STANDARD Section

    I recently made a mistake in that I edited the STANDARD section and did not fully consider the consequenses. I ticked all subsections which cascaded down the stadard section to the enitre site, messing up my section based security model.

    To remove this I had to re assign all my other sections to the right setting.

    Also is there a easier way of doing this (other thank thinking first!)
  • Different visual outputs for objects of a same Node/Section

    I haven't been able to solve a problem I am facing: I have built an index page that shows the titles of all the "children" (articles published within a given Node/Section), but I would like my index page to have one visual look and the children (the articles themselves) to have another look. Unfortunately, ez publish seems to link the looks of the index page to that of the final news pages should look -- if I change the index, it influences the children, and vice-versa.

    I see no reason why all the pages within a node/section should look the same. I am studying two alternatives: creating a node/section which contains all the index pages and other node/sections for the news articles, but I am not sure whether I can make an index page linked to one node/section go fetch the children of another node/section.

    Why is this problem important for me? Because my index page appears in a layout that has three columns (a left one, with a navigation menu; a center one, with the content, and a right one, with another navigation menu), whereas the final news pages have only two columns (the left menu and the content area, which expands further to the area where the right menu column was in order to open more space for the article to appear, since in some cases it comes accompanied with photos).

    How do I get around this problem? Will ez publish force me to have a single layout for both areas? Thanks a lot.