bernhard

Thx @FrancisChung and @kongondo, the quickest possible fix was to just copy laragon's php binary folder, rename it to php...-noXDebug and remove the .dll and comment out the section for xdebug in php.ini Now i can just turn on/off xdebug with 2 clicks:

Just added support for closures: This makes it very easy to use the PW api for each row but also makes it a lot more imperformant: As you can see in the SQL it is done by adding an empty column to the sql statement and then looping all rows and executing the closure. Edit: Just pushed an update that removes one unnecessary $pages->findIDs() call. Compare sort disabled with closures: 15.3ms findIDs id>0, limit=1000 15.3ms getSQL 6847.7ms executeClosures 6868.4ms getObjects Includes executeClosures 6869.7ms Overall Inputfield Render Sort enabled with closures: 15.2ms findIDs id>0, limit=1000 15.3ms getSQL 6924.6ms executeClosures 6949.9ms getObjects Includes executeClosures 6951.1ms Overall Inputfield Render Sort enabled without closures (11.400 rows): 71.9ms findIDs id>0, limit=0 71.9ms getSQL 0ms executeClosures 374.4ms getObjects Includes executeClosures 378ms Overall Inputfield Render Sort disabled without closures (11.400 rows): 74.4ms findIDs id>0, limit=0 74.5ms getSQL 0ms executeClosures 126.9ms getObjects Includes executeClosures 130.5ms Overall Inputfield Render

Any news on this? Same issues here Edit: Just realized that the loading speed is OK when I have "listen for xdebug" in vscode ENABLED (sic!). When I switch it off, PW get's really bad load times. Can anyone confirm this?

I love TracyDebugger, but today I had a hard time debugging some stuff and tried XDebug to get support for breakpoints. It was a quite straightforward setup: create a file on your server and output phpinfo() Copy the content of this page to the wizard: https://xdebug.org/wizard.php Follow the instructions, they look like this: Instructions Download php_xdebug-2.6.0-7.1-vc14-x86_64.dll Move the downloaded file to C:\laragon\bin\php\php-7.1.14-Win32-VC14-x64\ext Edit C:\laragon\bin\php\php-7.1.14-Win32-VC14-x64\php.ini and add the line zend_extension = C:\laragon\bin\php\php-7.1.14-Win32-VC14-x64\ext\php_xdebug-2.6.0-7.1-vc14-x86_64.dll Restart the webserver check if everything worked by visiting the phpinfo() page again - it should show a section about xdebug now enable validaton in vscode by adjusting the user settings: "php.validate.enable": true, "php.validate.executablePath": "C:/laragon/bin/php/php-7.1.14-Win32-VC14-x64/php.exe", "php.executablePath": "C:/laragon/bin/php/php-7.1.14-Win32-VC14-x64/php.exe", "php.validate.run": "onType", install "PHP Debug" extension by Felix Becker and read the instructions enable remote debugging by xdebug by adding this to your php.ini [XDebug] xdebug.remote_enable = 1 xdebug.remote_autostart = 1 create a testfile, eg home.php and set the debug config to "PHP" add breakpoints and start debugging by pressing the green play icon reload your page in the browser and the debugger will stop on lines 2 and 3 where we set the breakpoints. open vscode (if you don't have two screens) and follow code execution step by step. There are also some videos on youtube: https://www.youtube.com/watch?v=poty5nKk2m4 Edit: Just realized that xDebug slows down ProcessWire extremely. See here: If anybody knows how to tackle this, please post the solution in the linked thread and I'll update this tutorial. Thanks See quickfix in my next post

Thanks @Robin S for your thoughts. It does not work either with using a reference. Same behaviour as without reference. Hopefully Ryan will have an explanation.

same here. though I haven't noticed this issue yet.

I've deleted the RockSqlFinder repo on gitlab and created a RockFinder repo. This will be the final name once I'm done with testing + writing docs. I've also added a simple tester process module to quickly inspect and test find operations: Note that this processmodule requires RockGrid which is not available for public yet, so this screenshot is just a sneak peak what will come.

OK finally I came back to this one and I found the problem. See these Tracy Console codes: Works: $p = $pages->get(1002); $p->of(false); $r = $p->repeater; $item = $r->getNew(); $item->title = 'created via api @ ' . date('YmdHis'); $item->save(); $p->repeater->add($item); $p->save(); d($p->repeater->count); Does NOT work: $p = $pages->get(1002); $p->of(false); $r = $p->repeater; $item = $r->getNew(); $item->title = 'created via api @ ' . date('YmdHis'); $item->save(); $r->add($item); // <<------------ here is the change $p->save(); d($p->repeater->count); Saying "does not work" I mean, that a d($pages->find('repeater.count>0')->each('path')); does NOT list a page with a repeater item added via the second code example, whereas it shows pages where I used the first (upper) example. Looking at the database it becomes obvious why: For the page with id 1002 there is no data and no count value present. @Robin S you should be able to reproduce it now. I've tested it on a fresh 3.0.99 dev version with the default profile and just added a repeater to the basic-page template. I'm not sure if this is a bug or I just have to use the api correctly... But at least I think it is an odd behaviour since it looks like everything is working correctly also with the bad code and you might not notice that you are in trouble... Items are available and even published: Here is the github issue: https://github.com/processwire/processwire-issues/issues/413

Same here, no time to test it right now, but what do you think of adding a field just like the exclude field but for manual INCLUDEs? Should be quite easy to implement, just pass the content of the field to a $files->find($dir) and scan that files. You are absolutely right that scanning the caches and compiled files is nonsense. But I think it's not a good solution to have a checkbox for the assets folder and then you have to exclude all unnecessary files... in my case I could just add /site/assets/RockGrid to my field and would have the todos show up in the tracy bar

Sorry, please try to rename your module's folder to "RockFinder" instead of "RockSqlFinder"

@adrian could you please add an option for the todo-panel to also scan /site/assets ? I always put my files for field configs there (runtime markup, rockgrid etc) so it would be great to have that files scanned as well. Thank you

@flydev please use dev3, it's a complete rewrite!

I get your point and it's not easy to formulate my answer properly. I'll come back to you.. I wouldn't see github as a place for grabbing software and removing brandings If they don't accept it, well, there are several other options: develop something on your own use formbuilder and support ryan find another client ( ) contribute something to this module (like you already did @gebeer ) sponsor new features for this module ... Please don't get me wrong - I just don't want to get too serious about that topic We also have those discussions for the pw Pro Modules from time to time... So you would prefer a commercial module? Don't get that point... Just contact me and suggest a proper price for removing that branding - and I'm not talking about thousands of euros here. Some contributions to the community would totally be fine BTW: I've started this experiment in my signature quite some time ago. Guess how many donations and likes I got until then? One donation, zero likes...

Of course it works. getForpage() returns the page where the repeater item lives. your code snippet was not clear to me, so you might use it differently, but using getForpage() is the key. You didn't provide any information of what your code does, which variables are what kind of data (pages, repeater items) etc.; Also you didn't provide information what you did exactly (where you placed my code) and what did not work. "doesn't work" is not a lot of information... Yes, that's correct and totally makes sense, since it is a repeater item and not a page with a parent page.

@Robin S I'm not an expert either and I will not pay a lawyer for consultancy on a module that I released for free... If anybody wants to make a fork with a removed branding: Go for it (bad karma for free ). As long as somebody uses MY version of the module (meaning he can also get all future updates), I don't think it is a problem to limit the MIT license by this detail. At least that is how it is meant... BTW: There was quite a similar discussion about that regarding pw itself long time ago: