Skip to content

6.0.0
Compare
Choose a tag to compare
@gggeek gggeek released this 09 Oct 16:27
· 20 commits to master since this release
6.0.0
768387f

  • 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

Assets 2
Loading