Bill

I think i know the issue... kinda wild tho - not sure if it's a buffering limit or what... as i'm on my localhost.. (shrug). Its when I do var_dump of the 'children' objects, etc.. any time i seem/tend to dump that to the screen, then i'm seizing up the system, and it gives me the 'white-wall-of-doom!' When i remove it, ir do the var_dump on anything else (obviously smaller than the children object array, etc...) it's all fine. Bill p.s. er so it seems

Thanks... (high-five with all of you for helping me with it!)

Module :: HelperAttributes <?php /** * ProcessWire 'HelperAttributes' module * * Adds a getAttr() method to all PageArrays * * ProcessWire 2.x * Copyright (C) 2012 by Bill Ortell * (acknowledgements: Ryan Cramer) * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * */ /** * adapted from example thrown in by Ryan Cramer on this thread: * http://processwire.com/talk/topic/1083-get-specific-page-attributesfields-from-pagearray-set/page__pid__9500#entry9500 */ class HelperAttributes extends Wire implements Module { static public function getModuleInfo() { return array( 'title' => 'Get Page Attributes', 'version' => 100, 'summary' => 'Adds "getAttr()" method - get any {one} attribute from all pages in PageArray', 'href' => 'http://processwire.com/talk/topic/1083-get-specific-page-attributesfields-from-pagearray-set/', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHook('PageArray::getAttr', $this, 'getAttr'); } public function getAttr(HookEvent $event) { $pageArray = $event->object; $key = $event->arguments[0]; $pageKeys = array(); foreach ($pageArray as $page) { $pageKeys[] = $page->$key; // all pages have one! } $event->return = $pageKeys; } } The above was saved to a HelperAttributes.module and placed into my site/modules folder IF ANYTHING - someone will find this helpful in starting their own module (possibly?)

I only have about 100 pages (nothing to sneeze at...). Got it now. The "::" abstract call was throwing me off a bit was all. Bill

Thanks for the very thorough explanation. Lovin' it.

So this thread (http://processwire.com/talk/topic/745-module-want-related-pages/) could also use this approach - very similarly, right? If so, then this [iS] the best way to go. If not, then i'm even more confused . But i'm pretty sure you're going to say that it COULD indeed be used as a solution to the thread aforementioned... (or at least as a good alternative). [ I SURE as heck wished that i wouldn't have gotten SO invested into taxonomies, tags, categories, etc... and just stuck with "a page is a page is a page" before I got SUCKED into the wormhole called WordPress and of the like ... ah, but live-n-learn, I will - live-n-learn! ]

@Soma - thanks for the tip, and guidance @Ryan - what the 'oh my!' brain cell implant did you have to come up with such a ridiculously versatile system, Ryan. I mean really! I created plugins for WP, addons for a few others, and 'implementing' your modules (once i've now done it) is like a cakewalk... no FUNKY nomenclature, tricks, 'jam this into here...' and the ever-present 'oh yeah, you can't do that here so you have to hack your way in this way' stuff... period. Just soup to nuts, awesome, using observer patterns, full reflection, and keeping everyone on the handrail using "implements" in modules you rawk Ryan! (... and obviously the community that supports ya! ) Thanks all again... Maybe i'll post my two new modules... for anyone else who wants to use them. Just launch platforms is all - for making new/improved modules and sorts.

So (as in the above), you're accessing the (object) "input" via the PW API, right? And, in the code below, you're accessing it via the Wire (that this module is actually extending) And, since it's extending the Wire, obviously $this->input is all that's needed. (gotcha!) Now, just for my information, is using one over the other preferred? I'm assuming $this->input->.... Reason I'm asking is that if i use the wire() API in the future from outside of PW (typ. Wire API usage), will it totally "reflect" on my module better if it's incorporated using the wire("input") vs. the $this->input??? Just don't want to back myself into a corner is all .

continuing on this ePic journey... how would i grab the $input->urlSegment1 stuff/lingo from within the module itself.. i init. did the lazy way of 'global $input' but got nuttin'

just a follow up for clarity's sake only - I implemented (no pun intended) the above module, created my module as such, invoked the $page->children()->getAttr('id') request and voila, the EXACT same id's that i expect! Only now, instead of foreach's, extra php within the template/header, i have my *very own* (blush! tear runs down the cheek) module that i can now tweak and incorporate new goodness within..., now gets invoked when i call. This rawks! to no limited level, Ryan. Thanks.

awesome, thanks.

Right this is with the debug already set to TRUE. It's like it churns, churns, etc... on my localhost and then stalls out... nothing, no unseen html either... the page source is blank. Only (i mean ONLY) when i do the find('template=cool-page') syntax. As you can see from above, the find('id!=...') works like a champ - and fast as heck! By autoload, you're stating that this would be a module that i could put inside my site's modules' folder and install it and it then autoloads it? Thanks,... i'm still a bit unclear as to how to make my own module... i'm assuming that what you've done above it does essentailly that. I'd put it there, inside my site/modules folder, as such, check for new modules, install that module, and it'll autoload. And, upon teh use of the 'PageArray' instance, i'll now have the 'hook' for getAttr, which will be a part of the extension of Wire - as does PageArray. Right? (sorry, feelin' n00b to this PW stuff still, but testing a ton of things out for my next project... it's all swirling in my head right now...) THANKS for taking the time to do this above tho. [EDIT] Just curious, why is it an abstract call to that method, and not directly... conversely, if i used it to only extend the PageArray and implement Module, then wouldn't it be a direct call? (sorry, my lack of uber-PHP genius is showing... )

Just recently installed the Twitter Puller module, going to really have fun with that puppy i think . When i first 'checked for new modules' - the page refreshes and then says it found TwitterPuller. Now, upon trying to search for it, i'm left to rescan the entire page to see where it was placed (or at least I did that). Suggestion: Upon 'checking for new modules' - and upon successfully finding one or more new modules, whereby it states such in the green bar at the top, can you please name-tag hyper link that new module to the location on that page. Typically speaking if someone checked for new 'non-Core' modules, they're looking to ultimately install it . That way it'll make it easier to find and thus hit that beautiful install [submit] button .

okay but that'll probably do an internal foreach as well... negating the impact, but certainly one-line it . also, as i mentioned in my updated post above, i'm getting WIERD 'churning without any results, blank screen' activity on my use of ->find(), or ->children() - when using the selector of "template=cool-page" (which is the page template i'm using for this particular page). very wild... also - as an update to my code above... here's the most succinct way i've found thus far to accomplish things (yes, using the helper class above, and i'm still open to getting ideas more closely knit to PW.... but here goes: $children = $page->children('limit=3'); $ids = PageArrayHelper::getAttr($children,'id'); $randomChildNotInChildren = $page->children()->find("id!=".implode("|",$ids))->getRandom(); ... let the stone throwin' begin!

Right - thanks Soma - i'm honored with your reply, you're an active person in these forums, and in developing kick-butt modules/snippets ... My whole idea of grabbing the random would be to grab a random value was to on each page shown to the browser/user, that i have a paginated result set... (ie, showing page 2 of 10), then i want to show a random one (ie, at the top, at the bottom, or in the sidebar area) but I don't want the random one to be the same as any of those shown on that particular page #2 list. So, my idea was to grab the paginated list - that's the main priority, and then from that list grab their ID's and then grab a random page from this template, where NOT IN in the list of ID's shown. I'll play with the find() feature a bit more, and see how i can incorporate that into my page - ... will follow-up shortly. [followup] not sure what i'm doing wrong, but whenever i do a lookup using find("template={template_name}") or even a $page->children("template={template_name}") the system just goes into this churning fit to leave me with a blank freakin' page (lol). still at it... i have a work around using my solution above, incorporating a find(!=) syntax, but was wanting to fully use what you're telling me to see which one is more effic. and as close to native PW as possible. ... i'm on it

Just fyi - here's what i'm doing... (please save the 'stoning' for after i leave this forum... and get a head start on din-din with the family so i can proceed into heaven with a full stomache ) abstract class PageArrayHelper { static function getAttr(PageArray $PageArray, $key='id') { $pageKeys = array(); foreach ($PageArray as $page) { $pageKeys[] = $page->$key; // all pages have one! } return $pageKeys; } } Then by just calling it as such... $IDs = PageArrayHelper::getAttr($randomChildren); // returns (array) of ids now i can include that in the header, and i'll use throughout... my thoughts on this were if i'm displaying content and/or random content elsewhere on the page, and/or footer type - 'also check this out -' i don't want to have that same content be placed all over the place, i want it to be in one spot and one spot only but the pagination would be more of the uber spot, with the other random spots being secondary... (right now only 1 random spot, but you get the idea).

Interest'd in others' thoughts as well, but appreciate your K.I.S.S. approach and promptness (+1 @Pete! ) Truly! Thx.

(embarassed to ask... but the shame isn't too deep!) Module completed and available to public? (whistling as if no one heard a thing...) ;P

I see many times on the forums where this 'find' feature is used... but everytime i see that successively done - i always tend to cringe - hence my question for clarification below: "Is the above 2 liner - literally two separate queries on the dB? Or is it just a rifling thru what was already queried from the uber-query?" Thanks.

Right, i can use the above, and i init. had that in there (my code) in the template itself, and was looking to remove 3 lines from it and just do (what you assumed already from my pseudo-hack-code above) which was "get all the id's of the children associated with the pageArray object" So,... My next thought cuz i'd like to potentially do this for a multitude of uses, and to keep my code as DRY as possible... would you all recommend, when creating helpers (i know, i know... the CI in me coming thru - lol) like this (the foreach -> method by extending the PagesArray / WireArray class) that it's better to just simply create a catch-all 'helper' module? or do a general include int he head.inc (for ex.)?

Gotcha - yep aware of the find method, and thanks for explaining more thoroughly for this application of it. I am mainly interested in if there's a pre-established method i might be missing is all... like "->children('')->getAttr('id')" or something of that nature... that would 'internally' to the Wire/PageArray class would iterate thru the pages to get an array/object of all the id's for that particular pageArray set, like ... 3, 14, 23, 154, 161 -> allowing me to use them in a successive query based on those. In particular i'm wanting to do a ->getRandom() of all the pages, but in my pagination results (of those pages) below, i don't want the random one to be of the same as those listed in the page[d] results below. So, if the paginated listing below (showing page 2 of 10, the page id's are: 3, 14, 23, 154, 161 - then the random id i want to be still random but just including them). I know i can DO it, i was just wanting to Quickly (one-liner) Methodize it is all , like $pagedIDs = $pageArray->children()->getAttr('id'); (pseudo-hack code )

Thanks! Yeah, i don't mind doing it but i was hoping that there was a method like.... $pageArray->children()->getAttr('id');

I have a pageArray "$p" - that contains 10 pages; how can i get any particular attribute from each one without formally setting up a foreach/iteration over the 'set'. something like $p = $pageArray->getField('id'); ... where it would return all the id's of all child pages / pages within the pageArray? I'm sure this already exists. thanks!

btw, this post helped me out a lot guys, thanks for the hard work noticed this tho in an example of mine... I have a bunch of 'test' posts for a page (using a template) that i have and i'm using the pagination (i think) correctly, and pagination works splendidly... (incoming!) however! ... interestingly enough - when i selected page 11 (in this case), it show the numbers from 11, 12, 13, 14, 15, ... , 16 (do you see it? the "..." shouldn't be there at all - OR the "15" shouldn't be there hence allowing for the ...'s to take its place, but CERTAINLY not both. thanks for any help/fix. Bill

Duuuude! thanks... that's awesome! I'm not sure why there'd ever be a limit on this... but i totally get how this is done - thanks again for pointing this out! Bill