mvolke

For all of you who want the model stored in files, maybe you should have a look into Bolt CMS. In Bolt you can configure your content types in YAML files and import them via a migration tool integrated into the CMS. In my opinion this is by far the best approach. This enables... versioning of data structure easy deployment working in teams (because branching/merging in Git workflows is now possible) much faster editing of data structure (for professionals) than clicking through UIs What I miss in this discussion is, what is the audience of users of Processwire? Do we want to be attractive to professionals working for clients (I would count me to this group) or is Processwire just another CMS that will blow up its backend UI (like Joomla, Drupal, Wordpress) because it wants to be attractive to users without any programming skills? My personal opinion is you cannot combine both groups in one system.

I discovered that if I create two thumbnails with the same size but different additional settings only one file (the first setting) is created because the settings are not reflected in the filename. E.g. $image->size(200, 100, array('cropping' => false)); $image->size(200, 100, array('cropping' => true)); In this case the second image won't be cropped. I would expect that two different thumbnail will be generated.

@mindplay.dk This sounds really great. I think it could be the perfect solution in the long run. Until this module is finished and tested, I can recommend the phpmig migrations approach.

1) Migrations I had the same problem during my work with Processwire. If you have a team working on a Processwire project where everyone has his own dev server then you need to be able to version the "structure" you put into Processwire and keep it in sync with the template files. I found it to be important to strictly distinguish between structure and data. In 90% of the cases this means templates and field can be seen as structure and pages would be the data. In my current project I tried to use the concept of migrations with Processwire utilizing the phpmig library. If you strictly create all of your "structure" with migrations and never with the Backend UI then it works perfectly, your structure is always in sync with the template files and you can put both in your favorite VCS. To give you an example of how this works: https://gist.github.com/webholics/6191779 2) Structure vs. Data I'd like to add more thoughts to the problem of mixing structure and data in CMSes. This is not a problem only Processwire has, but most CMSes do this (in my opinion) wrong. If your main target user group are developers, it should be possible to keep those things separate in order to enable professional workflows like continuous integration and TDD. This is only possible if you define the structure in code or in config files and not in the database and via a backend UI. It is always the case that template files and structure are strongly depended on each other. One CMS - I'd like to mention here for inspiration - which implements this concept perfectly is Bolt (http://bolt.cm/) . They use YAML files to configure the database models. Bolt then tries to keep them in sync with the database. Maybe it helps to have a look at how they did it.