Jump to content

New video: How to add RockMigrations to an existing Project


bernhard
 Share

Recommended Posts

The fields- is very nice to know. This would actually do what I was expecting when adding my fields to a template.
But I also understand why it doesn't by default when just using field.

In regards to the question you have shown in the video, the user was actually asking a bit more.
Something I asked myself as well.

Let's say I want to start using RockMigrations within one of my projects it would be nice to have a migrate.php file that contains already all fields, templates and fields in templates with their settings. With that file I could copy the migrate.php file over to a new instance, make my changes and run the migration. With this in place I could clone my existing structure of templates and fields right into a totally new and clean installation.

Right now I have to copy the code hints from all of my 100 fields over to the migrate.php and that's something I'd probably never do unless really necessary. For now I would export all fields the PW-way and import them in the project. The same for the templates.

If I remember this correctly you had a demo of exactly that functionality in the past somewhere. RockMigrations was watching for all changes that were made and wrote it into a file. Maybe it was in RockMigrations1 or a proof-of-concept. I don't know.

  • Like 1
Link to comment
Share on other sites

Hi @wbmnfktr thx for the input 🙂 

Well... That is something that should be possible as well. RockPageBuilder does already save field + template settings to YAML so that you can edit all content blocks via GUI and don't need to write a single line of migration code (as I think there are still many that are not comfortable with writing migration code).

The problem with adding that to RockMigrations are the following:

  • It would mean several hours of work to make that possible. And the benefit for myself would be non-existent, as I prefer to write migrations by hand as its faster and maybe more reliable.
  • Making field + template migrations available via GUI + YAML I'm quite sure there will be some that want the same for permissions. And then for users. And then for roles... The list goes on.
  • It would need a lot more testing to see if the YAML approach does really work out as expected.
  • When writing migrations you instantly see if what you write leads to the expected result. If it does, then it's almost certain that on remote it will work exactly the same. When saving config as YAML that does not apply. But I'm quite sure that users will expect a smooth experience and they would be upset/angry if something didn't work out. 

I'd be more than happy to add support for that to RockMigrations at least for template and field settings. But I'm not going to do that in my spare time. If you see any chance how to get that funded I'm more than happy to work on it 🙂 

 

Link to comment
Share on other sites

1 hour ago, bernhard said:

as I think there are still many that are not comfortable with writing migration code

It's hard to get started. It's either me or missing parts in the documentation. Not only writing the necessary code but to grasp the whole thing. I started using it and already broke a minimal setup with it - due to trial and error. So I'm learning.

I probably won't need a real and fully supported GUI for that.  These code hints do the trick for me know, even though they are quite verbose. Yet it won't work for most of my existing projects as I had to deal with so many fields and templates. That's were something like an initial-migrate.php file would come in handy.

1 hour ago, bernhard said:

RockPageBuilder does already save field + template settings to YAML so that you can edit all content blocks via GUI and don't need to write a single line of migration code

That's the part that's probably the most interesting for some of us as most migrations become difficult due to the missing feature that tracks necessary changes made across fields and templates.

Writing each and every field and template in migrate.php feels and is super slow for me right now. Using the backend to create my fields is so much faster still. I can't image doing it for large projects to be honest. Maybe after practicing and working with RockMigrations for a longer time or after wrapping my head around it. I still feel I miss something yet I can't really say what's missing to fully understand it.

1 hour ago, bernhard said:

If you see any chance how to get that funded I'm more than happy to work on it 🙂 

Sure. But that would probably end in a ProModule of some kind and with a more broader approach in some aspects. Still we could talk about that and try to find out how this could be possible. 😉

  • Like 2
Link to comment
Share on other sites

13 hours ago, wbmnfktr said:

Let's say I want to start using RockMigrations within one of my projects it would be nice to have a migrate.php file that contains already all fields, templates and fields in templates with their settings. With that file I could copy the migrate.php file over to a new instance, make my changes and run the migration. With this in place I could clone my existing structure of templates and fields right into a totally new and clean installation.

Right now I have to copy the code hints from all of my 100 fields over to the migrate.php and that's something I'd probably never do unless really necessary. For now I would export all fields the PW-way and import them in the project. The same for the templates.

+1 !

That is the main reason why I am too afraid / too busy to start using rock migrations right now. I understand that in the end it can save you a lot of time but you have to start somewhere and it seems that all the field administration/creation will be done from the migrate.php instead of clicking around in the backend (the normal way) from then on.

I mean the typical use case for me would be the following scenario:

During site development I do all my field/template creation and settings in the backend. Adding fields to templates, edit the field in template context, etc. etc. 

Then the site goes live.

THEN the client wants something new on the site or wants to change things. 

This is the moment where PW development becomes a little painful. You have to alter fields or add some new on your local dev environment and test it. Then you have to make all those changes on the live site again. 
You COULD however replace the database on the server (which includes all the new stuff) but what if other changes were made in the meantime on the live site? Like new articles, new subpages...

  • Like 3
Link to comment
Share on other sites

@wbmnfktr

I'm not using @bernhard’s tool but you could go this way to have your initial migrate.php:

$rm = $modules->get("RockMigrations");
$excludedFields = ["admin_theme", "pass", "permissions", "process", "roles"];
$fieldsCode = [];
foreach($fields as $field) {
    if(in_array($field->name, $excludedFields)) continue;
    $fieldsCode[] = $rm->getCode($field);
}
$fieldsCode = "\$rm->migrate(\"fields\" => [\n" . implode(",\n", $fieldsCode) . "\n];";
$excludedTemplates = ["admin", "permission", "role", "user"];
$templatesCode = [];
foreach($templates as $template) {
    if(in_array($template->name, $excludedTemplates)) continue;
    $templatesCode[] = $rm->getCode($template);
}
$templatesCode = "\$rm->migrate(\"templates\" => [\n" . implode(",\n", $templatesCode) . "\n];";

And export $fieldsCode and $templatesCode in a file.

Regarding the verbosity, it unfortunately boils down to how PW generates the export data. You could be pretty agressive and skip all falsy values but you might get unexpected behaviour.

  • Like 3
Link to comment
Share on other sites

Thank you guys for the input! I appreciate the explanations.

1 hour ago, Stefanowitsch said:

THEN the client wants something new on the site or wants to change things. 

This is the moment where PW development becomes a little painful.

...and that's exactly the reason why RockMigrations exists.

1 hour ago, Stefanowitsch said:

You have to alter fields or add some new on your local dev environment and test it. Then you have to make all those changes on the live site again. 

Or you write the things you do in migrate.php and just upload that file...

$rm->createField('mynewfield', 'text', [
  'label' => 'I am the field that the client wanted to have',
]);
$rm->setTemplateData('home', [
  'fields' => [
    'title',
    'mynewfield',
  ],
]);

Is that really too much to ask? Seriously. What is the pain here? Is it that you don't know the settings? That's why I added the code section to copy&paste. I'm not trying to convince you here. I'm trying to understand.

I know it would be nice to have a "copy current field & template config" button. But I'm afraid it's not that easy and it would be a lot of work for me to build a good solution while it would be really easy for you to just learn the basics of RM and simply write some lines of code. (And not to forget: It would make you a better developer as you'll quickly become more efficient overall and you'll learn a lot about PW which would help in many other situations as well!)

14 hours ago, wbmnfktr said:

Sure. But that would probably end in a ProModule of some kind and with a more broader approach in some aspects. Still we could talk about that and try to find out how this could be possible. 😉

Let me know if you find something.

  • Like 2
Link to comment
Share on other sites

1 hour ago, bernhard said:

 

$rm->createField('mynewfield', 'text', [
  'label' => 'I am the field that the client wanted to have',
]);
$rm->setTemplateData('home', [
  'fields' => [
    'title',
    'mynewfield',
  ],
]);

Is that really too much to ask? Seriously. What is the pain here? Is it that you don't know the settings? That's why I added the code section to copy&paste. I'm not trying to convince you here. I'm trying to understand.

No pain! Its just a question of the workflow.

At some point or another you would have to do all things from the migrate.php instead of going through Setup->Fields->Add. 
It's just different way of approaching things... how can I describe it... it's like a more professional, developer-style approach.
I personally am a fan of frontend editing, where you can see what you do and where you click. Sometimes this is safer to use but none the less it will slow you down after time.

What I like about RM is that it only takes a few moments to do lots of things once you are familiar the RM syntax. But at first it will resolve in a bit of trial and error and some people (including me) might be afraid to start using it in a finished and complex project.

That does not mean that I never want to use RM. The opposite: Your recent video here answered a few of my questions I had before so now I want to try a few things out.

  • Like 2
Link to comment
Share on other sites

On 1/17/2023 at 2:13 PM, Stefanowitsch said:

At some point or another you would have to do all things from the migrate.php instead of going through Setup->Fields->Add.

No, not all. Only all the things that should be the same across all your setups 😉 That's a small but important difference. You can still use the GUI if you want to. But that means that you need to apply those changes manually to all other instances of your project as well.

The thing is: Those changes are really really easy once you get used to it. 90% of the time it's setting the 'label' property or the 'columnWidth' setting of a field and adding fields to templates.

Using the snippets for VSCode is definitely a huge help. Without them creating fields would be a little pain 🙂 If anybody knows how that feature can be ported to other IDEs let me know!

But if something is very complicated using RockMigrations you can still use the old-school way of making those changes manually! For example you could create some fields on the remote system and create some pages, then pull the database changes to your local development and just add all the easy stuff to migrate.php

PS: Many of the settings I do not know by heart as well. But it's most of the time quite easy to find them by hovering the inputfield:

vMpFwyH.png

PPS: I'm quite sure that finding the setting and writing it to migrate.php is faster than doing that manually on local dev and then replicating that change on the live system. It get's even better once you use multicursor in your IDE to set for example 3 fields to 33% width!

  • Like 2
Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...