bernhard

Thx, I know all those options. Don't know exactly what I meant with my comment I think I was talking about some kind of staging/dev setup... Not related to vscode of course

Phew... This was quite hard but finally I made progress. Please see the dev branch if you want to play around @flydev : https://gitlab.com/baumrock/RockSqlFinder/tree/dev#notes (other parts of the readme are outdated meanwhile, It's just some notes for myself and old examples..., sorry no more time today). This is an example query with a join. This is necessary for pagefields when you want to get not only the page id's but also the related page's fields information like "title": Next step is to make CONCAT operations possible so that the join will return a concatenated string of ids and titles (miau, cat ..., mimimimi). This should also make aggregations like sum() possible (see here: https://gitlab.com/baumrock/RockSqlFinder/tree/dev#notes -> not much change needed for the resulting sql). The new version of the module is completely recursive, so I hope (haha...) that support for image fields with description (in this case it's not a related table but on the same table like the imagefield) easy. We will see... PS: Actually I just realized that defining the field "cats" is stupid when we define a join named 'cats'. Because I'm removing this field later anyhow... need to change this. You see there will be some more changes in the future, sorry...

thanks for the headsup glad you found it! I'm right now working on a complete rewrite of the module. The syntax will change a little bit but be a lot more flexible. I'm working on a recursive version that should make it possible to easily query pages that are referenced by pagefields. This is a huge timesaver when working with mysql because this joins can really be a tedious task. This setup should also make it possible to do easy aggregations via custom SQL statements. That's why I think I will not need your aggregation functions for $pages api Hmm... Thinking about it... Maybe this could be helpful in some situations. Maybe you want to share it in the dev board with all of us? I hope I can push an update this week.

awesome! this helps a lot, thanks

just merged @gebeer's changes to support multiple renderers in separate files and he also added a bootstrap renderer thank you!

yes, you can $session->redirect() after processing your form, then it will clear your post data. next thing to take care of is when the form is submitted and there is a validation error on the server, the form for the user needs to be re-populated with the values already submitted

Hi @SamC, great to see you are making progress 2 things: 1) I'm always sending forms to the same page an in that template I do something like this: if($config->ajax AND $input->post->submit) { // process form } // regular template code Usually this makes the setup easier. 2) As you see there is a LOT to consider with forms. That's why I built the RockForms module using Nette Forms, because that takes care of all this stuff. I'm not saying "stop learning and use my module" here But the nette docs might be an interesting read for you. You'll come across the things mentioned above (CSRF, validation etc.). And besides that, it is the only library I found that does validation on the client side and on the server side with one single setup of the form

Another option could be to use repeaters in your template. This might or might not be better and depends a lot on your situation... The TOC would be really simple then. Find operations might be harder...

Sorry, no idea. Only situation where I know that it is slow is when it loads pages because of closures. Do you have the current version? Is this check available in your module? https://gitlab.com/baumrock/RockSqlFinder/commit/17464b0397ed5f3d62bc86177d0c2395f33b5d9e Thanks, no need at the moment

can you post your $pages->findObjects() call please? Sorry, missed that you already did that. You can try dumping the query that is created by my module and throw that to the dbms and analyse it. As I wrote in the related thread I'm working on another implementation of RockSqlFinder as I came across some limitations yesterday

hey @adrian would it be hard to implement a fullscreen feature for the console panel? or maybe all panels? the resize is great, but a fullscreen would even be greater no priority at all, but if it is easy I would highly appreciate this feature ps: sometimes i have z-issues with the panel:

@flydev that's exactly what it is built for. I think you'll love it combined with RockGrid I worked on it quite heavily yesterday because at the moment it is not possible to query referenced page fields easily. See this example: "account" is the bank account where the transaction relates to. "account:title" should show "MyBankAccount 1" and "MyBankAccount 2" but it shows the "title" of the transaction (uniqid). I'm tackling this today, so if you have some time to wait, that might make sense. Or you might come up with a good solution for that? I thought of adding dot-notation, like "account.title.status" showing the account id, the account title and its pw-status. When I tried that, I realized that it might be better (or the only way) to JOIN all the field's tables so that they are available to query for the related information afterwards. This is not possible with the current subquery setup. The other option I will check today is to make easy JOINS possible. This might be easier. Something like this: $pages->findObjects( ['template=transaction', ['id', 'title', 'account', 'images:description'], [ 'name' => 'trans', 'joins' => ['template=account', ['id', 'title', 'status'], ['name' => 'acc', 'on' => 'acc.id = trans.account']], 'concat' => ['account', 'images'], ]] ); What do you think?

Thanks @szabesz and @tpr, same feeling here. I just thought there might be a processwireish-3-lines-of-code-no-dependencies-at-all solution Also thanks @jmartsch, but the last thing i want is to include any dependencies for such a small priority Thanks for your feedback.

I'm quite sure you will Actually it's a VERY important part of my RockGrid module. This makes building Grids (or Datatables, or "Listers" how we in the PW world would call it) a breeze. You just throw a $pages->findObjects() call to the grid and let it do the rest (sorting, filtering, pagination etc). Another usecase where this can really be a lifesaver is all kinds of data exports, feed generation etc. - It makes a huge difference to load 10.000 pw pages compared to executing an SQL and a quick php foreach. I'm working on the module again because it was too limited for my needs. I think I will come up with a good solution the next days! (And proper docs)

If anybody of you like me totally missed the markdown preview of vscode just click the preview icon on the top right:

Thx. But I don't want to add any dependencies if not really necessary (like RockSqlFinder)

I knew you would ask Thats the screenshot tool Hm, never worked with gulp and don't think it would be worth the effort. Maybe it does not matter at all? Does anybody know of any real issues when loading a lot of files? Does anybody know at which number this "a lot" could be? I thought of a snippet that does a foreach and creates a file on the fly with file_put_contents. But the file would need to be different for all pages (thats how it works now). Hm... I could actually change that behaviour and create one single js and one single css file thats always loaded when any rockgrid item is available on the page. Since all the plugins load with eventlisteners this should work... I'll leave this on the ideas-list...

Please see the current version of this module here: https://modules.processwire.com/modules/rock-finder/

Question to all of you: At the moment the module loads all assets separately. Each plugin and each renderer is placed in one file. I don't want to change this, because that way it stays clean and maintainable. But I thought it might not be ideal to load all those files separately for sometimes only one line of code inside this file. Do you have any ideas how i could combine those files to one js file and one css file? ProCache could do that on the frontend, but I don't want to rely on a pro module, and it would not work in the backend. Thanks for any hints

Just tested the field on a custom admin page: public function ___execute() { $form = $this->modules->get('InputfieldForm'); $f = $this->modules->get('InputfieldRockGrid'); $f->label = 'Default Report'; $f->themeBorder = 'none'; $f->setData("id>0, limit=10", [ 'title', 'templates_id', 'created', 'status', ]); $form->add($f); return $form->render(); } Thanks again @adrian for Tracy's awesome request info panel to get the proper "themeBorder" setting edit: ajax mode does not yet work in processmodules...

Welcome to the world of ProcessWire Same feeling here for the last 4 Years Regarding your code: Maybe you need to check if the given pagename already exists. Not sure if that happens automatically or not, but you should definitely try and see if it throws an error.

@Artomultiplo of course everything is still working. The index.php file is the main processwire file, see https://processwire.com/api/include/ If you only want to create new pages from inside processwire (eg in a template file) you don't need to include index.php, because processwire is already booted.

Thx, this looks nice, but am I right that this forum is 0% responsive and also has no mobile version? All those solutions look so oldschool Even https://www.phpbb.com/community/ looks more modern... May I hear your reasons for choosing mybb over phpbb (they look quite similar)?

I think I'm almost done Plugins are now very easy to create and extremely useful as they are reuseable across multiple projects: Sample setup of column statistics: // custom column stats grid.plugins.colStats.valueGetters = { id: function(column, selected) { return grid.pluck(0,{selected}).length + (selected ? ' selected' : ' rows'); }, percent: function(column, selected) { return grid.avg(column, {selected}); }, }; Everything works in the backend and in the frontend, just echo the field as you would do with any other field echo $page->mygridfield Data loads blazingly fast. The 10.001 rows here load in 500ms and are automatically compressed by the server to reduce transfer time (here it results in 90KB instead of 1MB of data!). Thx again @adrian for that idea. Cell renderers can be combined as you like! That's really powerful and great! We can build libraries of different cellRenderers that we need often and then just wrap them in a function and return the one's we like: In this column I combine the "actionItems" renderer and the "percentBar" renderer. The actionItems are only applied for regular rows. For rows of the "colStats" plugin we only append " (avg)" to the cell and don't show the icons because they are here to edit this lines related page (and of course the statistics row has no related page): colDef.cellRenderer = function(params) { var str = ''; if(!params.data.colStatsRowType) { str = RockGrid.renderers.actionItems(params, [ { icon: 'fa fa-bolt', href: '/admin/page/edit/?id=' + params.data.id, target: ' target="_blank"', str: 'Open external: ' + params.data.title, },{ icon: 'fa fa-search', href: '/admin/page/edit/?field=percent&id=' + params.data.id, str: 'Open panel: ' + params.data.title, class: ' class="pw-panel hover"', }, ]); } else { str = ' (avg)' } return RockGrid.renderers.percentBar(params, str, (!params.data.colStatsRowType ? 0 : 2)); }; Updating the grid after closing the panel is on my todo-list

Wow, collabora code looks very interesting!! Thanks for bringing this to my attention. I'm very excited about how you will integrate this with processwire!