Global navigation

   Documentation Center
   eZ Studio & eZ Platform
     User Manual
     Technical Manual
     Glossary
   eZ Publish 4.x / legacy

 
eZ Publish (5.x)

eZ Publish 5.x | For eZ Platform & eZ Studio topics see Technical manual and User manual, for eZ Publish 4.x and Legacy topics see eZ Publish legacy

Skip to end of metadata
Go to start of metadata

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.

assign section to content

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

assign section to content

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

assign section to content

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.

assign section to content

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

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 of this type will be named 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 ContentType.

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 ans 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 ContentType 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 ContentType draft using ContentTypeService::publishContentTypeDraft().

3 Comments

  1. Unknown User (krieftm)

    When you want to add a more complex fieldtype to a contenttype through public api, you may have to pass the mandatory fieldSettings.

    This example is for the Page-Fieldtype:

    $field = $contentTypeService->newFieldDefinitionCreateStruct('layout', 'ezpage');
    $field->names = ['eng-GB' => 'Layout'];
    $field->position = $pos;
    $field->isRequired = false;
    $field->isSearchable = false;
    $field->fieldSettings = [
     'defaultLayout' => 'IAmTheLayoutFromTheYml',
    ];

    Also notable is here that you can add a field of the type ezpage, although the public api for contents of this field-type is read only by now.

  2. Unknown User (nmharald)

    Worth noting that loadContentTypeGroupByIdentifier's parameter is casesensitive, which mean that this will throw an exception on a default installation:

    $contentTypeService->loadContentTypeGroupByIdentifier( 'content' );

    Might want to change content to Content, as examples like this might be expected to work out of the box.

  3. Unknown User (krieftm)

    Just came across this again:

    Example additional properties for Selection-type (legacy: ezselection):

    $fieldDefinitionCreateStruct->fieldSettings = [

     'isMultiple' => false,
     'options' => [
     1 => 'Option 1',
      2 => 'Option 2'
     ]
    ];

    You can see how it works here: vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/FieldType/Selection/Type.php#35 Also see this resource: The Selection FieldType