Jonathan Lahijani

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

@bernhard RockMigrations and ProcessDbMigrate take fundamentally different approaches. RM takes the traditional web application framework approach while ProcessDbMigrate is more of a change recorder, similar to Craft CMS Project Config. There's trade-offs to each approach, but I will say it's nice to have changes to be recorded automatically, even if it's not a 100% full-proof approach (although I'm looking into that). It's basically automating what I typically do when I need to migrate a changes "by hand" on the sites I work on, which is an approach I like. I'm experimenting with the change recorder approach in a module of my own for now, but development of it is on and off for the moment. Understanding ProcessDbMigrate helped with understanding the approach, and the recording part of it is straight-forward. The "playing" of the recording gets tricky for all the reasons we all know about.

This idea is so under rated. Forums have declined in popularity as the primary communication method for software projects and general communities over the years in place of social networks and chat apps (Reddit, Discord, Twitter, Facebook). This makes me very sad because I find forums to be the optimal way to communicate while maintaining true control of the community. Discussions on Discord/Slack can't be discovered by a search engine. Twitter and similar services aren't ideal for long discussions. Reddit seems childish and their UI update is terrible. Facebook is closed and has bad discoverability. If ProcessWire didn't have this forum, it wouldn't be nearly the same. If a large software project similar to ProcessWire doesn't have a community powered by a forum like this, it's a big missing feature in my book. When I did a small Craft CMS project a few years ago, there was no equivalent to this forum, only Slack, although it did have a lot of people in it. Then if I asked a question that was answered in the past many times over, I would probably feel like an idiot.