The import of nodetype information is a powerful feature which can make migrations much easier. But in every day import scenarios you may not want to allow nodetype modifications (and creations) via import. Therefore you should consider carefully which roles and rights you give to the sophora user the importer uses to connect to the sophora server. The modifications of nodetypes is bound to the sophora system right "administrator" - so if the importer user does not have this right, it is not possible to modify nodetypes.
It is possible to import nodetype definitions, default property configurations, default childnode configurations and nodetype configurations. Therefore, the root element of an import XML file has to be <sophora>
. If you want to import nodetype information you have to put the element <nodetypes>
as direct and first child element of <sophora>
.
The following table shows, which element you have to place inside the <nodetypes>
element in order to import the desired node type information:
Importing... | Element inside the element |
---|---|
Nodetype definitions (CNDs) | <nodetypeDefinitions> |
Default property configurations | <defaultPropertyConfigurations> |
Default childnode configurations | |
Nodetype configurations | <nodetypeConfigurations> |
Each of those four elements must have exactly one element as child, namely the element <data>
. The required attribute "specificationMethod" specifies how the data is represented: Either as file "reference" - in this case the text content of the element <data>
is just a (relative or absolute) file reference to the corresponding CND or XML file - or "inline". In the latter case the whole content of the CND file or the XML configuration file (including the inline DTD!) is placed as CDATA content in the element <data>
.
The first example shows the import of a nodetype definition (CND) via reference:
<?xml version="1.0" encoding="UTF-8"?>
<sophora xmlns="http://www.sophoracms.com/import/4.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<nodetypes>
<nodetypeDefinitions>
<data specificationMethod="reference">story.cnd</data>
</nodetypeDefinitions>
</nodetypes>
</sophora>
The referenced file story.cnd
has to lie in the same directory as the import XML file. Alternatively, you can specify a relative path like import/cnds/story.cnd
or an absolute path like file:C:/importer/import/cnds/story.cnd.
Due to security reasons a relative or an absolute path cannot reference a file in a higher folder hierarchy.
The second example has the same effect as the first example - but in this case the content of the beforehand referenced CND file is put inline in the sophora import XML document:
<?xml version="1.0" encoding="UTF-8"?>
<sophora xmlns="http://www.sophoracms.com/import/4.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<nodetypes>
<nodetypeDefinitions>
<data specificationMethod="inline"><![CDATA[<'content-nt'='http://www.content.de/content-nt/1.0'>
<'nt'='http://www.jcp.org/jcr/nt/1.0'>
<'content'='http://www.content.de/content/1.0'>
<'sophora-nt'='http://www.subshell.com/sophora-nt/1.0'>
['content-nt:story'] > nt:base
orderable
- content:emailContact (string)
- content:contentType (string)
- content:referenceDate (date)
+ content:broadcasts ('sophora-nt:reference') multiple]]></data>
</nodetypeDefinitions>
</nodetypes>
</sophora>
The next example shows the import of nodetype configurations via reference:
<?xml version="1.0" encoding="UTF-8"?>
<sophora xmlns="http://www.sophoracms.com/import/4.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<nodetypes>
<nodetypeConfigurations>
<data specificationMethod="reference">content-nt_storyRef.config.xml</data>
</nodetypeConfigurations>
</nodetypes>
</sophora>
In the following example the content of the config XML file of the previous example is put inline in the sophora import XML document:
<?xml version="1.0" encoding="UTF-8"?>
<sophora xmlns="http://www.sophoracms.com/import/4.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<nodetypes>
<nodetypeConfigurations>
<data specificationMethod="inline"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE descriptions [
<!ELEMENT descriptions (nodetype*)>
[...]
<!ATTLIST childnode summary (true|false) #IMPLIED>]>
<descriptions>
<nodetype name="content-nt:storyRef" authorisation="false" unsearchable="false">
<mixins />
<label>Artikelreferenz</label>
<searchResultProperties />
<referenceNodeTypes />
<variantValidChildNodeNames />
<icon>
<binarydata mimetype="image/gif">data:;base64,R0l [...]</binarydata>
</icon>
<displayTab name="system">
<property name="sophora:overridingProperties" />
<property name="sophora:reference" />
</displayTab>
<displayTab name="base">
<property name="content:headline" />
<property name="content:subHeadline" />
<property name="content:teaserHeadline" />
<property name="content:teaserText" />
<property name="content:teaserLabel" />
<property name="content:teaserIcon" />
<property name="content:teaserAttribute" />
<childnode name="content:teaserImages" summary="false">
<inputFieldType>com.subshell.sophora.eclipse.imageReferenceEditorComponent</inputFieldType>
</childnode>
</displayTab>
<displayTab name="meta">
<property name="sophora:endDate" />
<property name="sophora:startDate" />
</displayTab>
</nodetype>
</descriptions>]]></data>
</nodetypeConfigurations>
</nodetypes>
</sophora>
It is also possible to put the different kinds of nodetype modifications within one sophora XML document. Additionally you can have mutiple elements of the same kind of nodetype modification.
The following example shows this use case: Two different nodetype definitions are imported together with default property configurations, default childnode configurations and nodetype configurations. All data is specified by using file references - it would also be possible to use inline data or to mix the use of file references and inline data.
<?xml version="1.0" encoding="UTF-8"?>
<sophora xmlns="http://www.sophoracms.com/import/4.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<nodetypes>
<nodetypeDefinitions>
<data specificationMethod="reference">story.cnd</data>
</nodetypeDefinitions>
<nodetypeDefinitions>
<data specificationMethod="reference">image.cnd</data>
</nodetypeDefinitions>
<defaultPropertyConfigurations>
<data specificationMethod="reference">default_property_configurations.config.xml</data>
</defaultPropertyConfigurations>
<defaultChildnodeConfigurations>
<data specificationMethod="reference">default_childnode_configurations.config.xml</data>
</defaultChildnodeConfigurations>
<nodetypeConfigurations>
<data specificationMethod="reference">nodetype_configurations.config.xml</data>
</nodetypeConfigurations>
</nodetypes>
</sophora>
Merge with existing Nodetype Configuration
It is possible to import a nodetype configuration to update an existing one. In this case you will only need to provide the configuration entries you wish to update.
Such an XML might look like this:
<descriptions>
<nodetype name="sophora-content-nt:story" merge="true">
<mixins>sophora-mix:cronControl</mixins>
<label>Story New</label>
<displayTab name="meta">
<property name="sophora:cronNextOffDate" position="0">
<label />
</property>
<property name="sophora:cronNextOnDate" position="1">
<label />
</property>
<property name="sophora:cronOff" position="2">
<label />
</property>
<property name="sophora:cronOn" position="3">
<label />
</property>
</displayTab>
</nodetype>
</descriptions>
Note that you need to set the merge="true"
attribute to the nodetype
element to enable the merge feature. Otherwise a normal import will be performed which means that all absent configuration entries will be removed from the existing nodetype configuration.
The example above will do the following:
- add the mixin
sophora-mix:cronControl
to the nodetype - replace the label of the nodetype with the new label "Story New"
- add 4 new properties to the "meta" tab at the given positions
You may also add childnodes and groups in the same way.
- if the configuration entry can only hold a single value it will be overridden by the new value (e.g. label, description etc.)
- if the confifuration entry can hold multiple values the new value(s) will be added to the existing values (e.g. reference node types, mixins etc.)
- these rules also apply when form field configurations for properties and childnodes will be merged (e.g. label, input field types etc.)