Assigning section to content
The Section a Content 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'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.
This operation involves the
SectionService, as well as the
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,
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.
SectionService::assignSection() won't return the updated Content, as it has no knowledge of those objects. To get the Content with the newly assigned Location, you need to reload the ContentInfo using
ContentService::loadContentInfo(). This is also valid for descendants of Content. If you have any stored in your execution state, you need to reload them. Otherwise you would be using outdated Content data.
Creating a content type
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
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::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 of this type will be named as their 'title' field.
- the human readable name for our type is set using the
namesproperty. 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
namesproperty, we can set human readable descriptions, again as hashes indexed by locale code.
The next big part is to add FieldDefinition objects to our ContentType.
We need to create a
FieldDefinitionCreateStruct object for each
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:
descriptionsare set using hashes indexed by the locale code, and with the name or description as an argument.
fieldGroupis set to 'content'
- Fields are ordered using the
positionproperty, ordered numerically in ascending order. We set it to an integer.
- The translatable, required ans searchable boolean flags are set using their respective property:
Once the properties for each create struct are set, the field is added to the ContentType create struct using
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 ContentType draft using