bernhard

Sorry for the delay @arjen Don't think there should be any restrictions. My module should not break any functionality that comes with aggrid. Maybe some of my additional tools might need to be adopted to also support enterprise features, I don't know, but the module will be extendible via plugins so you can do whatever you want with it. Another feature that I've implemented is called Batcher. This makes it easy to create batch processes sent via AJAX and execute custom actions on the server. An action can be as simple as that: $this->ajax('trash', function($data) { foreach($data as $id) { $p = pages($id); if(!$p->trashable()) continue; $this->pages->trash($p); } }); And the GUI: var Batcher = RockGrid.batcher; Batcher.items = grid.pluck('id', {selected:true}); Batcher.batchSize = 2; Batcher.action = function(items) { // send ajax request to this grid var ajax = grid.ajax({ action: 'trash', data: items, }).done(function(params) { Batcher.nextBatch(); }); }; Batcher.confirmStart({ msg: 'Are you sure you want to delete the selected rows?', onYes: function() { Batcher.nextBatch(); }, onNo: function() { $(grid.getWrapperDOM()).find('.rockgridbutton.trash i').removeClass('fa-spin fa-spinner').addClass('fa-trash'); Batcher.abort(); } }); Batcher.onStart = function() { $(grid.getWrapperDOM()).find('.rockgridbutton.trash i').removeClass('fa-trash').addClass('fa-spin fa-spinner'); }; Batcher.onEnd = function() { $(grid.getWrapperDOM()).find('.rockgridbutton.refresh').click(); $(grid.getWrapperDOM()).find('.rockgridbutton.trash i').removeClass('fa-spin fa-spinner').addClass('fa-trash'); setTimeout(function() { Batcher.vex.close(); }, 500); }; ? Edit: The screencast does not really delete mails and it's a lot slower than real-life, because the ->trash() operation is replaced by a sleep(1) ?

check your trailing slash option and see if that is the reason

Could you please tell us what you mean by that?

hi @stand-ground and welcome to the forum, Because these options are a site-wide config setting and site-wide config settings are placed in the config file, which is stored as /site/config.php - That's how pw is built.

I've added 3 new methods to the module: getArray(), getValues() and getPages() and officially released the module as BETA with a dedicated thread: I also added docs for all available methods with examples, here are the new ones: @joer80 see here for what you requested: https://gitlab.com/baumrock/RockFinder/tree/master#custom-sql-aggregations-groupings-distincts @Guy Verville I cannot reproduce your issue - please provide more information with exact steps to reproduce. Please use the other thread for all further discussion.

--- Please use RockFinder3 ---

I don't think so, but I don't care about that any more as the new version works differently and always returns a sorted resultset quickly and efficiently ? Absolutely! By default the finder query would be this: $finder = new RockFinder('template=person', ['title', 'surname']); $sql = $finder->getSQL(); d($sql, [6,999]); Doing the distinct: getting ids (verbose): Selecting only ids by group_by: And finally to get the pages: (btw: the portion of the sql dump is from an outdated version of rockfinder... but it still works) I see those kind of things have been requested several times now and I guess they will pop up quite often (doing aggregations, distincts, group_bys etc). It would be great to have a method for that in RockFinder, so if you have some time I would appreciate a PR making things like this possible: $finder = new RockFinder('template=person', ['title', 'surname']); $sql = $finder->getSQL(); $sql = "SELECT id FROM ($sql) as tmp group by concat(title,coalesce(surname,''))"; $ids = $finder->getArray($sql); $distinct_pages = $finder->getPages($ids); // or $sql = "SELECT id FROM ($sql) as tmp group by concat(title,coalesce(surname,''))"; $distinct_pages = $finder->getPages($sql, 'id'); ?

@mattcohen not sure what you are trying to do exactly but you have lots of if/else and duplicates that makes the code quite hard to read. Maybe somethink like this could clean things up a little? $path = '/foo'; $selector['foo'] = 1; $selector['bar'] = 2; $selector['type'] = $sanitizer->text($input->post->type); $selector['limit'] = 100; switch($path) { case '/foo': unset($selector['bar']); $selector['limit'] = 10; break; case '/bar': unset($selector['foo']); $selector['limit'] = 20; break; } d($selector, 'selector array'); $session->tmp = json_encode($selector); d($session->tmp, 'session as string'); d(json_decode($session->tmp), 'session as object'); As you can see I would highly recommend to use d() = dump() or bd() = bardump() in tracy. It's a lot more readable than var_dump() and a lot less effort. See the tracy docs for all the options (maxLength etc).

Considering this it might be true in austria: https://euobserver.com/justice/141746. Not sure if you are serious, but that's not what I meant. That's a different topic and I don't think that what we are doing here is good. I also think/hope that is is not legal and will change in the future... But I've no idea about law and politics ?

Fun fact: In Austria the authority for the GDPR regulations has <30 employees, while we have >300.000 companies. I guess those 30 employees will have other priorities than my website's cookies... And I guess this will not be very different in other countries. Not saying that we should not care about GDPR at all, but imho GDPR is really not meant to ruin every small business...

@thetuningspoon seems that you have some experience with pw's internal pagefinder. I would highly appreciate if could find some time to compare my implementation to the core features of pagefinder. I have the feeling that some parts of RockFinder are overly complex and maybe already built into the core and there is some room for improvement...

Maybe the docs can explain that? ? https://www.google.com/search?q=site:processwire.com/api/ref+session

ProcessWire is a lot more than just the API. Lots of hidden treasures inside the /wire folder - just have a look and see the comments in all those files. if($config->ajax == true) { // do ajax stuff }

<?php foreach ($page->children('template=child') as $child) { echo WireRenderFile('templates/child', ['page' => $child]); } ?> ?

Sorry, I don't get your question. What is your exact setup, what is the problem? What is your hanna code? Why do the children prepend + append the template file and why is that not placed in the config.php file?

Do you have a multilang setup? Maybe the page is not active in one language?

Hey @Robin S I have not had the need for that, but I also haven't come across the page path in the db... One option would be the "Page Paths" module in the core section of the modules, that says: Another option would be a field populated by a saveready hook. This could also be multilang. But I guess you want it directly from the DB? The saveready hook would maybe not be a good solution if you rename a parent with 1000s of children... you would have to take care of those situations and also it would be slow. Maybe you could build a query that joins all the pagenames together to one path? You would need to define a max nesting level then, I guess... Maybe that query would be slow? Sorry, no better ideas atm

well, you can style them however you want: http://github.hubspot.com/vex/api/themes/

Another hidden treasure in the PW Backend: PW 3.0.61 introduced the VEX library for dialogs: https://processwire.com/blog/posts/processwire-3.0.61-master/#admin-and-ui This is how you can use them in your custom admin pages: In your module's php load the vex library (eg in the ready() method of your module - init() might not work as it might load too early!) $this->wire('modules')->get('JqueryUI')->use('vex'); Then in your javascript: // show confirm dialog ProcessWire.confirm('Are you sure you want to delete this E-Mail?', function() { // on confirm $i.removeClass('fa-trash').addClass('fa-spin fa-spinner'); $.get('./trash/?mailid=' + $a.data('mailid'), function() { $a.closest('.RockGridWrapper').find('.rockgridbutton.refresh').click(); }); }, function() { // on abort grid.api().deselectAll(); }); Result: I opened a pull request with a little fix for handling clicks on the CANCEL button. If you want to support it, give it a thumb: https://github.com/processwire/processwire/pull/108

what are your settings for the file search ignore? today I hit ctrl+p to find and edit /site/ready.php but I accidently chose ready.php inside the filecompiler folder... **/site/assets/cache/** This snippet in the user settings helps, but I wonder if you have any other folders excluded?

glad it worked. 2 things: TracyDebugger helps a lot when trying new code. You can use the console to execute code quickly and use d() to dump instead of echo. This makes things a lot more readable, especially when you are dealing with arrays and objects: As you can see, getJSON might also be nice to use here

No, this is not the way pw does it, because pw needs more options in the find() method, handling shortcut calls from findMany(), findIDs() etc.; But your method is perfectly fine You could try to modify the query and add restrictions to the query array: you could do something like this (you have to try&error, not sure how/if that works): $query->orderby('yourorderby statement');

Thanks to @thetuningspoon reminding me of this thread I updated RockFinder to use the SQL portion of the $pages->find() operation instead of using findIDs() method. This has three main advantages: The query stays small even when querying thousands of pages (before this meant we where listing thousands of IDs in the WHERE statement) No need for $finder->sort = true/false; The returned results are always returned in the same sort order as defined in the selector RockFinder now also supports PW versions prior to 3.0.46 because it no longer needs the findIDs() method Before: WHERE `pages`.`id` IN (21245,........) ORDER BY field(`pages`.`id`, 21245,........) After: WHERE (pages.templates_id=54) AND ((pages.parent_id=21205 OR pages.parent_id IN (SELECT pages_id FROM pages_parents WHERE parents_id=21205 OR pages_id=21205))) AND (pages.status<1024) GROUP BY pages.id Version 6 is on gitlab

hey @tpr could you please add "noAutosize" class support for textarea autosize feature? line 1766 in aos.js (and maybe also some lines below) autosizeTextareas = target.querySelectorAll('textarea:not(.noAutosize)'); Otherwise it does autosize on my custom textareas, thanks This does not seem to work Could you please add a way to exclude custom textareas from this feature? Thanks!

No, as I said it will always return an array of objects. Or the plain sql query that you can use for later modifications. The reason why I built RockFinder was that I didn't want to load all page objects into memory. Therefore it does not return page objects... When using closures it actually loads all pages into memory, but it still returns a plain array of data. I don't see any reason to return a pagearray, that's the job of $pages->find() and all the other api methods... ps: you could easily loop the returned array and create pages as needed. all entries have the page id as you can see in the screenshot above.