adrian

Thanks - I guess it's not a big deal to do it that way. I think I am just so used to using SQL to do most of the work first that the idea of returning so many results just to later throw them out seems weird

Is this possible? I am trying to combine results of more than one $pages->find. I know I could append the results of one to the pagearray of the other, but I want to be able to apply a limit to the combined results of both, sorted by modified, before returning the results. Thanks

Thanks diogo - a nice solution - I hadn't thought about the remove option. Only catch is that my find makes use of a limit selector. Obviously I can break the foreach loop after my limit requirement, but it will mean grabbing all the pages that match and then not using most of them in the foreach - just seems wasteful.

Hi everyone, Trying to simply find pages where the modified date is greater than the created date. I would think this should work: $pages->find("modified>created"); but no luck. Thanks for any suggestions.

Hi Soma - no worries - I know how you feel Basically what I am doing is creating a custom RSS feed and latest activity widget, but I only want to highlight details from certain sections of the site. I have some user edited pages, a user edited glossary, and a forum. These are the three parent pages. I ended up going with this which is a little ugly, but does the trick: $latest = $pages->find("sort=-modified, limit=30"); $items = new PageArray; foreach($latest as $lpage){ if(($lpage->rootParent=='1130' || $lpage->rootParent=='1192' || $lpage->rootParent=='1021') && ($lpage!='1130' && $lpage!='1192' && $lpage!='1021')){ $items->add($lpage); } } I actually might end up switching to a template selector as I think this will be cleaner and still achieve what I need.

Hey Pete - yep, I was using proper page ID numbers. I actually just tested out a has_parent using the selector test tool, with multiple pipe-separated page IDs and found that it returns every page in my system including all admin/system pages. Each of the individual page IDs on their own work as expected.

Thanks Soma, but using that in a find gives me array to string conversion errors. It does seem like has_parent can only be used with one page: http://processwire.com/talk/topic/1921-has-parent-issue/

Thanks teppo, Just a note on that SQL command. The second one has: ON version_control_for_text_fields_id__data but it should just be: ON version_control_for_text_fields__data

Yep, that would do it. I am still not quite always thinking in PW yet I was initially setting it up as: $latest = $pages->find("rootParent=xxx, sort=-modified, limit=10"), but in reality I want to specify more than one rootParent, so I would need the ability for "get" or "find"ing more than one anyway, which isn't possible - correct?

I was hoping there would be a selector called rootParent. I ended up getting all the pages that matched the rest of my selectors and then filtered them out with $page->rootParent in the foreach loop. This isn't a bad option, but causes problems when using limit in the initial selector set. Anyway, just wondering if there is a better way to do this, or if rootParent could be added as a selector. Maybe the template selector is a cleaner solution in most cases?

Hi Soma - thanks, checking for the original size of the image is definitely an option. I do think though that the upscaling=>false option should work with one dimension set to 0. However, this also seems to work: $options = array('upscaling'=>false,'cropping'=>false,'quality'=>90); $image->size(500,'',$options); As does this, which is maybe the most logical option: $options = array('upscaling'=>false,'cropping'=>false,'quality'=>90); $image->width(500,$options);

Sorry for the confusion teppo - I thought I was on the very latest version, but apparently I was one or so behind. All working again - thanks!

teppo - not sure if you want issues listed here or on github, but with the new version I am getting this error: "Method VersionControlForTextFields::removeExcessRows does not exist or is not callable in this context" Reverting to old version fixed it.

Ryan, My goal in this case is to make sure that the images being displayed are go greater than 500px wide. I don't care about the height, so I set it to '0'. What I want to make sure is that no image gets upscaled to 500 if its actual dimensions are less, which I think in most cases would be default behavior due to the quality issues associated with upscaling. One of the test images I uploaded with 175px (w) by 297px (h) and it was upscaled to 500px. Setting things to 500,500 seemed to take care of things. I assumed that the values were maximum dimensions for each, rather than crop, but I get the feeling now that maybe this is not the case. I have been using SLIR for image resizing for several years and I am used to that behavior. Is that approach possible with PW - ie to set both dimensions as max for the respective dimension, rather than assuming a crop. Does that make sense?

Curious - did you start getting front end errors after your login attempt? I came across some weirdness like this the other day making my first PW site live. Both dev and live are on the same server, so in my case I think it was a caching issue - an apache restart did the trick. Might be worth trying as a quick fix. Otherwise, it does look potentially like you have some path issues.

You could probably just add $image = ''; as the first thing inside the foreach so it gets emptied. You might need to do the same with $thumb

Not sure if this is expected behavior or not, but unless I set both dimensions during an $image->size, the upscaling option is ignored.

Actually, I think a module that allows for extracting the metadata, storing it in the database, and making it editable in the PW admin (in an expandable section below the description field) would be awesome. Any changes here could be written back to the image on save. Now if only we could get Google to stop stripping out metadata and actually read it for indexing purposes....

I have also used The PHP JPEG Metadata Toolkit and found it very useful for both reading and writing. Imagemagick actually maintains metadata during image manipulations, although the requirement for exec or the PECL imagick package are still important considerations. So, in the end, I wonder if making use of the toolkit in a module to automatically add the metadata back in for thumbnails might be the easiest way to support this functionality for the most number of PW installs (ie hosted servers without IM).

Hey Pete - for sure - I was definitely thinking of a module for this. I guess I should have posted this on the modules board. I might even get around to doing it myself once I have a little free time. I mostly just wanted to get the idea out there while I thought of it.

Looks like maybe some directory issues when migrating to live that didn't quite get sorted out: http://processwire.com/talk/topic/2931-site-migration-101/ EDIT: Sorry, stating the obvious here I know - kind of wish I could delete this post!

I'd really love to see swiftmailer integrated as an option for all emailing. I have used it exclusively since it was released in 2005 and it is just brilliant for everything from attachments to combined plain text / html versions of emails, through to bulk enewsletter mail outs to thousands of recipients, including Mail merge. It has various features to prevent overloading mail servers etc. A brilliant mailing class. I have already used it with PW, but would love to see it part of the core and directly accessible from the API.

One option I would like to see is support for imagemagick through the pecl imagick package. It gets around the need for exec and gives all the power of imagemagick. And if the server has IM compiled with rsvg it does a fantastic job of handling and rasterizing vector images.

Hey Jennifer - definitely a fantastic looking site! Some design inspiration for me, so thanks! Also, think I should check out Foundation - it is definitely time to start making use of these tools. The only comment I have is the size of some of the images in the sidebars. I noticed them loading slowly and checked out one which was almost 400KB and ended in "1633x0.jpg". I see that you have some great responsive design set up, but it seems that when these actually first switch to bigger dimensions they are at 690px, so it seems like there is about 1000px of extra un-needed width / filesize. Maybe I am missing a screen size scenario that needs images that big, but thought I'd mention it just in case. Also, just found another broken link for you. From http://fyp.washington.edu/getting-started-at-the-university-of-washington/ the link to Fees, Changes and cancellations is broken. Actually, just noticed something weird on this page: http://fyp.washington.edu/parents-families/out-of-state-parent-frequently-asked-questions/ In Chrome at least you can't actually scroll to the very bottom of the page - it flickers and jumps back. No content is hidden, but still a little annoying. Another broken link from: http://fyp.washington.edu/faculty-staff/ to the 2013 Advising and Orientation Schedule PDF (http://fyp.washington.edu/downloads/2013cal.pdf) Anyway, now I am just starting to feel mean and picky - you really have done a brilliant job. Mental note - don't show off any of my sites here or you'll be hunting me down looking for all my broken links

I just tried a migration from dev to staging and got a whole bunch of class not found and problems trying to redeclare things that are "include_once" (sorry I didn't record exactly what they were). I tried several times clearing the cache folder of module files with no success. Initially the front-end looked fine and I could even get into the main admin pages, but couldn't edit anything without these errors. What finally cleared it all up was killing APC and restarting apache. Of course I guess I don't which it was - APC, or just the apache reboot - that fixed things.