Support setting content main location; better support for eZTags v3 bundle

• New: references are now resolved in validator-configuration settings for content type definitions. This is useful eg. when using the eZTags v3 bundle

• New: allow to set content main location

A couple of bugfixes

• Fix: allow usage with Solr as default search engine for migration steps matching contents or locations

• Fix: allow usage of phpunit 6 for migrations using 'assert' migration steps

• Improved: do not ask the search engine for the total number of hits for migration steps matching contents or locations. This should result in a minor speed improvement

Improve Tag and ContentType management

Hot on the heels of release 4.0, in version 4.1 more features have been implemented, that were requested by the community. Changelog:

• New: allow to set the 'name' and 'description' in many languages in a single 'create' or 'update' operation for ContentType. This is possible both for the ContentType itself as well as for all its attributes

• Fix: when updating a ContentType defined in many languages, do not loose 'name' and 'description' set in other languages

• New: allow to set references to the 'name' and 'description' of a ContentType

• New: it is now possible to remove specific versions of contents

• New: allow to set references to the 'version_count' of a Content

• New: allow to set references to the properties of a Tag: always_available, depth, main_language_code, main_tag_id, modification_date, path, parent_tag_id, remote_id

• New: operation 'load' 'tag' can be used to set references to existing tags properties

• New: operation 'update' 'tag' is supported

• Improved: better validation of the definition of fields of type eZSelection for ContentType creation/update

Version 4.0 is finally out!

The changes compared to version 3 are too long to list here - you can find them instead at https://github.com/kaliop-uk/ezmigrationbundle/blob/master/WHATSNEW.md

Allow migrations to deal with files, mails and http requests

• New: it is now possible to send emails as migration steps.

• New: it is now possible to execute http calls as migration steps.

• New: it is now possible to load/save/delete/copy/move files as migration steps.

First RC for version 4 - lots of new features and cleanups

• New: the migrate command by default will print out the number of executed, failed and skipped migrations, as well as time and memory taken

• New: the ka:mi:migration command learned a new --info action to give detailed information on a single migration at a time

• New: the ka:mi:status command learned a new --summary option to print only the number of migrations per status

• New: migrations can now be cancelled by using a custom migration step. Ex:

    -
        type: migration
        mode: cancel
        if: ...
  

  More details in Resources/doc/DSL/Migrations.yml

• New: migrations can now be suspended and resumed:

    -
        type: migration
        mode: suspended
        until: ...
  

  More details in Resources/doc/DSL/Migrations.yml

• New: it is possible to use overwrite: true to change the value of an existing reference

• New: it is now possible to save the current references to a file

• New: it is now possible to specify a custom Content Type for users created via user/create migrations

• New: it is now possible to specify a custom Admin account used to carry out migrations instead of the user 14

• New: it is possible to use a 'not', 'attribute', 'creation_date', 'group', 'modification_date', 'object_state', 'owner', 'section', 'subtree' and 'visibility' condition when matching Contents. Matching when using 'and' and 'or' is also more efficient

• New: it is possible to use a 'not', 'attribute', 'content_type_id', 'content_type_identifier', 'creation_date', 'depth', 'group', 'modification_date', 'object_state', 'owner', 'priority', 'section', 'subtree' and 'visibility' condition when matching Locations. Matching when using 'and' and 'or' is also more efficient

• New: it is now possible to set references to the values of Content Type field definitions. The syntax to use is similar to the one available for Content fields, described in the notes for release 3.6 a few lines below

• New: it is now possible to set references to 'section_identifier' when creating/updating/loading Contents and Locations

• Fixed: removed from the list of possible references which can be set for Locations the non-working 'position'

• New: the Executor services have been made reentrant

• BC changes:

  • eZPublish 5.3 and eZPublish Community 2014.3 are not supported any more (eZPublish 5.3 ends support in May 2017)

  • the code will start targeting php 5.6 as minimum version starting with this release

  • the following interfaces have been modified: MigrationGeneratorInterface, StorageHandlerInterface,

  • the following deprecated interfaces have been removed: ComplexFieldInterface

  • lots of refactoring in the Core (non API) classes. If you have extended them, be prepared for some porting work

More friendly output

The migrate command by default will print out the number of executed, failed and skipped migrations, as well as time and memory taken

One more bugfix

Fix: when using an AND condition to match locations, the results where closer to what an OR condition would produce; too many nodes would be matched

One bugfix

Fix: when setting both content creation and modification time upon content creation, modification time was lost

Some new feature and two bugfixes

• New: it is now possible to set references to:

  • content type: creation_date, modification_date, name_pattern, remote_id, status and url_name_pattern
  • language: enabled, language_code, name
  • object state: priority
  • user: email, enabled, login

• New: it is now possible to set references to the values of Content fields. The syntax to use is slightly different
  depending on whether the value for the field at hand is a scalar or a hash. Example code:

        references:
            -
                identifier: a_user_first_name_field_is_a_string
                attribute: 'attributes.first_name'
            -
                identifier: a_user_account_field_is_a_hash
                attribute: 'attributes.user_account.email'
  

  TIP: if you are unsure about the hash representation of a given field, you can generate a content/create migration for an existing content to find out how it looks.

• Added a new type of migration step: migration_definition. Only supported mode so far: generate.
  For the moment, it is mostly useful for unit testing

• Fix a case of circular dependencies in services (highlighted by the workflow bundle)

• Fix: when setting a specific language via a 'lang' attribute in a migration step, the same language would be used for all subsequent steps in the same migration