Jonathan Lahijani

Nice. Just wanted to mention Cerberus as an alternative to MJML if you want to use email-friendly HTML templates directly.

Very cool. You got the "PATH" stack going there too (ProcessWire, Alpine, Tailwind, HTMX). Nice. Funny enough, I happened to watch this video on YouTube about the history of Palm Springs architecture.

@bernhard How do RM's config migrations work when it comes to creating pages, since it doesn't support page creation? So let's say I wanted to create /colors/ with child pages red, green and blue. I would have: /site/RockMigrations/templates/colors.php /site/RockMigrations/templates/color.php /site/RockMigrations/fields/color.php To make the 'color' single-select page field use /colors/ as a parent page and 'color' as a template, the /colors/ page needs to be created using the 'colors' template and red/green/blue need to be created with the 'color' template. Where would the code go for creating those pages if now the code for fields and templates are done in the new "config migrations" way?

@FireWire Have you used managed databases with Vultr? I see that they don't have MariaDB, but I suppose MySQL should be fine.

@markus_blue_tomato Is there a reason you didn't use Session Handler Database? https://processwire.com/docs/security/sessions/

I was thinking about this as well recently. Here's what I came up with: function convertRepeaterPageToPage($repeaterPage, $newParent, $newTemplate, $newStatus) { // store for cleanup $forPage = $repeaterPage->getForPage(); $forField = $repeaterPage->getForField(); // convert $repeaterPage->set('parent_id', $newParent->id); $repeaterPage->set('templates_id', $newTemplate->id); $repeaterPage->set('status', $newStatus); $repeaterPage->set('published', time()); // make this adjustable as well? $repeaterPage->save(['noHooks'=>true]); // cleanup $forPage->save($forField, ['noHooks'=>true]); return $repeaterPage; } Note: It should be improved to make sure what's provided in the arguments is valid. Also maybe have the ability to set the 'name' field of the page as well instead of preserving the auto-generated one that a repeater item gets assigned. Also maybe use types for the arguments. --- Example: Let's say you have a repeater field called 'books'. Then you decide one day that it would be better that they existed as regular pages instead of repeater pages. Therefore, you would create a new template called 'book' making sure it has the same fields as the repeater fields, then do this: foreach($pages->get('/path/to/page/')->books as $book) { convertRepeaterPageToPage($book, wire('pages')->get('/foo/'), 'book', 1); }

I've literally thinking about that these past few weeks. What a timely post!

@Jan Romero Thanks for your research. Your approach worked but yea it's not efficient as you say. I created a feature request: https://github.com/processwire/processwire-requests/issues/550

@Jan Romero Thanks for making me aware of that method. I tried it and used the full path, but it didn't seem to work. I tried it in /site/init.php and /site/ready.php and other status files, but no luck. I traced the code to see where it executes, and from what I can tell, it seems that path will not get added in time, which is a little surprising. But maybe I haven't totally thought it through? Since this is kind of a rare thing I'm trying to do, I wonder if it's technically supported.

ProcessWire's default folder for site modules is /site/modules/. I want to have a separate folder called /site/modules-2/ where additional modules are available. I believe this is technically supported however I haven't seen any discussion on it. I tried doing this in /site/init.php: // init.php wire('modules')->loader->loadPath(__DIR__ . '/modules-2/'); That finds the additional modules when I refresh the admin modules page and allows me to install a module in that folder. However after installing it, it technically becomes immediately uninstalled. I can't uninstall the module at that point, but if I try to reinstall it, I get an integrity constraint violation. So I have to remove the bit of code above. Then if I refresh admin modules again, it becomes missing (correctly) where I can then remove it. Doing it over again leads to the same result. I feel like while having multiple module holder folders is possible, it's either buggy in ProcessWire, or my approach is incorrect. Any suggestions?

I have a page that has a two repeater fields. Those two repeater fields have nested repeaters, etc. I want to run a hook after the page has been saved, BUT only after all the repeaters and nested repeaters have been saved as well. If I use addHookAfter on Pages::saved(template=mytemplate), the hook fires after the page is saved, but before all the repeaters and nester repeaters are saved. What's the correct way to do this?

It was a pleasure speak with you today @bernhard. For the others wondering, we mainly talked about "rabbit hole" you can go down with ecommerce and how there has to be a line drawn between what one gets with a fresh installation vs. what one must build on their own. Basically, how turn-key the solution is and how that relates to the target audience the system would be for.

I've integrated Stripe Payment Elements with my system which we can discuss @bernhard. Stripe is hugely popular in the US and it's probably the easiest to work with.

@bernhard Would love to chat about RockCommerce. I have my own internal ecommerce system that I've built with PW so I've walked this path as well and can offer some insights.

This thread is #1 on HN at the moment: https://news.ycombinator.com/item?id=41805391 Do a search for processwire on the page. Looks like an old forum member.