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