bernhard

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 ?

you mean uikit components? like slideshow, accordion, alert etc.? not classes like uk-text-center and so on?

I don't understand this part. What do you mean?

hi @yrglx just copy&paste the code from the quickstart to your _main.php file (if you are using the default profile) or your template file (like home.php): <!doctype html> <html lang="en"> <head> <link rel="stylesheet" href="https://cdn.rawgit.com/openlayers/openlayers.github.io/master/en/v5.1.3/css/ol.css" type="text/css"> <style> .map { height: 400px; width: 100%; } </style> <script src="https://cdn.rawgit.com/openlayers/openlayers.github.io/master/en/v5.1.3/build/ol.js"></script> <title>OpenLayers example</title> </head> <body> <h2>My Map</h2> <div id="map" class="map"></div> <script type="text/javascript"> var map = new ol.Map({ target: 'map', layers: [ new ol.layer.Tile({ source: new ol.source.OSM() }) ], view: new ol.View({ center: ol.proj.fromLonLat([37.41, 8.82]), zoom: 4 }) }); </script> </body> </html> You'll see that this will work. Then you can continue replacing part after part and see where it starts to break.

hey @Beluga I tried your steps and cannot reproduce your error: It works as expected. I used the default profile and the latest versions of rockgrid + rockfinder (used git clone with the master branches).

thanks @jmartsch that was a bug and I fixed it in version 1.0.7 edit: note that as soon as you are using callback functions like you do in your example the find will not be more performant than any other $pages->find() command. To make it more performant you could populate a hidden field with the page's path on every save and then just list this field in the finder call.

If you give me clear step by step instructions I can have a look. I don't understand your explanations in the previous posting

Hi @Beluga please can you provide detailed step-by-step instructions so that I can try to reproduce your issue. I don't really get what is wrong. Is it not working as expected? Edit: Sorry, I missed your first post. Please follow the quickstart tutorial here: https://gitlab.com/baumrock/FieldtypeRockGrid/wikis/quickstart From there you can continue adding features and always check wether it is working on the frontend or not. Some plugins do not have front-end-support yet. Most of the times it should not be hard to make them work on the frontend too. Please report back if the quickstart tutorial is working for you.

PW just got an update that is closely related to this module: https://processwire.com/blog/posts/pw-3.0.111/

setTimeout(function() { UIkit.alert('#youralertid').close(); }, 1000);