bernhard

The PW core comes with many great classes such as WireData, WireArray and so on. Sometimes I'm developing stuff without a running PW instance and I'd love to have the great PW api available there as well. I've mentioned that in the PW Roadmap 2021 thread and Ryan stated: https://processwire.com/talk/topic/24897-weekly-update-– 8-january-2021/?do=findComment&comment=209891 With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection). A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). That sounded interesting, so I've tried how that works and created a repo for quick and easy testing so that everybody can try what works and share their findings so that everybody can learn. https://github.com/baumrock/PwStandalone PwStandalone The ProcessWire core has many great classes such as WireData, WireArray, WireRandom etc.; Many of them can be used without a running PW installation! This repo helps testing those features and hopefully will motivate others to share their findings (as PRs). It's as simple as creating a new file in the examples folder! I'd appreciate any help regarding the examples throwing an error! PRs for other examples that you've tried very welcome!

d() is the dumping feature of Tracy Debugger 🙂 Use it in the tracy console code panel and you'll be a lot faster with such quick php snippet tests/creations 😉

Robin, I disagree here. I've modified the admin quite a bit to fit to my needs. The problem has always been, that I had to rely on the old admin theme source files meaning that changes would potentially break my theme or backend fixes would not apply to my old version... I hope that's fixed now with the latest admin theme updates - I'm currently locked to the latest master as the latest dev does not work with my custom admin theme. I have to investigate... But it somehow proves, that it has unfortunately not just been simple CSS 101...

Crazy 😎 Thx for the clarification!

No hurry at all 🙂 Thx!

@adrian david pushed a fix: https://github.com/nette/tracy/commit/cffea9d4a625eccc870144273e60cb131edd5d40

This does really look great in many ways! I guess you are using https://grapesjs.com/demo.html for all that client side magic? When playing around with the demo my first thought was: Wow, that's brilliant and opens up so many possibilities and can solve so many client needs. Then I copied one person of the team: Also great. But the problem here is that we totally lose the content management part of ProcessWire - or am I wrong in this assumption? Jessica White is just some kind of text. Dead data. Like a Word document. What if Jessica White married - we would have to change her name on all of our pages where we have placed such a block, right? Using ProcessWire fields on the other hand we might have used ASMSelect to choose from a list of persons in the system and so we could do changes in one central place. I've never worked with grapejs, so my question is: Can we combine both worlds? Have a flexible layout builder on the one hand and have it use smart CONTENT of our page on the other hand? Thx for your effort on this! 🙂

I think both would be nice 🙂

v1.0.7 fixes an issue with non-lowercase fieldnames I had a field called "isFN" and rockfinder tried to look for data in "field_isFN" in the DB, where the actual table name was "field_isfn" (all lowercase). Seems like an easy fix - if you find that makes any problems on another end please let me know! 🙂

Hi @flydev 👊🏻 this is also due to the tracy core update, but it has nothing to do with the topic of this thread 😉 I think this has been discussed somewhere already...

Yeah, I think they are quite confusing. But I think they can also be very helpful in some situations... I'm also not sure about the padding on the left... Is that a core thing? The easiest would be a display:none on the <i> tags. But I'm really not sure if we should do that. It adds a lot of clarity to the dump (as one can see in the screenshot above). Maybe something like this? Not sure how to deal with it in the debug bar though 🙂

Thx @adrian I've already done that, but instead of bd($finder->getSQL()); I'd have to use be("<pre>".$finder->getSQL()."</pre>"); now 😞 See examples: Nicely formatted, but having \n: No \n but a pain to read: Nice format but hard to dump: Maybe I've found a CSS solution: .tracy-dump-string i { -webkit-touch-callout: none; -webkit-user-select: none; -khtml-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; } This prevents all <i> tags in the dump from being copied (at least on my chrome). Should we add that to the tracydebugger style? I've opened an issue at nette: https://github.com/nette/tracy/issues/458

PagePaths is a core module, you just need to go to Modules > Core and click on "install" 😉

v1.0.6 improves the groupby() method I have a survey tool where my clients can send emails to all persons participating in that project. Every person can give multiple "feedbacks" to other persons and every "feedback" has several "answers" that can be answered. On the mail-interface they see all persons of the project, but they did not see which of the persons had answered all questions. As they wanted to send a reminder to all that have open questions we needed an aggregated answer-count for each person. I've updated the project from using RockFinder1 to RockFinder3 and so the task got a lot easier 🙂 --- updated readme for groupby() --- If you need the SQL statement instead of a PHP array you can set that as one of several options: $sql = $finder->groupby('foo', [...], ['sql'=>true]); For example you can then JOIN complex queries quite easily: $foo = $rockfinder->find(...); $foosql = $foo->getSQL(); $bar = $rockfinder->find(...); $barsql = $bar->groupby('bar', [...], ['sql'=>true]); $join = "SELECT foo.xx, foo.yy, bar.xx, bar.yy FROM ($foosql) AS foo LEFT JOIN ($barsql) AS bar ON foo.xx = bar.yy"; db($rockfinder->getObjects($sql)); ----- If anybody is interested in the real world code: // setup main finder to find all persons $persons = $rockfinder ->find("template=person, has_parent=$project") ->addColumns(['isFN', 'lang', 'forename', 'surname']); // get results count for all FG (feedback giver) $rf = $rockfinder ->find("template=feedback, has_parent=$project") ->addColumns(['fg', 'answercount']); // add fixed number of questions asked per feedback $questions = $project->competences->count(); $rf->query->select("'$questions' as 'questions'"); // get sql of grouped result (grouping by FG) $answered = $rf->groupby('fg', [ 'IFNULL(sum(questions),0) AS asked', 'IFNULL(sum(answercount),0) AS answered', 'IFNULL(sum(questions),0) - IFNULL(sum(answercount),0) AS todo', ], ['sql' => true]); // build final query $persons = $persons->getSQL(); $sql = "SELECT persons.*, answered.asked, answered.todo FROM ($persons) AS persons LEFT JOIN ($answered) AS answered ON persons.id = answered.fg"; // set sql query as data for RockGrid $grid->setData($sql); Now they can easily sort and filter persons that they want to message 🙂 Happy finding 🙂

Would be nice to get some examples that I can add to the readme if you come up with a working solution 🙂