Ivan Gretsky

@Chris-PW, the module looks pretty cool. But using it without github and modules repository is kind of hard and limits the possible audience for it. And it is harder to contribute. Could you please reconsider @netcarver's advice?

Hey, @Michael Lenaghan. The setting() function might be a fit.

As it is all urls and html content at the end the answer is yes to all of those questions. The difference is that you don't get a unique page object for a urlSegment as you do for a regular page. The urlSegment can show data from some other page though (as you mentioned). You need to code all this. And there might be only a little or a lot of code. You need to start solving tasks one by one to find out all the answers. I do not see any difference where to test it at. Surely, most of the time it is done in some sort of a test env. Locally is totally fine. But maybe there is some sort of a limitation at your external data provider. If so, elaborate on this and we will answer in more detail.

Look here for a detailed instruction.

@franciccio-ITALIANO, everyone here gives good options. But it seems that either you are not yet into PW or PHP deep enough to fully grasp the answers or we just have not understood your case well enough. Please provide more details (like screenshots or code snippets) to help us help you better)

There is also this free module. Didn't try it myself though.

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?