bernhard

Thx everybody for pointing that out. Actually I'm quite surprised that those files are not blocked by default ? I'll have to do some refactoring (again) ^^

Just added support for really easy translation of all aspects of your field ?

Does it work in the backend? Do you have the latest version (git pull)? It looks like $RockFinder2 api variable is not available for you, but it should (the module is autoload).

Hi, @jens.martsch brought up the concern that .ready and .hooks files that I'm using for RockMarkup2 could be a security risk. See https://github.com/processwire/processwire-requests/issues/329 What do our security experts think? Is it worth the effort of refactoring my module to using .ready.php and .hooks.php extensions?

https://www.google.com/search?ei=Ic5wXcH_FsqNkwWrkrrABw&q=site%3Aprocesswire.com+user+template+image+upload&oq=site%3Aprocesswire.com+user+template+image+upload&gs_l=psy-ab.3...24062.26703..26931...3.0..0.86.703.10......0....1..gws-wiz.6KgaF6uurX4&ved=0ahUKEwiBlLOqqLnkAhXKxqQKHSuJDngQ4dUDCAs&uact=5

Maybe file permissions. Did you try it on another server/setup?

Hi @Marc Thx for that interesting question! I've pushed a little update so that RockFinder takes a DatabaseQuerySelect object as find() parameter. You can then add your find as a relation to your finder: Relations can be great for options fields or 1:n relationships. In this case we have 1:1 so a join would maybe make more sense (though have in mind that this creates one more row in the main resultset, so if you had 1000 rows that would mean 1000 more data items whereas in the relation it would be only the number of the templates). You can join ANY sql to your initial finder quite easily. First analyze the query and resulting SQL: We need two things: 1) LEFT JOIN the data 2) SELECT the column we need in the base query Voila ?

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.