Importing, exporting, and promoting content
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.
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 thejahia.site.import.scanner.interval
property in the jahia.properties file. The default value is 30000ms.
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.
or
- 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.
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).