nik

Hi Peter, I'm not sure if the selector engine has something to take care of this in a more straightforward way now but let's see if I'm able to help you with this approach anyway. Looks like you're not saving the results of your find() calls into variables. Check my example you're referring to: I'm using $results and $additionalResults to hold the found pages and import the contents of $additionalResults to $results. And remember $pages is a system variable you shouldn't be saving anything to yourself. On top of that, it would be better to find unattached domain_ip's first and import only one page (which you don't have to find by the way), not the other way around. Something like this would probably work: // find free ip's $selectable_domain_ips = $pages->find("parent=/domain_ips/,server_id=$page->server_id_select, include=hidden, account_id="); // add currently selected one to the list $selectable_domain_ips->import($page->domain_ip_select); return $selectable_domain_ips; It seems you've got a two way relation here - or do you really? For this to work you'd have to take care of (un)setting account_id of domain_ip pages yourself. If you've got that set up and working already you should be fine. If not, I'm sure someone here will help you get there (or suggest a whole another approach to make it simpler). I'm a bit rusty myself not having done anything with PW or PHP in months.Hope this helps.

Hi Benjamin! That kind of selector is not supported in the core apart from dev version. I'm not sure exactly when selectors have been updated to allow wildcard search to the names of pages via a page reference (which "roles" is), but that seems to work in the latest dev at least. Then again, the module doesn't handle these kind of errors too good - you need to logout and login again to get rid of the error as the selector is saved in the session. Maybe I should try and find a better way as I've been tripped by this behavior myself a couple of times as well. But meanwhile, and to achieve what you were trying to do, update the PW core if possible. That should do it.

You're welcome. It's always a pleasure to be able to help someone. I'd suggest you (and everyone else for that matter!) take a look at Soma's great Cheatsheet. Click around and discover something new for your toolbox.

Ryan's on fire! There's nothing too big missing from the selector engine after this update anymore. But it seems like someone should start a whole new project on testing PW. My old project (on selectors mainly) has fallen way behind and I'm not sure it's a good basis for any broader testing. There's a lot of new stuff in place already and I'm sure there will be much more in the future, along with fixes and optimizations. Regarding selector grouping from a while back: What about repeaters - if I'm not mistaken their not supported? This thread has an example of a situation where grouping would have made things a whole lot easier. And didn't try it out at all but I guess PageTable isn't supported either. I'm happy to ditch the rest of my repeaters if only PageTables would be supported in the future.

Well, I read through your code a week back but couldn't spot any obvious flaw. Now I had another look and feel like I should've seen it in the first place... Actually you did yourself in the very beginning as you had the very same problem then. You're welcome. And you should still hang on to what you had working . Here's the problem line (core of it anyway): $matches = $all->find("rental_period.date_from>=$df, rental_period.date_to<=$dt, rental_period.booked=0"); As you figured out before (and Ryan confirmed you right), this kind of selector is something to beware of. While all of the three conditions must match, they only have to match the same page (property_availability), not the same repeater item. So this would match any page that has rental_period-repeater with one item matching the condition for date_from, another item matching the condition for date_to and third item matching the condition for booked. All the conditions could have a match in the very same repeater item, but that's not required (and you'd want it to be). That's just the nature of repeaters. Nasty, I know. Take the version with working date ranges and add the capacity and region handling like you have now in the beginning. Then, instead of first finding all cottages matching region and capacity, just go for the repeater items matching the date range like before and modify the match handling like this: foreach($matches as $item) { $property = $item->getForPage(); if(!$property->viewable()) continue; // skip if property is unpublished or something // add this: skip the match if it doesn't match your region or capacity if(!$property->matches($filterSelector)) continue; // now you have the $property and the matching repeater $item $termCottages[] = $item->id; } Here $filterSelector should be empty if no region or capacity has been chosen. Or it could be something like "location=xyz, sleeps>=10" to rule out any cottages not located in xyz or having capacity of less than 10. I haven't tested it but naturally it'll work like a charm . So you were on the right track all along. Just don't go for something that's been proven faulty for this scenario before.

Really? Either I don't quite understand what you're after here or you've got some kind of blackout . See https://github.com/apeisa/UserGroups/issues/20 to refresh your memory. Page::isPublic() was made hookable by Ryan about the same time too and it's in 2.4 stable. I wish I had time to polish the package but it doesn't look too promising any time soon. Everything works but there are some smaller things missing that would make the implementation more complete. Hopefully someday.

You've been tripped by scopes. Twice. Other guys have given you the solution to both problems above but you're going around in circles. I'll try once more. The first problem was using $pages inside a function. That and many other variables are not visible in a function due to scoping (see the post diogo linked to in the very first response to your question). You fixed this first scoping issue by replacing $pages with wire('pages'). But when you assign the results of the find() function to a variable $selects inside your function, you're inside another scope - a scope that is not visible outside your function. Returning the value of $selects returns only, well, the value. It does not expose a variable called $selects to be usable outside the scope of your function. So you'll need to either use the returned value straight away (see diogo's foreach example) or assign it to a variable. This is actually exactly what owzim proposed earlier on. If you take a closer look at his code you'll see the foreach is not inside the function but outside. Maybe you got confused by the same variable name. Something like this should work (with minimal changes to what you originally had): function selector() { $selects = wire("pages")->find("template=child-template, limit=2, sort=company"); return $selects; } $selects = selector(); include("./myinclude/browse.inc"); // browse.inc holds html for display Personally I would avoid using the same variable name twice to avoid confusing myself. Here's an example combination of what has been said earlier in this thread by others: function selector($tpl) { return wire("pages")->find("template=$tpl, limit=2, sort=company"); } $selects = selector("child-template"); include("./myinclude/browse.inc"); // browse.inc holds html for display Functions are useful and I really hope you're able to wrap your head around them (and scopes and variables) eventually. Reading a book explaining the very basics of PHP programming might be beneficial.

The picture is so much better with me already gone (and Antti behind the camera).

Nope, your syntax is correct. But it looks like the template for page $house does not have a field called 'repeater' and thus foreach gets something it can't iterate (null I guess). Check the name of the repeater field and it should work just fine.

I had totally missed this topic! So Joss, if your liver is no good for anything else it still did get my attention. I'm in, definitely.

Good catch Kongondo, thanks! I didn't test that quite enough obviously. I fixed this and also added a little bit intelligence to the option: If currently edited page is hidden but published all published pages are acknowledged (visible or hidden) If currently edited page is unpublished all pages are acknowledged Otherwise (visible, published page) only visible and published pages are acknowledged That may lead to some confusion I'm sure, but it felt quite natural to me. Feel free to disagree .

There you go. Pushed a new version to GitHub and updated modules directory + opening post accordingly. Changed the name to Admin Save Actions (though the damage has been done). Don't know how this affects those trying to update the module via ModulesManager - probably you need to remove and reinstall the module, sorry for that. Added "edit next sibling page" as described in some of the earlier posts. Basically does what Kongondo's version does too - a bit different route though. There's also a config option to set a safety net for this: option will not be show if there are more siblings (defaults to 100). Option is not shown also when there is no next sibling available (root page or last visible and published page under this parent). @Martijn: I didn't go for hidden/unpublished pages at this time. But I'm thinking of modifying this a bit so that when the edited page is hidden/unpublished also siblings are searched with "include=all". Do you think that would be logical?

Thanks for the input guys! I made a (classic, for me at least) mistake trying to make other modifications at the same time and ended up not publishing any of my changes. But Kongondo's code and Martijn's comments both revealed some things I hadn't taken into account. I'll try and publish the changes as soon as possible but I won't promise anything as it seems I never keep them anyway. Sorry. That possible performance issue is not solved just by using selector version of next(). The problem is we've got no general form of selector that would for sure limit the pages getting loaded there. Like Martijn explained, all the siblings have to be loaded to find out the current page's place among them before it's possible to say which page would be the next (no way to do this in the database, without stored procedures at least ). So using "limit" is not the answer here as you'd only get an incomplete PageArray possibly not even including the current page. I'm trying to get there by offering "edit next sibling page" as an option only if there are less than 100 siblings (could be made configurable of course). This way there's always a safe net to make sure editing a page doesn't slow down too much because of this module.

We Finns just want to stay quiet. Otherwise someone could notice us. Well, obviously you're an exception. Have to talk about this at work a bit (hadn't noticed the thread until today).

I have to say it's been fun working with this module. And at the same time quite weird as I'm not used to writing open source code during the daytime. Still some work left until it's truly ready for production use but it looks like we're getting there. Just keep on pushing those green buttons, we'll handle the rest!