adrian

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.

Awesome - thanks teppo - I didn't think to look in the modules section at all. I will definitely poke around more in those module settings dialogs.

Not sure if this is currently possible, but I have some custom user fields, but when I browse the list/table of users from the admin, I can only see Name, Email Address, and Roles. Is there any way to show other fields in this view? The custom field in my case is organization, and it would be nice to be able to quickly sort by organization. Of course I could always create a front-end view, but I feel like this should be option for the backend. Thanks for any suggestions.

Just been playing around with this, and so far it's brilliant, and works great with frontend page editing as well. Thanks so much for your hard work on it. I'll let you know if I come across any issues!

Good point about what that module does - sorry I think I was a little sleepy when I posted that. Anyway, I have it working on the front end as I need it to, so all good. Thanks

Hi Soma - thanks for the thoughtful post. I agree that just because you should doesn't mean you should In this case of what I am working on right now - it is an interactive educational website/app that allows students to enter various parameters, generate graphs and maps, and then produce summary pages reporting on their findings, that will become part of the site content. Things really do need to be done via the front end, not just for aesthetics and user experience, but also because of requirements to perform various unit conversions etc before storing in the DB. I actually nearly went with your iframe/modal=1 approach, but it still wasn't clean enough for my needs in this case. Just to clarify - there is no data input/upload allowed on the front-end by guest users, and all registered users must be manually registered, so hopefully things are ok from a security standpoint, even if I don't fully understand all those issues in PW just yet. I have created similar types of sites before, but never with an off the rack CMS - I have always built my own to fit the exact needs of the project because I never thought there was anything out there that could do what I wanted without mountains of hacking. When I found PW I thought it was time to give it a try. To be honest at some times it has felt like a bit of a struggle, but hopefully it will be worth it in the end. In some cases it has cost me lots of time, but I know it has saved me lots of time too, and the learning process will be invaluable for future sites. I have some other data heavy sites which I still think will never be a good fit for PW (at least not completely - I think a hybrid approach might work well - content in PW and data in separate tables with custom queries). I have a couple of much simpler projects coming up very shortly where all the content will be developed by the clients. I am really looking forward to using PW on these and hopefully I'll be back in the realms of 'normal' PW usage and might be able to start helping out here, instead of just asking all the questions Ryan - would definitely love to hear your thoughts. PS Antti and Ryan - do you think we could make that change to the postUrl variable in InputfieldFile.js?

Thanks Soma, I changed that modified line to: var postUrl = config.urls.admin + 'page/edit/?id=' + $('#Inputfield_id').val(); which take cares of variable locations for the admin in different PW installs. However, I am not sure if this was all you were hoping I got from that link. I had a look over your example front-end form it is very close to what I am using. However I can't see how your example would work with the HTML5 uploader. This code at the end of InputfieldFile.js requires the presence of an element with the #PageIDIndicator, which I don't see in your form code. if (window.File && window.FileList && window.FileReader && $("#PageIDIndicator").size() > 0) { InitHTML5(); } else { InitOldSchool(); } Is there something in your code that I am missing that gets around this requirement? Can you think of a way that I can avoid the need to edit the postURL in the InputfieldFile.js file?

Ryan, I don't suppose you'd consider changing the permission for that module to 'image-select' or something along those lines. I could make the argument that you might want to be able to give some backend users the ability to upload files and images, but not be able to edit pages. One scenario might be giving the new high school intern the ability to upload new images for a gallery/carousel without access to anything else. I'll make use of your suggestion to move the module and rename the class for now though. Thanks as always! EDIT: I guess this would only work if you could have multiple permissions for the module (is that possible?). Either that, or is there a way to inherit 'lower level' permissions - ie the page-edit permission includes image-select permission? Maybe I don't have a full handle on all the permission/role options just yet

That's perfect for now - thank you. This permission stuff is all starting to make sense now I guess why I find the current scenario weird is that in the end I haven't even given them access to edit any templates - so they could edit comments, but nothing else. I only set their role to page-edit to allow access to the select image/insert image modal popup. Of course your reply to that issue of mine should help me disable them from admin access altogether.

Maybe I am going about this the wrong way, but I wanted to make use of the admin image upload features for a front-end form. The only way I could think of to achieve this was to modify InputfieldFile.js like this: //var postUrl = $form.attr('action'); var postUrl = '/admin/page/edit/?id=' + $('#Inputfield_id').val(); That, together with: <p id="PageIDIndicator" class="">'.$page->id.'</p> lets everything work as expected. I haven't tested thoroughly yet, but I don't think this breaks anything. Of course you can see that my admin is at "admin", rather than the default "processwire". Not sure the easiest way to get this path from within InputfieldFile.js There is very likely a better way to do this, but since I want my form action to post to itself, but have the xhr open the page/edit?id= link, I am not sure what it is I guess I could set the action of the form so that it works for the image upload and then override the action for the actual form onsubmit, but that seems hackish too. Thanks for any suggestions.

Ryan, Not sure if this is the best place to ask, but I am using a front-end form that makes use of the select image/insert image modal popup. I am requiring the user be logged in for this, but I'd prefer not to have to give them edit rights (just want to keep the entire admin inaccessible to their role). Only problem is that the select image only works if I give them page edit permission. I'd love if access to this could be made available through this module (maybe tied to "page-edit-images"), or perhaps some other approach. Thanks for any suggestions

Awesome resource diogo and so well implemented!