bernhard

@psy used $bookdetail, whereas @SIERRA you used $bookeddetail Use TracyDebugger and you'll easily be able to solve such issues on your own via the bd() function (bar dump), eg bd($bookdetail) would have showed you that this is not a repeateritem but NULL Also it might be helpful to post the whole error message for us... And please use the code option for pasting code in the forum.

hey @jmartsch, not really. I'm fighting with it on several new projects Some changes turn out to be not as simple as I thought (as always). I'll release a version when I finished my projects and did some more testing. Yes, it will be renamed to "RockGrid" because I changed the grid library from datatables.net to ag-grid.com

As long as you use regular selectors and don't loop over thousands of pages it will be perfectly fine

I guess what kongondo is talking about is that PW is blocking access to /scripts folder via its .htaccess so you would have to modify it to grant access to this folder to everybody. Or you just leave the script in a web-accessible folder like inside /site/templates

You really should!! Just make sure port 80 is not blocked by any other program ( https://forum.laragon.org/topic/929/no-port-80-in-use-check ) It's incredibly easy to switch php versions and different php settings (like I showed with xdebug). You can even use it as portable version on a usb drive (I think that version is limited to one php version, though). But moving your sites is as simple as copying the related "www" and "data" folders to another instance of laragon. https://medium.com/@oluwaseye/add-different-php-versions-to-your-laragon-installation-d2526db5c5f1 It's also the fastest setup I've had so far (tried xampp and vagrant).

thx @kongondo, the easiest solution for me was to just turn it on when needed. Via laragon this is very simple and fast (it will reload apache automatically):

Sure, I'm with you here. But I think it's much more critical to get an empty dump than to get a bloated one where you need to look for the correct information and maybe turn on the "cleanup feature". But I can live with both versions, of course Edit: @adrian could it maybe show a notice on empty debugInfo objects to turn "debugInfo cleanup" OFF to be sure it is really empty?

hi @hberg539, welcome to the forum and to the world of ProcessWire very interesting project, indeed! ProcessWire is awesome for making interfaces for managing your database in an easy, and (by everybody) understandable way (gui). The problem that comes with all the flexibility is that regular SQL queries are WAY harder to do (just take a look at the database. Every field is a single table, so you need to join all tables before you can actually use them for a useful query). So if you are used to having your database tables and doing some SELECT this FROM that... then you'll have a much harder time. That's why I built the linked RockFinder (that is still alpha, so be careful - there might be some breaking changes in the sooner future). Using RockFinder it will be very easy to use the PW API (which is great, of course), plus - and that's the awesome part - do everything you want via SQL. See this post how you can easily combine both worlds. Basically you just let RockFinder create the complex SQL query for you and then you build another SQL select around it: $finder = new RockFinder("template=dooraction", [...fields...]); $sql = $finder->getSQL(); $database->query("SELECT foo, sum(bar) FROM ($sql) as mytable WHERE DATE_FORMAT(...)"); There are also some performance tests in the linked topic. Hope you share a great showcase with us once you are done Good luck and lots of fun!

Welcome to the club, Adrian ? +1 for making the large dump default. I also think it's better to turn it off if you need but see everything by default so that misleading situations like yours and mine some days ago are less likely to happen

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 You can enable/disable php extensions with a simple rightclick in laragon:

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 DON'T follow the instructions there, it's simpler with laragon (choose your files and paths of course): 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 Enable xdebug via laragon 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.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 If XDebug slows down your server you can simple enable/disable it via laragon. This will require only two clicks and reload apache automatically

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:

Thanks for that one! Edit: Still seems mollie.com is better for my needs. But don't want to get offtopic...