Leaderboard

Alan (and others), In a few days time, I'll post updated theme, based on Futura Remixed Theme which has rewritten almost everything in the code and is compatible with PW 2.2+ so it will be more consistent. It also supports multi language capabilities.

http_build_query is nice. You can also build them yourself if you want. I usually use PW's $input->whitelist() to store values after I've sanitized them. As an added bonus, PW's pagination/pager module knows to include any $input->whitelist() get vars in it's links. So you can have your GET vars persist through pagination. Here's an example where the GET vars get used in a $pages->find() query, and also use them in any links. $allowedTypes = array('item1', 'item3', 'item7'); $allowedSorts = array('title', 'date', '-title', '-date'); if($value = (int) $input->get->region) $input->whitelist('region', $value); if($value = $sanitizer->name($input->get->type) && in_array($value, $allowedTypes)) $input->whitelist('type', $value); if($value = $sanitizer->name($input->get->sort) && in_array($value, $allowedSorts)) $input->whitelist('sort', $value); $selector = "template=something, parent=456, "; $url = "./?"; foreach($input->whitelist as $key => $value) { $selector .= "$key=$value, "; $url = "$key=$value&"; } $url = rtrim($url, '&'); $selector = rtrim($selector, ", "); $results = $pages->find($selector); echo $results->render(); // link to another region but with all other vars the same $region = 123; if($input->whitelist->region) $url2 = str_replace("region={$input->whitelist->region}", "region=$region", $url); else $url2 = $url . "&region=$region"; echo "<a href='$url'>Region</a>";

Great! Thanks, Ryan! I am still amazed of the power of the selectors engine.

PW loads stuff on demand, so if you print_r $page, then that's going to trigger it to load a lot of stuff and perhaps even an infinite loop. It's best not to print_r or var_dump $page objects for this reason. A $page object is pretty light in it's default state. It gains weight based on the number of autojoin fields you have. Following that, all fields you access are loaded on demand and then become part of the page's data. To keep pages as lightweight as possible, you'd want to limit your autojoin fields to only those that you need for every instance of a $page (like the 'title' for example). While a $page is intended to be lightweight, it's obviously going to be heavier than just an ID. And by that logic you can store more IDs in memory than you could pages. Though it's rare that I would do so because an ID rarely provides much value on its own. But there are cases, and here's how you can do it. You can query any field_* table and expect that it will have a pages_id field. So if I wanted to find all pages that had the title 'Templates', I could do this: $ids = array(); $result = $db->query("SELECT pages_id FROM field_title WHERE data='Templates'"); while($row = $result->fetch_assoc()) { $ids[] = $row['pages_id']; } // ...if you later want to convert it to Page objects, there is a getById function: $matches = $pages->getById($ids); // returns a PageArray Note that getById function performs faster if it knows what template is used by the page. It is an optional param that can be specified like this: $pages->getById($ids, $template); Here's another scenario. Lets say that you want to do something like a $pages->find(), but get the IDs rather than the Page objects. Here's how you can do that: $finder = new PageFinder(); $query = new Selectors("title=Templates, template=basic-page, sort=-created"); $results = $finder->find($query); // $results is array $ids = array(); foreach($results as $result) { // each result includes: id, templates_id, parent_id and score (if rank sorting) echo "<li>Found Page ID $result[id] using template ID $result[templates_id]</li>'; } That's how you can use the PageFinder class, which isn't part of the public API, but may be useful in certain situations where you only need to interact with IDs. However, keep in mind that when you use this, you are bypassing PW's caching and such. So if you are using this to ultimately generate Page objects then you will likely lose performance by going this route. But if you have a use for thousands of page IDs and don't need to turn them into Page objects, this would be the way to go.

This will help you a lot: http://php.net/manual/en/function.http-build-query.php Simpler way is to always have all the parameters on links, but set them zero/empty when not set, so your urls would be like this: ?region=0&sort=title&type=0 ?region=123&sort=0&type=item etc...

And i use LiteSpeed and i dont have any trouble with PW works perfect i use it till from 2011, BR

For a field that can contain multiple images, the value of that field is always going to be a type of array. So you'd have to either check to see if there are any items in the array, or try to retrieve the first time like Soma did. Here's how I usually check if there are any images: if(count($page->images)) { // images here } else { // no images } When it comes to a single image field, you are dealing with just one item that is either set or it isn't (rather than an array). You only need to check if it has a value: if($page->image) { // image here } else { // no image } When you use $pages->find(), $pages->get(), $page->children(), etc., you can also find pages that have a given amount of images. So if you wanted to find pages that don't have any images, you could do this: $pages->find("images.count=0"); ...or pages that have one or more images: $pages->find("images.count>0");

I would consider that an upgrade.

Thanks for all suggestions. Following the Soma's template, I have created a master layout template (functionally identical with the default PW template), that looks like this: <!DOCTYPE html> <html lang="en"> <head> <? include "blocks/htmlhead.inc" ?> </head> <body> <p id='bgtitle'><?= $page->rootParent->title ?></p> <div id="masthead" class="masthead"> <div class="container"> <? include "blocks/masthead.inc" ?> </div><!--/container--> </div> <div id="content" class="content"> <div class="container"> <div id="sidebar"> <? include "blocks/sidebar.inc" ?> </div><!--/sidebar--> <div id="bodycopy"> <? include "views/{$page->template}.inc" ?> </div><!--/bodycopy--> </div><!--/container--> </div><!--/content--> <div id="footer" class="footer"> <div class="container"> <? include "blocks/footer.inc" ?> </div><!--/container--> </div><!--/footer--> <? include "blocks/editpage.inc" ?> </body> </html>

Things I would pay for, in order of likely payment output: Ready-to-go commercial site profiles (setting up separate templates for different sections and whatnot is a bit of a time suck right now) $$$$ This would be so terrific. Here, look, a product database that provides XML feeds and tagging is already set up, too. Hey, there's a PW site with a membership system with a customizable profile for each member! This would be worth tons to people like me. Training materials $$$ Videos $$$ I guess the subject matter would be pretty wide open but a set of PW videos where 1-3, for free, cover setting up a single HTML page into an editable site, and 3-9 cover additional pages and some other features, for a cost...I think lots would be interested. Don't give away the sunroof but it's an awesome car. Books (short as they may be, not looking for the bible of PW here) $$$ At this point I would love something on developing modules for PW, with a few examples. Also an example of CodeIgniter integration, for doing more app-type stuff, this really interests me right now. I can't name a specific example I'd like to see, but as a PHP junior-level type, I'd love to see how PW can help me work with a framework like CI or Symphony. This could be a video too, I'd pay for that. Custom module development $$$ Name your rate, and don't price it so low that you can't sustain it. I think a lot of us will find a way to pay if we need it and really love to see that type of backing available. It's a bit intimidating to ask somebody in your position to bid on a custom development job though (don't want to bug ya), so you'd probably want to put up a page somewhere explaining that yes, you will do it and what your terms are, etc. Commercial support $$ Very helpful for some perhaps, but I don't see myself using it much for now. Maybe if I'm scaling up dramatically or working with a big team and needing some insurance. Add-on modules $ I've been stung several times by paying for modules. Support can end up being very poor or hard to understand, or the new version comes out with a more sustainable codebase but 25% of the features of the old one, or the developer becomes a playwright, etc. So I'm cautious about that stuff but I readily admit it's nice to have the option. I'd like to support you in that. You deserve it.

Nobody's said anything about making PW commercial. It is a "truly" open source project in every way possible and that's not going to change. I don't want any implication of anything other than that. I don't personally have any commercial aspirations with ProcessWire. My interests are in helping it to grow as an open source project and meeting the needs of the community. I'm not here to make a buck. People don't get into open source for the money (there's no money in it). Instead, I'm here to put money and time in it – I saved for a few years to pay for the time it took to make ProcessWire as an open source project. I did it for the same reason that one would invest a lot of time and money building model airplanes or trains… it's what I enjoy doing. Especially now that there's so many of us. I find the work and community here hugely rewarding, surpassing anything I could have ever been paid. There's no expectation of making money here. But now that we've got a dedicated community, I do think we've got a responsibility to chart a path forward for growth so that the product can grow with the community and continue to meet their needs. My financial resources are not unlimited and I've got a family to feed. I can do that by taking on more client work, and just work on PW on my spare time. But my preference would be to find a way to make ProcessWire self-sustaining, so that it can grow on it's own funds more than mine. I'd also like for myself and others to be able to afford to put more and more time towards it. Actually, I'm determined to put more time towards it even if it means going without sleep. While I'm not sure if it's the right path or not, I do like aspects of the idea of having options for commercial modules. I think it could help us to attract high-profile and mission critical websites, and service-oriented module developers that can bring more exposure to ProcessWire… increase its audience and help it grow. I also think that providing a centralized gateway for modules (free and commercial) serves our community a lot better than the alternative. Whether anyone will actually build any commercial modules remains to be seen, but I'd like to encourage high quality 3rd party module development, free and commercial. I have no problem if someone wants to make a buck on creating a commercial module, so long as they make it good and support it well. If we don't serve as a gateway for this stuff, then we have no means of effecting the quality and service to our community. Perhaps C5 is making some mistakes in the manner in which they are doing this, and it would be good for us to study what they are doing right and wrong. If its really hurt their community there, and that's a widely held opinion, then that would be a good reason not to use them as a potential model. I like Symphony's model of making commercial support options available. I think this is another thing that attracts high-profile and mission critical websites, while also supporting development of the CMS. Though I have no idea if it's been successful for them or not. Correct me if I'm wrong, but the WordPress business model is primarily centered around hosting. I'm not sure this model translates to ProcessWire very well, because our audience is more web-professionals than bloggers and writers. It would be interesting to know more about why WordPress supports commercial themes but not commercial plugins. I am wondering if their plugin system is such that anything built on it has to be GPL. Whereas ProcessWire's templates and modules are using the same interfaces and API. What are other ways that WordPress or other open source CMS projects are growing in a self sustainable way? Some other ideas are books, commercial tutorials and training (videos or in-person), commercial site-profiles (ready-to-go school website, or the like), custom module development (for individuals), selling advertising (though not very interested in this), coffee mugs and t-shirts. Please throw some more ideas into this if you have them. Ultimately if the community isn't supportive of any specific business-models, then we'll throw the ideas out because the project will grow and move forward either way. But I'd like to get to the point of being able to put more and more time towards the project, so just looking for ways to do more PW work and less client work.