6.3.4

Fixed: the --admin-login option had been broken for migrate commands since version 6.3.0

6.3.3

• Fixed: exception thrown at end of migration if the migration steps include sql executing transaction commits

• Fixed: correctly abort a migration when it leaves a database transaction pending (nb: this can be detected only for transactions started using Doctrine, not for transactions started using sql begin statements)

• Improved: reporting of errors happening before/during/after migration execution, esp. anything related to transactions

• Improved: when generating migrations, try harder to reset the repository to the originally connected user in case of exceptions being thrown

BC notes (for developers extending the bundle):

• MigrationService::getFullExceptionMessage gained a 2nd parameter: $addLineNumber = false
• AfterMigrationExecutionException produces a different error message when passed 0 for the $step parameter
• service ez_migration_bundle.migration_service requires an added setConnection call in its definition

6.3.2

Fixed php warning in class PHPExecutor due to trait being used twice

6.3.1

• Fixed: php warning when generating Role migrations for roles with policy limitations

• Fixed: in rare circumstances (having two siteaccesses configured with the same repo and root node, but different languages), the TagMatcher could use the wrong language when matching by tag keyword

• BC change (for developers extending the bundle): class TagMatcher changed its constructor signature. the same applies to service ez_migration_bundle.tag_matcher

6.3.0

• New: migration step migration_definition/include. This allows one migration to basically include another, the same way it is possible to do that in php.

  It is useful for scenarios such as fe. creating a library of reusable migrations, which can be run multiple times with different target contents every time. This is often achieved by copy-pasting the same migration logic many times.
  As an alternative it is now possible to create a "library" migration, driven by references, and store it only once, in a separate folder, then create many "specific execution" migrations which set up values for the required references and include the library migration's definition.

  Please note that migrations which rely on external resources, such as in this case would be the included migration, go against the principle of migrations being immutable for ease of replay and analysis.

  Ex:

    -
        type: migration_definition
        mode: include
        file: a_path
  

• Improved: when executing migrations with the set-reference cli option, the injected references will be saved in the migration status

• BC change (for developers extending the bundle): method MigrateCommand::executeMigrationInProcess changed its signature

• BC change (for developers extending the bundle): Migrationservice methods executeMigration, executeMigrationInner and resumeMigration should now be called using a different signature. They do still work with the previous signature, but that usage is considered deprecated

6.2.1

• Fixed: when setting references to a ContentType sorting attributes, numeric values were used instead of their string representation

• Fixed: when generating contentType migrations, do export the default_always_available, default_sort_order and default_sort_field attributes

6.2.0

• Fixed: migrations created using kaliop:migration:generate would create yml which was not valid for import, for content
  fields of type eztags

• Improved: it is now possible to set references to the value of content fields which are recursive arrays (only
  1-level arrays were supported previously)

• Improved: in step reference/set, when reference resolving for value is enabled, it will be done recursively if value is an array

• Improved: migration step mail/send learned how to deal with multiple attachment files, using an array for element attach

• Improved: added a cookbook recipe about adding tags to an eztags field

• BC change (for developers extending the bundle): class AbstractExecutor gained a few method and properties, and it lost method parseReferenceDefinition, which was moved to trait ReferenceSetterTrait

6.1.0

• New: when matching contents, it is now possible to filter based on empty fields, eg:

  -
      type: content
      mode: load
      match:
          and:
              - content_type_identifier: file
              - attribute: {'file': empty}
  

• New: command k:m:migration learned action --fail. It should be used sparingly, only to set manully to failed status migrations which for any reason got stuck in an incorrect status, f.e. those which are still listed as executing after the corresponding process is terminated

• Fixed: migrations creating/updating contents with an ezmatrix field would result in corrupted data. Also, trying to create a content/create migration for a content with an ezmatrix field would lead to a crash

• Fixed: migrations creating/updating contents with an ezmatrix field used to work with an undocumented yaml format, up to version 5.14.0. We now allow that format to be used as well, besides the preferred format - although such format most likely does not work with the ezsystems/ezplatform-matrix-fieldtype bundle and is to be considered deprecated (see issue #250 for details).

• Fixed: make error messages from subprocesses be echoed to the console when running k:m:migrate -p with eZP 2.0 and later

• Improved: bumped the version of phpunit used to run the tests from 4.x/5.x to 5.x/8.x

• Improved: updated documentation in README and in Cookbooks

• Changed: renamed master branch on Github to main

• BC change (for developers extending the bundle): const Kaliop\eZMigrationBundle\Command\MigrateCommand::VERBOSITY_CHILD has been transformed into static variable Kaliop\eZMigrationBundle\Command\MigrateCommand::$VERBOSITY_CHILD

• BC change (for developers extending the bundle): all \Exception generated by the bundle have been converted into Kaliop\eZMigrationBundle\API\Exception\MigrationBundleException or subclasses. The same applies for all previously existing Migration Bundle exception classes.

5.7.4

Fix: backport fix for issue #232: bad method signature for EmbeddedRegexpReferenceResolverTrait

6.0.0

• New: everywhere a reference was previously resolved, ie. using reference:myref or [reference:myref] syntax
  it is now possible to use eval:expression or [eval:expression].

  The syntax for "expression" is the one of the Symfony ExpressionLanguage component. See: https://symfony.com/doc/current/components/expression_language/syntax.html

  Ex: to take the value of an existing reference and add 1 to it: [eval: 1 + resolve('reference:myref')]

  Ex: to take the value of an existing reference and concatenate 'a' to it: [eval: resolve('reference:myref') ~ 'a']

  BC BREAK: note that this can be an issue if you have existing migrations which might have the text [eval: in their data.
  If this is a problem for your environment, you can fix it by overriding the definition of Symfony service
  ez_migration_bundle.reference_resolver.customreference.flexible and remove from its arguments the service
  @ez_migration_bundle.reference_resolver.expression

• New: migration steps php/call_function and php/call_static_method, to ease one-off calling php code as part of a
  yaml migration. See the relevant DSL for details.

  Ex: it is possible to add an element to an array-valued reference, with an admittedly cumbersome syntax, given here
  as a self-contained example:

  -
      type: reference
      mode: set
      identifier: pippo
      value: [a, b]
  -
      type: php
      mode: call_function
      function: array_merge
      arguments: ['reference:pippo', ['c']]
      references:
          pluto: result
  

• New: multiple migration steps url_alias/... and url_wildcard/... are now available to manage urls aliases. Please read
  their documentation in UrlAliases.yml and UrlWildcards.yml for details

• New: migration steps loop/break and loop/continue

• New: migration step file/load_csv, allows to easily initialize references with long list of values

• New: for migration steps content/create and content/update, when content fields of type eZBinaryFile, eZImage or
  eZMedia are defined using array syntax (instead of a single string defining the file path), references are now resolved
  for each element of the array. Eg:

  -
      type: content
      mode: create
      content_type: an_image_type
      attributes:
          image_field:
              path: 'reference:a-reference-name'
              alternativeText: 'looking good'
  

• New: references are now resolved in the following migration step elements: file/load_csv/separator, file/load_csv/enclosure,
  file/load_csv/escape, file/save/overwrite, file/copy/overwrite, file/move/overwrite, http/call/method,
  http/call/client, migration/cancel/message, migration/fail/message, migration/sleep/seconds migration/suspend/message
migration/suspend/sleep, process/run/timeout, process/run/working_directory, process/run/environment,
  process/run/fail_on_error,

• New: migration step migration/sleep now supports the if clause

• New: command migrate and mass_migrate can pass down to children processes custom php.ini settings, such as f.e.
  memory_limit and error_reporting. Useful to run migrations as subprocesses in hostile environments

• Improved: it is now possible to set references to the value of content fields which are of type array

• Improved: content/update and location/update steps will throw an exception if there is nothing to update in their
  definition. This might happen f.e. if there is a typo in the yaml, and was silently ignored beforehand

• Improved: we now strive to always save paths to migration definition files as relative (to the app's root directory).
  This should help when copying the eZ database between different environments, such as fe. Prod and QA, which reside
  in different root directories in their respective servers/VMs, and then running kaliop:migration:status.

  BC BREAK: the paths reported for migration definitions by commands status and info will now most often not be
  absolute paths, but relative paths instead

  BC BREAK: if you are running the migration commands from a directory which is not the application's root dir, and use
  the --path option with a relative path, be aware that the path will now resolve to the app's root dir instead of the
  current dir

• Fixed: when running kaliop:migration:status, migration definition files found in a different location than what is
  stored in the db were not being reported as such

• Fixed: when running kaliop:migration:status --path ..., the status of skipped or failed migrations might be reported
  incorrectly as not-executed, due to mixing up relative and absolute paths. NB: in order for this to work properly,
  please execute the migration found in file vendor/kaliop/ezmigrationbundle/MigrationVersions/20220101000200_FixExecutedMigrationsPaths.php

• Fixed: a warning generated by the mass_migrate command