gebeer

https://warp-design.co.uk/blog/why-we-love-processwire/ https://dotnetic.de/blog/processwire-the-best-cms

@kongondo on multilang installs, when the title field is set to TextLanguage, MM pages that are creted for each image under Admin->Media Manager->Media Manager: image are published in the default language only. Other languages are disabled. This poses a problem with $pages->find operations, e.g. $this->wire->pages->findIDs("template=media-manager-image, image_gallery=1, products.id={$this->id}"); this return 0 pages for non-default languages. I had to change the selector to $this->wire->pages->findIDs("template=media-manager-image, image_gallery=1, products.id={$this->id}, include=all, status!=" . Page::statusUnpublished . ', status<' . Page::statusTrash); in order to get results. It might be good to have these pages published in all languages by default.

In PW you would typically use https://processwire.com/docs/front-end/how-to-use-url-segments/ The docs should help you get started. If not, feel free to ask.

Thanks for the suggestion. This is throwing all kinds of errors. If I want to bd($vars), I get: User Error Exception: Method RockMigrations::getModuleInfo does not exist or is not callable in this context (in /var/www/html/wire/core/Wire.php line 563) #0 /var/www/html/wire/core/Wire.php(419): ProcessWire\Wire->___callUnknown('getModuleInfo', Array) #1 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___callUnknown', Array) #2 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\RockMigrations), 'callUnknown', Array) #3 /var/www/html/wire/core/Wire.php(487): ProcessWire\Wire->__call('callUnknown', Array) #4 /var/www/html/site/modules/RockMigrations/RockMigrations.module.php(4560): ProcessWire\Wire->__call('getModuleInfo', Array) #5 /var/www/html/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Dumper/Describer.php(295): ProcessWire\RockMigrations->__debugInfo() With print_r($vars) I get: Fatal Error __debuginfo() must return an array Related to RockMigrations::__debugInfo(). Seems like this method is interfering with print_r(). After uninstalling Tracy I finally got to outputting var_dump($vars). Still throwing a Warning about RockMigrations::__debugInfo(). $vars contains all defined vars including fuel which contains wire and so on. So this is not feasable for the simple purpose of passing on some vars. What I finally did, is putting all vars that I need to pass on into an array $arr, then passing $arr to the render file. In the render file I can retrieve it with $arr and pass it on. Sometimes solutions are so simple. But the other day it was getting late already. Braindead just around the corner ?

Thanks. I'm aware of that. But I'm looking for a way to get the $vars variable like it was sent to the render method so I can pass it on easily. Imagine you pass a $vars array with 10 items to render(). Then from the render file that you passed them to you want to take $vars and pass it on to another partial with the render() method. ATM you have to write each one out again in the new render() call. That is tedious and it would be much easier if we could just grab $vars and pass it on.

I just tried this and $vars is still null inside the render file, even when sending $options. Also $options is null. I am using this to render files (views) inside a module. So the render files sit inside /site/modules/myModule/views. I am rendering those with $this->files->render('/full/path/to/viewFile', [...], []); Can't find anything in the docs on how to retrieve $vars here. I need to pass them on to another render file. With ReflectionMethod, we can get all the parameter names passed to $files->render(). But not the values passed to that instance of the method. $f = new ReflectionMethod(wire('files'), 'render'); bd($f->getParameters()); If anybody knows how to get $vars inside the render files, would be much appreciated ?

For all that are interested in testing, I have created a PHP7.4 compatible version at https://github.com/gebeer/RockMigrations/tree/repeatermatrix-php74 It just so happens that I needed it urgently on a live project where I couldn't change the PHP version in time ?

Sure. I'd like some other people test this before I make the PR.

Hi, my current state of RepeaterMatrix (RM) integration is here: https://github.com/gebeer/RockMigrations/tree/repeatermatrix It is based off @bernhard's dev branch. I just merged the latest changes from dev into my repeatermatrix branch. I have basically done what Bernhard suggested and ported over the original RM methods from RockMigrations v1 and did some minor adjustments. You can create RM fields inside the $rm->migrate(['fields]) array like this: self::content_blocks => [ 'label' => 'Content Blocks', 'type' => 'FieldtypeRepeaterMatrix', 'repeaterTitle' => '#n: {title}', 'familyFriendly' => 1, 'repeaterDepth' => 0, 'tags' => 'repeatermatrix', 'repeaterAddLabel' => 'Add New Block', 'columnWidth' => 100, ], Note that I'm using class constants in my Site module for field names. You can of course use ordinary strings here. Alternatively you can create the field like this: $rmfContent = $rm->createField('content_blocks', 'FieldtypeRepeaterMatrix', ['label' => 'Content Blocks', 'tags' => 'content']); And then after the $rm->migrate() method you can define your RM types like this: $rm->setMatrixItems(self::content_blocks, [ 'test_rte' => [ 'label' => 'Test Repeater', 'fields' => [ self::title => [ 'label' => 'Title', 'required' => 0, ], self::images => [ 'label' => 'My Images', ], self::rte => [ 'label' => 'My Text', ], 'my_repeater' => [ 'label' => 'Test RTE in RepeaterMatrix', ], ] ], ]); As you can see, you can also have regular repeater fields inside RM types. Besides setMatrixItems() there are following RM related methods: setMatrixItem(), setMatrixItemData(), addMatrixItem(), removeMatrixItem() There is no way atm to have the full field definition inside the $rm->migrate() method as array definition. That is something that would need some extra work mainly because the getCode() method as is doesn't play nicely with RM fields. But other that that it seems to work pretty well. Actually I'm using it in a bigger project which is still in development and makes heavy use of RM fields with nested repeaters. I would be happy if you and others could test this. @gornycreative wanted to have a play with it some weeks ago. Don't know if he already had the time to look at it. Eagerly looking forward ? It is totally different from RepeaterMatrix but really great what I saw so far.

Great Talk! And thanks for the mention ? Very well structured introduction to PW. I like the clean aesthetics. This surely will get some people interested in PW. Please everyone go and like/comment this on YT.

I would use a Pages::published hook for that. Assuming that the "help request" is a single item (I'll call it job in my example) on your "job board" and that both users and jobs have a page reference field "interests" that links to the area of interests, you can attach that published hook and everytime a job is published, those emails will get send. Dummy code: wire()->addHookAfter('Pages::published', function(HookEvent $event) { $page = $event->arguments(0); if($page->template !== 'job') return; // build selector value for interests, e.g. 1234|3456|5678 $interests = implode('|', $page->interests->explode('id')); // get users who are interested in this job, assuming the template for users is 'applicant' $interestedUsers = wire('pages')->find("template=applicant, interests={$interests}"); // either send emails directly foreach ($interestedUsers as $u) { // logic for sending emails } // display send result status message wire()->message('Notifications sent', 'success'); // or create a page for job-notifications and redirect there }); Sending emails directly from this hook will take some time until the admin user gets a message displayed. So this might not be optimal. As an alternative you could create a job-notification page and redirect the admin there. On that page you can list the interests and intersted users and a sent status as well as a send/resend button and handle the sending there. With these separate notification pages available in the system you could build a custom Lister for an overview which makes it more convenient to interact with the notification system, see sent statuses etc.

Great you solve it. Jut for explanation: if you hook after Pages::save and save the page again within that hook, this will cause an infinite loop as you already have observed. To avoid this you can either use a before hook like you did or take advantage of the the $page->save([options]) by using `$page->save(['noHooks' => true])`

At the time of import of new pages you should use the same sanitizer that you use later for the exist check and assign the page name manually when creating. That should give you consistency.

I'm reviving this. @LostKobrakaihas nginx vhost confs in this gist: https://gist.github.com/LostKobrakai/b895e2e0e8a2c14b4da88cc7e16cf954 Just wondering if they are up to date with the latest PW .htaccess rules? What seems to be missing are 16A and 16B which are needed for better control over multilang installs with UTF-8 page name support. When I try to run those through available online converters it results in garbage. Not having enaugh expertise in .htaccess or nginx vhost configs. So any help would be much appreciated.

I think this is a great idea and would love to see it implemented. Of course you could achieve this with partials, if statements etc. But your proposal would make things much cleaner imo. Great resource. Thank you for putting this together.

There's

I made a proof of concept how this could look like: https://codepen.io/gebeer/live/qBJdJjd If you want to adapt that, we can go on from there.

The search is working now ? Some thoughts: For someone who doesn't really know what they are searching for, it would be good to have a tag list (either complete or a subset) on the search page. By clicking one ore more tags, all relevant recipes should be listed as results. a tag list with the same functionality could also be implemented on the main recipes page (top or side)

Very interesting. I was looking into vicuna as well. Haven't installed it yet due to hardware "shortages". But these open source projects are very promising. Only thing they would need is some more specific trainig for programming, PHP, ProcessWire before they can be useful for that purpose. And that training stuff is the most time consuming. But generally I would prefer using an AI installed in my local network and specialized in the tasks I need to solve rather then those all purpose models that are publicly available for the masses...

@gornycreative guess you meant to post this at ?

Thanks for the updates and happy easter! When I click on the search icon I get redirected to https://processwire.recipes/topic/search/. Some if I type /search in the URL diractly. Something going wrong with the routing there, I guess

Additional info: with above solution, chinese characters are preserved as UTF8 in page names. But all other UTF8 characters in other languages do not get translated with pageNameTranslate like they would if the site didn't have $config->pageNameCharset = 'UTF8'; That is undesirable because for example, german umlauts now get translated from ä to a instead of ae. If setting $config->pageNameCharset = 'UTF8' is active, the pageNameTranslate sanitizer ignores the character map, that we can usually set in the module settings for InputfieldPageName. Actually, that editable character map is no longer available when $config->pageNameCharset = 'UTF8'. To circumvent this issue, I manually replace all characters before passing them to sanitizer pageNameTranslate I wrote a function that takes the default character map for replacements from InputfieldPageName::$defaultReplacements, adds custom characters and then performs string replacements based on the character map: /** * replaces characters in a string with characters from a custom character map * needed because Sanitizer::pageNameTranslate() doesn't take into account the character map defined in InputfieldPageName * because the site uses $config->pageNameCharset = 'UTF8'; * used in the Pages::saveReady hook in ready.php * * @param string $string * @return string */ public function replaceCustomCharacters($string) { // take default character map from InputfieldPageName class $defaultChars = InputfieldPageName::$defaultReplacements; // add additional characters $allChars = array_merge($defaultChars, [ 'ä' => 'ae', 'ö' => 'oe', 'ü' => 'ue', 'ß' => 'ss', ]); // replace all characters from map $allChars in $string $string = str_replace(array_keys($allChars), array_values($allChars), mb_strtolower($string)); return $string; } My final saveReady hook now looks like this: /** * only use UTF-8 page names for defined languages */ $wire->addHookBefore('Pages::saveReady', function($event) { /** @var Page $page */ $page = $event->arguments(0); if($page->template->name == 'admin') return; // exclude admin pages if($page->rootParent->id === 2) return; // exculde pages under admin tree (e.g. media manager pages) $languages = $event->wire('languages'); /** @var Sanitizer $sanitizer */ $sanitizer = $event->wire('sanitizer'); $utf8Languages = ['cn']; // Add more languages as needed foreach ($languages as $language) { if ($language->isDefault()) continue; $langName = $language->name; $translatedTitle = $page->getLanguageValue($language, 'title'); if (in_array($langName, $utf8Languages)) { $pageName = $sanitizer->pageNameUTF8($translatedTitle); } else { $pageName = $sanitizer->pageNameTranslate(wire('site')->replaceCustomCharacters($translatedTitle)); } $page->setLanguageValue($language, 'name', $pageName); } }); Note that my replacement function lives in a custom Site module that is made available to the API as wire('site'). All in all there is a lot to consider with UTF8 page names activated. I wish PW would make life easier here. Just the other day when I played around with GPT-4 and asked it how we could solve that problem, it started to halluzinate and proposed that the only thing I had to do was setting utf8PageNames property per language like in this dummy code: $lang = $languages->get('cn); $lang->utf8PageNames = true; $lang->save(); In reality the Language object does not have such a property. But I think, this would be a great enhancement and would allow setting page name behaviour based on each language and not globally only, like it is now. Will open a feature request.

After all the research I have done on how we can train chatGPT specifically for ProcessWIre, I came to realize that it knows already knows PW and its API quite well. I experimented with prompts to make GPT-4 into a PW specialist. This is what I came up with and what seems to work really well: This primes GPT-4 and brings really good results when asking further questions. This example shows that it knows a lot about the API in detail: Q: Are you aware of the ProcessPageClone class and its methods? Not bad at all ? What I'm still having difficulties with is prompting copilot, tabnine or codeium to give me PW specific code. But thats a different story...

This is great news and highly appreciated. The module as is works great for the most parts. But to make it work with snipcart v3, it does need some adjustments. Other than that I have it running without major issues. Since I thought that it won't be continued, I did quite some changes to the code in my install. Might turn that into a fork. Maybe there's something you can make use of. EDIT: Oh, I just saw that I had already forked it. But needs some cleanup, I guess...

The status can be used as active toggle. But, as you said, this highly depends on the use case. I have several sites where a separate 'active' checkbox field is required because in PageLister (like Pages->Find) those pages should appear for user roles other than superuser and not be striked-through.