bernhard

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?

Yep, thx, I'm aware of that, but in my case I needed an url with forced HTTPS independent from the template setting. Thx again. I'll wait for an explicit example to see if anything is missing or I was just not reading the docs carefully enough ?

could you please give an example of what you would like to do and what is currently possible and what is not?

Thx, totally missed/forgot that ? Anyhow, I think there are other shortcuts missing (eg httpsUrl or functions to return the whole query string, host, scheme etc). I'll post back if I stumble over the next one...

From time to time I find myself adding custom api methods/properties like this one: /** * get http edit url */ $this->addHookProperty('Page::httpEditUrl', function($event) { $event->return = $this->wire->pages(2)->httpUrl . 'page/edit/?id=' . $event->object->id; }); Or this one for $page->httpsUrl, where I started a PR: https://github.com/processwire/processwire/pull/116 What do you think? Have you ever come across any needed page url variants. It might be better to collect all of them and create a aggregated PR? This is what we have so far: https://processwire.com/api/ref/page/

It's easy using RockFinder. See the example in the docs: https://gitlab.com/baumrock/RockFinder#custom-sql-aggregations-groupings-distincts

Sorry, I don't get what you are trying to do and why. Maybe horst's suggestion would have helped, but I think I'd need a better explanation even with better variable naming. A shot in the dark: Maybe it's easier to bootstrap PW in your "outside world app" instead of passing variables to there?

Same here. Welcome to the forum @scottc , please explain everything more and give some examples and explain what all those fields are for (av_date might have a meaning for you but it does not have one for me ? ). You should also explain what kind of data you have in your database and what kind of data you have in your PW installation. And last but not least: Why you have it there (eg you get data in the database format from a 3rd party system that you cannot change or you need to store this and that inside PW because there is a frontend search for clients etc...). Give us the bigger picture and we can suggest you some ways you could go. I'm quite sure there will be many ways - as with PW most of the time you have free choice ?

PW already has VEX onboard. You can easily use it like I did in RockGrid. See this example: You'd just need to target the right save-button and save only when the user confirms.

Thank you! Happy to hear that and glad I could give something back to you, Reno - thanks for all your great contributions ?

I'm quite sure that this has nothing to do with either RockGrid or RockFinder. Please try a clean install and report back if you have any problems. Thanks.

hey @mel47 and @dragan please try the latest version (v1.0.8)

thanks @mel47 that is a bug! I'll fix it as soon as possible. then also your problem @dragan should be gone ?

two things: 1) i think this would be a perfect fit for or That way you can either add a store to the user or add a user to the store. How do you make sure that every store has only one assigned user? Or is this not necessary? You might need to take care of that as well. 2) To anwer your question ? I think the easiest and maybe best option would be to add a checkbox field (eg "user_published") to the store template and set the value of the checkbox via a saveReady hook. You could then just do a $pages->find('template=store,user_published=1'); and use all the internal pagination features.

This happens when you have a grid that tries to show more rows, then adds scrollbars and therefore does not have enough space to show those rows and removes one. Then it tries the same thing again. You can set your grid to a fixed amount of rows. The number of rows in your case do not change. It's only the number of pages that changes (and that's correct of course, if you add/remove one row you'll end up with different page numbers). This can happen if you have page fields or repeaters with multiple items. The RockFinder might return those values as joined results with each referenced value in a separate row. Analyze your SQL or your RockFinder and the result itself to see where this comes from. You can comment out some fields of the RockFinder then you see which field causes the number of results to increase to more than you'd expect. You can either create a different SQL (see the RockFinder docs, or - sorry - look into the code). Another way to prevent such situations is to create a new hidden field that gets populated via saveReady hook and holds the information you need. Eg you create a field "linked_pages" that holds an array of linked pages, eg [{id:123,title:"demo page1"},{id:456,title:"demo page2"}] You can then use a cellRenderer to show this information as you want (eg with icons, as comma separated list, as number of linked pages etc.). It might sound complex but it totally makes sense when you build more advanced grids. Having said that, that's how it works right now. It's not perfect for sure. If you have any suggestions for improvement let me know. In that case just setup a valueGetter and make sure you return a proper value for all cells. This is how you make sure it is a number (for calculating sums/avg etc): document.addEventListener('RockGridItemBeforeInit', function(e) { if(e.target.id != 'RockGridItem_rockgrid') return; var grid = RockGrid.getGrid(e.target.id); var col = grid.getColDef('yourcolumn'); col.valueGetter = function(params) { if(typeof params.data == 'undefined') return; var val = params.data[colDef.field]; return val*1; // make sure the value is a number and not a string } }); Of course you can hide it: https://www.ag-grid.com/javascript-grid-column-definitions/ document.addEventListener('RockGridItemBeforeInit', function(e) { if(e.target.id != 'RockGridItem_rockgrid') return; var grid = RockGrid.getGrid(e.target.id); var col = grid.getColDef('id'); col.hide = true; var col = grid.getColDef('title'); col.headerName = 'MyDemoTitle'; });

Don't you use Tracy Debugger? You could have easily done a bd($page->rockgrid) or d($page->rockgrid) and should have seen and been able to debug it quickly. PS: Even if you lost 15 hours - the module took many many more to develop so you are still saving loads of hours ?