Ivan Gretsky

Those retrogrades surely understand their fate and deserve no adminer updates))) But seriously we need to move the tech forward a bit also by upgrading system requirements. I think it is time to move!

@Christophe, did you try it?

A useful feature indeed! Thanks Ryan and Jonathan!

The next major upgrade to admin in general would be to support saving without reloading IMHO. This could be a SPA. But maybe unpoly or htmx would fit PW spirit better. Anyway, this seems like a gigantic task to tackle. And surely Ryan should decide if he is willing to do it now or ever.

Great to learn that not only Santa has been working these days))

Thanks, @ryan! Being here for so many years it feels like home. And everyone in the forums like relatives, even though I never seen them in person and only imagine them as their avatars living somewhere around the globe) So these "winter holidays" celebration posts are kind of like a family reunion, when everybody gathers at a holiday table after a not so easy year passed. Happy new year to everyone! Let it be a better one! С наступающим! Всего хорошего и доброго! ???

@Roych, as I can see from his post @Clarity is already doing almost the same as you suggested. But he is looking for a cleaner way to handle it that already exist (or asks @kongondoto update the module to provide it).

Thanks to both of you! We are now able to manage RM fields which is super important for at least my workflow. Maybe eventually we will get methods for other Pro fields (or at least workarounds like this one)))

Hey, @teppo! Hope you're doing fine! I've been using Wireframe for a while without too much thought just relying on it. Thank you for this module! It really helps with structuring PW projects. Once upon a time I've borrowed your convention to put all the static files to site/templates/static folder. I am putting both sources and generates stuff there. I've handled the build process with VS Code plugins to get rid of the node based build chain. Anyways, now I see that you recommend creating two other folders: site/templates/resources and site/assets/dist. I can guess that you renamed static to resources and probably added assets/dist for the generated files. But could you please describe how you suggest using all these folders in the Wireframe-based workflow for building and maintaining sites in a little more depth. Couldn't find any docs on this. Maybe there are some useful methods and/or settings that can make use of these? How do you use them?

@Clarity, Combo is a 1st party Pro field and it seems to be not supported out of the box with Rock Migrations. I think that only Repeater Matrix field is supported of all Ryan's Pro fields thanks to @gebeer's work. Those Pro fields all need special treatment and you can't expect them to work with just createField(). But you can always fall back to just raw ProcessWire api and create the Combo field with just that. See here how to do it if you got Pro fields support board access. If you don't, here is the code Ryan suggested (hope this is alright to post it here): You can make a special method for Rock Migrations out of this (should be pretty easy if this code works) and make a PR if you want it there))

Looks cool @BitPoet! Could you describe uses cases for this so we know when we can use it?

It seems to be a permissions issue. When Rock Migrations is run the regular way, it makes the $user a superuser with a sudo() method. If you run your migrations from your own script you probably need to do the same there.

If you are willing to use Rock Migrations 3rd party module, it has a special method for that.

Good day, all the super clever RockMigrations users! I am just starting to get my head around this super module. I've got what seem like a bug when using installModule() method. As the title says installModule() does not actually install the module when run the 1st time, but only downloads it. When the method is run the 2nd time, the module is actually installed, but not until then. I've already created the github issue, but double posting it here to find out if someone else is facing the same issue. Seems to be an critical one. Just want to make sure it is reproducible.

Thanks for the info. Hope you'll find some time for that soon ?

@gebeer, did you manage to make that PR? Not pushing but just trying not to miss this thing I am looking forward to use)

The main module is a mix of process stuff and helper functions for the main logic. And it is more than 3000 lines. So a little refactoring here seems reasonable. But adding stuff via hooks (or some other way) to implement the plugin architecture seems reasonable too.

Thanks @gebeer! I really wish you a quick recovery. Great to hear the code is not abandoned and the PR is coming!

Good day @bernhard! I was testing @gebeer's PR (see this thread), and I was looking at the code of RockMigrations.module.php. It seems to me that it might be beneficial for supporting this long-time to split the code into submodules. I think that all the code that actually creates fields/templates/users... could be moved to a helper module(s). And the main one would deal with all the admin logic. This way it would be not only easier to add field-specific methods, but also possible to use those great methods in different types of workflows (including them). I would love to see other Pro fileds' specific methods added. Maybe other commercial or just 3rd party modules too. Maybe there could be some plugin system for those?

Good day, @gebeer! I've tested setMatrixItems() metod - it seems to work fine so far. There are some bd()'s that cause errors when the field to be added does not exist. But that is minor thing. I am eager to see this PR merged. Ready to do more testing if needed. But just maybe it is better to do it with your code already in the core? We do not want to lose this work!

Good day, @gebeer! I would be really happy to see those RM methods merged into RockMigrations core. I am testing things right now. This is what I've found so far. There are some not-deleted bd()'s. I am trying to create RM field and add types in one run (see the code below) But it seems not possible. Should I put some code in between to make it work? <?php namespace ProcessWire; /** @var RockMigrations $rm */ $rm = $modules->get('RockMigrations'); $rm->installModule( "FieldtypeRepeaterMatrix" ); $rmfContent = $rm->createField('content_blocks', 'FieldtypeRepeaterMatrix', ['label' => 'Content Blocks', 'tags' => 'content']); $rm->setMatrixItems('content_blocks', [ 'test_rte' => [ 'label' => 'Test Repeater', 'fields' => [ 'title' => [ 'label' => 'Title', 'required' => 0, ], 'images' => [ 'label' => 'My Images', ], 'rte' => [ 'label' => 'My Text', ], 'my_repeater' => [ 'label' => 'Test RTE in RepeaterMatrix', ], ] ], ]);

Thanks for the reply. Reading it I am happy I got the way it works right. But I need to automatically install the modules not available via url and not already installed. My use case is the initial system setup. I need some paid modules installed and do not want to do it manually, but rather in an after install script (install profile). I am thinking to have the Pro modules installation packages downloaded as zipped files and put in the web root folder or above (along with some other stuff I need during the install). I then I would install them from there with installModule(). The show-stopper is that I can't do it as there is no option to get module not from the url, but from the local path... Ok. now I just realized that I can just extract those zips to site/modules and just run installModule() without the url param, right?

Good day! Is there a way to install modules that are not accessible via direct link like Pro modules and other commercial modules? It could be done by getting a module from a local path. But there seems to be no such option for this method. Am I missing something obvious? Could an install from local path option be (please))) added? Thanks!

@szabesz, I am quite with you as I have been toying with unpoly and htmx a bit, and understand quite well that one should sometimes work hard to achieve with htmx something that comes with unpoly out of the box. I was just saying that AlpineJs has a different purpose (Js sprinkles, jQuery replacement) and is used with either htmx or unpoly.

AFAIK unpoly does not have an analogue to AlpineJs. In fact, unpoly users seem to also adopt AlpineJs for the frontend stuff. It is more a complete (and more opinionated) replacement for htmx though.