Ivan Gretsky

Ok, if it's time for claiming rights for abbreviations I will put PATU here. It is unpoly instead of htmx. Umpoly is more close to PW way of doing things being an opinionated but more full fledged solution. More to that, Ryan once said he liked it more. And it is not such a buzzword as htmx nowadays, quite in the spirit of PW. I even have two logo ideas for that to choose from: 1 - https://en.wikipedia.org/wiki/Patu_digua 2 - https://en.wikipedia.org/wiki/Patu The only small thing left is to actually build something meaningful with it))

Good day everybody! How are you doing @teppo! Wireframe\Controller has int() and render() methods. Their docblocks say that inti() is to perform early checks and render is the place to pass vars to view. I've been working with this a while but still do not quite grasp how to use them together. I either use one or a another. Demo repo doesn't have any examples with both methods. Could plrease someone in the know share their wisdom (or opinion) on this? And a more specific question. If I use them together and put checks into init(), how do I avoid triggering render, if those checks do not pass? For example, some fields are empty and regular render should not happen, but an error should be shown instead. Thanks!

@bernhard, is that module not deprecated in favor of migrations tweaks? If not, shouldn't we be encouraged to develop the Tweaks module instead? Does it have its own support thread?

I really like the idea with a tweaks pluggable collection. But I would prefer its usage was separated from the RockMigration module, so one could use tweaks without the more developer-centric migration tool. I thought that @bernhardstarted a dedicated module for that, but not sure if it is still alive.

PW doesn't work with SQlite, so no PW based nativephp apps possible) This is PW forum, so my first reaction is to explore possibilities of every tech mentioned concerning PW. I am sure the DB is not the only limitation though) But nativephp is something cool to know about anyway. Thanks, @szabesz! P.S. I've seen @flydev following static-php-cli which is a dependency for nativephp. Maybe he can share his wisdom on the topic.

Looks cool! PW based desktop apps on the way? Ahh... SQLite not supported... Probably not.

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