bernhard

Of course, you're right ? Forget about that! And for situations like this it's really nice to add the inputfield via hook so that no field (and table) is created unnecessarily in the database.

Maybe you find some help in the links in this post?

Did you have a look at RockMigrations? Seems that we are having similar goals... And I've added Fieldset support lately - maybe you can get some inspiration there: https://github.com/BernhardBaumrock/RockMigrations/commit/8417b2b33422e741eeb7f84a5320c249b73d18c9

https://medium.com/@spp020/vs-code-extensions-for-complete-ide-experience-bca5bb2f0f90

I've opened an issue in the intelephense extension repo: https://github.com/bmewburn/vscode-intelephense/issues/652 Maybe you want to add your thoughts or give a thumb there ?

Thx @kongondo I'm also really loving it already. RockFinder1 felt complex in comparison and every added feature added more complexity to id. Now using the queryselector syntax things got a LOT easier and therefore a lot more solid, eg https://github.com/BernhardBaumrock/RockFinder2/commit/6ca0937a499259afe46745ef4cce4486fdc9443d

Just added support to hide columns in the final output. Before I've always hidden those columns via JavaScript in the final table, but if you don't need them, why not removing them from the result before transmitting them to the client? Now it is as simple as that - and the example also shows the new concept for single-page-reference joins which I really enjoy using as it is so much clearer than in RockFinder1: $rf = new RockFinder2(); $rf->find('template=husband'); $rf->addColumns(['title', 'wife']); // wife is a single page reference // find all wifes $wives = new RockFinder2(); $wives->find("template=wife"); $wives->addColumns(['title']); $rf->addJoin($wives, 'wife'); Result so far: id | title | wife | wife:title --------------------------------- 11 | John | 22 | Sue Hide the wife column (the page id of wife pagefield): $rf->hideColumns(['wife']); id | title | wife:title -------------------------- 11 | John | Sue ?

Mollie has a service called Plink for that purpose. You can create one-time-payment links for free or reusable payment links for 0,25€ per payment (plus transaction fees). You have the option to let the user choose the amount or you can define the amount via url segments: link removed --> description = PW-Demo, amount = 5€, will redirect after payment to this forum topic So the easiest would be to create a simple form where you let the user choose the amount (if necessary), after submit you send the user to the plink endpoint and if you want you can redirect the user back to your website after payment (that costs again 0,25€ per payment). PS: As @dragan mentioned paypal donate buttons are even simpler (or links as shown in my signature)

Does anybody of you know if/how it is possible to get intellisense support for methods that are added via hook? $wire->addHook("Page::foo", function() { ... }); So when I type "$page->" in my editor it should list "foo" as suggestion...

If that's your goal you should maybe have a look at PW Kickstart, especially this reply: https://processwire.com/talk/topic/18166-processwire-kickstart/?do=findComment&comment=187284 It's a lot more flexible than site profiles (spoiler: I don't like them ?)...

Thx @ryan That's strange, I've just tried on a new install and I can confirm that everything seems to work as expected. I'll try on that special installation once more and report back if the problem persists. One little change that I've made is catching and logging exceptions instead of throwing them (eg in db-backups process module): try { $http->download($url, $file); } catch (WireException $e) { $this->log($e->getMessage()); }

What does this method do? Can you share the code or explain where it comes from?

You can just dump() or barDump() the $row object: You have the "debug info" and the "full object" options.

Did you try this solution? ProcessModules are great for custom user interfaces, but a settings page is - at least how I understand it - primarily for storing some data. That's a little harder to do using ProcessModules and it's exactly what ProcessPageEdit is built for. So I think the solution described by @Jonathan Lahijani is still the best option.

Did you think of packing the content of ready.php in your own boilerplate module?

Sounds good ? PS: I recommend using conditional hooks as they make it very obvious what's going on when: $wire->addHookAfter('Pages::saved(template=xyz)', function ... ); PPS: I think even this should work: $wire->addHookAfter('Pages::saved(template=xyz,notify=1)', function($event) { $page = $event->arguments(0); // send email // reset checkbox $page->setAndSave('notify', 0); });

Taking Robins example I'd also add some feedback for the user: $wire->addHookAfter('ProcessPageEdit::processInput', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->arguments(0); // We only care about the top-level form $level = $event->arguments(1); if($level) return; // Get the notify field $notify = $form->getChildByName('notify'); // Return early if notify field doesn't exist or isn't checked if(!$notify || !$notify->value) return; // Now send the email notification... if($form->getErrors()) { $this->error('Mail NOT sent'); return; } else { $mail = new WireMail(); $mail->to(...)->from(...)->... $sent = $mail->send(); if($sent) $this->message('Mail was sent successfully to ...'); else $this->error('Error sending mail to ...'); } });

That should not be too hard ? Actually code completion is also a benefit compared to plain css.

--- Please use RockFinder3 ---

Ok that's what I was guessing. And I understand why it has never been an issue for me: $wire->addHookAfter('ProcessPageEdit::processInput', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->arguments(0); if($form->name != 'myform') return; ... }); I'm usually checking for the name, so $level is not issue ?

Interesting thoughts. I wonder if anybody has ever tried using purgeCss with uikit and if the results are similarly impressive as when using tailwindcss? @Tom. any numbers to share? Parcel.js looks interesting!

??

Hey @Robin S could you please explain this part. I know I've seen this $level check somewhere in the core but I've never come to a situation where I needed it for myself (and I've hooked processInput often, so maybe I'm missing something?). Thx

Just add a checkbox to the pages that should be shown (or should not be shown, whatever makes more sense) and exclude/include those pages in all your selectors $selector = [ 'template' => 'blogpost', // and so on ]; if($config->httpHost == 'yourdomain.de') { $selector['show_de'] = true; } $pages->find($selector);

I don't know yet. I've had a glance at firebase for maybe 3 minutes. From what I've seen documents have several fields just like pw pages have several fields. Only difference is that pw has a defined set of fields (defined in templates) whereas firebase documents can hold any kind of key-value-pairs. That's what makes firebase complicated to use (what they told me - maybe there are already ways to handle this better and they/we just don't know about it yet). I guess this would be firebase because they integrate everything with it (mobile app, other services etc). But I thought of even not storing data in PW at all. The more I do in the backend the more I'm using ProcessModules for many things. I think it should be quite easy to write an own process module that just provides an interface for the input (several fields) that sends that data to firebase on submit (via processInput, error handling built in).