How does the publish process work?

The publish process will bring the content online. It is started by a scheduler task and runs in the background.

1 What will be published

The publish process will publish pages, files, images and folders that are scheduled to be published (“dirted”) and will remove objects that were deleted or should no longer be online for other reasons. Whether to publish pages, files/images and/or folders can be configured for each node in the node settings.

An object is scheduled to be (re-)published if

  • The object is new and (in case of pages) “published” by an editor
  • The object itself was changed (and “published”)
  • Another object was changed that influences the rendered output of the object
  • The object was scheduled to be republished using the content maintenance
  • The object is a page and has to be (re-)published due to time management.
  • The object is an image or file and has to be published due to the feature file publish dependencies

Objects will be removed from the online content if

  • The object was deleted
  • The object is a page and was taken offline by an editor
  • The object is a page and was to be taken offline due to time management.
  • The object is an image or file and has to be taken offline due to the feature file publish dependencies

Objects will not be changed in their online status (although they were dirted) if

  • Publishing of the object was delayed using the content maintenance
  • The node containing the object has updating the contentmap/filesystem deactivated

1.1 Status

  • Offline – the page will be taken offline if it is currently online.
  • Being edited (online) – someone is currently editing the page. The latest published version will be accessible online.
  • Being edited (offline) – someone is currently editing the page. The page will be taken offline if it is currently online.
  • Published – the page will be published.

2 Where online content goes to

Content can be published into the filesystem or into a database (content repository) or both.

The target of the publish process can be defined for every node individually.

3 Phases of the publish process

3.1 Waiting for dirt events

The publish process needs to wait until all pending dirt events have been handled.

3.2 Initialization

In this phase, the publish process collects data for calculation of the expected publish duration.

3.3 Synchronize Object Types

Changes made in the tagmap of Content Repositories are written into the Content Repository Databases.

3.4 Delete old Objects from Content Repository

Objects, that are removed from the backend (or pages taken offline) are removed from the Content Repositories.

3.5 Publish Files and Folders into Content Repository

Files, images and folders are published into the Content Repositories if enabled.

3.6 Rendering pages

All pages, that need to be republished are rendered, the content is stored in the backend database and also written into Content Repositories (if configured). This is the only phase, that uses multiple parallel threads for rendering if the feature multithreaded publishing is activated. Saving the changes is synchronized to avoid possible DB locking problems.

3.7 Checking online status of images and files

In this phase, images and files will be checked, whether they need to be online or not. When the feature file publish dependencies is used, some images or files may have to be taken offline in this phase, dependening on whether they are referenced in any page.

This phase will done in every publish process, even if the feature file publish dependencies is not used.

3.8 Writing Pages and Files into Filesystem

All pages, images and files are written into the filesystem, if configured in the node settings.

Writing the objects into the filesystem will be done completely (not incrementally) for all online objects, even if nothing changed or updating the contentmap/filesystem was deactivated for the node.

3.9 Invoking GenticsImageStore

The contents of all pages is scanned for GenticsImageStore URLs. The images are resized (if not found in the Cache) and the resized images are written into the filesystem.

3.10 Finalizing

The database transactions are committed and final cleanup is done.

4 Multithreaded publishing

Activating the feature multithreaded publishing can significantly improve the publish performance on systems with multiple cores or multiple processors.

5 URL rendering

There are a few options how URLs to pages and files/images are rendered. This can be configured for each node individually for pages and files:

  • Automatic – The way the URL is rendered will be chosen automatically, depending on if the object is published into the FS or CR and if it is in the same node or not.
  • Portal-Links (<plink>) – Portal.Node URLs. example: <plink contentid=“10007.123”>
  • Static URLs (dynamic) – Static URL that is absolute (with domain) or relative (without domain) depending on if the target is in the same node or not.
  • Static URLs with domain – Absolute URL
  • Static URLs without domain – Relative URL

This setting only affects links to this node, and not links from this node.