Page tree
Skip to end of metadata
Go to start of metadata

This page describes the current migration support of the data module, as of Magnolia 5.2.1.



What is in 5.2
  • We configure content-apps for all existing types in the data module
  • We use detail subapps to create/edit new entries
  • We also migrate default data-module-based Company type for fresh install
    • We don't migrate Contact and category, those are already migrated
    • We don't migrate RssAggregator, module is currently being migrated to its own workspace
  • We drop legacy admininterface classes and config
    • where we provide proper replacement and migration to this replacement
What is NOT in 5.2
  • We don't move content to new workspaces
  • We don't change ACLs consequently
  • We don't have an app to manage custom types


Migration concretes

1. Dialogs
  • (tick) We migrated Types dialog definitions to 5.0 dialogs
    • and refer to their inner form from the data-types detail subapps
2. Content apps
  • (tick) We created migration tasks for creating content apps based on dataTypes
    1. creating basic app definition with a task + appLauncherLayout entry
    2. create browser subapps (workbench)
    3. add browser "default" actions + availability (edit)
    4. create detail subapps, link to dialogs' inner form definitions
    5. add actions to create items with different types
3. Multiple hierarchical types
  • (tick) We open the right subapp based on selected item type
  • (tick) For creation, we have multiple add actions for each available item type, displayed based on action availability
4. Mixin supertypes for data nodeTypes
  • If mixins are missing, nodes are not decorated with LastUpdateContentDecorator, and lastModified properties are not updated
  • (tick) Node-types migrated:
    • dataBase - added mgnl:created, mgnl:lastModified supertypes
    • dataItem - added mgnl:activatable, mgnl:versionable supertypes
    • dataItemNode - added mgnl:activatable supertype
    • dataFolder - added mgnl:activatable supertype
5. Legacy code and configuration
  • (tick) We removed old DataModule 2.x legacy apps (as seen until Magnolia 5.1)
  • (tick) We removed legacy GUI classes and config (trees, pages)


Cleanup of legacy UI classes and config

ElementsAffected sourcesAffected configChanges / ReplacementMigration
 (minus) adminInterface 
  • @Deprecate getIcon()
  •  configure icons in workbench nodeTypes instead
  • (question) deprecate whole class? 
  (minus) server.URI2RepositoryMapping.mappings.dataModuleTypeImagesno longer used  
  • Activation commands which need to be based on itemTypes should have this property configured on the command itself.
    • This might involve using a specific command catalog for each tree that was previously configuring itemTypes.
    • The activation actions in browser subapp should then set the catalog property accordingly.
    • (warning) We should also do the same for versioning actions
    • (warning) We don't migrate this automatically
    • Ideally in the future, such behavior is driven directly by node-types (e.g. mgnl:content vs. mgnl:contentNode)
  • The data commands which activate/deactivate "All" are no longer used
    • one may configure or implement bulk actions instead
    • see info.magnolia.ui.framework.action.AbstractMultiItemAction

(minus) TypeActivateCommand
(minus) TypeDeleteCommand


Replaced with plain activation of data/apps and appLauncherLayout

Controls(minus)*(minus)*Replaced with fields(tick)



 Migrator exists(tick)


 Support of migration to UploadField is unlikely to land in 5.2(warning)


 No longer required 
  • No longer required, uses multi-value transformers instead
  • Post-save actions should be migrated to info.magnolia.ui.form.EditorCallback


  • Dialogs for types are migrated to the 5.x style
  •  TypeSelectDataDialog has been replaced with multiple actions + availability in browser subapps
  • Creating data types on the fly no longer supported
    • This will be replaced with a content-app creator in the future
    • For the time being, one may still create types at runtime via groovy, and configure content apps accordingly.
Import  No changes 

(minus) mgnl-resources/js-classes/mgnl/data/DataTree.js
(minus) mgnl-resources/js-classes/mgnl/data/TypeTree.js 

(minus)*Replaced with content apps(tick)

(minus) info/magnolia/module/data/lists/DataAwareInbox.html

(minus)*Replaced with versioning actions in content apps(tick) @Deprecate the whole class:
  • Since 5.2, handling of multiple values is done at field level by setting property transformers
  • We no longer configure legacy dialogs for data module
  • TypeDefinitions are solely used initially for migration to content apps.



  • Move and split app creation tasks to ui content app?
  • Do customers prefer:
    • auto-upgrade of custom datatypes with less control (e.g. icons)
    • manual upgrade of custom datatypes with more control, but via groovy
    • still defaults to all but you can pass additional config
    • can we run such a migration twice to refine resulting app
  • Dialog migration
    • i18n, where does it come from? old i18nBasename still supported?
    • missing label and description for e.g. company dialog






  • No labels

1 Comment

  1. What is NOT in 5.2 will be in 5.2.x?

    And what about the content if it is not moved?