Ivan Gretsky

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.

@bernhardis so productive I must have missed the RockPageBuilder thing. Can't find it on github. @Stefanowitsch, where did you get it?)) Ahh. Should've read it from the start) It is explained earlier in this thread.

@Jonathan Lahijani, would you mind elaborating on this a bit? How do you manage your frontend without node based build chain? I am very interested as I am moving along a similar path, having ditched gulp. Now I do not even concatenate my js leaving it to http2. The only thing i still compile is scss) How do you do it nowadays?

I am long-time used to writing bem classes. They feel natural to me. But earlier this year I was also looking for more modern alternatives (that could be used without build step). Here is a nice article by Dave Rupert I've found on the topic. Didn't try any of it (yet?) though.

Looks cool! Could you attach full screenshots of admin pages styled this way? Just for fun)

Hi @joer80! AFAIK this feature is still missing due to the way ProcessWire works with files. It has been requested and discussed lot of times thought. Read this whole thread for example. There is a module that claims to help with AWS S3. Haven't tried it myself.

Sounds super cool! The wire shell project was one of the greatest tools in the PW ecosystem. Glad it is reborn! Especially great to hear that there are plans to work on a unified solution with @bernhard's RockShell. A true community spirit! AFAIK RockShell has a lot of Rock*-specific stuff. So maybe need to think about the expandable architecture right away? Would love to test and contribute. P.S. Can't save wire shell in a single word. Is there some smart spell checking and correction going on now and how do I get around it, @Pete)))

They are on github first.

Let me encourage you to create a PR) I promise to work with it.

Congrats to your daughter! And looking forward for the next master.

Had same problem recently. P.S. @horst, it is page 17 of WireMailSmtp support thread. Maybe it is time to split it in Module-Specific Support section?

Super! Need to keep everything in order. A Higher Order of Perfection, nothing less)

Ahh! Reading this in the early morning laying in bed. Almost always start the weekend with PW blog. What I read makes me smile. A great weekend indeed! Thanks!

Those are awesome news for us! We've had a long standing problem with moving ProcessWire installations from one server to another concerning the caches table. It would be great to completely decouple the modules cache from the user generated cache. Maybe move the modules cache to a separate db table. It seems intuitive (and most administrators seem to take this as granted) that you can simply purge the caches table to reduce the database dump size. But it is not like that ATM. Just had this problem yesterday with an experienced ops engineer, who doesn't have any PW experience... so your are magically right on time @ryan, as multiple times before!

I have installed the modified module. But there was no records in session-errors logs file. In fact it has not even been created. And it didn't solve the issue as far as I can tell as the mentioned error didn't go away. With Tracy turned off it appeared less often but still did. I think that long and heavy DB queries do cause this.