Leaderboard

I respect Drupal, but strongly dislike using and developing in it. This comes from a couple years of developing sites in it. The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious). People may use Drupal at large scale, but I don't believe the product itself was ever truly designed for it. Like with WordPress, being used at the large scale is something that happend to Drupal rather than something it made happen. Drupal is a pig that people have affixed wings to because there wasn't any other way to do it at the time. You see similar things happen with the other big platforms (WordPress, Joomla). As far as pigs go, Drupal is a good one. There are some things to respect (though not necessarily agree with) about Drupal's roots and the original thinking behind it. There's no doubt that it is far better than Joomla, for anyone that cares about this stuff. Beyond that, where it excels is in all the 3rd party stuff written for it, to do just about anything. It's a diesel-powered cuisinart in that respect… whatever you need to blend, it will blend… but it'll be messy. Working at large scale, 3rd parties have built all kinds of caching, CDN and load shifting things to throw on top the pile (and likewise with WordPress). Even a pig can fly if you strap wings on to it. And Drupal has a lot of folks thoroughly invested in it to the point where they are making that pig fly. Drupal is also such a household name that it represents a low-risk position for decision makers (low risk of job loss from choosing Drupal). None of this makes it a good product, just a safe one for people that don't know any better. But for people that do know the difference, we want a panther, not a pig.

This module creates a page in the ProcessWire admin where you can test selectors and browse page data and properties without editing a template file or a bootstrapped script. Given selector string is used as is to find pages - only limit is added, if given. Errors are catched and displayed so anything can be tested. Pages found with a valid selector are listed (id, title) with links to the page. I was thinking this would be useful for someone new to ProcessWire, but it turns out I'm using it myself all the time. Maybe someone else finds it useful as well. Module can be downloaded here: https://github.com/n...essSelectorTest Modules directory: http://modules.processwire.com/modules/process-selector-test/ Features Edit selector string and display results (and possible errors as reported by ProcessWire) Explore properties and data of matching pages in a tree viewLanguage aware: multi-language and language-alternate fields supported Repeater fields and values Images and their variations on disk More data is loaded on-demand as the tree is traversed deeper Quick links to edit/view pages, edit templates and run new selectors (select pages with the same template or children of a page) Page statuses visualized like in default admin theme Add pagination Screenshots

I think eventually we will have a few very different site profiles that, combined with some good marketing videos, may do a lot of the convincing for us. For example, with the shop module I love the point "any page can be a product". Plus once there are enough totally different profiles its easier to show prospective clients that you can do anything without hacking the core at all. I know this has been mentioned elsewhere, but I think the profiles in my head would be Shop, Blog, Member-driven content and of course the default basic site. If you can show more then that's awesome of course but when trying to get across the point that it can do anything, having these varied examples to fall back on would make it so easy. Then to sell it to those heavily invested in other systems you could just change a few fields and tweak a template right in front of their eyes and show how simple it is. People are wary about having to learn anything new when they've spent a lot of time (even forgetting about the money they have probably invested years of time) so if you can get across how simple it is then I think you can win them over. So variety + simplicity + power = panther (which still sounds like it should be a bad aftershave ).

That error indicates the $user->viewable_pages either doesn't exist and or is not an page array so it can't call has().

For the other part of it, in preventing the duplicates. As mentioned before, the pages you retrieve are already going to be unique. But like you said, you may have duplicate field values even among unique pages. Lets say that you wanted to guarantee the uniqueness of a 'title' field, for example: $uniqueResults = array(); foreach($results as $resultPage) { $uniqueResults[$resultPage->title] = $resultPage; } Following that, there will be no pages with duplicate titles in your $uniqueResults array. You can take the same approach with any other field(s). Though make sure your field resolves to a string before using it as a key in your $uniqueResults array.

That's more or less what I though you were trying to do - so I'm thinking it was me who wasn't clear enough then. Because of memory limitations you can't foreach through the whole 3000 page resultset in one go, just like you said in the first place. Instead you can loop through the very same 3000 pages, but in 500 page pieces. In a hurry, again. Not sure about the syntax and definitely not tested, but you'll get the idea: $start = 0; $limit = 500; do { // replace "..." with your actual selector $results = $pages->find("..., start=$start, limit=$limit"); foreach ($results as $resultPage) { // do you magic here, collect the results that match to another PageArray maybe? } // free some memory $pages->uncacheAll(); // advance to next set $start = $start + $limit; } while (count($results) > $limit); Hope this helps. There could be another variable to make sure the do-while doesn't get crazy, but I left that out for now.

One other thing about this module that's maybe interesting from a module development standpoint: It installs a page (/service-pages/), and the template for that page loads and runs the ServicePages module when it is viewed. So it installs the means to run itself, and it's not autoload. I might be wrong, but can't think of another module that does this, and maybe it's a good pattern. At least, I thought it was fun when building it. I've been thinking about building a module starter kit that includes skeletons for various types of modules and install/uninstall patterns (ready to build from), and this type of pattern would be one among a few others.