bernhard

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 ?

Hi @kalimati I don't have one at hand and have lots of client work to do. If your request is important I'm happy to help and you can request a quote via PM ? I'm also working on another forms project right now, so it might be interesting to hear your needs and discuss options...

Hi @adrian I'm doing some more complex RockFinder operations and need to work with the dumped SQL statement. I have the dumpSQL() method for that, but since one of the last updates the newlines show up in that output: That makes it hard to copy the statement to mariadb and work on it there. Do you know how I can get rid of those \n characters? Thx --- Edit: I've now this quickfix in place: /** * Dump SQL of current finder to console (supports chaining) * @return RockFinder3 */ public function dumpSQL() { echo("<pre>".$this->getSQL()."</pre>"); return $this; } Not sure if there is a better solution? PPS: That is really annoying... whenever I'm doing bd($sql) I get the newline characters in my dump... ? I think they CAN be nice to have, but often they are totally useless and annoying. Maybe an option would be nice? Or is there already one?

I don't really like RockGrid any more, but it was the best option I had back then ? I've had to work on a quite old project over the last few days that uses RockFinder + RockGrid for several data presentation pages. I thought RockFinder3 was way easier to use and much more powerful, so I've added support for RockFinder3 in RockGrid - even it the module will likely not see any updates in the future...

For rapid development it is really great to trigger migrations on Modules::refresh(); As I'm using this technique all the time I've added a new method "fireOnRefresh" to v0.0.27 public function init() { $this->rm()->fireOnRefresh($this, "migrate"); } public function migrate() { $this->rm()->createField(...); } Another handy update is the trigger() method that I use in combination with custom pageclasses. Custom pageclasses are awesome, but they do not trigger init() and ready() methods by default. That is a pity, because I usually want several hooks to live in the pageclass and not in the module (for example auto-publishing pages or creating random pagenames etc). Now that can simply be done in an autoload module: // in init() $rm->trigger("\MyNamespace\MyPageClass", "init"); // in ready() $rm->trigger("\MyNamespace\MyPageClass", "ready"); I've also updated the example module that uses this technique ?

I guess you mean that pages can be visible in the admin, but if they lived under a parent that is not listable than they'd become "invisible"? That would not be a problem at all for me, because I'm creating custom listings pages all the time anyway (the page tree is simply not good for listing tabular data!).

I often need to explain my clients that they need to be more precice with their bug reports and explain step by step what they did and what happened. Today a friend of mine shared a link of an austrian startup that wants to help in such situations with easy on-the-go screen/audio/video recording. https://recorder.calipio.com/home What do you guys think? I could think of a "support" button in the PW backend that opens that tool and sends the link directly to me via mail as a support request...

Unfortunately we don't have a view-in-backend permission in ProcessWire. I've hit that wall several times, but it seems that nobody else is seeing that... https://processwire.com/talk/topic/15854-how-to-hide-menu-item-in-the-backend/ https://processwire.com/talk/topic/22369-hide-uneditable-pages-in-admin-treeprocesspagelist/ https://processwire.com/talk/topic/10195-hide-pages-from-admin-tree/ Would be great to open an issue in the requests repo so we could upvote that feature! I think PW would GREATLY benefit of such a permission level. For example @adrian 's "hacky" module should be obsolete then, I guess. Or am I wrong here @adrian?

At least this part can be done with a simple hook ? // site/ready.php $wire->addHookAfter("Pages::saved(template=foo)", function($event) { $page = $event->arguments(0); $page->name = $page->id; });

That's exactly how things already work ? At least the first part of your message. https://processwire.com/blog/posts/processwire-2.5-changelog/#adding-pages

How does the output look like? Are you sure that the image exists? Well, it should, if it is a static image and in other areas it works as expected... Not sure if $pdf->save() using a relative path for the pdf is a good idea ? Are you sure that the hook is executed?

Yeah - every block is a separate template (all having a prefix here): No idea how I could measure or tell about the performance impact of such a setup compared to other strategies, but it's nothing noticeable and I thought if that really became a problem I'd simply do some caching...

While reading my other post of the 5 most used features I thought: A one-click download of a DB dump would be nice! That could then be restored on local dev easily (maybe also as one-click). Using Adminer is not a problem at all. But it would be handy to have that in the tracy bar. But on the other hand I'm not sure if that should really be a tracy feature or a separate module. I'd love to have a better CI/CD workflow. Also coupled with RockMigrations. But in the meantime it would be nice to have a good workaround. If you guys have any other good suggestions I'd also be happy to use those so that adrian does not waste his time ?