Releases: kaliop-uk/ezmigrationbundle
5.3.0
-
Fix: declare incompatibility with Simfony 3.4.12
-
Fix: declare compatibility with nikic/php-parser 4
-
Fix: references set to locations attributes in 'location/update' steps that resulted in a location being moved or swapped would be wrong for path-related data
-
New: it is now possible to use the
lang
key for filtering when matching contents -
New: it is now possible to alter the Groups that a ContentType belongs to in
content_type/update
steps -
New migration steps:
user/load
anduser_group/load
, which can be useful to set references -
New: it is now possible to set references to the users of a group and to the groups of a user
-
New: it is now possible to set references to the parent of a user group
-
New: it is now possible to set references to the groups of a content type
5.2.0
-
New: references are resolved in all fields when creating/updating users. This makes it easier to mass-create users in conjunction with the eZLoremIpsum bundle
-
New: the
status
command got atodo
option. When using it, all that is printed is the list of the migrations to execute (full path to each file). This can be useful fe. in shell scripts that want to execute each migration separately -
Fix: one case where array values where tried to be resolved as references (introduced in 5.1)
-
Fix: it was impossible to import a content exported via migration generation with an eZPlatform Rich-Text field (ticket #160)
-
Fix: better error reporting for the case where an error happens at the end of a migration (commit phase)
Two bug fixes
-
Fix: a bug introduced in 5.1 with resolving references in handling tags
-
Fix: do allow resolution of references for multi-valued Content Fields (eg. a reference that returns an array is ok to use for a field of type object-relation)
Allow multi-valued references; give tags some love
-
New: it is now possible to set references when a migration step results in a list of items, and not just in a single item. The resulting reference will have a value which is an array instead of a scalar value.
This has to be specifically enabled for each migration step where references are expected to be multi-valued:references_type: array references: - attribute: some_id identifier: my_array_ref
-
New: references are now resolved for in the
keyword
element fortag/create
andtag/update
. This makes it easier to mass-create eztag tags in conjunction with the eZLoremIpsum bundle -
New: tags can now be matched by their parent tag id
-
New: its is now possible to set references to a tag
keyword
-
New: it is easier to create/update tags in a single language (the main language of current siteaccess is used if unspecified)
-
BC changes:
- the RepositoryExecutor class now expects subclasses to implement method
getReferencesValues
and notsetReferences
any more
- the RepositoryExecutor class now expects subclasses to implement method
Ansible, here we come!
-
New: everywhere references are accepted, text strings can now be used as well, which embed the reference within square brackets. This will lead to the substitution of the text within brackets with the value of the reference.
Example: assuming that the 'myref' reference has a value of 99
Possible before:
match: content_id: "reference:myref" # we get content_id = 99
Possible now:
match: remote_content_id: "something [reference:myref] times different" # we get remote_content_id = "something 99 times different"
-
New: it is now possible to create references with values that are generated from other references, such as:
type: reference mode: set identifier: three value: "both [reference:one] and [reference:two]"
-
New: when creating and updating ContentType definitions, it is possible to use a reference to define each field. The value of the reference must be an array with all the usual keys: 'name', 'searchable', etc...
This makes it easy to define multiple ContentTypes sharing fields with the same definition such as f.e. the 'title'attributes: title: "reference:title_field_definition" body: name: Body ...
-
New: added migration step
loop
. More details in Resources/doc/DSL/Loops.yml -
Changed: when no language is specified on the command line or in a specific migration step dsl, instead of defaulting to
eng-GB
we will default to the first language in the list of languages set up for the current siteaccess (this is usually found in theezpublish.yml
config file) -
New: the bundle is now tested on Travis with eZPlatform 2 besides eZPlatform 1 and eZPublish 5
-
BC changes:
- two new interfaces have been added:
EmbeddedReferenceResolverBagInterface
,EmbeddedReferenceResolverInterface
.
Those replace the expected types in the constructors of most Executors. If you have subclassed Executors, be prepared for some porting work
- two new interfaces have been added:
4 new features
-
New: migration step
file/prepend
, works just likefile/append
but adds content at beginning instead of end of file -
New: migration steps
file/append
,file/prepend
andfile/save
can load the file contents from a template file on disk besides having it inline in the migration definition -
New: all migration steps that deal with the content repository, as well as sql, php class, sf services, files, mail,http calls, process execution have gained support for being skipped via an
if
tag. The semantics are the same as for the existing stepmigration/cancel
:if: # Optional. If set, the migration step will be skipped when the condition is matched "reference:_ref_name": # name of a reference to be used for the test _operator_: value # allowed operators: eq, gt, gte, lt, lte, ne, count, length, regexp
-
New: it is now possible to define the following parameters using siteaccess-aware configuration:
kaliop_bundle_migration.version_directory
,ez_migration_bundle.table_name
,ez_migration_bundle.context_table_name
This is useful when you have multi-site eZPlatform installations which do not share a single Repository database, and as such might need to execute different sets of migrations for each site.
As an example, just use this parameter format:
kaliop_bundle_migration.my_siteaccess_group.version_directory
Allow resolution of references in more places
Allow resolving references for the identifier
element of steps create
and update
for ContentType, ContentTypeGroup, ObjectState, ObjectStateGroup and Section
New type of migration step: call Sf services
-
New: allow resolving references for the
filename
element of stepsreference/load
andreference/save
-
New: migration step
service/call
allows to call a method on any existing Symfony Service, and set a reference to the result
Bugs and Features requested by end users
-
Fixed: make the cli commands compatible with Symfony 3.0 and later
-
New: the element
remove_drafts
can be used for migration steps of type ContentType/update to make sure that any existing drafts of the given ContentType are removed -
New: support the value '*' for the
remove_attributes
parameter in ContentType definitions. This allows to remove all the attributes which already exist in the ContentType, except for the ones defined in theattributes
parameter -
New: added a new loader class to allow scanning the Migrations folders recursively for migrations files. Useful when you have a massive number of migration files and keeping them in a single folder hits the filesystem limits. At the moment, the only way to enable this is to redefine the alias in your app configuration, ie:
ez_migration_bundle.loader: alias: ez_migration_bundle.loader.filesystem_recursive
-
New: a new command
kaliop:migration:mass_migrate
is available to execute the migrations found in a directory, including all its subdirs, using a specified number of parallel processes. This is a somewhat efficient way to achieve f.e. mass import of contents via migrations -
Improved: when using the
separate-process
option to themigrate
command, pass on to the child process theno-debug
andsiteacess
options, if they have been specified by the user -
Improved: better error message when trying to generate a migration for the creation of a Role which has Policies with limitations that can not be exported
Better compatibility with Solr Search Engine Bundle and support for Trash management
-
New: migration step:
migration/sleep
to delay execution of a migration for a fixed number of seconds -
New: migration steps:
location/trash
,trash/purge
,trash/recover
andtrash/delete
-
Improved: do not use the Repository Search Service when matching Contents or Locations using only their Id or Location Id.
This has the advantage that those items will always be loaded from the database, even in the case of Solr Search Engine Bundle being enabled, which in turn means that you should get fewer problems related to usage of database transactions and delays Solr in indexation.
This fixes issue #134.
BC note: if you use Solr Search Engine Bundle and the find the new behaviour undesireable, you can easily switch back to the previous one by altering the value for parametersez_migration_bundle.content_matcher.class
andez_migration_bundle.location_matcher.class