Share your PW dev setups / tools

adrian · January 7, 2022

2 hours ago, MoritzLost said:

To be honest, for new projects I'm currently settled on option 3: to not use ProcessWire at all, unless the project won't require any significant updates after launch. Even all the problems mentioned above can be solved one way or another, it's just not worth it compared to other systems where I get full compatibility with version control by default.

I'd love to know your favorite PW alternative - if something else exists with all the features, flexibility and ease of PW which also has full compatibility with version control, that would be perfect. Surely it would require a flat file database, but even that has its problems when it comes to data querying, doesn't it?

szabesz · January 7, 2022

2 hours ago, MoritzLost said:

Yeah, that's close to what I'm doing for updates as well. As long as you're keeping track of any field/template changes diligently, it's not too much work. Though it still bugs me doing the same thing twice. And of course it doesn't solve the problem of working on an update with multiple people at the same time.

The good thing that the most important bits needed by native migration features are there. The bad thing is that it is not completely automated. If you already spotted the missing bits, maybe you (including Horst, since he does something similar) could cooperate with Ryan on implementing the "rest"?

I am asking this because I am planning to apply this method as well in the future.

MoritzLost · January 7, 2022

1 hour ago, adrian said:

I'd love to know your favorite PW alternative - if something else exists with all the features, flexibility and ease of PW which also has full compatibility with version control, that would be perfect. Surely it would require a flat file database, but even that has its problems when it comes to data querying, doesn't it?

@adrian Last year we've started using Craft CMS for some new projects, which has full support for version control out of the box. In terms of feature set it's quite similar to ProcessWire – you can define your own fields and entry types (similar to ProcessWire templates) and create custom field layouts. It's not a flat-file system, it does use a database. It also provides an API similar to ProcessWire's $pages to query for entries (pages) or other data. To keep track of schema changes, Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder. Those can be version controlled, merged and reasoned about easily. You can even read a pull request in Github and see what changes it introduces to field/entry type settings, it's great. It's called project config, here's the documentation. Particularly pleasant is that you can still use the backend to create fields and field layouts – every change in the backend is automatically written to the config folder. So you can just create field layouts in the backend and everything you need to track it in git is already there when you're done. To propagate changes between environments, the CLI has commands to apply the project config to the current environment (database).

I was thinking about writing a comparison between ProcessWire and Craft CMS regarding feature set, support for version control and development experiences. There are some good ideas there that ProcessWire could really benefit from.

BTW, if you want to track content in git as well as configuration – we also looked at Statamic, which does support flat files and can commit every backend edit to git. Haven't tried it though.

@szabesz Not sure if it's that easy, making every aspect of ProcessWire version control friendly would require massive reworks. Including making ProcessWire and it's module installable through Composer and reworking the directory structure to have a better distinction between content and config, as well as dependencies and custom code. This would need to be ProcessWire 4 (at least). Not sure this can be done if ryan isn't looking to put massive amounts of work into this. I don't have the impression that this is the direction ProcessWire is going – though I'm happy to be proven wrong.

elabx · January 7, 2022

4 hours ago, MoritzLost said:

So all your sites are identical in feature set? That definitely doesn't apply to our projects ?

Well in this scenario I was talking about a particular project that is more "app like". But the rest of sites I manage, which might have specific features regarding template/fields, different templates that are for one specific website/design, I handle them the same way, repo and deployment through pipelines.

4 hours ago, MoritzLost said:

it's just not worth it compared to other systems where I get full compatibility with version control by default.

I'd love to hear about what other things you've tried if you'd be keen on sharing. I've seen some folks move to Statamic/Kirby for this purpose.

4 hours ago, MoritzLost said:

But handling everything in code is a pain as well.

Thinking about this I've thought a "migration recorder" built on field save hooks, would be neat. Like, you're doing your work on PW thinking about the awesome features you wanna build, building repeaters/matrix, changing file widths, show conditions, all those things we love. Then you go into Setup > Migrations and you find all the work you just did on your repeater field recorded. Just a thought for one part of the whole problem. EDIT: I just read about the YAML thing Craft does, thanks for sharing! ?

benbyf · January 7, 2022

5 minutes ago, elabx said:

Well in this scenario I was talking about a particular project that is more "app like". But the rest of sites I manage, which might have specific features regarding template/fields, different templates that are for one specific website/design, I handle them the same way, repo and deployment through pipelines.

I'd love to hear about what other things you've tried if you'd be keen on sharing. I've seen some folks move to Statamic/Kirby for this purpose.

Thinking about this I've thought a "migration recorder" built on field save hooks, would be neat. Like, you're doing your work on PW thinking about the awesome features you wanna build, building repeaters/matrix, changing file widths, show conditions, all those things we love. Then you go into Setup > Migrations and you find all the work you just did on your repeater field recorded. Just a thought for one part of the whole problem. EDIT: I just read about the YAML think Craft does ?

They had a similar thing I've used in Drupal 7 (back in the day), you would edit the Drupal config in the admin and it would track changes which can then be exported and imported or git'ed up and then executed on your live server either pressing a button or by adding a hook

bernhard · January 7, 2022

4 hours ago, MoritzLost said:

Can the array syntax for fields/templates handle field overrides in a template context as well?

Yes

<?php
$rm->migrate([
  'templates' => [
    'car' => [
      'fields' => [
        'title' => [
          'label' => 'Name of the Car',
          'columnWidth'=>50,
        ],
        'km' => ['columnWidth'=>50],
      ],
    ],
  ],
]);

voila. fields "title" and "km" will be 50% width in the car template context. the title field will have a custom label on the car template.

It's really that simple most of the time! Change some properties, commit, push, done!

4 hours ago, MoritzLost said:

Look real close to a version-controllable schema config.

What are you missing?

4 hours ago, MoritzLost said:

How would you approach an existing site that doesn't use migrations – add all the existing fields to one big migration file? Or include a database dump as the base state and perform all further changes in the form of migrations?

Depends. Both are possible. RockMigrations is really also great if you add it later on a project that did not handle migrations before. It really does not care. For example you could add this in your ready.php:

<?php
$rm = $modules->get('RockMigrations');
$rm->createField('test', [
  'type' => 'text',
  'label' => 'Testing RockMigrations',
]);
// add field test to home template after the title field
$rm->addFieldToTemplate("test", "home", "title");

You'll have your test field right after the title field of the home template. You can do the same for everything you add to your site. Doing it like this, of course, the migration will run on every page request. The great thing about the migrations is that this will just work! It's not ideal of course, but I just want to show how it works. Add another field? Here we go:

<?php
$rm = $modules->get('RockMigrations');
$rm->createField('test', [
  'type' => 'text',
  'label' => 'Testing RockMigrations',
]);
$rm->createField('test2', [
  'type' => 'text',
  'label' => 'Testing RockMigrations again',
]);
$rm->addFieldToTemplate("test", "home", "title");
$rm->addFieldToTemplate("test2", "home", "test");

Now we got two fields.

Ok, we want those fields in a row? Lets refactor this (it would be possible using the syntax from above as well, but I just prefer the array syntax as it has everything in place):

<?php
$rm = $modules->get('RockMigrations');
$rm->migrate([
  'fields' => [
    'test' => [
      'type' => 'text',
      'label' => 'Testing RockMigrations',
    ],
    'test2' => [
      'type' => 'text',
      'label' => 'Testing RockMigrations again',
    ],
  ],
  'templates' => [
    'home' => [
      'fields' => [
        'title' => ['columnWidth'=>33],
        'test' => ['columnWidth'=>33],
        'test2' => ['columnWidth'=>33],
      ],
    ],
  ],
]);

Commit, Push, Done. So do you really think manually creating those fields was quicker? Even if you create those fields remotely first and then pull a DB dump and you have at least semi-automated the process and a dump takes "only 15 seconds or so"... I bet migrations are quicker, more versatile, more powerful.

Let's say you want to tidy up your project a little bit. Let's add tags for those two test fields:

<?php
$rm = $modules->get('RockMigrations');
$rm->migrate([
  'fields' => [
    'test' => [
      'type' => 'text',
      'label' => 'Testing RockMigrations',
      'tags' => 'RockMigrationsTests', // <----- add this
    ],
    'test2' => [
      'type' => 'text',
      'label' => 'Testing RockMigrations again',
      'tags' => 'RockMigrationsTests', // <----- add this
    ],
  ],
  'templates' => [
    'home' => [
      'fields' => [
        'title' => ['columnWidth'=>33],
        'test' => ['columnWidth'=>33],
        'test2' => ['columnWidth'=>33],
      ],
    ],
  ],
]);

Thats it!

Both fields live under that new tag:

Nice and clean!

Ok, now let's remove those changes: The IDE will help you find the right method...

So we can do:

/** @var RockMigrations $rm */
$rm = $modules->get('RockMigrations');
$rm->deleteFields("tags=RockMigrationsTests");
$rm->setFieldData("title", ["columnWidth"=>100], "home");

How long would it take you to delete those two fields manually? Making sure that all checks are met ("you can't delete this field... it is used by XX templates..." *#*&!), going back to the templates editor, removing the field first, then deleting the field, then going back to the home template and setting the title field back to 100%... I don't know the exact workflow - I haven't done that for a long time now ? Yeah and we are not even talking about doing those changes in a team... Have fun ?

Yeah, @adrian, I know Tracy can help. Just trying to show how quick you can get when doing things using RockMigrations. Of course there are some situations where you might not know the properties you need to set. But Tracy can help you. Or you inspect the inputfield and lookup the name in your devtools. The nice side effect: You learn a lot about PW and you will understand it a lot better and improve even more.

Well... I don't know what more to say. I feel your pain, but I don't really understand why there are many here "complaining" about those missing features of ProcessWire but nobody seems to be using RockMigrations or seems to have given it an hour or two to simply try it out... ?‍♂️

PS: I know the example runs migrations on every page request, which is not ideal. You can come up with your own strategy to prevent that or you can simply use $rm->fireOnRefresh() so migrations will only fire on modules::refresh

5 hours ago, MoritzLost said:

I'm a bit of an all-or-nothing person, if I can't have 'clean' version control I'd rather not have version control at all. Probably unwise. To be honest, for new projects I'm currently settled on option 3: to not use ProcessWire at all, unless the project won't require any significant updates after launch. Even all the problems mentioned above can be solved one way or another, it's just not worth it compared to other systems where I get full compatibility with version control by default. I don't think this will change as long as ProcessWire doesn't support version control natively.

I'm maybe similar. There's not a single new project not using RockMigrations and custom PageClasses now. It might be overkill for some, but I think for people that are asking questions that you are asking RockMigrations is just the right tool and you are missing something.

5 hours ago, MoritzLost said:

to not use ProcessWire at all, unless the project won't require any significant updates after launch

That would be a pity. We need more people like you here ?

5 hours ago, MoritzLost said:

But handling everything in code is a pain as well.

Sometimes life as a developer is hard. But we get paid for that ??

5 hours ago, MoritzLost said:

But I do want translations in my version control, turns out those are in random directories in the assets folder … the list goes on.

I agree on that. I'm working on it and I wished more were doing so ?

5 hours ago, MoritzLost said:

And what about ProcessWire itself, I don't want the entire core in my version control.

Why not?

5 hours ago, MoritzLost said:

There are just so many small issues if you want a 'complete' version controlled ProcessWire site, which to me means (1) the site can be rebuilt completely from the repository alone and (2) there's no external code or dependencies. And if you solve all of these with scripts, those become hard to manage and even harder to enforce in a team … not sure where I'm going with this to be honest ?

I agree it's not perfect, but I've put hard work into making this possible over the last years. And I think I've come very far. I don't know much other systems though, so I might be on the wrong track. If you know any better systems I'm just as happy to hear about them as @adrian

bernhard · January 7, 2022

On 1/7/2022 at 4:40 PM, MoritzLost said:

@adrian Last year we've started using Craft CMS for some new projects, which has full support for version control out of the box. In terms of feature set it's quite similar to ProcessWire – you can define your own fields and entry types (similar to ProcessWire templates) and create custom field layouts. It's not a flat-file system, it does use a database. It also provides an API similar to ProcessWire's $pages to query for entries (pages) or other data. To keep track of schema changes, Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder. Those can be version controlled, merged and reasoned about easily. You can even read a pull request in Github and see what changes it introduces to field/entry type settings, it's great. It's called project config, here's the documentation. Particularly pleasant is that you can still use the backend to create fields and field layouts – every change in the backend is automatically written to the config folder. So you can just create field layouts in the backend and everything you need to track it in git is already there when you're done. To propagate changes between environments, the CLI has commands to apply the project config to the current environment (database).

Sorry I missed your second post... Actually something similar would already be possible using RockMigrations. At least for basic setups. I'm not sure how that can work for more complex setups though. I'll try to explain that by an example:

Let's say we created a new blog module. We need a blog page (parent) and several blog-items (children):

- home
   '- blog
       |- blog entry 1
       |- blog entry 2
       ...

This setup could easily be built into a module using rockmigrations:

<?php namespace ProcessWire;
class MyBlog extends WireData implements Module {

	public static function getModuleInfo() {
		return [
			'title' => 'MyBlog',
			'version' => '0.0.1',
			'summary' => 'blog module using rockmgirations',
			'autoload' => true,
			'singular' => true,
			'icon' => 'smile-o',
			'requires' => [],
			'installs' => [],
		];
	}

	public function init() {
		$this->rm()->fireOnRefresh($this, "migrate");
	}

	public function migrate() {
		$this->rm()->migrate([
			'fiels' => [...],
			'templates' => [
				'blog_parent' => [...],
				'blog_item' => [...],
			],
		]);
		$this->rm()->setParentChild('blog_parent', 'blog_item'); // --> this sets the family settings for both the parent and the child template - how long does that take by hand? ;) It means that all pages having the "blog_parent" template will create a "blog_item" page automatically when you click on "add new page". Basically the stuff that you set on the family tab of the template.
	}

	/**
	 * @return RockMigrations
	 */
	public function rm() {
		return $this->wire->modules->get('RockMigrations');
	}

}

That means I'm literally defining my config in the module code. We could also have the config read from a config.yaml - that would really be the same (just less powerful IMHO)!

The problem arises when you want to make that config customizable. For example you want a page reference field to select the author for every blog post. Building that into the blog module would probably not be a good idea because not every site might need such a field. What I do in such situations is this: I make the migrate() method hookable and create one module that handles all the project-specific stuff:

<?php namespace ProcessWire;
class MyProject extends WireData implements Module {

	public static function getModuleInfo() {
		return [
			'title' => 'MyProject',
			'version' => '0.0.1',
			'summary' => 'module that handles site specific stuff',
			'autoload' => true,
			'singular' => true,
			'icon' => 'smile-o',
			'requires' => [],
			'installs' => [],
		];
	}

	public function init() {
		$this->addHookAfter("MyBlog::migrate", $this, "migrate");
	}

	public function migrate(HookEvent $event) {
    $this->rm()->createField("author", "page", [
      'label' => 'Select the author',
      ...
    ]);
		$this->rm()->addFieldToTemplate("author", "blog_item", "title");
	}

	/**
	 * @return RockMigrations
	 */
	public function rm() {
		return $this->wire->modules->get('RockMigrations');
	}

}

That means you can have your blog module that you can reuse from project to project (and improve it and just pull changes if you need to) and you can still customize it the ProcessWire way (which we all love I guess).

BUT

Now we got a new field on the "blog_item", the "author" field. So the config.yaml of the blog module would change, wouldn't it? I'm not sure how CraftCMS handles such situations? And that's one of the reasons why I think that efforts like this are going in a wrong direction. It sounds intriguing for sure to have something like a "migrations recorder". I'm working or at least thinking about that since 2016. But I simply can't imagine a way that could reliably work in all situations.

RockMigrations does. And it does it really well. And it does it for almost 3 years now and has evolved a lot. It's still not perfect for sure. But I don't think that

On 1/7/2022 at 4:40 PM, MoritzLost said:

Not sure if it's that easy, making every aspect of ProcessWire version control friendly would require massive reworks. Including making ProcessWire and it's module installable through Composer and reworking the directory structure to have a better distinction between content and config, as well as dependencies and custom code. This would need to be ProcessWire 4 (at least). Not sure this can be done if ryan isn't looking to put massive amounts of work into this. I don't have the impression that this is the direction ProcessWire is going – though I'm happy to be proven wrong.

This feels wrong. I'dont know how to explain. I think you have a good understanding of composer and such things. Likely a much better understanding than I have. So if it is true what you are saying, I must be doing a lot wrong in my daily work or at least I must be understanding a lot wrong... Because a lot of my workflows do feel very version control friendly. And I've lately started working in a company in vienna where we work on ProcessWire projects with fully automated workflows. We work in a team. We work on different local machines. We deploy to staging and if everything works (which has been the case 100% so far), we deploy to production with a single click.

But maybe I'll change my opinion some day and look back and laugh. Maybe I should just try CraftCMS. Maybe many other fancy new tools. At my company they also work (or worked) with another CMS. They said they liked to be able to define fields and templates in code. They said that was one of the (few) things they didn't like about ProcessWire, because they love professional workflows and automated deployments... But they also admitted, that it was somewhat painful to define fields and templates in the other CMS. They said you have to add pieces of config in that file, then change another piece in another file. And end up changing many files for simple changes.

Now they like RockMigrations ? And such comments make me think I am on a right track and we as ProcessWire enthusiasts are not that far away from what you seem to be missing.

@MoritzLost have you ever heard someone saying "ProcessWire is great for small websites, but not for larger, more complex ones"? We all know how wrong that is, don't we? That's the way I feel when people here on the forum are talking about missing migration / version control features...

PS: I tried to keep this post short and not so emotional. I think I failed, sorry ?

Robin S · January 8, 2022

12 hours ago, MoritzLost said:

I was thinking about writing a comparison between ProcessWire and Craft CMS regarding feature set, support for version control and development experiences.

Please do, I'd be very interested to read that!

12 hours ago, MoritzLost said:

To keep track of schema changes, Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder. Those can be version controlled, merged and reasoned about easily.

It seems like this should be doable via a module in PW. I have a work-in-progress module that does something like this. It's not complete and haven't looked at it a while but it seemed like a promising avenue at the time. I think if the concept could be illustrated in a module then Ryan might see the benefits and then hopefully incorporate the features into the core.

Seeing as you've clearly spent some time thinking about these issues, would you mind writing up a wishlist of what things you think PW should handle via files for the sake of version control? Fields and templates are the obvious things but you also mentioned translations which I wouldn't have thought of (I only work on single language websites) so it would be great to have a comprehensive list of problem areas for version control. Thanks in advance! ?

rastographics · January 8, 2022

On 1/3/2022 at 11:36 AM, elabx said:

I use bitbucket pipelines for deployments, and it's a very simple script involving rsync and running the Migrations CLI.

would love to see your script for pipelines. I tried setting this up a couple years ago and gave up.

wbmnfktr · January 9, 2022

On 1/7/2022 at 4:40 PM, MoritzLost said:

Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder

This would be some kind of a dream for me to have in ProcessWire.
Wasn't there a Wishlist somewhere for features to include in PW that @ryan takes as a kind of inspiration?

If I could I vote for something like that 100 times TBH.

bernhard · January 9, 2022

12 hours ago, wbmnfktr said:

On 1/7/2022 at 4:40 PM, MoritzLost said:

Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder

This would be some kind of a dream for me to have in ProcessWire.

?‍♂️

szabesz · January 9, 2022

Thanks for the showcase @bernhard! What I would personally still need is ProcessWire "recording" my manual modifications in the admin, so that I do not have to remember too much, as I can't. At least not this sort of thing, becasue I do not have to do it on a daily bases. In fact, often I do not work with PW on a daily bases, PW is "just" – albeit a very important – a tool for me, which I use from time to time. So the more I don't even have to memorize the better.

bernhard · January 9, 2022

TracyDebugger shows all the available options, so you don't have to remember them already. But you have to write them down manually at the moment. I guess it would be possible to create that yaml file on the fly. If tracy knows all the settings and can write them to the panel I'm quite sure it is possible to write them to a yaml file as well. Maybe @adrian can tell us something about that?

bernhard · January 9, 2022

Did a quick test:

wbmnfktr · January 9, 2022

Ok... that's what I meant @bernhard.

Awesome!

gebeer · January 10, 2022

12 hours ago, bernhard said:

Did a quick test:

This is totally freaking awesome! Can't give enough thumbs up. Any plans to release this? Wannahave ? That would just be such a great help for keeping things in sync.

elabx · January 12, 2022

On 1/8/2022 at 5:44 PM, rastographics said:

would love to see your script for pipelines. I tried setting this up a couple years ago and gave up.

Basically something like this:

image: atlassian/default-image:2

definitions:
  # Copy files and exclude the ones from .gitignore,
  # which includes logs and custom overrides out of version control.
  # Run latest migrations if existing.
  script: &deploy-script
            rsync --stats
            --human-readable
            --recursive
            --delete-after
            --no-perms
            --no-owner
            --no-group
            --exclude-from=$BITBUCKET_CLONE_DIR/.gitignore
            --exclude="bitbucket-pipelines.yml"
            $BITBUCKET_CLONE_DIR/* $SERVER_USER@$SERVER_ADDRESS:$APP_PATH;
            ssh $SERVER_USER@$SERVER_ADDRESS "php $APP_PATH/modules/Migrations/bin/migrate run";

pipelines:
  branches:
    main:
      - step:
          name: awesomewebsite.com
          script:
            - SERVER_USER=$USER
            - SERVER_ADDRESS=$SERVER
            - APP_PATH=$PATH
            - *deploy-script
   dev:
      - step:
          name: dev.awesomewebsite.com
          script:
            - SERVER_USER=$DEV_USER
            - SERVER_ADDRESS=$DEV_SERVER
            - APP_PATH=$DEV_PATH
            - *deploy-script

So it's like a tad bit more fancy FTP upload lol

MoritzLost · January 14, 2022

On 1/7/2022 at 4:47 PM, elabx said:

I'd love to hear about what other things you've tried if you'd be keen on sharing. I've seen some folks move to Statamic/Kirby for this purpose.

@elabx Craft CMS ? I'm also trying to move towards static site generator and headless and/or git-based CMS (like Forestry or Netlify CMS). My personal websites are built with SSG and hosted for free on Netlify (processwire.dev & mehrlicht.photos) – though those don't use a CMS at all. But most of the tools for the SSG/Jamstack approach are built to accomodate version control from the ground up. I've been eyeing Prismic, hopefully I'll get a project soon where I can try that out. Though it's hard to find clients for static sites + CMS right now, most have never heard of it …

On 1/7/2022 at 4:54 PM, benbyf said:

They had a similar thing I've used in Drupal 7 (back in the day), you would edit the Drupal config in the admin and it would track changes which can then be exported and imported or git'ed up and then executed on your live server either pressing a button or by adding a hook

@benbyf Drupal 8/9 has that as well, Configuration Synchronization, but it's a pain to use (like Drupal itself). Luckily I migrated the last Drupal project I had to actively support away from Drupal and to Craft CMS last year ?

@bernhard Thanks a lot for the detailed explanation and all the code examples! For the next bigger ProcessWire project, if there is one, I'll be sure to use RockMigrations. Sounds like it solves my problem regarding project schema / config well.

But there's still a cost associated with this – every developer needs to know how to use it and not shoot themselves in the foot. How does a new developer install and work on the project from the repository? Is it as simple as composer install, php craft install, npm ci, npm run build? Because every additional step is something we don't have to do when using a CMS with first-party git support. For example, how do you install ProcessWire in this case? Manually? That's work I don't have to do if I can just composer install. Sure, I can hook something up to install ProcessWire using composer scripts on install (in fact, I have done something like this for our starter template which is under version control). But now I have a custom script that I need to maintain, fix if it breaks. Or I put the core in my version control, which means I have to litter my version history with core files. (BTW I could use git submodules but somehow nobody knows they're a thing ?)

There are more issues like this as I mentioned (e.g. the issue regarding default selected pages in page reference fields; folders containing a mix of files that should and shouldn't be in version control; modules that don't use composer, …). Every one of those can be solved. But every solve either comes with some trade-off (like keeping not project related files in git) or with a maintenance cost and learning curve for a custom solution. And that's a hard sell if there are systems that don't require all that work.

Beyond that, I have zero guarantees from the core that all those custom solutions will still work with the next core version (the lack of semantic versioning for the ProcessWire core doesn't help either). There are also side-effects to there not being explicit support from the core regarding those setups – for example, if we want to outsource something to an external developer or train a new hire, we can't just point them to the ProcessWire docs, but have to teach 'the way' to them. For Craft projects, we just follow the standards.

Besides the problems I mentioned, there are also advantages that come from the fact that Craft supports version control explicitly and is geared towards it. For example, the production site will not allow any configuration changes (new fields, setting changes, etc) by default. So I have a guarantee that that the configuration will be exactly as I left it so I can deploy with confidence from the repository. With ProcessWire, I don't have a guarantee that nobody has changed some field setting in production while I was on holiday. Of course, not changing stuff in production can be established as a rule, but it's again something to be consciously aware of and enforce, instead of having the system enforce it.

I feel like there isn't one single answer to this debate. I hear you – it's easier to complain than work on solutions. Not every project needs a totally 'clean' version control. Trade-offs are acceptable and arguably what we are paid for. I think there's room for multiple CMS with maybe slightly different focus. Right now I'm in the planning stage for a new ProcessWire project that I'm looking forward to. It's just a matter of using different tools depending on the job, no need for a single CMS to rule them all ?

On 1/7/2022 at 6:41 PM, bernhard said:

BUT

Now we got a new field on the "blog_item", the "author" field. So the config.yaml of the blog module would change, wouldn't it? I'm not sure how CraftCMS handles such situations? And that's one of the reasons why I think that efforts like this are going in a wrong direction. It sounds intriguing for sure to have something like a "migrations recorder". I'm working or at least thinking about that since 2016. But I simply can't imagine a way that could reliably work in all situations.

Not sure I understand the problem; with Craft, the project config is always the source of truth and the interface is just window dressing to edit the project config. If you're using external modules, they have to be built to support project config, but most plugins are by now.

On 1/7/2022 at 6:41 PM, bernhard said:

@MoritzLost have you ever heard someone saying "ProcessWire is great for small websites, but not for larger, more complex ones"? We all know how wrong that is, don't we? That's the way I feel when people here on the forum are talking about missing migration / version control features...

I have said that myself ? After having supported a larger project with regular updates for a while now, which is a bit of a pain. Maybe it would go better if we'd used RockMigrations from the start! Hindsight is 20/20 …

On 1/8/2022 at 5:17 AM, Robin S said:

Seeing as you've clearly spent some time thinking about these issues, would you mind writing up a wishlist of what things you think PW should handle via files for the sake of version control? Fields and templates are the obvious things but you also mentioned translations which I wouldn't have thought of (I only work on single language websites) so it would be great to have a comprehensive list of problem areas for version control. Thanks in advance! ?

@Robin S I'll try to get around to that comparison between Craft CMS and ProcessWire, which would include all the issues regarding version control. But knowing me and my tendency of feature-creep for articles that might take a while ?

elabx · January 14, 2022

On 1/7/2022 at 9:40 AM, MoritzLost said:

I was thinking about writing a comparison between ProcessWire and Craft CMS regarding feature set

This would be great!

dotnetic · January 17, 2022

@bernhard The YAML recorder and migration of the project.yaml look awesome. Any plans to release these additions to RockMigrations?

I think this is a good way to make fields and templates version controlled. Having a feature like the YAML config and recorder added to the core would be a very good thing IMHO. The not programmable definition of fields and templates and migrating contents and structure to a live server is cumbersome (without RockMigrations) and led me to try out alternatives to ProcessWire in the past.
I used Statamic and Kirby which both have configuration files for fields/templates, which can be version controlled and I really like the way it's done.

bernhard · January 18, 2022

On 1/17/2022 at 8:47 PM, dotnetic said:

The YAML recorder and migration of the project.yaml look awesome. Any plans to release these additions to RockMigrations?

thx! I'm thinking about it. But I think not to the current version. RockMigrations has evolved over the last years and it's time to refactor and clean up and that would be a good opportunity.

What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array. That's almost the same as a YAML file but you can do additional things if you want or need. See this example:

<?php namespace ProcessWire;
/** @var RockMigrations $rm */
return [
  'fields' => [
    'foo' => [
      'type' => $wire->languages ? 'textlanguage' : 'text',
    ],
  ],
  'templates' => [
    'demo' => [
      'tags' => RockMails::tags,
      'fields-' => [
        'title',
        'foo',
      ],
    ],
  ],
];

That migration file would add a "foo" field and depending on the system make this field single or multi-language. That would be just one example which would not be possible using YAML syntax. Another thing is using class constants. Possible in PHP (see RockMails::tags in the example above), not possible in YAML.

I'm really curious what it is really about, thx.

zoeck · January 18, 2022

30 minutes ago, bernhard said:

What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array.

That's exactly what I always think. It already bugs me with Docker Compose and also with other tools.

But your recorder looks really cool ?

szabesz · January 18, 2022

1 hour ago, bernhard said:

Possible in PHP

Well, editing YAML is easier, that's what YAML is about, after all. However, most PHP developers are probably more familiar with the PHP syntax than the YAML syntax and since the recorder would generate the text file, a developer would just read the file and not edit it anyway (at least that would be the point, wouldn't it?) So yeah, PHP looks a lot more feasible than YAML.

benbyf · January 18, 2022

2 hours ago, bernhard said:
thx! I'm thinking about it. But I think not to the current version. RockMigrations has evolved over the last years and it's time to refactor and clean up and that would be a good opportunity.

What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array. That's almost the same as a YAML file but you can do additional things if you want or need. See this example:
<?php namespace ProcessWire;
/** @var RockMigrations $rm */
return [
  'fields' => [
    'foo' => [
      'type' => $wire->languages ? 'textlanguage' : 'text',
    ],
  ],
  'templates' => [
    'demo' => [
      'tags' => RockMails::tags,
      'fields-' => [
        'title',
        'foo',
      ],
    ],
  ],
];
That migration file would add a "foo" field and depending on the system make this field single or multi-language. That would be just one example which would not be possible using YAML syntax. Another thing is using class constants. Possible in PHP (see RockMails::tags in the example above), not possible in YAML.

I'm really curious what it is really about, thx.

I'm guessing that is any file format that shows changes to the system that can be commited to another system. PW uses json for its template and field export import... so I'm guessing it really doesnt matter... but (kinda of my original point about this module) that migrations, in my mind, are about reflecting changes, where as RockMigration goes a step further and basically sticks all config in code. I would prefer using PW for config (opening the door to less technical admins for example), and have those changes migratable like templates and fields but in a way that is less cumbersome. The fact you can code up your cofig isnt really migration to me, the migration is because of changes, where ever the changes happen.

gebeer · January 19, 2022

6 hours ago, bernhard said:

What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder?

I am more excited about the recorder than about YAML. And I see your point. When using a PHP array for the migrate() method, you can do things that you can't do in YAML. But on the other hand, for recording changes locally and than migrating them to staging/live, YAML would be sufficient.
Your use case, where you setup fields and templates for a RockMails module with RockMigrations is different. When installing that module, it needs to check whether it is being installed on a multilang site or not.
But when recording and migrating changes, we already know the context for the migration since it has been recorded through YAML.

My conclusion would be to store the recorded data in YAML or JSON. For other use cases, like you described, we can still use a PHP array.

Sign In

Share your PW dev setups / tools

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Similar Content