bernhard

Better late than never ? ? You can use Pages::added for this: https://processwire.com/api/ref/pages/added/ And using conditional hooks (https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks) it gets even easier and cleaner: $wire->addHookAfter('Pages::added', function(HookEvent $event) { $page = $event->arguments(0); bd($page); }); I always start with the basic hook and test it. In this case this was quite interesting, because it fired twice! The reason is that this page contains a repeater matrix that creates a page for the first (possible) item: Then you can modify the hook to be more specific: $wire->addHookAfter('Pages::added(template=basic-page)', function(HookEvent $event) { $page = $event->arguments(0); bd($page); }); Voila, it fires on the right page only: And it will not fire on any further publish/save/etc events ?

Cheers:) Would be nice to see a little tutorial when you manage to do it ?

I'd recommend using adrians great tracy debugger module. Then you can easily (and instantly) see the content of your variables. It has lots of helpful information so you'll learn a lot quicker and it has the console, where you can try out things quickly and easily. See what you get by a simple dump - using the short syntax d()

Thanks for testing my module ? That's because the default Uikit theme's getUikitCss method is not hookable. I'm waiting for ryan to accept my PR... https://github.com/ryancramerdesign/AdminThemeUikit/pull/77 Would be nice if you could investigate more time to debug on this. I can't reproduce this, so I can't fix it.

Thanks for your help and for clarification. You said so I thought it has nothing to do with my module. Could you please provide a working PR for those changes?

Thanks for clarifying. That's why I don't like multi-site installations. There are always edge-cases where it doesn't work as expected... But this one might be worth an issue on github.

Hi @tiefenbacher_bluetomato, thx for sharing! Do you have a demo for us where we can see it in action? ?

Great to hear that ? Thank you for your PR ?

Just merged a PR that takes care of camelCase fieldnames: https://github.com/BernhardBaumrock/RockFinder/pull/4/commits/c3bef03c5fc00b9439c0b6bba0997a5843f5868e @simonGG the filter might work, but it's for sure more efficient to do this via SQL. But if you don't have lots of entries it might be easier to stay with your solution.

Nice site! I like it ? You might want to fix this: ?

Is your site a multi-instance installation? Why is it site-ncog and not just site? PS: Please try it with a fresh PW single installation and report if that works. If not, report the error. If yes, please try to debug what could be the problem with the other installation.

I guess this has nothing to do with my module. Where and how did you install AdminThemeUikit?

Yes, that's correct.

You need the files AND the database for a working processwire installation, so if you don't have a database dump anywhere, you'll not be able to run pw. Maybe you have a dump in /site/assets/backups/database ?

Hi Torsden, try to use ProcessPageEdit::buildForm, do a google search for this exact phrase and see if you can get examples. Sorry, on mobile ? The principle is to get the right field in the hook and then just change the "required" setting.

Glad to see you again, @Nvim! @Pete, are you also happy?

OR selectors should not be a problem. Could you please try to refresh all cached files? Maybe there's something else that causes this? Please try to narrow it down a little more... What's the array that is converted to string on line 195 of PageFinder.php ?

New version online: 1.1.2 The selector for the finder is now always stored as string, but can be retrieved as string or array - getSelectorStr() or getSelectorArr() This can be useful to share code for grids that are similar but need little adjustments, like one grid shows all available trainings, one grid shows only trainings that where booked by the current user: include(__DIR__.'/trainings.php'); $finder->setSelectorValue('client', $this->user); $finder->addField('done'); $this->setData($finder);

The new rockfinder updates make it easy to extend grids: Extending Grids Sometimes several RockGrids are very similar and you don't want to duplicate your code. You can create one base file and include this file from others: // trainings.php $finder = new RockFinder([ 'template' => 'training', 'sort' => 'from', ], [ 'first', 'from', 'to', ]); $finder->addField('coach', ['title']); $finder->addField('client', ['fullname']); // trainings_booked.php include(__DIR__.'/trainings.php'); $finder->setSelectorValue('client', $this->user); // only show trainings of current user $finder->addField('done'); // add column to show if the training was completed $this->setData($finder); You can then create another file, for example trainings_available.php to show all trainings that are in the future and available for booking: include(__DIR__.'/trainings.php'); $finder->setSelectorValue('from>', time()); $finder->setSelectorValue('client', null); // client must not be set -> means available for booking $this->setData($finder);

Nice! ? Please let us now about the results/answers.

I'm using 5.7 both on dev and live. Sorry, no idea ? http://smalldatum.blogspot.com/2017/06/sysbench-for-mysql-50-51-55-56-57-and-8.html , while http://www.oaktable.net/content/mysql-56-vs-57 says they perform quite similar. Maybe 5.6 has a problem with those subqueries?

RockFinder now supports array-syntax, which makes the code a lot cleaner:

hey @tpr, is there a way to disable the filterbox on some admindatatables, eg via adding "nofilterbox" class to the table? Edit: Created a PR

Sure, it was just an example. This would of course be possible. A shopping cart only functional after signing in? No guest-checkout? No, that's not what I'm thinking of ? But yes, SSO could be a good tool for many other usecases using this approach!

Sorry dragan, totally missed your post! Seems your comments where exactly what I've come up yesterday ? Yeah - it's an early stage idea ? Real logged in users could just have more rights than silently logged in users. What pages are created would have to be managed by the module. But that would be the same if you built that app in the frontend! Take again the shopping cart example: What if you wanted to provide an image upload feature for your user? You'd need to create a temporary page and make sure that the user can only edit this page. If the user did not finish checkout, you'd delete this page after 1 day. The same thing could be done in the backend. I think it is not always necessary to keep track of which user edited recordset x. Again the shopping cart: It would be enough to count how often a product was added to a cart by a public user, or how often a cart was checked out successfully. But as long as the user does not check out the cart, it might not be necessary to log him in as a real, unique user. Another example: What about a public guestbook? Users could click on "create new entry", then the backend could create an unpublished page that only this user can edit (don't know yet how this could be done), the user could save this page (having all backend features like url field sanitization, email, ckeditor input, file upload) and an admin could then publish it after approval. Or think of a forum software: Logged in users could create new content, but public users could only read entries. This would also make a lot of sense to be built in the pw backend as we already have a standard there: Uikit, ProcessModules, jQuery. And boom, one Forum Module could then be instantly used on every other PW installation, with easy theming support via LESS (eg RockSkinUikit). We could even work a little bit on the admin to make it easy to replace the header + footer of the theme, so it would be even easier to integrate the whole forum into an existing website by just injecting the menu and footer section!