<p>Yii migrations will be applied in alphabetical order, and the convention is that their names start with the letter <code>m</code>, followed by the date and time when the migration was created (for example, something like <code>m221206_185401_create_foo_field_group</code>).</p>
<p>In other words, to create a set of migrations that needs to be applied in a particular order, simply make sure that the first migration has an earlier date/time in its name than the second one, and so on.</p>
<p>A good idea is using the core <code>migrate/create</code> CLI command to scaffold your migrations. That console command will create the necessary migration files for you, with generated file/class names containing the current date and time. So to create your set of migrations, you could simply execute the <code>migrate/create</code> command multiple times; scaffolding each migration <em>in the order that they should be run</em>.</p>
<p>Note that the utility defaults to creating content migrations, but can also be used to create plugin migrations by specifying a plugin handle with the <code>--plugin</code> parameter:</p>
<pre><code>php craft migrate/create create_foo_field_group --plugin=some-plugin-handle
</code></pre>
<p>It's also worth mentioning that except for creating an entry, all of the operations you plan on handling in these migrations are things that Craft will track in <a href="https://craftcms.com/docs/4.x/project-config.html" rel="nofollow noreferrer">project config</a>. As such, you should make sure that your migrations apply their schema changes defensibly; avoiding the risk of conflicts in cases where the project config YAML files are checked into version control and <code>allowAdminChanges</code> is set to <code>false</code> in the current environment. <a href="https://craftcms.com/docs/4.x/extend/project-config.html#project-config-migrations" rel="nofollow noreferrer">The official docs have a decent outline on this topic</a>.</p>

CC BY-SA 4.0
2022-12-06T21:10:18.333Z
Thank you for the reply. How about relating objects to each other? For example i would need to know id of the field group to make create field belonging to that field group. But i cannot know id of field group before it is created and hardcode it into migration.
Piotr Pogorzelski
CC BY-SA 4.0
2022-12-06T22:43:14.363Z
@piotrpog You'd have to query in migration B for the thing (for example, field group) that was created in migration A :) FWIW I'd seriously consider merging some of these operations into a single migration. There's no rule or technical limitation that says a migration only has to do a single thing. IMO, creating a field group *and* any and all custom field(s) that should belong to that group, sounds like something that would fit nicely into a single migration, which would probably make everything a bit easier – as opposed to creating a lot these very singular, one-op classes.
Mats Mikkel Rummelhoff
CC BY-SA 4.0
2022-12-06T18:29:29.107Z
2022-12-06T18:29:29.107Z
Mats Mikkel Rummelhoff
<p>lets say i want my plugin to have migrations that:</p>
<ul>
<li>create entry section</li>
<li>create field group</li>
<li>create text field, belonging to newly created field group</li>
<li>assign text field to entry type field layout</li>
<li>create entry, save some text into newly created text field</li>
</ul>
<p>As you can see, these migrations are depending on each other, you cannot create entry without entry sections not existing or cannot create field belonging to field group, if no such field group exists.</p>
<p>How that can be done? ANy examples in existing plugins?</p>

<migration>
How to create multiple migrations that depend on each other
# How to create multiple migrations that depend on each other

(Asked by: username_0 on 2022-12-06)

lets say i want my plugin to have migrations that:

* create entry section
* create field group
* create text field, belonging to newly created field group
* assign text field to entry type field layout
* create entry, save some text into newly created text field

As you can see, these migrations are depending on each other, you cannot create entry without entry sections not existing or cannot create field belonging to field group, if no such field group exists.

How that can be done? ANy examples in existing plugins?

**Tags:** migration


---

## 1 answers

### Answer by username_1 on 2022-12-06. Score: 2 | Accepted answer

Yii migrations will be applied in alphabetical order, and the convention is that their names start with the letter m, followed by the date and time when the migration was created (for example, something like m221206_185401_create_foo_field_group).
In other words, to create a set of migrations that needs to be applied in a particular order, simply make sure that the first migration has an earlier date/time in its name than the second one, and so on.
A good idea is using the core migrate/create CLI command to scaffold your migrations. That console command will create the necessary migration files for you, with generated file/class names containing the current date and time. So to create your set of migrations, you could simply execute the migrate/create command multiple times; scaffolding each migration in the order that they should be run.
Note that the utility defaults to creating content migrations, but can also be used to create plugin migrations by specifying a plugin handle with the --plugin parameter:
php craft migrate/create create_foo_field_group --plugin=some-plugin-handle

It's also worth mentioning that except for creating an entry, all of the operations you plan on handling in these migrations are things that Craft will track in project config. As such, you should make sure that your migrations apply their schema changes defensibly; avoiding the risk of conflicts in cases where the project config YAML files are checked into version control and allowAdminChanges is set to false in the current environment. The official docs have a decent outline on this topic.

> **Comments:**
> **username_0**: Thank you for the reply. How about relating objects to each other? For example i would need to know id of the field group to make create field belonging to that field group. But i cannot know id of field group before it is created and hardcode it into migration.  
> **username_1**: @piotrpog You'd have to query in migration B for the thing (for example, field group) that was created in migration A :) FWIW I'd seriously consider merging some of these operations into a single migration. There's no rule or technical limitation that says a migration only has to do a single thing. IMO, creating a field group *and* any and all custom field(s) that should belong to that group, sounds like something that would fit nicely into a single migration, which would probably make everything a bit easier – as opposed to creating a lot these very singular, one-op classes.  

---

