Importing data¶
To import data from YAML migration files into repository, you run the ibexa:migrations:migrate
command.
The ibexa:migrations:import
command automatically places migration files in the correct folder.
Alternatively, you can place the files manually in the src/Migrations/Ibexa/migrations
folder or in a custom folder that you configure, and specify the file name within this folder as parameter.
If you don't specify the file, all files within this directory are used.
1 |
|
Migrations store execution metadata in the ibexa_migrations
database table.
This allows incremental upgrades: the ibexa:migrations:migrate
command ignores files that it had previously executed.
The --siteaccess
option usage can be relevant when multiple languages or multiple repositories are used.
Migration step¶
A data migration step is a single operation in data migration process that combines a mode (for example: create
, update
, delete
)
and a type (for example: content
, section
, currency
), with optional additional information depending on the specific step.
In a migration file, a step is an array item starting with the mandatory properties type
and mode
, for example:
1 2 3 |
|
Then, the step is described by additional properties depending on its type and mode.
- See Available migrations for the modes available for each type.
- See Migration examples to explore what you can do with each type.
- For a custom migration step, see Create data migration step.
Available migrations¶
The following data migration step modes are available:
type |
create |
update |
delete |
swap |
---|---|---|---|---|
attribute |
✔ | ✔ | ✔ | |
attribute_group |
✔ | ✔ | ✔ | |
content_type |
✔ | ✔ | ✔ | |
content_type_group |
✔ | ✔ | ✔ | |
content |
✔ | ✔ | ✔ | |
currency |
✔ | ✔ | ✔ | |
customer_group |
✔ | ✔ | ✔ | |
language |
✔ | |||
location |
✔ | ✔ | ||
object_state |
✔ | |||
object_state_group |
✔ | |||
payment_method |
✔ | |||
product_asset |
✔ | |||
product_availability |
✔ | |||
product_price |
✔ | |||
product_variant |
✔ | |||
role |
✔ | ✔ | ✔ | |
section |
✔ | ✔ | ||
segment |
✔ | ✔ | ✔ | |
segment_group |
✔ | ✔ | ✔ | |
setting |
✔ | ✔ | ✔ | |
user |
✔ | ✔ | ||
user_group |
✔ | ✔ | ✔ |
Repeatable steps¶
You can run a set of one or more similar migration steps multiple times by using the special repeatable
migration type.
A repeatable migration performs the defined migration steps as many times as the iterations
setting declares.
1 2 3 4 5 |
|
Tip
You can use repeatable migration steps, for example, to quickly generate large numbers of content items for testing purposes.
You can vary the operations using the iteration counter.
For example, to create five Folders, with names ranging from "Folder 0" to "Folder 4", you can run the following migration using the iteration counter i
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
To vary the content name, the migration above uses Symfony expression syntax.
In the example above, the expression is enclosed in ###
and the repeated string SSS
.
Note
Iteration counter is assigned to i
by default, but you can modify it in the iteration_counter_name
setting.
Generating fake data¶
You can also generate fake data with the help of FakerPHP
.
To use it, first install Faker on your system:
1 |
|
Then, you can use faker()
in expressions, for example:
1 2 3 |
|
This step generates field values with fake personal names.
Expression syntax¶
You can use Symfony expression syntax in data migrations, like in repeatable steps, where you can use it to generate varied content in migration steps.
The expression syntax uses the following structure: ###<IDENTIFIER> <EXPRESSION> <IDENTIFIER>###
The IDENTIFIER
can be any repeated string that encloses the actual expression.
Built-in functions¶
Built-in expression language functions that are tagged with ibexa.migrations.template.expression_language.function
:
to_bool
,to_int
,to_float
,to_string
- convert various data types by passing them into PHP casting functions (likefloatval
,intval
, and others).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
reference
- references a specific object or resource within your application or configuration. Learn more about migration references.
1 2 3 |
|
project_dir
- retrieves the project's root directory path, for example to construct file paths or access project-specific resources.
1 2 3 |
|
env
- retrieves the value of an environmental variable.
1 2 3 4 5 6 7 8 |
|
Custom functions¶
To add custom functionality into Migration's expression language declare it as a service and tag it with ibexa.migrations.template.expression_language.function
.
Example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Service-based functions can be also added, but they must be callable, requiring either an __invoke
function or a wrapping service with one.
Migration examples¶
The following examples show what data you can import using data migrations.
Content types¶
The following example shows how to create a content type with two field definitions.
The required metadata keys are: identifier
, mainTranslation
, contentTypeGroups
and translations
.
The default values of field definition properties mirror the underlying PHP API, for example:
translatable
defaults totrue
required
defaults tofalse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
Content items¶
The following example shows how to create two content items: a folder and an article inside it.
When creating a content item, three metadata keys are required: contentType
, mainTranslation
, and parentLocationId
.
To use the location ID of the folder, which is created automatically by the system, you can use a reference.
In this case you assign the parent_folder_location_id
reference name to the location ID, and then use it when creating the article.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
Images¶
The following example shows how to migrate an example-image.png
located in public/var/site/storage/images/3/8/3/0/383-1-eng-GB
without manually placing it in the appropriate path.
To prevent the manual addition of images to specific DFS or local locations, such as public/var/site/storage/images/
you can move image files to, for example src/Migrations/images
.
Adjust the migration file and configure the image
field data as follows:
1 2 3 4 5 6 |
|
This migration copies the image to the appropriate directory, in this case public/var/site/storage/images/3/8/3/0/254-1-eng-GB/example-image.png
, enabling swift file migration regardless of storage (local, DFS).
Roles¶
The following example shows how to create a role.
A role requires the identifier
metadata key.
For each policy assigned to the role, you select the module and function, with optional limitations.
The following example shows the creation of a Contributor
role:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
To update an existing role, two policies' modes are available:
replace
: (default) All existing policies are replaced by the ones from the migration.append
: Migration policies are added while already existing ones are kept.
The following example shows how to replace the policies of the existing Editor
role:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
The following example shows the addition of a policy to the Anonymous
role:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
The following example shows how to delete the Contributor
role:
1 2 3 4 5 6 |
|
Locations¶
The following example shows how to swap content items assigned to given locations.
1 2 3 4 5 6 7 8 9 |
|
The metadata keys for Location are optional.
Users¶
The following example shows how to create a user.
The required metadata keys are: login
, email
, password
, enabled
, mainLanguage
, and contentType
.
You also need to provide the user group's remote content ID.
You can use an action to assign a role to the user.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
Languages¶
The following example shows how to create a language.
The required metadata keys are: languageCode
, name
, and enabled
.
1 2 3 4 5 6 7 |
|
Product catalog¶
Attributes and attribute groups¶
The following example shows how to create an attribute group with two attributes:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|
You can also update attributes, including changing which attribute group they belong to:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
You can't change the attribute type of an existing attribute.
Product types¶
The following example shows how to create a product type.
The main part of the migration file is the same as when creating a regular content type.
A product type must also contain the definition for an ibexa_product_specification
field.
fieldSettings
contains information about the product attributes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
Products¶
The following example shows how to create a product:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Product variants¶
The following example shows how to create variants for a product identified by its code:
1 2 3 4 5 6 7 8 9 10 |
|
Product assets¶
The following example creates an image content item from a local image file, and then uses it as a product asset for a variant (created in previous example):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
This migration uses a reference to store the created image content ID, and then uses it while creating the asset.
It uses an expression syntax to concat (~
)
the mandatory scheme ezcontent://
and the image content ID through the reference
function used on the reference's name.
Product prices¶
The following example shows how to create a price for a product identified by its code:
1 2 3 4 5 6 7 8 9 |
|
Customer groups¶
The following example shows how to create a customer group with a defined global price discount:
1 2 3 4 5 6 |
|
Currencies¶
The following example shows how to create a currency:
1 2 3 4 5 |
|
Commerce ¶
Payment methods¶
The following example shows how to create a payment method:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
Shipping methods¶
The following example shows how to create a shipping method:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
|
Segments ¶
The following example shows how to create a segment group and add segments in it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
When updating a segment group or segment, you can match the object to update by using its numerical ID or identifier:
1 2 3 4 5 6 |
|
Settings¶
The following example shows how you can create and update a setting stored in the database:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Taxonomies¶
The following example shows how you can create a "Car" tag in the main Taxonomy:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
The field identifiers must match the identifiers used in the ibexa_taxonomy
configuration file.
If the content type associated with the tags is changed, the configuration should be adjusted when creating migrations.
Note
If there are multiple taxonomies, the taxonomy
field is then necessary here (line 21).
You can use the following example to assign tags to a Content (content type Article has an additional field):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
When updating a content type, use:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
Criteria¶
When using update
or delete
modes, you can use criteria to identify the objects to operate on.
Caution
Criteria only work with objects related to the product catalog.
1 2 3 4 5 6 7 8 9 10 |
|
Available operators are:
=
<>
<
<=
>
>=
IN
NIN
CONTAINS
STARTS_WITH
ENDS_WITH
You can combine criteria by using logical criteria and
and or
:
1 2 3 4 5 6 7 8 9 |
|
Criteria can be nested.