Magnolia 5.4 reached end of life on November 15, 2018. This branch is no longer supported, see End-of-life policy.
Importing and exporting content and data is useful when migrating content from one system to another, taking a backup or bringing in a custom taxonomy. The default file format for content exports is JCR System View XML. The tools available range from a quick right-click export to scripting and writing custom import handlers depending on the frequency of use.
Magnolia exports JCR data to JCR System View XML format by default. Imported XML files must also adhere to the same format. The exported XML reflects the hierarchy of the data in the repository. File name matches the path of the data in the repository such as website.travel.tour.xml
. When you export a node its children are also exported.
You can export JCR data from the YAML export is only available for definition items: The Export to YAML action is disabled for other items. When using YAML files originating from export, you might have to change the file name if you want to use it within a module; for instance the name of the YAML file defining an app must reflect the app name with the pattern config
workspace to YAML. This is useful for moving from repository-based configuration to file-based configuration.<app-name>.yaml
.
You can import and export nodes from most workspaces with the Import and Export actions. They are available in the action bar and in the context menu (right-click).
The actions use the import
and export
commands to export and import XML. When you import a file the imported nodes become children of the selected parent node. The commands are configured in the ui-admincentral
module and implemented in
ImportCommand
and
ExportCommand
classes.
To export XML:
To import XML:
If a node in the incoming file has an ID (UUID) that is already used in the repository, the imported UUID will be changed.
You can upload a ZIP file in the Asset app. See the Export tool on how to export content to a ZIP file.
To import a ZIP file:
In Magnolia 5.4.6+ the JCR Tools app replaces the earlier legacy apps Export app, Import app and Query app.
The import and export tools allow you to operate on data in all Magnolia workspaces, including those where the Export and Import actions are not available in the workspace-specific app, for example in the Forums and Security apps.
To export:
To import:
In the Content Translation app can import and export page content in Excel, CSV, ZIP and Google Spreadsheet formats. When open the exported Google Spreadsheet in Google Drive is machine-translated automatically.
You can export content from Magnolia using a Groovy script. This example exports the about
page and its children. The script is equivalent to selecting the about
page and using the Export command.
import info.magnolia.importexport.DataTransporter hm = ctx.getHierarchyManager('website') aboutRoot = hm.getContent('/travel/about') xmlFileOutput = new FileOutputStream('C:/test/export/about.xml') DataTransporter.executeExport(xmlFileOutput, false, false, hm.getWorkspace().getSession(), aboutRoot.getHandle(), 'website', DataTransporter.XML) xmlFileOutput.close()
Similarly, you can import content with a Groovy script. This example imports the XML for the careers
page and its children. The script is equivalent to selecting the parent page about
and using the Import command.
import info.magnolia.importexport.DataTransporter import javax.jcr.ImportUUIDBehavior hm = ctx.getHierarchyManager('website') aboutRoot = hm.getContent('/travel/about') xmlFile = new File('C:/test/export/about.xml') DataTransporter.importFile(xmlFile, 'website', aboutRoot.getHandle(), false, ImportUUIDBehavior.IMPORT_UUID_CREATE_NEW, true, true)
For more information on Groovy see Groovy module. The
DataTransporter
utility class explains the parameters for the executeExport
and importFile
methods.
The import and export functionality is implemented in the info.magnolia.importexport
package. This implementation is mostly contained in the DataTransporter
and PropertiesImportExport
classes. You can invoke methods in these classes from your own class.
Here is an example of implementing the executeExport
method:
File xmlFile = new File(folder.getAbsoluteFile(), xmlName); FileOutputStream fos = new FileOutputStream(xmlFile); try { DataTransporter.executeExport(fos, false, false, MgnlContext.getHierarchyManager(repository).getWorkspace().getSession(), node.getHandle(), repository, DataTransporter.XML); } finally { IOUtils.closeQuietly(fos);}
These classes will not complete the import for any UUIDs that are identical to existing UUIDs.
Here are cases when importing and exporting is useful.
You can accomplish site migration in a number of ways.
You can back up content by exporting it to XML and store the files in a disaster recovery system. The file name is the path of the exported data, making identification easier.
The Backup module is an alternative to file system and database backup solutions. With the module you can take manual and scheduled backups.
How to import tags depends on the size and format of the taxonomy. It also depends on whether you need to do it once or repeatedly. If the taxonomy does not need to be added repeatedly and its size is reasonable, create the tags manually in the Categories app. If the taxonomy is large, import the tags as mgnl:category
content type into the category
workspace and use the Categories app to manage them, or create your own content app and content types.
Taxonomy size | Import frequency | Recommendation |
Small | Once | Create the taxonomy by hand. Use the existing mgnl:category content type in the Categories app. If that content type does not work for you, register a new content type in your module descriptor. While you are at it, register a new workspace too. |
Large | Once | Write a groovy script. |
Large | Repeatedly | Write a groovy script and create a command that executes it so that editors can run the process at will or that you can schedule it. |
Copying production data to a test or development environment is a task you may need to do regularly. You should test new templates and features with realistic content before releasing them production. Here are strategies for prod-to-test exporting.
Transfer the data and the JCR Datastore (all binaries in the file system) to the test instance.
In production:
In test:
|
|
Use the Backup and restore JSP scripts. This option is a quick win as you can be use it without any development and without having to restart the system. Export only the data you need in test. Define the exported content in the JSP, for example:
public void run() { MgnlContext.setInstance(MgnlContext.getSystemContext()); try{ backupChildren(ContentRepository.WEBSITE, "/travel"); backupChildren("dms", "/"); backupChildren("data", "/products"); backupChildren(ContentRepository.USERS, "/admin"); backupChildren(ContentRepository.USERS, "/system"); backupChildren(ContentRepository.USER_GROUPS, "/"); backupChildren(ContentRepository.USER_ROLES, "/"); // backupChildren(ContentRepository.CONFIG, "/modules"); // backupChildren(ContentRepository.CONFIG, "/server"); } catch(Exception e) { logMsg("can't backup", e); } finally { // nothing to do here } logMsg("backup completed"); }
In production:
Use for example a shell script to copy the exports from the production server to the test server.
In test:
|
|
Magnolia's own export command is more flexible but still very comparable to the Jackrabbit JCR import/export tool. You can also use the tool in combination with the Scheduler module or trigger it from any other Java process.
In production:
In test:
|
|