Soma

1. The upload max width and height setting is a way to avoid having the user upload 4000x10000px images. Remember it's a "max" size setting not a "thumbnail" setting. See it more as a original image that should be un-cropped. This keeps it flexible and simple to start with and if you maybe want to change the image size you still have the original image. Note that there's also several API calls in the image file to check for original and variations. Theres modules or simple ways for creating cropped images - as per Thumbnails module http://mods.pw/1b - or to requires a certain format http://processwire.com/talk/topic/3476-fixed-image-size/?p=34110 (add "min" size settings to image fields) - or a way to resize images on upload using simple module http://processwire.com/talk/topic/3718-lots-of-images-to-resize-timeout-in-frontend/?p=36291 2. Again it's not meant as a cropping setting for uploaded images. It works this way that if you set width "1000" and height "500" the image upload will be resized either in with or height or both depending on which side is larger than 1000px or 500px. That's why it checks both separate, at least I think so. 3. Most of the times you upload images and on output in the template file you generate the image size $image->size(520,261)->url and it will only create it if it's not already found and it will also recognize your crop settings. It creates a new copy and names it with the size you specify beside the original. This is the most straight forward way to work with images and there's not much more about it. But the system still allows to build on that and extend and change behavior of the image field if you wish.

A field's name is almost like an id and it shouldn't be changed. This might happen when you start but once you setup your fields they most likely also are referenced by their name in template files or other settings and changing the name will break your code or output. In a perfect world this module maybe would have some configuration you could define the field by reference. Using the id here you'd have to get the field first. I changed the code var $field to $inputfield, to avoid confusion as it's actually the inputfield and not the field (as the hook already suggests). Inputfields have no id. They serve mostly as the input that interacts with the user. If you get the id of the inputfield you'll get the Inputfieldimage_fieldname, which is used for the markup when it's rendered. It's the fieldtype that is the one that has a id property, the id you see when editing a field and in DB. To debug the module it's a little special, but it can be easily done by using a simple trick. Add this in the hook function echo $inputfield->id; exit(); or die("id:" . $inputfield->id); Now if you upload an image it will stop there and you should see what it outputs. If you're using ajax upload, this is seen in the ajax request response if you look in the developer tool. It will show "InputfieldImage_yourfieldname". Now to get the actual field you get it via the "name" of the field using $fields API. $fieldID = $this->fields->get($inputfield->name)->id;

Try adaptiveimages.com by matt wilcox. Works fine for what you try to do. I used it myself on a pw project.

Cropping option is meant for when using size(100, 100) on images on front end. You changed the max width and max height resizing which isnt meant to crop but limit image sizes the user uploads. So it's all fine as it is.

Does it work, means is there no timeout? I just removed a line that was not needed.

Ahh, it doesn't redirect if LanguagePageNames module is installed...

I also wanted to try this, but in my install here it doesn't redirect to a trailing slash!?

Sorry to hear, but I can't reproduce... It's always post (of course) when the form method submitted is set to post. The request method is only GET when loading the page. urlSegments doesn't have any effect. I'm on XAMPP Mac.

This is the only way I know to create different sizes when uploading images: <?php class ImageCreateThumbs extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'ImageCreateThumbs', 'version' => 100, 'summary' => '', 'href' => '', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHookAfter('InputfieldFile::fileAdded', $this, 'sizeImage'); } public function sizeImage($event) { $inputfield = $event->object; if($inputfield->name != 'images') return; // we assume images field $image = $event->argumentsByName("pagefile"); $image->size(120,120); $image->size(1000,0); } } https://gist.github.com/5685631 What I don't know is if it really makes a difference (I guess), and if using drag and drop ajax upload and old school upload would process image one by one. My suggestion is to also upload image already in 1000x* pixels because if they upload 3000+ px images it will just takes a lot longer.

$page->next($pageArray); As I said Ryan must have reasons, but I don't know really and haven't analysed all those traversal methods just thinks it isn't that trivial.

And does you method work with PageArray?

And the sorting and selectors? As you can also do next('selector'). And next() also is for in memory (PageArray) usage not only direct query. I'm sure Ryan has reasons Edit: but if performance matter you could create your own next() methods.

No problem, I just confused by terminology I guess. This should get you there: $language->getUnformatted('title')->getLanguagevalue($language->id)

I dont get it really...

Well then just enter the same for each language.. no need to go fancy..

next == next() children == children() parent == parent() ... and so forth, PW doesn't care here both are covered.

No need to add another field, you already have PageTItleLanguage on the language template (see my screenshot). If not change the "title" field to language text field. There you can translate the language titles, you don't need to change anything in your code or setup. Ok, but that what you want!? Translated language titles, so in english it will show all language titles in english.

You mean like this? If you set the "title" field to PageTitleLanguage you can already.

No that was just an alternative way. Sorry for the confusion. Do what adrian said here, exclude the image and file fieds. Edit: lol now we have chaos

Well this works: $form = $modules->get("InputfieldForm"); foreach($page->child()->template->fields as $field) { $form->append($field->getInputfield($page->child())); } echo $form->render(); But would also have to clean values.

Yeah I think a german will have real problem with your second method

Ahh I think I missed that you render out a form with those fields. Thats whats missing in my test. So my code throws the error when rendering .. Ok but pitbulls problem is that he seems to have image or file fields which throws the error. It says even what is wrong.

Page field dont need values to function and show the list according to the field settings. The value I mean is which is selected. But then your child page is empty then that could work out.

You define them yourself in the languages you created.

Well change the language of you user and it will take that locale regardless of the front end language set. This is more for Ryan to checkout. I have no clue how to make it behave.