bernhard

Hi @MischaK, welcome to the forum and the world of ProcessWire ? It's always interesting to read about experiences of others - depending on what your intention is on that topic, we also have the pub and dev talk forums. If you have questions related to processwire you'll always find a helping hand here in the forum. Enjoy ?

Hey @adrian what do you think of adding a fullscreen button to the dump div right beside the collapse toggles? When having large dumps this could greatly improve readability and it would just need to apply a simple class with these css rules: element.style { position: fixed; left: 0; top: 0; z-index: 99999; width: 100%; height: 100%; background-color: #fff; overflow: scroll; } Then it could turn this: Into that: The collapse toggles still work. Of course we'd also need a "close fullscreen" button (or maybe ESC keyboard shortcut?)

hi @MoritzLost , thanks for the detailed tutorial! do you know this module? If yes, you might elaborate what is different on your approach ?

You can do many kinds of sorting/counting/aggregating using RockFinder quite easily and efficiently, I just posted an example:

I created a demo-installation of RockGrid/RockFinder that I want to share soon that shows several examples of RockFinder/RockGrid Here's one example that @jmartsch requested support for - a grid listing the sum of all pages that reference this page: the residents can assign a house with a single pagefield: The php file for the grid (returning the final finder's sql, that's why I post it here) looks like this: <?php namespace ProcessWire; // the base table contains all houses // https://i.imgur.com/e5bC4sA.png $houses = new RockFinder('template=house', ['title']); // then we create another table containing all residents that have a living assigned // https://i.imgur.com/zYXEVIL.png $residents = new RockFinder('template=person|cat|dog,livesin.count>0', ['title', 'livesin']); // we join both tables and get a combined table // https://i.imgur.com/TE0vEPd.png $houses->join($residents, 'resident', ['livesin' => 'id']); // then we can modify the resulting SQL to our needs // https://i.imgur.com/UgzNqDD.png $sql = $houses->getSQL(); $sql = "SELECT id, title, count(resident_id) as numresidents FROM ($sql) as tmp GROUP BY resident_livesin"; // set the data // to check everything i created a test-grid where we can filter for the house title // https://i.imgur.com/9pdlYVz.png $this->setData($sql); The screenshots of the comments are here: -- -- -- -- -- The grid in the last example called "residents" is as simple as that: <?php namespace ProcessWire; $residents = new RockFinder('template=person|cat|dog,livesin.count>0', ['title']); $residents->addField('livesin', ['title']); $this->setData($residents); As you can see this somewhat complex example can be done in only 6 lines of codes (same example as above, just without comments): $houses = new RockFinder('template=house', ['title']); $residents = new RockFinder('template=person|cat|dog,livesin.count>0', ['title', 'livesin']); $houses->join($residents, 'resident', ['livesin' => 'id']); $sql = $houses->getSQL(); $sql = "SELECT id, title, count(resident_id) as numresidents FROM ($sql) as tmp GROUP BY resident_livesin"; $this->setData($sql);

there it is:

Good point. Need to have a look at his module. Didn't try it so far ? I wanted to make it supersimple but a PHP file would also be fine of courses. Thanks for the input!

I just pushed an update to my RockGrid module and came up with a new strategy for the module's version numbering: https://gitlab.com/baumrock/FieldtypeRockGrid/blob/master/FieldtypeRockGrid.module.php#L13-24 I placed a changelog file in the repo: https://gitlab.com/baumrock/FieldtypeRockGrid/raw/master/changelog.md And then the module reads the first line as the version number: 'version' => fgets(fopen(__DIR__ . '/changelog.md', 'r')), That way I just update the changelog with some comments, have everything in place and the module automatically updates the version number. This is also handy to share one version number for all child modules (eg Fieldtype + Inputfield). I'm not sure about that one, though. Do you think it is a good or a bad idea to have one common version number for both the fieldtype + inputfield or do you think it would be better to have that separate. The concept of having a readme and reading the version number from there would not be affected.

Lots of updates for the weekend ? I merged all updates of the dev branch to master and bumped the version to 0.0.8 I added a changelog here: https://gitlab.com/baumrock/FieldtypeRockGrid/raw/master/changelog.md I added an example filter + floating filter that you can easily copy and customize Regarding the filter: To apply this filter to one of your columns you just need to do this (full example here: https://gitlab.com/baumrock/FieldtypeRockGrid#create-custom-filters): col = grid.getColDef('title'); col.filter = RockGrid.filters.example; col.floatingFilterComponent = RockGrid.filters.exampleFloating; Here is the example filter implementing a "smart search": https://gitlab.com/baumrock/FieldtypeRockGrid/blob/master/plugins/filters/example.js It looks like this: Code with removed comments to see that it only 100 lines of code for your very own filter without limits (custom GUI, custom filter logic etc):

Wouldn't it have been easier in that case to first get all the id's of the pages that are in the trash and then loop all available tables in the database and remove all rows that have a pages_id of the trashed pages? Maybe it's not that easy, though. Not sure... I'd do a backup first ? ?

Hi mel, MySQL has a maximum number of 61 joined tables: https://dev.mysql.com/doc/refman/5.7/en/joins-limits.html Why are you adding those fields via ->addField and not just pass them in the fields array of the finder? Can you show your code and the resulting sql please? I'm not sure. Any chance you can send me a site profile to help you?

No, absolutely not ? You just have to make sure that it is loaded properly. I'd recommend you name your field and place everything in a separate related php file to keep everything clean and organized. You'll end up with much nicer processmodules like this one: The yourfield.php file can look like this: <?php namespace ProcessWire; $this->rg->assets->add($this->config->paths->siteModules . 'FieldtypeRockGrid/lib/moment.min.js'); $this->rg->assets->add($this->config->paths->siteModules . 'FieldtypeRockGrid/lib/currency.min.js'); // your finder here $finder = ... // set data $this->setData($finder); // send variables to JS // for example you can send an array of key/value pairs of a select options field // in the grid you can then replace the options ID that is returned by the finder with the corresponding label // like that (pseudocode): cellRenderer = function(params) { return grid.js.youroptions[key] } $this->js([ 'youroptions' => $youroptions, ]);

thx, I updated the readme and it will be committed in the next version. It now looks like this: You need to include `moment.js` to your assets. In your field's php file do this: ```php // eg site/assets/RockGrid/fields/yourfield.php $this->rg->assets->add($this->config->paths->siteModules . 'FieldtypeRockGrid/lib/moment.min.js'); ``` Assets is a property of FieldtypeRockGrid, you are inside the inputfield so there is no assets property. Does that help?

Tracy debugger can help a lot monitoring such things. You have the log function where you can dump something to files. You can then follow in real-time what's happening. Eg l("removing page $page->id from trash"); and monitor the logfile, eg tail -f site/assets/logs/tracy/info.log Not sure if that path is correct ? You might also use flush the pages cache: https://processwire.com/api/ref/pages/uncache-all/ or something like https://processwire.com/talk/topic/7572-processwire-recipes/?do=findComment&amp;comment=88505

Ah, ok. Didn't know what you need exactly and thought I'd share it with you. I'll have an update filter-wise for you (and of course everybody else) soon on the dev-branch ?

OK I couldn't find the post any more..

I've done a RockGrid that lists the translation availability like this and I think for custom listings that's the best option and better than adding labels for all kinds of whatsoever to the tree: I think somebody in the AOS thread came up with a solution to style language tabs differently based on the state (populated/empty). @tpr ?

Hi @jmartsch thanks for the hint. Regarding the alpha state: Yes. Still alpha. Whatever that means. I'm using it on several sites in production but I'm still developing things and sometimes change some concepts, so there might be breaking changes in the future. That's why it is alpha and I don't plan to change that, but it's working great for all my scenarios and it's already a huge step forward compared to the old datatables module/library ?

@Beluga working on filters right now and just saw that your example could also be done with the quickfilter: https://www.ag-grid.com/javascript-grid-filter-quick/ maybe that's interesting for you?

No worries ? No - working on a dev environment so it is/was no problem. I get your points. Don't know what would be the best approach. Maybe tracy should not be responsible for that at all and I should adopt my code to make sure OF is always false? But on the other side the docs say that OF is always false in module context, so I'm not sure what is the best approach? Would be happy to hear your thoughts. Personally I use the console a lot for testing hooks etc. and I've come over several occasions with weird results where it made a difference if I saved the page manually or via the tracy console $page->save(). I guess that where all OF issues... Hm... First I wanted to vote for OF=false by default, but I see that in the frontend it makes sense to have it ON to get the same results as in template context. But I don't think it is a good idea to have different settings in frontend and backend. I guess that would lead to unexpected/unwanted bugs even more than now. I think there should be one standard that is equal everywhere. Maybe two little radiobuttons on top of the console would be the best option? That would ad least remind us of thinking about it and make it easy to change? Edit: The state of the radio would need to be saved somehow. Not sure how to treat that best? Maybe the easiest and best option would be a simple hint on top of the console that adds "$pages->of(false)" to the code when we click on it. That way it would not change the settings for all other open consoles and it would make sure that this one code has the correct setting. Or maybe the best would be just to remember it myself? ? What do others think?

Hey @adrian I've had some headache today because of outputformatting and the tracy console. I have several saved and saveready hooks active that populate fields, do aggregations and so on. Everything seemed to work well, but when I updated all pages through the tracy console (basicalle a foreach loop with $p->save() to trigger the hooks) things started to get weird. I found out that it must be an outputformatting issue. In the hooks and modules OF is always FALSE but using the console OF seems to be TRUE. Is this indented? When I add $pages->of(false) on top of my console code everything works as expected. I ended up with hundreds of pages having status corrupted (131073). Wouldn't it be better to set OF to FALSE by default?

Just have in mind that this method gets very slow with lots of pages.

Hi kongondo, also best wishes from my side! Have you ever tried RockGrid? I think you should! It's great for building all kinds of custom backend listings. Just drop me a line if you have any questions.

This should not be necessary at all. The image fieldtype is used all around the world in many installations without any problems, so I think the problem is related to your setup and not any of pw's security settings. Sorry, I have no idea what could be the reason. You need to try everything on another environment and see if it works so that you can narrow down the problem.

sounds strange. does that help?