Importing, exporting, and promoting content

Written by The Jahia Team

You are looking at documentation for an older release. Not what you want? See the current release documentation.

This topic present best practices for managing content and configurations across multiple environments (development, integration, pre-production, production).

Jahia, in the course of content creation and editing, guarantees the integrity of editorial content (staging, default workspace) and the isolation of published content (live workspace). This is accomplished in the same environment thanks to strictly compartmentalized system of two workspaces. This architecture makes it possible to create and edit content directly on the production environment without the risk of making non-finalized content available on the live site.

Content is created and edited directly on the production environment then made available on other environments on an as needed basis. The process to propagate content between environments is described later in this topic.

Content export and import

Content of a site can be exported or imported through different ways. Every method offers advantages and drawbacks answering to different needs, especially in terms of automating, performances and granularity.

The environments used for export and import operations must run the same Jahia version and the same started module versions.

Platform export and import

Export

An export at the system level can be carried out using the following steps:

Export the Tomcat and the following folders: digital-factory-data and digital-factory-config
Export of the datastore (only if the binary content is stored in the default file system)
Export of the database

The order of these steps is important to guarantee data integrity.

Import

The following shows the procedure to restore from backup:

Restore Tomcat
Restore the digital-factory-data and digital-factory-config folders
Restore the datastore (if applicable)
Restore the database
Modify the datasource definition in tomcat/webapps/root/META-INF/context.xml

In clustered instance the following values may need to be modified in /digital-factory-config/jahia/jahia.node.properties file:

processingServer must be set to true on the processing server (and only on this node)
cluster.tcp.bindAddress must be set with the IP address where the server will listen to TCP communication.
cluster.tcp.bindPort must specify the port used for the server TCP socket

Exporting and importing a site

Export

Jahia provides the possibility of exporting an entire site or a specific arborescence. This export can be done in one of two ways:

Directly from the Web project administration panel
Through calling a URL (available for automating backups)

Import

There are two ways to import a site zip file:

Directly from the Web project administration panel
By dropping exported site zip file in the digital-factory-data/imports folder
Starting from DX 7.3.1.0, a validation of the import is performed before processing the import (no validation is done on Jahia versions prior to DX 7.3.1.0). If an error occurs during the validation, the import will be terminated and an email will be sent to the notify the server administrator of the import failure reasons. Note that the errors will also be available in the logs/jahia-errors folder.
It is possible to skip the import validation by adding -novalidation.zip at the end of the import zip file name. Jahia will force the import of the site in this case, bypassing potentially critical errors. For instance, if the required template set is missing, the force import procedure will use the first available template set, which means that the site will have a different look and feel and some content might not be visible anymore.

You can change the frequency where Jahia will watch for import zip files in the digital-factory-data/imports folder by modifying the value of the jahia.site.import.scanner.interval property in the jahia.properties file. The default value is 30000ms.

You can only import a web project that was previously exported in the same version of Jahia. Please note that the target Jahia needs to have the modules in the same version as the server used for the export. It is possible to have newer module versions on the target Jahia, if these versions are backward compatible with the version used for the export.

Partial export and import

Jahia allows an export or import based on the subtree of a content node as well as a single node of the tree. This is a manual action that is started from, the Editor Mode or from one of the Manager UI (Content Manager, File Manager, etc).

To export a node and its subnodes; right click on the node in the Editor Mode and select “Export” from the menu.

Recommendations and limitations

Recommendations

The environment for content contribution should always be the production environment:

The automatic merging of content from multiple environments is not possible
User Generated Content (comments, ratings, etc) can be created directly on the live workspace

This content can then be broadcast over different environments using methods described in this documentation.

Limitations

An exported content item will be compatible with an environment if:

The version of the deployed modules in both environments are identical.

The modules deployed in this environment support the backwards compatibility of the node definitions. (See the Jahia Development best practice documentation).

Use case

Intializing content

Initial creation of content can be done in two different ways:

Creation of the content in the testing environment, then export and subsequently importing into the Production environment.
Direct creation in the Production Environment

Regardless of the method used, it is recommended to consistently keep content contribution in a single environment.

Automating content synchronization from production environments

Several methods of export and import can be automated to allow sync of content from one environment to another.

Methodology

The automation of content replication is trivial and can use the same mechanisms that are outlined in the production server backup procedure

The automation of the replication procedure can be done as follows:

Export

Command wget
http://<Serverip>:<port>/cms/export/default/{siteKey}.zip?exportformat=site&live=true&sitebox={siteKey} --http- user=root --http-password={ROOT_PASSWORD} --auth-no-challenge

Import

Copy the exported file to the digital-factory-data/imports folder on the destination platform.

Note: To avoid duplication of content, Jahia blocks any imports whose names conflict with any zip file name previously imported. It is needed to append a timestamp or version number onto the imported zip file.

The automated import of a site does not overwrite the previous version of the site if it still exists on this platform. It is necessary to remove the previous version first. This action can be automated using a groovy script.

How often to replicate

How often to replicate content depends on the needs of the particular organization. The following list shows common restrictions and constraints when choosing a replication schedule:

Daily replication can result in increased restrictions or workload for developers and testers. This could result in loss of content used in integration/test environment
Replication each week or month can induce too much latency, making it hard for developers to replicate issues found on other environments
Ad-hoc replication is a manual action

A compromise must be found between these different restrictions and risks.

Content related to environment

The import of technical content via a module is made thanks to the src/main/import/repository.xml file in the module. The repository.xml file, containing the standard JCR data tree, can be automatically generated using a partial export of the content. (See the section on import methodology).