bernhard

Would be interesting to hear about your use case where you'd need such an API ?

Hi @tomasanjosbarao I'm not sure if this would help or make things more complicated ? The goals is anyhow that everybody can in the end learn by reading (and maybe watching) the tutorial ?

Thx, just realized that today in the morning when I had 2 windows opened from yesterday that opend because of my shift-click tests ? This does really not work. Not only where the panels unusable they where also hidden somewhere around my 3 screens ? If there's no easy solution that's fine. Really not that important, thanks for explaining ?

Hey @adrian these new dumping upgrades will be so helpful in so many situations!! ??

Absolutely! Just played around with RockPdf and that new tracy dumping features open up so many new possibilities (like rendering the generated pdf in an iframe). Really great stuff ? Thx for that reminder! I'm so used to them that I didn't think of them being optional ? I'll fix that instantly!

FockFinder1 had a totally different implementation (not based on DatabaseQuerySelect) and also a very different API, so there will be lots of differences. I think the concept of joins and relations should be very flexible though. And it's now also a lot easier to create custom column types that basically let you join whatever data you need. So I think RF3 should really be an improvement in all areas. If you find any use cases that RF3 does not support, please let me know ?

v1.0.3 adds two new features: addPath() each() Callbacks RockFinder3 supports row callbacks that are executed on each row of the result. Usage is simple: each() $RockFinder3 ->find("template=cat") ->addColumns(['title', 'weight']) ->each(function($row) { $row->myTitle = "{$row->title} ({$row->weight} kg)"; }) ->dump(); These callbacks can be a great option, but keep in mind that they can also be very resource intensive! That applies even more when you request page objects from within your callback (meaning there will be no benefit at all in using RockFinder compared to a regular $pages->find() call). addPath() A special implementation of the each() method is the addPath() method that will add a path column to your result showing the path of every page. This will not load all pages into memory though, because it uses the $pages->getPath() method internally. $RockFinder3 ->find("template=cat") ->addColumns(['title', 'weight']) ->addPath("de") ->dump(); If you need the path for linking/redirecting from your data to the pages it might be better to build a custom redirect page that works with the page id, so you don't need the overhead of getting all page paths: <a href='/your/redirect/url/?id=123'>Open Page 123</a> If you really need to access page objects you can get them via the $finder parameter of the callback: $finder->each(function($row, $finder) { $row->foo = $finder->pages->get($row->id)->foo; }

Great idea ? I've implemented your changes on the bardump branch: https://github.com/baumrock/RockFinder3/commit/436257b8822fd89e76951db1521c8f2619ef880c Once you have your code in Tracy please tell me and I can merge to master ? The new section of the readme: Dumping data For small finders Tracy's dump() feature is enough, but if you have more complex finders or you have thousands of pages this might get really inconvenient. That's why RockFinder3 ships with a custom dump() method that works in the tracy console and turns the result of the finder into a paginated table (using tabulator.info). For all the dumping methods you can provide two parameters: The title of the dump* The settings for the rendered tabulator table *Note that if you set the title to TRUE the method will not only dump the tabulator but also the current RockFinder3 object (see the next example). dump() or d() $RockFinder3 ->find("template=cat") ->addColumns(['title', 'created']) ->dump(true); barDump() or bd() For situations where you are not working in the console but maybe in a template file or a module the barDump() method might be useful. Dumping the SQL of the finder To understand what is going on it is important to know the SQL that is executed. You can easily dump the SQL query via the dumpSQL() or barDumpSQL() methods. This even supports chaining: $RockFinder3 ->find("template=cat") ->addColumns(['title']) ->dumpSQL() ->addColumns(['owner']) ->dumpSQL() ->dump();

Thx @psy It depends on how you have used it I guess. But you can definitely run both beside each other. That's why they have separate names so that I can use them together in my projects without the need of refactoring existing code. In the long run RockFinder3 should be the only module to stay. Meaning that if you build a new project you should definitely use RF3 only and if you find anything that does not work yet with RF3 just give me a ping and I'll implement it. Most of that should be easy and maybe just copy&pasting methods from RF2 to RF3 and doing some refactoring. So I guess the answer is: It is a completely different module ?

Done ? Just realized that this update actually breaks a lot of the functionality provided by RockFinder3 - so it's critical to get an update for this! ?

Hey @adrian would it be possible to make the panels open in fullscreen on shift-click? I think that could be a great benefit not only for the console but also other panels with lots of content!

Thx, is removed ?

I really don't care a lot about those things (neither the plus icon nore the favicon), but couldn't you also set the page title to something like: #DEV# xxx on the dev site and leave the favicon untouched? ?

That just happened with the latest commit ? Thanks! Didn't think of that and that would have really made the development difficult! I'll post a comment in the issue ? Thx for clarifying. I also don't like them, but it seems that Ryan likes them, because we have this setting in /wire/.editorconfig trim_trailing_whitespace = false Thx, just enabled the setting in VSCode as well ?

Thx @adrian works a treat ? I have slightly modified it so that it checks if Tabulator exists before loading it. Seems you have some code prettifier active: https://github.com/baumrock/RockFinder3/commit/2863b76e9109673d7095e08d5d0d9b6ad5193f3c What are you using? I've followed this issue and was a little afraid something would break anything in rockfinder, but I did the upgrade just before posting this topic and everything seemed to work. If you are referring to the screenshots containing "old" values instead of bind variables that's just because I made them before upgrading the core. Or is there anything I missed out or need to check again?

How does it look on your end? Why not use the fontawesome icons we already get shipped with PW?

True. Do I state somewhere that you need to use the processmodule for dumping?

Please try the latest commit ?

Hey @adrian a thank you is not enough!! The console was so helpful while building the new version of RockFinder - I hope you have a use for RockFinder3 so that you get something back for your brilliant work! ?

Thx @adrian does the error disappear when you remove the "created" column?

Combine the power of ProcessWire selectors and SQL Differences to previous RockFinder modules RockFinder3 comes with extensive docs ? RF3 supports chaining: $RockFinder3->find("template=foo")->addColumns(['foo']). RF3 fully supports multi-language. RF3 makes it super-easy to add custom columnTypes. RF3 makes it easier to use custom SQL statements. No bloat! The module does just do one thing: Finding data. Differences to findRaw Background: RockFinder has been there before findRaw existed findRaw makes it a little easier to query page fields, but RockFinder is more flexible in that regard RockFinder might be faster than findRaw: see here DOCS & DOWNLOAD: https://github.com/baumrock/rockfinder3 Thanks for using RockFinder3. If you find RockFinder3 helpful consider giving it a star on github or saying thank you. I'm also always happy to get feedback in the PW forum! Happy finding

That's what RockMigrations is for ? I've thought about a similar thing back in 2016 because I didn't know better (https://processwire.com/talk/topic/14603-rocksvn-brings-version-control-to-your-fields-templates/ ) but migrations are the way to go. The new migrate() function makes it very easy to build reusable setups: https://github.com/BernhardBaumrock/RockMigrations#migration-config-files

Thx for the interest everybody! I'm in contact with @elabx and @Sephiroth and we will try to build something useful and document the process so that everybody can learn from it. Similar to what ryan planned with the events fieldtype, but step by step, so it's easier to follow ?

Sorry, I can't get that to work properly and I don't want to hunt through all the options... Yes, it could. I thought about that. But I'm loading the tabulator library only if there is a RockTab field rendered on that page. Not sure - maybe it would be better to load those scripts automatically? It would be cached anyhow... Might be the better solution! RockFinder does actually not use Tabulator at all - that's a different module ? So as it is just used for testing/debugging finders a processModule that loads tabulator via CDN ist the best option imho ?

Basically just refactoring and getting rid of all the bloat that is in RockFinder2 that is not needed (process module for defining finders, the sandbox, etc). The API and usage will not change drastically though. I'm quite confident that RockFinder3 will be the final version that will be there to stay ? And it will also come with proper docs ?