Other recipes

Assigning Section to content

The Section that a Content item belongs to can be set during creation, using the ContentCreateStruct::$sectionId property. However, as for many Repository objects properties, the Section can't be changed using a ContentUpdateStruct. The reason is still the same: changing a Content item's Section will affect the subtrees referenced by its Locations. For this reason, it is required that you use the SectionService to change the Section of a Content item.

This operation involves the SectionService, as well as the ContentService.

We use ContentService::loadContentInfo() to get the Content we want to update the Section for.

SectionService::loadSection() is then used to load the Section we want to assign our Content to. Note that there is no SectionInfo object. Sections are quite simple, and we don't need to separate their metadata from their actual data. However, SectionCreateStruct and SectionUpdateStruct objects must still be used to create and update Sections.

The actual update operation is done using SectionService::assignSection(), with the ContentInfo and the Section as arguments.

Creating a Content Type

Creating a ContentType is actually almost more complex than creating Content. It really isn't as common, and didn't "deserve" the same kind of API as Content did.

Let's split the code in three major parts.

First, we need to load the ContentTypeGroup our ContentType will be created in. We do this using ContentTypeService::loadContentTypeGroupByIdentifier(), which gives us back a ContentTypeGroup object. As for content, we then request a ContentTypeCreateStruct from the ContentTypeService, using ContentTypeService::newContentTypeCreateStruct(), with the desired identifier as the argument. 

Using the create struct's properties, we can set the Type's properties:

• the main language (mainLanguageCode) for the Type is set to eng-GB,
• the content name generation pattern (nameSchema) is set to '<title>': Content items of this type will be named the same as their 'title' field.
• the human-readable name for our Type is set using the names property. We give it a hash, indexed by the locale ('eng-GB') the name is set in. This locale must exist in the system.
• the same way that we have set the names property, we can set human-readable descriptions, again as hashes indexed by locale code.

The next big part is to add FieldDefinition objects to our Content Type.

We need to create a FieldDefinitionCreateStruct object for each FieldDefinition our ContentType will be made of. Those objects are obtained using ContentTypeService::newFieldDefinitionCreateStruct(). This method expects the FieldDefinition identifier and its type as arguments. The identifiers match the ones from eZ Publish 4 (ezstring for TextLine, etc.).

Each field's properties are set using the create struct's properties:

• names and descriptions are set using hashes indexed by the locale code, and with the name or description as an argument.
• The fieldGroup is set to 'content'
• Fields are ordered using the position property, ordered numerically in ascending order. We set it to an integer.
• The translatable, required and searchable boolean flags are set using their respective property: isTranslatable, isRequired and isSearchable.

Once the properties for each create struct are set, the field is added to the Content Type create struct using ContentTypeCreateStruct::addFieldDefinition().

The last step is the same as for Content: we create a Content Type draft using ContentTypeService::createContentType(), with the ContentTypeCreateStruct and an array of ContentTypeGroup objects are arguments. We then publish the Content Type draft using ContentTypeService::publishContentTypeDraft().