Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by nik

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. The picture is so much better with me already gone (and Antti behind the camera).
  9. 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.
  10. 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.
  11. 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 .
  12. 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?
  13. 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.
  14. 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).
  15. 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!
  16. Thanks Ryan! And sorry . Like Antti said, the fix isn't needed for this module anymore. Then again, I'm actually working in the same office with Teppo (and few others) and it would really make a difference in our working conditions if you were able to solve this in the core. Seriously speaking, this really seems like something that needs to be fixed. Probably it doesn't need immediate attention and could wait for a while but I do hope you don't just let it be as it is now.
  17. This is what Soma's referring to: http://processwire.com/talk/topic/5299-vote-for-processwire-to-be-packaged-by-bitnami/.
  18. Thanks Matthew! I'm always interested in the cause when someone's got a problem with a selector. Well at least when it's not an obvious one . Often it's a misunderstanding of some kind or a structure complex enough to get anyone dizzy, but then there are those few cases where someone's actually hit a bug or some other kind of bad behaviour. And those are the cases I'm always willing to try and solve. So, wilsea, I wouldn't say your issue has been fixed. That's only a workaround. Of course it may be one good enough for your particular case, but at least I'm still wondering what's the reason. You checked the code lengths from the original table if I'm not mistaken? Could you run the check against the data in the "field_code" table (if the field is called "code" then that would be the table with the code strings in a field called "data")? Just to rule out the possibility of some inconsistency there. I'm guessing you've generated the pages in PW using a script and there just might be something wrong there. If everything seems fine there also, could you give a couple of example codes (working and not working ones)? There really has to be some explanation why you've run into this behaviour. Don't get me wrong - I'm glad you got the expected results and you're probably just fine using this approach. Just being curious .
  19. First I'd check and double check the code you're searching for is exactly right - but you must have done that already to be able to give such a detailed description. Still, could those codes for pages 99.. have for example a space in the beginning? To check if the issue is about getting an exact match you could try it out with $pages->find("code%=xyz"). If this gives you the right matches then it has to be something with the data. To check the data you could see the database directly. Something like "SELECT LENGTH(data), data FROM field_code" will expose codes that have a length different from what you're expecting. Be it a 6 or 9 letter string, don't know which as the length changed in you post .
  20. Thanks Martijn! I really should look into adding "edit next sibling" as it probably works just fine in most cases (I forgot kongondo's feature request, sorry!). And maybe I should also go with Antti's suggestion and rename the module to AdminSaveActions - I thinks there's been enough of after shave already . I'll take a better look at this after work/shave today.
  21. I tried those out and they all seem to work as expected for me (using the latest dev, 2.3.8). What's the page tree like? In what context are you running that code, in a template file or a module? Are you able to reproduce this behavior on a clean install? Or with some certain steps taken from a clean install?
  22. Just a quick one (on a mobile atm). If imageTags is a field on an image page then I guess the selector should be just "imageTags%=$q, limit=20". Does this (with the foreach RJay proposed) solve the issue?
  23. Well, another way would be using a different template for the child pages ("child-template" in the following example). Then you'd be able to fetch the grandchildren like this: $grandchildren = $pages->find("has_parent=$cat, template=child-template, limit=$limit, sort=-date, sort=title"); This scales really well and has no issues with the length of the selector string. And who knows, maybe you already have things set up in a compatible way. Of course with "has_parent=$cat" you could also filter by some other property that gives you child pages only: "property_abc=only-child-pages-have-this-value". Or filter out the subchildren level with "template!=subchild-template" or "property_xyz!=only-subchild-pages-have-this-value". Those properties and values are naturally only placeholders to demonstrate possible solutions. The possibilities are more or less endless. Some options, like using different templates, are pretty general but often there are ways specific to the situation available as well.
  24. Hi Alejandro! That else-block is never executed, that's why the page does not get created and rendered. This is because $pages->get() "Returns a Page, or a NullPage if not found.". So $fwd is always an object (either a Page or a NullPage) and "if($fwd)" is always true. Test for the page id to see if you got a real page, like this: if($fwd->id) { ... } else { ... } (And remember to sanitize $transaction_id if it's part of user input.)
  25. First of all, my examples were not right - not at all, sorry. Now they're fixed. The problem is that you're limiting pages under each "subchild" separately, not all grandchildren at once. Here's one way to get there: $limit = 4; $cats = $pages->get("/mypage/")->children; foreach ($cats as $cat) { $menu .= "<div>"; $menu .= "<h2 class='titlebg'>$cat->title</h2>"; $grandchildren = $pages->find("parent={$cat->children}, limit=$limit, sort=-date, sort=title"); if($grandchildren) { // if they have GRANDchildren $menu .= "<ul>"; foreach($grandchildren as $child) { $menu .= "<li><a href='{$child->url}'>$child->title</a></li>"; } $menu .= "</ul>"; if($grandchildren->getTotal() > $limit) $menu .= "<span><a href='{$cat->url}'>See More</a></span>"; } $menu .= "</div>"; } This would give (with the example structure again): cat1 cat2 child2.1.1 child2.1.2 child2.1.3 child2.2.1 See More cat3 child3.1.1 This trick to get grandchildren ("parent={$cat->children}") would not be the way to go if there were a lot of "subchild" pages under any "cat" page. This is because the selector expands to something like "parent=1234|1235|1236|1237|...|1507|1508" giving a too long selector string at one point. But assuming there aren't more than a couple of dozen of them, this would work just fine. I also added a little condition to show "See more" only if there are more grandchildren to see - just as an example.
  • Create New...