Leaderboard

This week we have ProcessWire 3.0.192 on the dev branch. This is about 20 commits ahead of the previous version and contains 11 issue fixes and 5 pull requests, along with various other updates. PR code contributors in this version including Daun, MrSnoozles, Radon8472, BernhardBaumrock and Tyde. Thanks! For more details see the dev branch commit log. In addition to core updates, in recent weeks I've also been working on a new module similar to the PageAutosave (developed for the admin) except that it is for front-end forms. It works with any front-end form (whether home brewed or from something like FormBuilder) and remembers the entered form values every time a field is changed. If the user doesn't submit the form, they get an email with a link to finish filling out the form after a configurable period of time. This is especially nice for order and reservation forms. Accompanying the module is a separate Process module that lets you view all the forms in progress in the admin. Each form entry has its own unique URL, making them easy for users to return to, from any device. Once the user submits the form, the data gets removed from the pending submissions database. This is something I've been meaning to develop for awhile, and with the admin PageAutosave module still fresh on my mind, I thought now was a good time to do it. Thanks for reading, Happy New Year and have a great weekend!

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 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 ?

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! What are you missing? 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 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. That would be a pity. We need more people like you here ? Sometimes life as a developer is hard. But we get paid for that ?? I agree on that. I'm working on it and I wished more were doing so ? Why not? 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

@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.

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?

Thanks everyone for the insights! Nice to see all the different approaches, and that I'm not the only one struggling to find a 'perfect' solution … @bernhard Thanks for this. Look real close to a version-controllable schema config. Can the array syntax for fields/templates handle field overrides in a template context as well? What about settings that are environment-specific, like specific parent pages in page reference fields? 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? You're right, doing everything manually is a pain. But handling everything in code is a pain as well. The problem for me is that too many areas of ProcessWire are not built with version control in mind. Migrations solve field/template configuration. But then you need to keep track of installed modules, if you want to install modules with Composer you need custom config so they're installed in the right folder. Of course you can't put the entire modules folder in gitignore, since site-specific modules go into the same folder. And what about ProcessWire itself, I don't want the entire core in my version control. So again, custom download script. The list goes on. You don't want to keep track of uploaded files, so the asset folder goes into gitignore. But I do want translations in my version control, turns out those are in random directories in the assets folder … the list goes on. 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'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. @horst 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. @szabesz We do that for significant updates to older projects where we don't have development versions any more. Though it means the client can't edit anything while updates are being done, and it doesn't work for sites with user-generated content or user accounts where you can't just freeze the live database for a larger amount of time … @elabx So all your sites are identical in feature set? That definitely doesn't apply to our projects ? The point regarding bitbucket pipelines is interesting. Though I'm hesitant to use automated deployments if I have too write too much custom logic for it or mix partially automated deployments with manual steps. Too error-prone and difficult to enforce in a team, in particular if you want to work on site updates with multiple people …

@szabesz same for me. Excited to give it a spin! ?

Thanks for the example! I think this weekend will be the earliest when I have the time to actually install it. Can't wait :)

Hello Padloper Alpha/Early Beta Testers. Shortly after this post, you will receive an email inviting you to access and test Padloper 2. Thanks! If you don’t receive an email within 2 hours, please let me know. A few things to note before you dive in. What to Expect Padloper 2 is a native ProcessWire module. It is not an SPA. A previous iteration powered by VueJS was discontinued. Instead, there is some sprinkling of htmx, alpine.js and Tailwind CSS here and there. Bugs: how many? We’ll find out soon. There are a lot of bd(), even db() calls left, deliberately, in the code. Most (all?) have been commented out. They have been left in the code for a reason; to help debug the product. A shop app that you can use incrementally. Many of the features are optional and can be left out (or added later) at install. Inbuilt invoice and PayPal payment gateways/systems. The latter uses V2, the latest PayPal SDK. What not to Expect Although it boasts a rich set of features in its current state, a number of features have not yet been implemented. Some have been implemented but not fully, so may not work as expected. In the expression of interest form I listed the features I’d want to implement next. I asked you to express your preference for these. I’ll be guided by your choices when prioritising the next set of features. Implemented but Incomplete Orders (backend) Manual order creation (creating orders via GUI) is incomplete. Actions including print invoice, mark order as complete, etc are incomplete. Products (backend) Product variants should lazy-load when the product is being edited. Currently, they are all loaded and can slow down the page if they are many. Checkout Settings (backend) Some of the settings including abandoned orders follow-up are not yet functional. General Settings (backend) The settings to limit allowed image and file extensions is not yet synced with the respective image and file fields. Shipping Zones (backend) It is not possible to prevent countries from being added to more than one shipping zone. Shipping Rates (frontend) If more than one shipping rate is matched for a customer for a given shipping zone, it is not yet possible to let the customer select their preferred shipping before finishing their checkout. A side note: matched multiple rates can be desirable in cases you want to offer more than one delivery method to your customers, e.g. a free but slower shipping and a faster but paid-for delivery. Downloads (frontend) Delivery of digital products is incomplete. Not Yet Implemented Access (backend) Access control via permissions and/or roles not yet ready. Other Desirables Not in any particular order and planned for future release(s). Bulk product images management Customer management Discounts Staff management Shipping classes Notifications management Detailed Analytics Additional in-built Payment Gateways (Stripe, etc.). Better management of abandoned baskets Invoice generation and management Known Issues PayPal showing lots of JavaScript console errors. These are all related to CORS as far as I can tell. PayPal struggling with some floats (prices). It will crash and payment will fail. Maybe this could be solved by charging in cents (in PayPal) but I haven’t yet found a way to do this in V2. If you have any questions please ask here. I will contact you later for where and how to report bugs. Please don’t use this thread for that. For generic issues, such as not being able to install, etc., please let me know in this thread. Thanks and happy testing!

ProcessPageAdd preselects the template according to these principles: If there is already one or more child pages under the parent then it preselects the same template as used by the most recently added child page. If there are no child pages it preselects the same template as used by the parent page. But if that template isn't allowed to be used under the parent page then no template is preselected. So probably you recently added a page using the template that is only used in 5% of the cases, or that is the template of the parent page. You can force a particular template to be preselected in a couple of ways. 1. You can add a "template_id" GET variable to the URL of the "Add New" page. Example: "/processwire/page/add/?parent_id=1234&template_id=29" This might be a good approach if you are constructing your own custom link to the "Add New" screen but not so useful if you are just adding a new page via the standard PW admin. 2. You can use a hook in /site/ready.php to set a template_id GET variable to $input: // Before the ProcessPageAdd form is built $wire->addHookBefore('ProcessPageAdd::buildForm', function(HookEvent $event) { $input = $event->wire()->input; // Get the parent page the new page is being added under $parent_id = (int) $input->get('parent_id'); $parent = $event->wire()->pages->get($parent_id); // Return early if a single parent page isn't available or valid if(!$parent->id) return; // Do whatever check you need to identify if this is the parent you want to target if($parent->template == 'home') { // Get the template you want to be preselected $child_template = $event->wire()->templates->get('basic_page'); // Set the template ID to the "template_id" GET variable $input->get->template_id = $child_template->id; } });

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

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 thing Craft does, thanks for sharing! ?

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.

The hack in the quoted post is quite simple @Krlos - you may wish to try it and see if it fixes your problem. If not, you can revert. Or you could just try \ProcessWire\_(“….”)

Github issue opened at https://github.com/processwire/processwire-issues/issues/1502 Suggested fix is to amend the regexes in $sanitizer->float() to not remove 'E-', 'E+', 'e-' or 'e+', but I have (yet?) to devise a suitable regex. If anyone is a regex whizz then please save me some head-scratching ? EDIT: I have also suggested, in the GIthub, a simple fix to deal with the internally-generated scientific notation that causes the InputfieldFloat problem. That's what I'm using for now, otherwise I consider InputfieldFloat is unsafe for live use! (I appreciate that may sound a bit dramatic, but I cannot risk major calculation errors).

Yes, this is the exact reason why I asked about it. In its current state it's not even as complete as Padloper 1 so the most I could do is playing around with it. And that would not be a proper beta test I'm afraid. It's been years since I last used PayPal for anything so Stripe is a must have on my list, I'm not so much into custom solutions though...

Hey @Moritz! I use RockMigrations to handle most of the API related stuff along the initial Migrations module, which has a CLI interface letting me run pending migrations per site and keeps the track of it. The sites all share the same features and templates, nothing can be added as a "site specific feature" that involves a "custom pw stuff" in the database, it religiously needs to be in sync. I use bitbucket pipelines for deployments, and it's a very simple script involving rsync and running the Migrations CLI. I do write everything that involves a "new feature" regarding fields on a page, repeater matrix, etc. I'd say once you got it figured out, most of the time i'm copy pasting between migrations and adapting. I'd love to get in sync with some sort of automated testing (end to end with cypress?), but right now it just involves manually testing, and deploying to a few sites to test, fix otherwise and deploy again. I guess this is more of a management issue?? Maybe I am not understanding your full perspective here. No db dumps becase as you mention, it will mess up content. HannahCodes I migrate using the text version export of the hannahcode haha Module updates I guess just upgrading the files?? Haven't got into a deeper issue where something breaks while doing these. I think, up to know, I have just installed new modules. I keep processwire install outside of this equation, I am not sure if this was a wise decision, but it is like that lol One thing that is super important that I haven't though very well is rollbacks. Right now I basically would just run another migration on top, chekout/cherrypick from earlier branch or sth. Though haven't had enough time on this setup to mess up like this and need a rollback or where just doing a migration on top wouldn't work.

Probably my method is in the dinosaur category, but it still works without spending too much time on migrating a database: If I do not mix up production with local then it is fool proof. It takes less than 15 secs from start to finish to clone a small database including all the keystrokes I have to perform at the beginning. Sure, it is the other way round regarding migrating, but for a one man show it is not a big deal. When modifying settings in production, I sometimes have to do the cloning more than once but since the whole process is so fast, for me it is a non-issue. "I am still waiting" for an official automated migrating solution included in the ProcessWire core :P

ATM I simply use the manual export <> import function from PW for fields and template settings. Every time I also have to alter field and or template settings, I write down the timestamp on a pad of paper when I start to do so and then collect a list (on the left side) of all fields I touches in the next time until deployment, (and on the right side I collect all template names).* When I'm ready for deploying, I may or may not shut down the live system for a short amount of time, depending on the amount of changes, then collect from the DEVs export selector all needed fields, copy the export json and drop it into the targets fields import field and proceed. Next step is the same with template changes. There is no need to shutdown a live site for long time. Mostly when I had large deployments, it was closed for one hour, but most of the time I do and have done those db migrations without any maintenance mode, because most of my sites uses ProCache. If it really would matter, I can prime the cache by crawling the site once before starting to deploy. It is not comfortable and also not the best I can think of, but it's not nearly as uncomfortable as described by @bernhard? Using these functions is not nearly as error prone as manually writing EVERYTHING into one schema or another for every field and template change. Noting everything by hand is not error tolerant for typos, I might forget to note a value, a change to a template, etc. All this is avoided by simply copy-&-paste ready generated JSON directly from PW. No typos, nothing forgotten, nothing added. Not perfect but for me much faster, easier and safer than writing everything down again by hand. PS: * In case you are not sure if you have written everything down on paper, you can generously include additional fields or templates in the export. In this case, it is better to have more (or even all) than too few. All unchanged settings will be recognized by PW during import and will not be processed further. ?

Depends on what you guys dig up when you put it through its paces in the next few weeks ?.

Yes, RockMigrations Yes Yes It depends. Imagine you already have a setup using RockMigrations and your class uses code like this: <?php $rm->migrate([ 'fields' => [ 'field1' => [ 'type' => 'text', 'label' => 'Field ONE', ], ], 'templates' => [ 'my_template' => [ 'fields' => [ 'title', 'field1', ], ], ], ]); And you wanted to add 2 new fields and show those fields in a 3-column layout in your page editor. Using RockMigrations: open the file that holds your migrate code in your IDE (eg /site/classes/MyTemplate.php) add some lines of code (it's copy&paste most of the time and really easy once you are used to doing so): <?php $rm->migrate([ 'fields' => [ 'field1' => [ 'type' => 'text', 'label' => 'Field ONE', 'columnWidth' => 33, ], 'field2' => [ 'type' => 'text', 'label' => 'Field TWO', 'columnWidth' => 33, ], 'field3' => [ 'type' => 'text', 'label' => 'Field THREE', 'columnWidth' => 33, ], ], 'templates' => [ 'my_template' => [ 'fields' => [ 'title', 'field1', 'field2', 'field3', ], ], ], ]); run the migration add code that uses the new fields test your results, commit and push to staging/production Not using migrations, option 1: login on the live system add new field2 set column width, save add new field3 set column width, save go to setup > fields > edit > field1 set column width, save add code that uses the fields on live system hope that everything works and none of your site visitors sees anything from what you are doing... if anything goes wrong: restore the backup you took before creating your fields what? you forgot to create a backup? ok... you took care of that and lazycron is doing backups every day! write an email to your client that explains that you had to restore a database backup from last night, which means that his website lost XX comments, or YY orders, or ZZ new entries ... That means that option 1 CAN be quicker, but can quickly get a lot more time-consuming than properly migrating your fields. Not using migrations, option 2: take your site offline to make sure that you don't lose any live data (you already mentioned that) make a db dump on the live system import data from the live system to your dev setup go to setup > fields > edit > field1 set column width, save go to setup > fields > edit > field2 set column width, save go to setup > fields > edit > field3 set column width, save create a db dump of your local system upload your local db dump to your live system take your site online again Option 2 is a little more secure, but imagine you are working on that project as a team... You'll quickly get a huge overhead in not using migrations! You need to tell all your colleagues what you did somewhere. Imagine one of your colleagues works on a different feature at the same time and pushes changes to live overwriting your changes... You'll be in trouble! RockMigrations was built for all those things you mentioned. And we have not even been talking about reusing things you do... Using RockMigrations you can literally copy&paste setups from one project to another. That can save you a huge amount of time. All of what I mentioned depends a lot on how you work, what projects you work on, what clients you have etc... The fact that you are using automated deployments already and asking those questions sounds like you should definitely give RockMigrations a try though ?

Some great examples here already and these are probably the best approach, but just another alternative (in case it's useful) is to use a Profields Table field - this way you can easily define a new string to translate as a new row in the table.