Rasso

You are right @bernhard, my wording wasn't completely fair – sorry for that. Thank you for all the time you've put into RockMigrations. Of course you are not obliged to take care of features that you don't need. It's open source, after all. I hope you get some subscriptions for your premium plugins. I guess the person really responsible for all the drama in this thread here is @ryan. I'd expect from a premium module like Pro Fields (NOT FOSS software) that it would provide a robust migration/syncing mechanism along with it. Otherwise, the ecosystem is doomed to playing catch-up forever. I'm pretty concerned with starting to learn and use a new CMS where deployment is such a big pain point. The WordPress vs ProcessWire article needs a serious overhaul IMO. I'm getting more and more frustrated by so many systems claiming that they are superior and then exposing such dirty corners (the ProcessWire panel feels pretty outdated to me as well to be honest).

@gebeer I gave this another try today. Related issue on GitHub: https://github.com/baumrock/RockMigrations/issues/43 Bernhard is not planning to support RepeaterMatrix anymore, as he now has his own module to sell. So I'm afraid it's on us to get it to work ? ...and I won't be a big help as I'm still such a ProcessWire noob ?

For WordPress+ACF it's pretty well explained here: https://www.advancedcustomfields.com/resources/local-json/#saving-explained. ProcessWire "Templates" do not really have a GUI in WordPress, they are being defined using various API functions like e.g. `regster_post_type`, `register_taxonomy`, ... With Kirby I have much less experience, but basically since everything is being defined using code, everything is in version control and synced between environments out of the box anyways. They have a very modular approach anyways, as you can see in their article about blueprints, where in the very first example it's already a plugin: https://getkirby.com/docs/reference/plugins/extensions/blueprints#file-definition

Woaa, thanks @bernhard for your extensive post. I guess with things like these, us devs tend to love what we know ? I think your enthusiasm for RockMigrations is great, but I think it would be enough to describe the mechanics of your module without denigrating other approaches... otherwise you're doing the same thing you've accused others of in this post: criticizing a tool that you haven't used extensively yourself ? – it makes your post feel a bit like you are trying to sell something. Even though it's actually free and open source! ? In WordPress+ACF, this is a non-problem. It's of course possible to create a plugin (the WP equivalent of a ProcessWire module) that contains definitions for Custom Post Types / Taxonomies (defined in code OR via GUI) as well as associated custom fields in JSON files (automatically generated) or even PHP files (the equivalent of your migrations files). The json/PHP files are not meant to be touched manually anyways, so no need to understand them – although they are easy enough to understand with some experience. In Kirby, it's absolutely different: there is no GUI for creating fields, anyways. All structure is being defined via code. So one could argue that their approach is not too different from using your module with writing migrations by hand, except they are using YAML wich was a total black box to me. Compared to that, your vscode snippets seem to be a clever solution. Not a problem in either WordPress or Kirby. Both allow to create re-usable templates, types and fields and put them in a plugin (=module) Yes I can read diffs ?. That's exactly how diffing would look in both WordPress and Kirby, as well. Only the things that changed, changed. Anyhow... I feel, like after some time I'll learn to love whatever system I end up using for ProcessWire migrations. That's how us developers are built right? I'm definitely a victim of Stockholm Syndrome in that regard sometime ?

Wow guys, that's a very lively discussion here! Appreciate it ? @gebeer thanks so much for pointing out that support for RepeaterMatrix has landed in RockMigrations! I guess I must have just missed it in my last project. I'll certainly give RockMigrations another go after all the passionate feedback here ? Since I know my forgetful self, a fully automated solution would be my gold standard: automatically generate and save migration files every time I create / update any field or template locally don't allow to edit or even access templates & fields in a production environment, at all @bernhard do you have a pointer how I could setup that behavior using RockMigrations? I don't want to overstrain your patience, but if you have a few quick links for me I'd be very grateful. I'll make sure to RTFM ? @MarkE I'll definitely also give your module a go when it's ready ❤️

@MarkE that sounds very promising to me! Have you thought about reaching out to @ryan about possibly merging your module into core and/or work on the functionality together? That's how I know it from WordPress – new feature proposals are often first being developed in so-called "Feature Plugins", and merged into the core as soon as they are ready for prime time. In my opinion, the problem with using modules for central functionality like this is, that they might become deprecated, as it happened with the original Migrations module. Also, you would have to carry the burden of making sure that the module would continue to work with the ProcessWire field types. That's why I'd always prefer functionality like this to be as close to the core as possible. Either in core or as a Pro plugin. This definitely sounds like something I'd reach out to Ryan about. You probably know the saying... "If you want to go fast, go alone. If you want to go far, go together" ?‍♂️

To add a bit more information: In the website I built with PW, I was using the Pro field Repeater Matrix. I tried RockMigrations (as the original Migrations module has been deprecated) with that field and it didn't work (can't remember what exactly went wrong, sorry for not documenting my findings better). I would be very open to pay for a new module Pro Migrations by the core team of ProcessWire, if that could provide a robust experience that would integrate with all pro fields.

Dear ProcessWire folks! First of all, thanks for all your work on this amazing CMS @ryan and contributors! ❤️ I'm a WordPress guy with 10+ years experience. I'm well aware of the shortcomings of WP (chaos API, no built-in multilingual support, to name a few), but was always able to find a way to work around these. In 2023, due to the never-ending praise from some of my developer peers, I finally gave ProcessWire (and also Kirby CMS) a try for two small projects. If nothing else, these excursions gave me a more senior perspective on the advantages and shortcomings of these three content management systems (none of them is perfect). I was impressed by many thoughtful decisions in ProcessWire's setup, data structure and API. But I am missing one last thing that both WordPress and Kirby have solved in a very clean an comfortable way: A clean solution for deploying fields between environments and committing them to version control. ✅ In WordPress, I am using Advanced Custom Field's local JSON feature for this ✅ In Kirby, all fields and templates are being defined using YAML blueprints, so they are also easy to deploy and version control (although YAML configs come with their own set of shortcomings ?) ❌ In ProcessWire, I couldn't work out a reliable way to define (/autosave/sync) the fields in my code base. So, my question is: Is there any chance the core team will give first-class support for programmatic deployment of fields another thought? If not, what are the considerations that lead to this decision? Syncing fields manually between environments is too cumbersome and error-prone for my taste. I know my request is not new, but the information available felt a bit outdated and not very convincing to me. I'd like to start a discussion here based on facts, not opinions.