ibexa

Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.

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.

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)


Comments

  • 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 :-)

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