gebeer

Have you tried https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory ? This seems to be the most popular one. Latest commits last year. The graph looks similar to git graph. There is a number of actions you can take on commits, like revert, create branch, cherry pick etc.

I'll try to replicate this. What versions of ProcessWire and RockMigrations are you on?

Thank you for this module. Great addition. Now people who prefer to work more in the GUI can manage migrations with your module. The automatic recording feature looks interesting.

@ryangreat news. Thank you so much for adding this to the core. Having the Pro module for a GUI is a good approach imo.

@nloyolareading my post after almost 2 month, I realize it can indeed be confusing if you are not deep into the code. In the meantime there is a method createRepeaterMatrixField() available that should avoid this problem. See https://github.com/baumrock/RockMigrations#repeatermatrix-field

Great way of managing the docs. I'll make a PR.

Thank you for the explanations ? Would be awesome to have this in the Wiki. Would you mind me adding it there through a PR? Splitting up migrations and working with multiple migrations distributed over the code base is something more advanced and not so easy to wrap ones head around. Especially when it comes to order of execution. Can we influence that? Might have overlooked it if it's in the documentation or Wiki...

I answered you there.

Thank you very much @ryanfor working on this. For larger corporate sites this is a must have. We are using ProDrafts atm and got it kind of working with nested repeaters with some dirty hacks. Approval workflow like mentioned by @Pete would be awesome ?

Hi @bernhard, referring to this post: Thank you for the detailed explanation there. I was not sure if the custom PageClass files would be called before the associated template exists and therefore the migrations would run initially. For example, I have a site/classes/MemberPage.php with migrations in it, where the migration creates the member template. Will the migrations be triggered before the member template even exists?

Thanks @bernhardfor the detailed explanations about splitting up the migrations. MAybe you want to add that to the Wiki. That would be awesome. For that big project where I have that 4000 lines migrations in one file I still need to do that. When I started out with that project I wasn't fully aware on how to properly organize my migrations. Like with any other tool, knowledge grows with usage time ?

Which version of RockMigrations did you use? I added Repeater Matrix support and this was merged approx. 2 months ago. Here's how to use it: https://github.com/baumrock/RockMigrations#repeatermatrix-field Repeater Matrix support is also mentioned on the module's page https://processwire.com/modules/rock-migrations/ If you tried the version with Repeater Matrix support and it didn't work for you, please let us know what exactly went wrong so we can help to fix it. In all my tests and using it in a production project, I didn't encounter problems so far. RockMigrations has been a big time saver and working reliably for me for the past 2 years or so. I haven't tried other solutions mentioned here since they are not actively maintained. As for having this functionality in the core. Yes, that would be great, indeed. Honestly, I don't understand, why @ryan hasn't implemented it yet. Maybe also because there is a great solution with a well designed API available already as a free module? Still, I think it would benefit the project if this was either in core or available as an optional core module. IMO, migrations are essential, especially when using PW for bigger projects and when working on projects in a team. As for the discussion here about potential problems with migrations brought up by @MarkE , I was able to work around all of those with RockMigrations since it is also declarative, but not destructive (unless explicitly intended). The "few things too many" argument is flawed since all the extra functionality is optional and therefore doesn't impact performance. And the addon-features are well designed and can be very useful. Performance with RockMigrations is really good. Only very large migrations take some time. I have a project with about 4000 lines of migrations for templates, fields, pages and roles in my main migration file and then some additional 1000 lines spread throughout modules and these take about 20 seconds. Since you are not doing migrations all too often, this is very tolerable. Migrations on smaller projects are almost not noticable.

actually the main work for this was done by @bernhardfor his old release RockMigrations V1. I just ported that to V2 and added some improvements/bugfixes :-)

It just so happens, that I needed to do overrides for a FieldTypeFieldsetPage field from the API inside a hook. Took some effort to finally get this working. Just wanted to share this. /** * HOOK for changing label, description, notes for fields inside a FieldtypeFieldsetPage field */ $wire->addHookAfter("ProcessPageEdit::buildFormContent", function (HookEvent $event) { $page = $event->object->getPage(); if ($page->template->name !== 'your-template-name') return; $form = $event->return; // product_description is our target field // which holds fields 'image', 'headline', 'description' // product_description is of type FieldtypeFieldsetPage (FieldtypeRepeater under the hood) // get InputField /** @var InputfieldRepeater $inputField */ $inputField = $form->get('product_description'); // get actual Field from InputField /** @var RepeaterField $field */ $field = $inputField->hasField->getContext($page->template); // change label, description, notes for 'image' field /** @var Field $field */ $field->fields('image')->label = 'Hero Image'; $field->fields('image')->description = 'Also shows on overview cards'; $field->fields('image')->notes = 'Dimensions: 800x600px'; }); @Boostdid you manage to do the overrides in the template settings? On my install this does not work. Here are my field settings: And here's how the override settings in a template look like: Just being curious how that looks on your install :-)

RockMigrations makes total sense for all the projects I'm using it on ?

Latest dev branch: https://github.com/baumrock/RockMigrations/blob/da0b08b9cc65ee5573a5041971fe6ec575130b98/RockMigrations.module.php#L4107 In the phpdoc the return value is RepeaterMatrixField|null. But inside the function when the field is created with $this->createField($name, 'FieldtypeRepeaterMatrix', $options); it seems to return the generic class Field. I also sometimes experienced the problem, that you described. As a workaround, I first created the field and then added the items in a second run inside a conditional which tests for the correct class of the created field from the first run. But in my latest tests, this did not occur. Unfortunately I can't seem to find out why this is happening sometimes.

@Ivan Gretsky please also take a look at https://github.com/baumrock/RockMigrations/tree/dev#repeatermatrix-field I added a convenience method to create the Matrix field and set the types in one go.

Unfortunately it is not possible to create a RM field in one go. The way I do it: // first create the field /** @var RepeaterMatrixField $rmfProduct */ $rmfProduct = $rm->createField('content_product', 'FieldtypeRepeaterMatrix', [ 'label' => 'Product Content Blocks', 'tags' => 'products', 'repeaterAddLabel' => 'Add New Block', ]); // then populate it if (wireInstanceOf($rmfProduct, 'RepeaterMatrixField')) { // TODO quickfix find out why $rmf instanceof Field after create $test = $rm->setMatrixItems('content_product', [ 'features' => [ 'label' => 'Features', 'fields' => [ 'repeater_product_features' => [], ] ], 'gallery' => [ 'label' => 'Image Gallery', 'fields' => [ 'images' => [], ] ], ... ] I will add a hint to the docstring. Note the issue that I had, that after first creation of the field it returned an instance of Field, not RepeaterMatrixField. So I added some logic to avoid errors. Then needed to run initial migration twice to populate. Haven't found out why that happened, yet.

Hi Ivan, thanks a lot for testing this. I've been working with it on a bigger project for the last 9 months and it seems quite stable. I had some health issues and am getting slowly back on track. Will do the PR on the weekend.

Same for me here, PHP 8 is ok. Also Snipcart v3 only. Thanks for updating the module!

As it happens, I looked into this with the latest version just a couple of days ago on a PW 3.0.208 install with Repeater Matrix and nested Repeaters inside Matrix items. Unfortunately there seems to be no support for Repeater Matrix.

Yes, PHP8.1 that is. I updated to latest version. Still same problem. Use Native PHP Session is unchecked. Thanks for all the effort you put into Tracy! We might just resort to not using SessionHandlerDB. The site is in development and about 1 month away from launch. Pre launch we will update PW to latest dev and test again. Maybe that thelps. I am not sure because I don't see Tracy anywhere in the backtrace. I can only tell that the error doesn't appear when Tracy is disabled. The reported error: Fatal error: Exception: Unable to obtain lock for session (retry in 30s) (in xxx/wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module line 96) #0 [internal function]: ProcessWire\SessionHandlerDB->read('dbee8f43c207f5c...') #1 xxx/wire/core/Session.php(327): session_start(Array) #2 xxx/wire/core/Wire.php(413): ProcessWire\Session->___init() #3 xxx/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___init', Array) #4 xxx/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Session), 'init', Array) #5 xxx/wire/core/Session.php(205): ProcessWire\Wire->__call('init', Array) #6 xxx/wire/core/ProcessWire.php(581): ProcessWire\Session->__construct(Object(ProcessWire\ProcessWire)) #7 xxx/wire/core/ProcessWire.php(315): ProcessWire\ProcessWire->load(Object(ProcessWire\Config)) #8 xxx/index.php(52): ProcessWire\ProcessWire->__construct(Object(ProcessWire\Config)) #9 {main} in xxx/index.php on line 64 Warning: Cannot modify header information - headers already sent by (output started at xxx/index.php:64) in xxx/wire/core/WireHttp.php on line 1705 Warning: Cannot modify header information - headers already sent by (output started at xxx/index.php:64) in xxx/wire/core/WireHttp.php on line 1705 Arrgh… Error: Exception: Unable to obtain lock for session (retry in 30s) (in /wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module line 96) #0 [internal function]: ProcessWire\SessionHandlerDB->read('dbee8f43c207f5c...') #1 /wire/core/Session.php(327): session_start(Array) #2 /wire/core/Wire.php(413): ProcessWire\Session->___init() #3 /wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___init', Array) #4 /wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Session), 'init', Array) #5 /wire/core/Session.php(205): ProcessWire\Wire->__call('init', Array) #6 /wire/core/ProcessWire.php(581): ProcessWire\Session->__construct(Object(ProcessWire\ProcessWire)) #7 /wire/core/ProcessWire.php(315): ProcessWire\ProcessWire->load(Object(ProcessWire\Config)) #8 /index.php(52): ProcessWire\ProcessWire->__construct(Object(ProcessWire\Config)) #9 {main} This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Error has been logged. Everytime that error happens, the site gets unresponsive for about a minute or so. After first reload I get another error reported by Tracy: User Error Exception: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away (in xxx/wire/core/PageFinder.php line 821) #0 xxx/wire/core/Wire.php(419): ProcessWire\PageFinder->___find(Object(ProcessWire\Selectors), Array) #1 xxx/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___find', Array) #2 xxx/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageFinder), 'find', Array) #3 xxx/wire/core/PagesLoader.php(424): ProcessWire\Wire->__call('find', Array) #4 xxx/wire/core/Pages.php(289): ProcessWire\PagesLoader->find('template=admin,...', Array) #5 xxx/wire/core/Wire.php(419): ProcessWire\Pages->___find('template=admin,...', Array) #6 xxx/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___find', Array) #7 xxx/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Pages), 'find', Array) #8 xxx/wire/core/PagesLoader.php(1917): ProcessWire\Wire->__call('find', Array) #9 xxx/wire/core/Pages.php(244): ProcessWire\PagesLoader->count('template=admin,...', Array) #10 xxx/wire/core/PagesEditor.php(1877): ProcessWire\Pages->count('template=admin,...') #11 xxx/wire/core/Pages.php(1912): ProcessWire\PagesEditor->newPageOptions(Array) #12 xxx/site/modules/RockMigrations/MagicPages.module.php(45): ProcessWire\Pages->newPage(Array) #13 xxx/wire/core/WireHooks.php(1051): RockMigrations\MagicPages->RockMigrations\{closure}(Object(ProcessWire\HookEvent)) #14 xxx/wir … #20 {main} And in that lifecycle there's also this warning PHP Warning: session_write_close(): Failed to write session data using user defined save handler. (session.save_path: /usr/share/cgi-fpm/w01d84f4/tmp/) in Unknown The whole thing remains mysterious to me. Unfortunately I can't reproduce it on local ddev so I can't step debug it. On staging we don't have xdebug available. Anyways thanks to everyone for looking into this. As I said above, I'll test again when the site is ready to go live. Fortunately. the error occurs only when using the InputfieldSelector in SearchEngine's module settings. When using it with regular PageFinder, everything is ok.

@netcarverunfortunately I'm now still getting that error with your module still enabled. Heres the session log: And always shortly after that there the DB goes away. I think those are related.

I can confirm that with your module I do not get the error.

I'll give it a shot and get back asap