add better configuration for fields and templates and make them version controllable

[wbmnfktr]

I'm not using them day-to-day... that would be such an overhead. But yes, worktrees are some kind of next-level chaos at first. Still sometimes really nice. 

I used worktrees in some larger projects in which lots of things happened at the same time. So switching from branch to branch, stashing, half-baked commits didn't work out at all. I mapped each worktree to its own virtual host, could switch code bases whenever needed without said things, like stash or commit.

Are they perfect? No. At least not in my day-to-day projects.
But there have been some projects I really benefitted from worktrees.
Still a tiny fraction, but still.

I assume it will work out totally different in case you do C/C++, Rust, Go, TS... things like that.
At least that's my impression while watching coding session similar to video linked above.

[dotnetic]

@MoritzLost I didn't use worktrees yet, but one advantage that I have seen in videos is, that you have your own dependencies for each worktree. This can be a huge advantage if you use different node modules (or composer dependencies) between branches (maybe because you need an additional library for a feature branch)

[MoritzLost]

@wbmnfktr Thanks! Mapping different work trees to different virtual hosts is a great idea, probably what I was missing for this to make sense to me. I'll try this out when I get the chance.

@dotnetic The different dependencies can just be tracked in the package.json / composer.json files (and the respective lock files) and installed with npm ci or composer install. Both tools cache packages locally, so it usually only takes a couple of seconds ... I guess this would be useful if you need to switch branches every couple of minutes, though I can't think of a workflow that would require that much switching ?

[wbmnfktr]

6 hours ago, MoritzLost said:

Mapping different work trees to different virtual hosts is a great idea, probably what I was missing for this to make sense to me.

Exactly that was kind of a game changer for me.
I switched my config settings, kept another database for branch/tree version1 and went from there.

I was able to switch between the old site and each and every new instance/feature set of it.
In total 6 branches/trees but it was worth it.

Relates to the last project in which I used worktrees.

[dotnetic]

Until we might have a native method for migrations, I encourage you to checkout the great RockMigrations module. With the module you can have one or multiple migration files, that handle all the stuff mentioned above, like adding fields, adding templates, creating pages with content and setting roles. As the migrations are file-based they are also version-controllable.

It is also a hassle-free setup and very easy.

This makes it easy to work on a feature in a different branch which requires to have other fields/template than in the main branch. Now you can switch between branches and always have the required fields and templates. This is a huge time and workflow improvement.

@bernhard steadily improves his module, and me and other contributors try to enhance it, or give feedback.

[thetuningspoon]

On 2/3/2022 at 11:32 AM, MoritzLost said:

@horst I just meant that existing fields that already exist in the database and still exists in the config aren't wiped and recreated when applying the config (since that would wipe the data as well). The config always includes all fields (as well as entry types, settings, etc) that exist on the site. So if I remove a field in dev, its removed from the config. If I apply that config to other environments, the field is removed from those as well.

I've been thinking about this and I think any declarative configuration system should be extremely conservative about removing any data from the database. One way of handling this would be to have a separate location in the config for listing out the names of templates and fields that you explicitly want to remove. If an install contains a field or template not in the configuration or in the removal list, it would simply ignore it.

Another approach would be to ignore any field or template not in the config, and provide a separate "cleanup" function that could be triggered with a button in the admin or a cli command. This would go through and remove any fields or templates that are not listed in the config.

While the config files could be updated automatically as changes are made in the admin interface, I think that any outside changes to the config files should require a manual sync and not be applied automatically. A notice in the admin could alert the superuser that the config file contains unapplied changes and then they could click a button or use a cli command to apply the changes.  

The algorithm for adding new fields and templates should first check for the existence of each field and template by name. If one is missing, it should proceed to create the field or template and with its name and type (but no other settings). After that it can go back and apply the settings for everything, at which point dependencies between fields and templates should resolve without issue (family settings, page fields that reference templates in their settings, etc.).

I've been tempted to try working on a module for this for a while now and was close to having a project that required it at work that would allow me to invest the time into it. That project is currently stalled but may still come about at some point at which point I could try working on this if someone else hasn't already gotten to it.

[bernhard]

You did an 100% exact description of RockMigrations. Really, that's exactly how it works.

[Ivan Gretsky]

Just a few days ago upvoted this github request. Everyone interested please do so too)

I am quite interested in @bernhard's take on this (RockMigrations). But it doesn't work with RepeaterMatrix and other Pro fields, as far as I know. And this is essential to me. And just maybe a core functionality would be a better solution?

Anyway, RockMigration is what we have now and I really appreciate @bernhard's effort on this. I still yet need to get my head fully around how it works though))

[bernhard]

1 hour ago, Ivan Gretsky said:

But it doesn't work with RepeaterMatrix and other Pro fields, as far as I know. And this is essential to me.

Quote

RockMigrations might not support all external fields, especially not ProFields like RepeaterMatrix. Adding support has no priority for me because I'm not using it. If you need support for it please provide a PR or if you are interested in sponsoring that feature please contact me via PM in the forum.

RM1 had support for RepeaterMatrix so it would likely just be copy&paste: https://github.com/baumrock/RockMigrations1/blob/1ee9f9eb4afaf83529bcedf443b31dd63a5403c8/RockMigrations1.module.php#L1336-L1384

So if you think RockMigrations is missing anything why don't you stop complaining and start asking me if it is already possible or if I can implement it?

1 hour ago, Ivan Gretsky said:

And just maybe a core functionality would be a better solution?

Why do you think that?

-----------

Sorry, but I have to say I'm getting a little pissed with you guys talking about migrations.

It's like you were sitting in front of your TV eating chips and watching a documentary about mountains. And you say: "Wow, that views are so great. It must really be awesome to see that in real life! I've dreamed about that for a decade (yep, quoting you here @Ivan Gretsky  ? But I don't mean you exclusively with the protagonist in that story )."

And then I tell you: "I built a car. It stands in your garage. You simply have to get into it, learn how to drive and 5 hours later you are there! It's great, I'm going there all the time and it's such a great experience and once you've been there you'll never want back. Ah, forgot to mention: You can take my car for free!"

And you: "Oh, well... Thank you... I totally appreciate that. You know... it's just... driving a car?! I've never been driving a car... And... You didn't say anything about the car-radio... Does it even have a radio? You know, it's so important to me, because I always hear the news on radio!" And you continue eating chips and watching TV...

Me: "You'll learn how to drive in 10 Minutes. It's an automatic car. The previous car had a manual gear shift, but the new car that I built has automatic gear shift, so you really just need to sit in, steer the wheel and push the break or the gas pedal."

You: "Well... I'm afraid I could cause an accident! That's really kind of you, but I'd much more prefer if there was a train to that mountains! That would be great! I'm sure the one that builds the train thinks of everything that I need. A radio. I could even take my Laptop with me and watch TV during the ride. I'd be the first to buy a ticket for that train (yep, quoting again)!" You continue eating chips...

Me: "Sure, I was also afraid when I first drove a car. But believe me: It's really not hard! And you can go really slow at first and of course, you don't start driving that car on a real street! You go to a big free area where no obstacles and no people are so that you can't hurt anybody or yourself. I have even made a video about how to drive the car."

You: "Ok wow, thank you, I have to try that!" You eat the rest of your chips.

--- one month later ---

Me: "Did you drive the car already?"

You (eating chips and watching docs about that great mountains): "Oh... well... yes... I tried... But it does not work. I think I'll wait for the train to be built!"

Me: "Ähm... Why? What is wrong with the car?"

You: "Nothing... it's just... it is too complicated for me. It's for sure great if you drive cars daily like you do. But for someone like me it's too complicated. It would be much easier to go by train. That would be so great, that mountains look so awesome. I'd love to go there one day." You open a new bag of chips.

--------------------

Get your *** up and stop eating chips! Watch that movie and get into that car! Go to a free and safe area and practise.

Once you did that I'm happy to hear feedback how the car could be improved. Maybe we need to add cruise control. Or maybe we need to put sunglasses in the car. Or maybe we need to place a sticker on the outside of the car that says: "If you want to drive that car you have to enter on the front seat where the steering wheel is. You can't drive this car from one of the back seats."

Or maybe you say "I've tried. I drove the car two hours, but it was terrible. It was loud, it was exhausting. I was not able to watch TV while driving." That's fine. If that is really what you want, then the car might not be the best choice for you. But one of my points is: We have that car already! The train would have to be built. If it is only about you not being able to stop watching TV and eating chips you could also pay someone to drive the car for you. Or you could pay me to add a self driving mode into that car. And for the noise: I'm happy to get those reports and then we can decide if it's something to take care of (to make sure the car does not explode while driving) or if it would be enough to just use oropax until the car get's its silent driving mode.

Another point is: I know that it sounds totally great to get into the train, continue watching TV and eating chips and arrive relaxed at the mountains. But you can't go anywhere else. With the car you have the flexibility to go anywhere. And you can go on top of the mountain whereas on the train you'll arrive at the train station and you have to go the last mile by foot.

So jump into that car and stop asking for a train by pretending that there is no other way to go to the mountains!

Do you get my point? I'm not against having a train to the mountains. But @thetuningspoon's message is like saying "I have thought about it. To go to the mountains we'd need a vehicle that can carry passengers. We'd need an endurance of at least 6 hours, because the mountains are 5h away. It should drive forward by default. Going backwards should require an extra step of caution because it might be more dangerous to push back with that vehicle."

Me: "Yeah, you are describing my car."

You: "Hm. I thought more of something like a train..."

---

So if you don't want to ride that car for whatever reason: Please start describing your train properly and add notes what should work differently to the car that we already have and why.

PS: Read the title of this thread... "Build a vehicle to go to the mountains and add gps tracking". Did I already say that my car has gps tracking??

[MoritzLost]

13 hours ago, thetuningspoon said:

I've been thinking about this and I think any declarative configuration system should be extremely conservative about removing any data from the database. One way of handling this would be to have a separate location in the config for listing out the names of templates and fields that you explicitly want to remove. If an install contains a field or template not in the configuration or in the removal list, it would simply ignore it.

@thetuningspoon I completely disagree, because that is farther removed from the goal of having a declarative dec config and closer to the territory of migrations. You don't want to give the system a list of instructions on how to build the correct state, you want to have a declarative list of configuration values that describes the correct state. Getting there happens under the hood. Similar to the difference between declarative or functional programming and imperative programming - you only describe what to do, not how to do it. The system can compare the list of fields in the config and in the database, add and remove fields as needed, and update config values. Combined with version control, this allows you to go back seamlessly to any previous state, revert changes to the declarative config etc, which is something that migrations struggle with, as mentioned.

I understand the hesitation to have the system outright delete anything that's missing from the config, but that's just a combination of not going 'all-in' on the declarative config, or not embracing some important workflow changes along with it.

You want the config to be the single source of truth for the state of the project, independent of any existing installation or database. If you take an existing 'base' state (for example, tracked in version control as a database dump of an existing installation) and only include changes relative to that base state in your config, you're not there all the way. You want the config to include everything, every field, template, setting, installed plugin, etc. This way, a new installation (for example, a staging environment for a specific feature) can ideally be created with a single console command. Once you have that, you don't have to worry about having the system delete fields that aren't in the config, because deleting a field from the config requires the same amount of effort and has the same visibility in your quality control pipeline as adding one.

The rest is just a question of workflow. Changes to the config should be tracked in version control, and merging those changes should require an approved pull request (if you're working in a team). Deleting a field is just as much of a change that is visible in the PR as adding one, since you will see the deleted field config in the PR and make sure that this is really what you want to do. Once you have a solid workflow in place, you can confidently delete everything that you no longer need, because you know you this change will go through review and quality control, and you can get it back through version control if you really need it again in the future.

Of course, mistakes still happen. Turns out the client still had some vital data in that field you removed? Well, that's what backups are for. The first step in every deployment script should be a backup.

13 hours ago, thetuningspoon said:

While the config files could be updated automatically as changes are made in the admin interface, I think that any outside changes to the config files should require a manual sync and not be applied automatically. A notice in the admin could alert the superuser that the config file contains unapplied changes and then they could click a button or use a cli command to apply the changes.  

Yes, absolutely. Though in a perfect world, changes to the config are only made in development environments, tracked in version control, and then deployed to the live site (after any staging environments in between). Pulling the config and applying it should be done as part of the deployment script. This way, there is rarely a need to have a button in the backend that applies the config (though this is still useful for development). The more you can automate deployments and get rid of manual steps, the better. This allows you to work in smaller iterations and get features out faster and with more confidence.

The Phoenix Project is a great read on that subject!

[bernhard]

Quote

You want to go to the mountains? You don't want to go by car or by train, you want to go by bus!

It's great. Everybody in your team can jump onto that bus and everybody will be at the same location at the same time. No more "when will you be there?" calls on the phone, so great!

You want to visit your grandparents on the way? Well, you can either convince everybody else on the bus to join you or you can forget that. But you don't want to visit them anyhow. I know that. It's just about going all-in on bus rides and changing your workflows!

Just another single-source-of-wisdom post. Congrats ?

[Ivan Gretsky]

4 hours ago, bernhard said:

So jump into that car and stop asking for a train by pretending that there is no other way to go to the mountains!

That's quite an expressive post, @bernhard! I am actually a pretty slow driver. My Renault is no racing car, and that's because I never wanted to race) And when I need to go a long way (like, to the mountains), I actually try to take a train, so I can have some (root?) beer and yes, chips, along the way and not exhaust myself driving. So you're right - at least in describing me)

To my defense, I can say that I actually did install your... car... in my remote testing... garage. And now I am testing how it is showing itself in a... no load situation. But you're right - I (we?) could go faster out of that garage to the mountains (I would rather go to the sea, but nevermind)))

Getting rid of those comparisons... yes, I am kind of picky here, as migrations / versionable config is something that can easily break things. ProcessWire is a really author's project, so I am used to be inclined to choose 1st party solutions. But I've already read the source code and tested in a few different ways. Long things short - agreed, I need to get in you car and step on the gas))) Will do so and report back!

Still this topic is about something similar, but a bit different than migrations - another way to store configs. So it interesting to me see how things go here. And, as always, Ryan's say on this is a big thing to me. And he still didn't answer in that issue).

[thetuningspoon]

@bernhard I know you've put a lot of work into your module and I can see why my post pissed you off (to be honest, after I posted it I thought about removing it because I was worried this might happen).

I did "test drive" RockMigrations last week. Unfortunately, my test drive started with me trying to create and migrate a ProField for a project I'm working on, and the result was that my new field's settings were wiped out each time the migration ran. Then I read a post you wrote that made it sound like you didn't plan on supporting ProFields and didn't understand why anybody would have need for them since you don't use them yourself. All of our projects use ProFields, so it's a showstopper for us if these aren't going to be supported. And I don't feel like I should really have to justify that need and I'm not interested in arguing about it.

That's why the system that I have in mind would use the existing JSON export/import mechanism from the core, which already supports migrating ProFields, and presumably will continue to support any new 1st party field types that are built. It would just bolt onto it and make the export/import process more automated. And as I described in my last post, it would be agnostic about the order of the field and template definitions so the user wouldn't have to worry about dependencies with order of import.

So I'm not really sure what to say. There's no reason why we can't have more than one approach to this. You're saying that you're interested in feedback, but then it feels like you're mocking our ideas. If you think our ideas are stupid or too limiting or whatever, then at least let us have fun with them on our own :-)

EDIT: I just looked over the processwire-requests thread on Github again and I see that some other people who have gotten deeper into this already have reported issues with the core JSON export/import module that would need resolving before certain fields could work. Other than the FieldtypeOptions I haven't had many issues lately in my experience. I also saw that you expressed interest in supporting the Combo field in that thread, so I apologize if I've misinterpreted. If RockMigrations can support my fields and desired workflow with just a bit of additional development (from either you, me, or someone else), then I would certainly prefer that to having to write a new module from scratch! 

Also, I have to say that your car analogy had me in stitches after reading it fully from start to finish. :D

 

On 11/1/2022 at 7:37 AM, MoritzLost said:

@thetuningspoon I completely disagree, because that is farther removed from the goal of having a declarative dec config and closer to the territory of migrations. You don't want to give the system a list of instructions on how to build the correct state, you want to have a declarative list of configuration values that describes the correct state. Getting there happens under the hood. Similar to the difference between declarative or functional programming and imperative programming - you only describe what to do, not how to do it. The system can compare the list of fields in the config and in the database, add and remove fields as needed, and update config values. Combined with version control, this allows you to go back seamlessly to any previous state, revert changes to the declarative config etc, which is something that migrations struggle with, as mentioned.

I agree in theory, but I would personally rather err on the side of caution. Neglecting to delete a field or template doesn't effect the operation of the system, but deleting one unintentionally (I'm picturing something like a merge conflict being resolved incorrectly) would require restoring from a backup. I see the list of deleted templates/fields as still declarative in the sense that it doesn't matter what order they're in or when they're added. It's just saying "these fields and templates should never exist".

Anyway, I can see wanting it to work either way. So this could simply be a matter of a setting in the module.

Edited November 3, 2022 by thetuningspoon

[thetuningspoon]

On 11/1/2022 at 4:57 AM, bernhard said:

You did an 100% exact description of RockMigrations. Really, that's exactly how it works.

Sorry, I didn't see this comment before my previous post. I know that RockMigrations does not remove fields and templates unless you explicitly request it to. Does RockMigrations support the additional features I mentioned?

• Automatic update of config files when changes are made in the admin (I know it offers the copy & paste feature, which is a great start and preferable when using multiple migration files)
• Order-agnostic migration
• Field/template cleanup function for those not defined in migration files
• Option to only apply changes manually via cli or button press in admin

[bernhard]

On 10/31/2022 at 11:09 PM, thetuningspoon said:

I've been thinking about this and I think any declarative configuration system should be extremely conservative about removing any data from the database. One way of handling this would be to have a separate location in the config for listing out the names of templates and fields that you explicitly want to remove. If an install contains a field or template not in the configuration or in the removal list, it would simply ignore it.

<?php namespace ProcessWire
class FooPage extends Page {
  
  // "location" one
  public function migrate() {
    $rm = $this->wire->modules->get('RockMigrations');
    $this->cleanup($rm);
    $rm->migrate([
      'fields' => ['foo', 'bar'],
      'templates' => ['footpl', 'bartpl'],
    ]);
  }
  
  // "location" two
  public function cleanup($rm) {
    $rm->deleteField('baz');
  }
}

 

On 10/31/2022 at 11:09 PM, thetuningspoon said:

Another approach would be to ignore any field or template not in the config, and provide a separate "cleanup" function that could be triggered with a button in the admin or a cli command. This would go through and remove any fields or templates that are not listed in the config.

RM does not have this approach. But you listed that as "another approach could be" so I did not take that into account.

On 10/31/2022 at 11:09 PM, thetuningspoon said:

While the config files could be updated automatically as changes are made in the admin interface, I think that any outside changes to the config files should require a manual sync and not be applied automatically. A notice in the admin could alert the superuser that the config file contains unapplied changes and then they could click a button or use a cli command to apply the changes.

I was not sure what you meant by "outside changes" and with your latest post I see that you where more thinking of a GUI way rather than a code solution. So my 100% are maybe a little too much and I'd say you did an 80% description of RM ? But I still don't think it is a good solution. Think of the excel macro recorder... It produces a total mess and you have no control what it does. I don't want that for my projects. I understand that it could work and I'm thinking about that all the time, but I still don't have a good solution. If someone else found it: PERFECT! Please let me know!! I released the module for free so that everybody can use it, everybody can see the code and improve it.

But instead of doing that I see a lot of people begging for "a way to go to the mountains". That's what annoys me. It's the way they talk about ProcessWire and RockMigrations. And that's what I tried to express with my story about the mountains. It's a totally different story if you say "I want to go to the mountains and I tried your car, but I had a huge tent with me (proField) and it did not fit into the baggage compartment (was not supported by the createField() method).

PS: RM works the other way round: You write "code" (it's actually a lot more plain PHP arrays that represent field/template settings) and the changes appear in the backend like magic (when using RockFrontend for live reloading as shown in the video).

On 10/31/2022 at 11:09 PM, thetuningspoon said:

The algorithm for adding new fields and templates should first check for the existence of each field and template by name. If one is missing, it should proceed to create the field or template and with its name and type (but no other settings). After that it can go back and apply the settings for everything, at which point dependencies between fields and templates should resolve without issue (family settings, page fields that reference templates in their settings, etc.).

100% RockMigrations:

First it creates all fields and templates: https://github.com/baumrock/RockMigrations/blob/df2ccefe2df49134c16b622c07e308864880827b/RockMigrations.module.php#L2177

And then it applies all settings: https://github.com/baumrock/RockMigrations/blob/df2ccefe2df49134c16b622c07e308864880827b/RockMigrations.module.php#L2198

On 10/31/2022 at 11:09 PM, thetuningspoon said:

I've been tempted to try working on a module for this for a while now and was close to having a project that required it at work that would allow me to invest the time into it. That project is currently stalled but may still come about at some point at which point I could try working on this if someone else hasn't already gotten to it.

You explain 100% how RM works in the paragraph above and end with "unless someone else hasn't already gotten to it". ? I know how you mean it but maybe you can understand that it's not nice to read for me...

13 hours ago, thetuningspoon said:

Then I read a post you wrote that made it sound like you didn't plan on supporting ProFields and didn't understand why anybody would have need for them since you don't use them yourself. All of our projects use ProFields, so it's a showstopper for us if these aren't going to be supported. And I don't feel like I should really have to justify that need and I'm not interested in arguing about it.

You are quoting me totally wrong here. I did never say that I don't understand why anybody would have a need for them! Quite the contrary, I've bought almost all if not all profields. Some because I use them on every project (ProCache), some because I used them in older projects before I had my own solution (RepeaterMatrix) and some just to support Ryan's great work and free CMS that has helped me in so many ways and is still so much fun to use.

I'm just not keen on adding support for them in my spare time, for free, for people that don't contribute anything to our community. It would be a totally different story if someone asked me to add support for it and sponsored that addition. In RM1 that happened and I see no reason why that should not happen in RM2. And I also see no reason for not adding a trailer hitch to my car so that others can use it with a trailer to bring all their baggage to the mountains...

And I don't think I have to justify that ? 

12 hours ago, thetuningspoon said:

Sorry, I didn't see this comment before my previous post. I know that RockMigrations does not remove fields and templates unless you explicitly request it to. Does RockMigrations support the additional features I mentioned?

• Automatic update of config files when changes are made in the admin (I know it offers the copy & paste feature, which is a great start and preferable when using multiple migration files)
• Order-agnostic migration
• Field/template cleanup function for those not defined in migration files
• Option to only apply changes manually via cli or button press in admin

At the moment no, but I'm happy to accept PR's in any of those directions and for example the last one would be extremely easy to add ? 

For Field/template cleanup I want to add that we both know that this is an unfair argument. You know that this would mean that you'd need to list EVERYTHING in your config before, so that you can afterwards remove one part and make the module remove that as well. So while that might sound a little more comfortable it is just so much more bloat and has so many drawbacks that I thought it would be better to just add those things that are defined in config and if I wanted to remove something simply use deleteField() or deleteTemplate() etc. But it does not mean one could not build it that way. But again: Why should I build that if I don't work that way? Give me a reason and I'll do it (if you don't want to).

13 hours ago, thetuningspoon said:

EDIT: I just looked over the processwire-requests thread on Github again and I see that some other people who have gotten deeper into this already have reported issues with the core JSON export/import module that would need resolving before certain fields could work. Other than the FieldtypeOptions I haven't had many issues lately in my experience. I also saw that you expressed interest in supporting the Combo field in that thread, so I apologize if I've misinterpreted. If RockMigrations can support my fields and desired workflow with just a bit of additional development (from either you, me, or someone else), then I would certainly prefer that to having to write a new module from scratch! 

Yeah I don't know exactly what problems I had, but I've tried using the internal export/import syntax (as it sounds so obvious and good), but it somehow did not work for me. I might revisit that at some point but I had to get things done so I implemented the array syntax (which is by the way a lot more intuitive to use for humans than the core export/import syntax that is built for computers).

I don't see any reason why RM should not be able to support any other field. RM is just an abstraction layer between the human brain and the PW API. The admin interface uses PW API to write GUI interactions into the PW database. So you could also just use PW api if you wanted. But I realised that using the PW api for creating fields/templates/etc is really not as easy as it could be (see createField() as an example) and it does not work the way the human brain works. And our brain works the way the PW GUI works, so we think "create a new template" and we don't think "create a  new fieldgroup, then create a new template and assign that new fieldgroup to that new template". At least my brain works that way.

And that's all RM provides. An easy to use API that can do anything for you that the PW GUI can do (and even more). Everything that we have in the GUI we have in the core API. RM just provides helpers to trigger the right methods in the correct order and catch edge cases etc.

If you find a way to use core json export/import for RM then great. Please let me know and we can work on a solution that supports profields out of the box!

13 hours ago, thetuningspoon said:

Also, I have to say that your car analogy had me in stitches after reading it fully from start to finish. ?

Glad you had fun reading it ? I didn't want to offend you @Ivan Gretsky but sometimes people need a helping hand and sometimes they need a kick in their *** and it's not easy to know when they need what... It sounded like you really want to do migrations so I thought maybe you need a push. If you need help I'm happy to answer all the questions you have. Just please be precise in your explanations and don't do "I tried it but it simply did not work" kind of feedback... Because others might be reading that and might get a wrong impression. And well, yes, I'm happy if people are using the module and liking the module, since that is the only "reward" I get from it (besides being a lot more productive and a lot more professional in my daily work).

[thetuningspoon]

@bernhard Thanks for the clarifications. I think we are on the same page now.

Regarding the order agnostic application of migrations, I had assumed that it was not order agnostic because of something you said to me in the RockMigrations thread about defining dependencies after creating fields/templates. does this also work when you have migrations spread across multiple files?

I guess I am also a bit confused about the difference between using the migrate() function and using the createField() and createTemplate() functions. Is it just a matter of preference or are there differences in how these are processed (i.e. do you need to put everything in a single migrate() in order for it to be order agnostic)? I didn't see anything about the difference between these functions in your documentation and it took me a while to figure out that I should use the migrate function when copying and pasting the data from the field/template back end editor.