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.

Sections

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:

ID

Name

Description

1

Standard

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

2

Users

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.

3

Media

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

4

Setup

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.

Behavior

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.

Note that sections are also used to offer enhancements to the UI. For example, objects in the Users section will have Roles and Policies available in the admin panel. Moving a User object to a different section will make this information unavailable.

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 (14/09/2010 10:56 am)

Dominika Kurek (23/05/2017 7:38 am)

Geir Arne Waaler, Dominika Kurek


Comments

  • 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.