Content is created and maintained in Gentics CMS component of the Gentics Content Management Platform, which is also responsible for saving content that has been published by a content manager into a Gentics Mesh Content Repository. Only content that has been published can be accessed in the frontend.
For Gentics CMS to be able to publish a node into a Gentics Mesh Content Repository the following features and settings are necessary:
Gentics CMS feature Gentics Mesh Content Repository must be enabled
Gentics CMS feature Publish Directory Segments must be enabled and active for the project’s node
Gentics Mesh Content Repository must be configured and the project’s node must be configured to use it as a Content Repository
The following settings are specific to Gentics Mesh Content Repositories.
Since the actual markup is bundled with the portal serving the content, Gentics CMS cannot render pages in preview or edit mode without the frontend. The Mesh Preview URL setting has to be set to the preview endpoint of the portal that will deliver the published content.
Permissions in Gentics Mesh are handled via roles. Gentics CMS can be configured to set permissions on published objects so that only users who have at least one of the listed roles can access them.
The permissions are set by an editor via a page property which contains a select part type for a datasource. Gentics CMS will automatically load the available roles from Gentics Mesh[1] and fill the respective datasource accordingly.
Two settings control how the Gentics CMS assigns Gentics Mesh roles to published object:
Roles Object Property: the name of the Object Property used to set the permissions by an editor
Default Role: the name of the role assigned to objects for which the above mentioned Object Property is not set[2]
| The specified Default Role must already exist in Gentics Mesh, otherwise the publishing process will fail. |
The cr_identifier part in the Gentics Mesh Content Repository’s
connection URL
determines the names of the Gentics Mesh
Schemas created by Gentics CMS
during publication. When the cr_identifier is for example MyProject,
Gentics CMS will create the following schemas for publishing pages, folders and files
respectively:
MyProject_content
MyProject_folder, and
MyProject_binary_content
When the
Project per Node
setting is active, several nodes can be published in the same Gentics Mesh Content Repository.
This only makes sense when these nodes are similar enough that they can use the
same Gentics Mesh Schemas.
The project names in Gentics Mesh Content Repository will then be the name of the nodes.
Without the Project per Node setting, the project name in Gentics Mesh Content Repository will be exactly
the cr_identifier from the Content Repository configuration.
| Restrictions exist when using Multichannelling, please check the documentation! |
Assigning multiple nodes in Gentics CMS to the same Gentics Mesh Content Repository without activating Project per Node is not recommended.
Setting an implementation version will cause the published objects to be stored in a new branch in Gentics Mesh. This way, the frontend services can still serve the current content, while content with a new implementation is being prepared.
Gentics Mesh will create one Elasticsearch index per schema and branch, and Gentics CMS will create the above mentioned schemas for pages, folders and files. Any special analyzers to be used in mappings need to be defined here for pages, folders and files — an example can be found in the CMS documentation.
Objects are either published during a regular publish run, or immediately when published by a user (when the Instant Publishing feature is activated for the Content Repository).
Only objects which have been published can be served to clients by the frontend portals. Depending on the configuration of Gentics Portal | php or Gentics Portal | java, due to caching there might be a slight delay for changes to be visible in the frontend.
Typically, during a publish run Gentics CMS will:
calculate dependencies to check which objects need to be (re-)published
render published pages
write the rendered data into Gentics Mesh Content Repository
perform clean-up tasks
Note that this is a simplified list of phases during a publish run and they are not strictly in this order (for example calculating dependencies can again become necessary, during another phase).[3] Furthermore, dependency calculation and clean up are limited when an object is published using Instant Publishing.
The scheduler of Gentics CMS will start a publish run in regular intervals (which can be configured, and typically range from every minute to every 15 minutes).
During a regular publish run, Gentics CMS will perform a thorough dependeny check to see if any changed attributes of an object are referenced in another object, so the other object has to be republished as well. For example, when the title of a page has changed, and this title is rendered in an overview published in another page. In this case, even when the page with the overview was not edited, it will be republished, because a dependency was modified and it needs to be rendered again.
Furthermore, all objects which should no longer be online will be removed from the Gentics Mesh Content Repository.
When the Instant Publishing feature is active in the Gentics Mesh Content Repository, the page will be rendered and written to Gentics Mesh immediately when a user with the necessary permissions sets its status to published (respectively the page will be removed from Gentics Mesh immediately when the page is taken offline).
Only minimal dependency checks are performed at this time, whether it is necessary to republish other objects, — the full check is performed during the next regular publish run. When a page is instant-published, the dependency checks will make sure that
the folder structure for the page is published
any files linked by the page are online[4]
Especially no indirect dependencies will be handled during instant publishing (because the necessary overhead would defeat the purpose of it). Since an instant-published page will also be marked to be published during the next regular publish run, those dependencies will be handled then.
A page can not only be published right now, or during the next publish run, but the publication can be scheduled ahead of time using Time Management feature, where a content manager can specify at which date and time the page should go online and optionally, when it should be taken offline again.
When a page is scheduled for being published at a specific time, a new major version of the page will be created immediately. When the scheduled time is reached, exactly this version of the page will be published, even if the page was modified afterwards.
Note that publishing the page after time management has been configured (or changing the time management settings for the page) will override the time management settings for it (the UI will warn about this though).
The Gentics CMS publishes data for pages, folders, and files (or images) defined in the Gentics Mesh Content Repository tagmap. These tagmap entries reference attributes of pages, folders, or files and will for the most part be made up from tags and object properties.
It is important to note, that while folders and files will always be published[5] when they are created or modified. Pages are only published when being triggered by the user.
The names of folders and pages do not have a one-to-one relation to a page’s final URL. There must be a tagmap entry for pages, folders and files which is marked as segment field. Normally, this will be the path segment for folders, and the filename for pages and files (other setups are possible but would be prone to problems with URL generation, e.g. uniqueness constraints).
When a page contains a link to another page (or a file/image), the correct URL for the target is resolved when the page containing the link is rendered. Gentics CMS only stores a special reference to the other object in Gentics Mesh, so changing for example the filename of a page, does not necessarily mean that other pages that link to the changed page have to be published again.
Since the actual URL generation is not done by Gentics CMS it is important to leave the URL rendering setting of the node to Automatic.
The final URL will be comprised from the nodes configured host as well as the values in the path segment tagmap entries of the object itself and its parent objects.
See How does the publish process work? in the Gentics CMS documentation