Jump to content
bernhard

RockMigrations - Easy migrations from dev/staging to live server

Recommended Posts

Hi @zoeck

10 minutes ago, zoeck said:

And a second problem with an option field:

See setFieldOptionsString() method

11 minutes ago, zoeck said:

Are there any problems when you create repeaters and use fields that are created in the same upgrade?

There is no error, but my fields were not assigned to the repeater.

I guess I've never came up with any migration for repeater fields, so this might need some custom integration. PRs welcome. I don't use Repeaters at all these days 😉 

  • Like 1

Share this post


Link to post
Share on other sites
23 minutes ago, bernhard said:

Hi @zoeck

See setFieldOptionsString() method

Is this possible with the "migrate" function?

Just Added one Line on the "Upgrade" with the setFieldOptionsString -> working 😉 Thanks!

 

Migrations without repeaters 😞 thats uncool... 

Do you not use repeaters at all?

Share this post


Link to post
Share on other sites
11 minutes ago, zoeck said:

Is this possible with the "migrate" function?

No. migrate() is just a shortcut array syntax. You can always combine both:

$rm->migrate([
	'fields' => ['foo' => ...]
]);
$rm->setFieldOptionsString('foo', ...);

 

11 minutes ago, zoeck said:

Migrations without repeaters 😞 thats uncool... 

😶

11 minutes ago, zoeck said:

Do you not use repeaters at all?

No. Pages for the win. A lot easier to handle in many situations (Migrations, RockFinder, ...). But I have a custom Repeater implementation... Maybe the need for migrating repeaters will arise one day for me and maybe I'll implemenet something then if nobody that needed it earlier did submit a PR...

Share this post


Link to post
Share on other sites
On 5/28/2020 at 2:23 PM, bernhard said:

I guess I've never came up with any migration for repeater fields, so this might need some custom integration. PRs welcome. I don't use Repeaters at all these days 😉 

After I had a closer look at the repeaters, I could add the items to the repeater.
It is actually not that difficult, but you need a little workaround:

$repeatertemplate = $this->templates->get($this->fields->get("**REPEATERNAME**")->template_id);
$rm->addFieldToTemplate("proj_milestone_date",$repeatertemplate);

For each repeater a (hidden) template is created, you just have to find the template from the repeater and then add the field via RockMigrations 🙂 
It is also possible to add several fields with "addFieldsToTemplate", setFieldData is also possible.

  • Like 1

Share this post


Link to post
Share on other sites
On 5/19/2020 at 4:59 AM, bernhard said:

Would be great to hear your experience then. Is @LostKobrakai's module really obsolete or does it still have its place?

Just to throw an opinion here, I still use @LostKobrakai module due to the command line support and I do like the way it works and how it keeps track of migrations run, which I'm not sure it's done in RockMigrations. But I guess RockMigrations could be made to work by invoking migrations script with the php command and add some tracking, I do like a lot how the field migrations are described here. 

Share this post


Link to post
Share on other sites

Thx for that report @elabx 🙂 The other module works totally different. My migrations can be run from anywhere, anytime. That makes it a lot easier to use but of course this has drawbacks. Keeping track of with migrations have already been applied is more complicated. I'm not sure how that could be done exactly. But I have to say that since I'm using RockMigrations I have not REALLY needed such a feature. My main goal was to make the changes as easy as possible. Migrations can always be applied several times so it does not really matter if they have been applied or not.

But I'd love to have a good concept for that and since RockMigrations is totally free and open source I invite anybody to contribute and improve it 🙂 I have lots of other more important things to do.

Command line support sounds interesting though. But I'm not sure if that would bring a huge benefit compared to the tracy console. And even more I wonder if it might make a lot more sense to have a command line module that can be used by any other module. Not one that is locked to RockMigrations...

Share this post


Link to post
Share on other sites
1 hour ago, bernhard said:

But I'd love to have a good concept for that and since RockMigrations is totally free and open source I invite anybody to contribute and improve it 🙂 I have lots of other more important things to do.

Didn't want to imply your module needs anything or that it is "missing" something or that I was asking for a feature, I apologize if that's how it came out! Just wanted to give an example of an exception to the norm in case anyone finds this thread and of course, I agree it's the mission of all of us to contribute to open source and I must say this community has inspired me a lot to thrive into that direction rather than just consuming the work of others but also contributing, first step is to solve the very serious personal time management issues I have and just force me to do get  open source done lol.

1 hour ago, bernhard said:

Command line support sounds interesting though.

So basically how it's useful for me is that, I keep a bunch of sites on one server and they all share template files and fields configuration. I keep files in sync using git and git worktrees, and with a shell script I make merges from the dev branch into the rest of the branches, including the migration files (each site is a branch). Then, if I need to make an update that involves any adding/removing fields I also have another shell script that goes on every site directory and runs a specific migration. It saves me a lot of time to run this for the 50+ sites I manage, I can very easily see if an error occurred, if migration was already run, if it didn't exist (then it means that site is now correctly wired up to the git repo), etc. 

Probably this is the least likely scenario of most PW users lol, as I have the feeling that most of PW users build heavily customized sites, for very specific requirements. 

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, elabx said:

Didn't want to imply your module needs anything or that it is "missing" something or that I was asking for a feature, I apologize if that's how it came out! Just wanted to give an example of an exception to the norm in case anyone finds this thread and of course, I agree it's the mission of all of us to contribute to open source and I must say this community has inspired me a lot to thrive into that direction rather than just consuming the work of others but also contributing, first step is to solve the very serious personal time management issues I have and just force me to do get  open source done lol.

Didn't take that as offense at all 🙂 Just tried to make clear that I have already thought of that but I don't plan to implement it any time soon. But if anybody would be up for it, I'd be more than happy to assist or to pull the changes 😉 Sorry if that was not clear.

  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, elabx said:

Probably this is the least likely scenario of most PW users lol, as I have the feeling that most of PW users build heavily customized sites, for very specific requirements.

I'm sure it's the less used path, but a CLI is useful for anybody automating deployments either using some kind of CI/CD or manually called scripts.

13 hours ago, bernhard said:

The other module works totally different. My migrations can be run from anywhere, anytime. That makes it a lot easier to use but of course this has drawbacks. Keeping track of with migrations have already been applied is more complicated. I'm not sure how that could be done exactly.

The goal of my migrations module was to result in reproducable db state, so automation is possible. If migrations can be run arbitrary times it's not going to do that – e.g. a field created and later deleted is not the same as a field deleted and later created. Therefore migrations have a fixed order (by timestamp) and a db table keeps knowledge about which migrations were already applied before.

  • Like 2

Share this post


Link to post
Share on other sites

v0.0.11 adds support for repeater matrix fields 🙂 

Thx to @aComAdi of https://www.a-commerce.ch/ for sponsoring this update! 😎

$rm->setMatrixItems('your_matrix_field', [
  'foo' => [
    'label' => 'foo label',
    'fields' => ['field1', 'field2'],
  ],
  'bar' => [
    'label' => 'bar label',
    'fields' => ['field1', 'field3'],
  ],
]);

 

  • Like 5
  • Thanks 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...