mindplay.dk Posted November 11, 2012 Share Posted November 11, 2012 EDIT: This project has been put on ice - I don't work with ProcessWire in my day job anymore, so this project is looking for a new maintainer. Knowing that, you can decide whether it's worthwhile reading through 7 pages of posts EDIT: The source code has been dumped on GitHub - feel free to fork and have at it. There's one thing about ProcessWire that pains me, and I've brought this up before - it's the same problem I have with e.g. Drupal...Because the meta-data (Configuration, Fields and Templates) is stored inside the database, once you have a live site and a development site, moving changes from the development site to the live site is, well, not really possible.Repeating all the changes by hand on the live site is simply not an option I'm willing to consider.Telling the client to back off the site and give me a day or two to make the changes, and then moving the whole database after making and testing the changes on a development site, is really a pretty poor solution, too.I had heard some talk about a module in development, which would make it possible to import/export Fields and Templates? It sounds like that would mostly solve the problem.Ideally though, I'd really like a solution that records changes to Fields and Templates, and allows me to continuously integrate changes from one server to another.So I started hacking out a module, but I'm not sure if it's going to work at all, if it's even a good idea, or if it's worth the effort. I'm looking for feedback on the idea as such, more than the code I wrote, which isn't real pretty right now. Anyway, have a look:https://gist.github.com/b7269bb7bd814ecf54fbIf you install this, create a "data" folder under the module's folder - migration files will be written there.Basic overview of the idea and code: The module hooks into Fields::load() and takes a "snapshot" of the current Field properties and settings on start-up. It also hooks into ProcessField::fieldSave() and when a field is saved, it compares it's properties and settings to the snapshot it took at startup - if changes were made, it writes the previous name and updated properties into a file. The same thing is not implemented for Templates yet, but would be. The migration-files are named like "YYYY-mm-dd-HH-mm-ss.json", so that they can be sorted and applied in order. Each file contains a JSON representation of a method-call - currently only updateField() which would repeat a previous set of changes and apply them to another installation of a site. (not implemented) So basically, the module would record changes to Fields and Templates, and would be able to repeat them.How those files get from one system to another is less of a concern - would be cool if servers could exchange migrations semi-automatically, using some kind of private key system, but initially, simply copying the files by hand would suffice.I'm more concerned about the whole idea of capturing changes and repeating them this way.Any thoughts? Is this approach wrong for some reason? Would this even work? 11 Link to comment Share on other sites More sharing options...
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
Already have an account? Sign in here.Sign In Now