PHPackages webcoast/migrator - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. webcoast/migrator ActiveTypo3-cms-extension[Utility & Helpers](/categories/utility) webcoast/migrator ================= Migration tool to convert DCE elements to content-blocks 01PHP Since Mar 6Pushed 2mo agoCompare [ Source](https://github.com/webcoast-dk/migrator)[ Packagist](https://packagist.org/packages/webcoast/migrator)[ RSS](/packages/webcoast-migrator/feed)WikiDiscussions main Synced 1mo ago READMEChangelogDependenciesVersions (1)Used By (0) Migrator (Core) =============== [](#migrator-core) This TYPO3 extension helps you migrate content elements from one content type to another, including the migration of the configuration. The `migrator` extension is only the core part, that provides the basic framework for building and executing migrations. Installation ------------ [](#installation) ``` composer require webcoast/migrator ``` Usually you wouldn't include the `migrator` extension in your project directly, but rather on of the extensions providing content type providers and/or content type builders, which should have the `migrator` extension as a dependency. Compatibility ------------- [](#compatibility) Migrator ↓ / TYPO3 →13.41.0.0✅Concept ------- [](#concept) The extension provides the necessary commands to migrate content element configurations and an upgrade wizard to execute the actual data migration. The framework uses different components to execute the migrations: Content type providers, content type builders and record data migrators. ### Content Type Providers [](#content-type-providers) Content type providers are responsible for providing a normalized configuration of a content type, that can be used to build a new content type. Furthermore, they provide the records' data in a normalized way, which is then handed over to the record data migrators, which execute the actual data migration. As time of writing, there are content type providers for DCE and Flux content elements available in separate extensions. You can easily write your own content type provider for your custom content types by implementing the `ContentTypeProviderInterface`. Classes implementing this interface are automatically registered as content type providers. **Important** When providing the normalized data for the data migration, data for file fields should be provided as instances of `TYPO3\CMS\Core\Resource\File` for legacy file fields (type=group and internal\_type=file or type=group and internal\_type=db), where no file reference record exist yet, and `TYPO3\CMS\Core\Resource\FileReference` for modern file fields (type=file or type=inline and foreign\_table=sys\_file\_reference), where a file reference record already exists. ### Content Type Builders [](#content-type-builders) Content type builders are responsible for building a new content type configuration based on the normalized configuration provided by a content type provider. They are part of the interactive migration wizard, which guides you through the process of migrating content type configurations. Each content type builder may ask the user for additional information, which is necessary to build the new content type configuration. The supported options and source content types may differ depending on the content type builder. Please see the documentation of the respective content type builders for more information. As time of writing, there are content type builders for Content Blocks and Container available in separate extensions. You can write your own content type builder by implementing the `ContentTypeBuilderInterface`. All classes implementing that interface and are automatically registered as content type builders. ### Record Data Migrators [](#record-data-migrators) Record data migrators are responsible for executing the actual data migration. They receive the normalized data of a record provided by a content type provider and must return an array structure compatible with the TYPO3 DataHandler, which is then used to update the record. Both data map and command map are used, so you can update the record data, add new records, move records and even translate them, if necessary. Record data migrations must extend the abstract `RecordDataMigrator` class. All classes extending that class and are automatically registered as record data migrators. For a more in-depth documentation of the record data migrators, please see the respective section about the [Upgrade Wizard](#upgrade-wizard-record-data-migration) below. Commands -------- [](#commands) The extension provides the following commands: CommandDescription`migrator:provider:list`List all registered content type providers`migrator:content-types:list`List all content types provided by the registered content type providers`migrator:config:from`Executes the interactive migration wizard to migrate content type configurationsThey can be executed as Symfony Console commands, like ``` ./vendor/bin/typo3 {command} ``` Upgrade Wizard (Record data migration) -------------------------------------- [](#upgrade-wizard-record-data-migration) The extension provides an upgrade wizard to execute the actual data migration. The upgrade wizard is available in the TYPO3 Install Tool and via the command `upgrade:list`and `upgrade:run`. The upgrade wizard itself does not execute any migration, but executes all registered record data migrators. Record data migratiors are classes, that extend the `RecordDataMigrator` class. They must have at least one `SourceContentType` attribute, which defines the source content type(s), that record data migrator can handle. The `SourceContentType` attribute has two properties: `providerIdentifier` and `contentType`. The `contentType` is used to fetch the records to migrate, while the `providerIdentifier` is used to get the normalized data of the records, which is then handed over to the `migrate` method of the record data migrator. **Examples:** - `#[SourceContentType('dce', 'dce_dceuid12')]` would migrate records with CType `dce_dceuid12` and fetch the normalized data from the content type provider with the identifier `dce`. - `#[SourceContentType('flux', 'sitepackage_mycontentelement')]` would migrate records with CType `sitepackage_mycontentelement` and fetch the normalized data from the content type provider with the identifier `flux`. The `migrate` method of the record data migrator receives two parameters: `$incomingData` and `$record`. The `$incomingData` is the normalized data of the record, provided by the content type provider, while the `$record` is the original record data as an associative array. The `migrate` method must return an associative array, with a structure compatible with the TYPO3 DataHandler, which is then used to update the record. **Important:** The returned data must contain the key `CType` with the new content type. It is possible to return different content types with different fields from the same record data migrator, e.g. depending on a layout field in the source content element. This can be used to split existing content elements into different content types, e.g a content element with a specific layout is migrated to a new content type, while the other records with the same source content type but different layout are migrated to another content type. The following example shows a record data migrator, that handles both a DCE and Flux content type and migrates them to a new content type `sitepackage_slider`. The elements, which may have been a section in the DCE or Flux content element, are migrated to images instead. ```