bernhard

no geo ip api, but a HTTP api: get the users ip: https://stackoverflow.com/a/13646735 get location info: https://ipstack.com/ or http://ipinfo.io using https://processwire.com/api/ref/wire-http/get/

hi @thetuningspoon, my module is a companion module for RockGrid. Those grids always need an array of objects as data source. Using $pages->find() and then foreach() to create such an array is terribly inefficient when dealing with several thousands of pages. That's why I built RockFinder -> it creates an efficient SQL statement for you and it is almost as easy as using regular PW selectors. The benefit of using SQL is that it is incredibly efficient. The downside is that some pw-related tasks become a headache (like checking for published state, sort order, multilanguage field values, to name just a few). RockFinder takes care of all that. It returns an array of objects that you can easily pass to a RockGrid or do whatever you want with it. See this example: The first array item is this (first row in the screenshot): Reading your question again RockFinder might not be the best fit for you. It does NOT support any kind of pagination (as this is done by RockGrid) and it does not return a pagearray. Though there is the option of using closures (see here) for using the pw api to return values.

I'm making progress! Current state is really, really nice. See these two examples of a feedback software that I've built for a client: full multi-language-support all kinds of custom cell stylings (backgrounds, icons, etc) custom filters filter by doubleclick on a cell (really handy) custom buttons-plugin (not part of aggrid): reload data via ajax (very performant thanks to RockFinder) reset filters fullscreen mode (really handy for large grids) excel export as CSV data reload grid automatically when a pw-panel is closed Another example: A list of all ratings for several categories See the bottom line: this is another plugin that is not part of aggrid. You can just show the sum of the column (like the second column) or render custom statistics (like min, max, avg). When you select multiple lines you also get the statistics only for the selected rows This is also an example how you can use pinned rows with aggrid (really awesome library!). Example of a range filter (aggrid standard feature):

maybe you are using an old php version that does not support short array syntax [ ] ?

@dragan see pm

Just make sure you have the latest version by deleting /site/modules/RockFinder and doing a git clone git@gitlab.com:baumrock/RockFinder.git

https://transfer.sh/brOON/site-RockFinderTest.zip (will be deleted in 14 days)

Exactly! @thetuningspoon see this post how you can use any SQL you want easily:

If you use setandsave there is no need for the upper two lines. Only this in the foreach: ...setAndSave('bookings_done', 10); Is the best way to do it.

@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.