adrian

Here's the same deal with a crop image field. Before: After: Maybe not terribly helpful sending you screenshots of it working for me though EDIT: I can't imagine why it would matter, but are you running PW 2.4 on this site? I am testing on 2.4.1. MORE THOUGHTS: Are the initial images that you're trying to resize named without the dimensions suffix? I assume so, but just checking. Maybe you could send screenshots of your before and after and also the before and after filenames in the 1157 folder. Might help us figure it out.

Ok, here is my test. I emptied the Max Dimensions settings and uploaded two images and got this: Then I went and changed the Max Width setting to 50 and left the height blank. Then I ran that script I gave you and then reloaded the page and I see this: That is the behaviour you're looking for - right?

Weird - just to be sure, you are definitely using the second script that I posted above? I just tested again and it works fine on multiple images in a field. Could you maybe post the exact code you are using if it differs at all from what I posted and maybe detail out all the settings for your images field. I can't think of what the issue might be at the moment.

Hey Marty, I did a quick test with a CropImage field and so long as you change: if($imagesfield->type == "FieldtypeImage"){ for if($imagesfield->type == "FieldtypeImage" || $imagesfield->type == "FieldtypeCropImage"){ it seems to work fine. Of course it will only resize the main image, and not the cropped version. I haven't tested this with Custom Upload Names yet, but I can't think of any reason why it wouldn't work.

Hey Marty, I'll take a stab at this. There are a few issues as I see things: The Max Image Dimensions setting: "..... does not affect any images in the system, or images added via the API." but you have noted that already. From your explanation it sounds like the images are already installed. You could resize everything using the API, but then you'd end up with the original sized one as the main image still, but will the sized variation available - I don't think this would help much. So if you upload using the API, you'll need to do the resize yourself. Of course the $image->size() method in the PW API will add the .XxY suffix to the filenames. So I have a couple of scripts for you. This first one allows you to install an image using the API and have it resized to match the Max dimensions settings. This assumes your images field is called "images". I don't think this specifically helps you since you already have the images installed, but I wanted to post this in case it helps someone else. Read below for the next version which I think does what you need. $cp = $pages->get("/"); $url_to_image = "http://ian.umces.edu/images/ian_banner.png"; $cp->images->add($url_to_image); $cp->of(false); $cp->save("images"); $pagefile = $cp->images->last(); $imagesfield = $cp->fields->get("name=images"); $filename = $pagefile->filename; $pagefile2 = null; if($imagesfield->maxWidth && $pagefile->width > $imagesfield->maxWidth) { $pagefile2 = $pagefile->width($imagesfield->maxWidth); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); // force it to reload it's dimensions } if($imagesfield->maxHeight && $pagefile->height > $imagesfield->maxHeight) { $pagefile2 = $pagefile->height($imagesfield->maxHeight); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); } I think this code should do what you need. Obviously the first line sets the $cp to the home page, so you'll need to adjust as necessary. After that it runs through all the image fields on that page and resizes the images to match the values in the Max Dimensions settings. Let me know how you go with it. $cp = $pages->get("/"); $cp->of(false); // required for a single image field foreach($cp->fields as $imagesfield){ if($imagesfield->type == "FieldtypeImage"){ foreach($cp->$imagesfield as $pagefile){ $filename = $pagefile->filename; $pagefile2 = null; if($imagesfield->maxWidth && $pagefile->width > $imagesfield->maxWidth) { $pagefile2 = $pagefile->width($imagesfield->maxWidth); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); // force it to reload it's dimensions } if($imagesfield->maxHeight && $pagefile->height > $imagesfield->maxHeight) { $pagefile2 = $pagefile->height($imagesfield->maxHeight); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); } } } } Both examples are quite verbose and I am sure could be optimized quite a bit, but should get the job done. I did some testing and they both seem to work just fine.

Thanks Marty - I'd really appreciate that

I am not having any issues specifically with the description not being available. However, I notice that the toggle expansion arrows for each field are not showing. Maybe there is a clue with that though? Just about to post this when I saw that you have fixed it - seems like it was related to the missing toggle arrows

Just committed a fairly major update to support full migration of files and images, including rewriting of the src tag to match the ID of the new page for images embedded into RTE fields. Additionally, the module now also migrates the template .php files. Files/images/template files and the json structure/data file are exported in a zip file which is then imported into the destination PW install. So, you can now select one parent page during export and it will migrate the following content for all child pages of the selected parent: All standard field types, including RTE, and decoding of links modified by the PageLinkAbstractor module and abstracting again on the destination PW install. File/Image/CropImage fields including the actual files/images/thumbnails and all other variations Repeater fields and all their required fields, templates, and all content, including files/images Page fields (and the pages, templates, and fields that make up their selectable pages) Multi-language versions of all field content Templates (including Access, Family, URL and other settings) and the template .php files. It even grabs the appropriate file if you are using the "Alternate Template Filename" setting. NB the templates directory on the destination PW installation must be writable for these to be imported. So, you could build sections of content on a local dev PW installation, export it, and then with a couple of clicks import everything into the live PW installation. Some outstanding issues that I hope to get to shortly: Need to support images inserted from a different page into an RTE field Rewrite any references to page ids, eg $pages->get(xxxx) in template .php files so they will be converted to the correct id on the destination installation. Need to look into the new core link abstractor that was added to PW 2.4 and see how to handle those links compared to the PageLinkAbstractor module. I still want to add finer control for determining exactly what components will be exported and imported. Generally needs lots more error checking for things like making sure required languages are installed on the destination PW install etc Need to add checks so that existing template php files are not overwritten (or give the option to choose) Might need to override PHP max_execution_time and other settings for larger exports and maybe chunk out zipping of all images to prevent memory issues on larger exports. In its current state it is handling almost all my needs, but I would really like to have this robust enough for anyone to use, so if you have time please do some testing for me - THANKS! At the moment, please only use it on two unimportant test PW installs!

You can make a simple contact form using either of these: http://modules.processwire.com/modules/form-template-processor/ http://modules.processwire.com/modules/form-template-processor-mailer/ Or if you want something more powerful you should take a look at: http://modules.processwire.com/modules/form-builder/ No matter which option you choose, it is easy to insert the form anywhere you want in your site.

Well the definition of cute that I remember from my Aussie upbringing was: "Ugly, but interesting" Glad we got that cleared up

Cute ? I actually thought it was pretty functional - nicer to be able to click on the parent item or expand it to access the children. You not sold on the idea?

I actually love the way meanmenu handles this issue: http://www.meanthemes.com/demo/meanmenu/demo.html

echo $page->documents->description; should work just fine. I think it is likely your documents field is set to handle more than one image, so you will need: echo $page->documents->first()->description; I just did a little testing a noticed something slightly unexpected. When there is one image in the field you get: echo $page->documents; //selfie.jpg echo $page->documents->first(); //selfie.jpg echo $page->documents->url; //site/assets/files/xxxx/ echo $page->documents->first()->url; //site/assets/files/xxxx/selfie.jpg echo $page->documents->first()->description; // image description echo $page->documents->description; // blank With two images in the field, you get: echo $page->documents; //selfie.jpg|selfie2.jpg So I guess I had never noticed that you actually get the filename returned from a files array. I would have expected an error with: echo $page->documents;

A couple of options from Soma for achieving this: http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/?p=31126 http://processwire.com/talk/topic/4680-block-access-to-settings-delete-and-view-tabs-for-page/?p=45734

I think this thread should answer your question: http://processwire.com/talk/topic/5083-possible-bug-page-fieldtype-with-custom-selector-to-find-selectable-pages-returns-error-while-saving-page/

I think offsite in general is a bad idea - eventually something will break. I did think of the Github option, but seemed wasteful to put images in with the module files and hackish to put them in a separate "pw-screenshots" repo. Hopefully Ryan will chime in with a better solution!

Well in the first example you pointed to, horst is hosting the image on his own website and the second example is from Ryan. He is hosting it in the assets folder of the modules directory, but I don't think the rest of us have that option - at least I don't see it when I try to edit one of my modules - maybe I am missing something?

foreach($page->children("sort=DMCContact_Country") as $child) { $class = $page === $child ? " class='on'" : ''; if($child->DMC_represented!=0) { echo "<li> <a$class href='{$child->url}'> <span class='label label-default'> {$child->DMCcontact_Country}</span> {$child->title}</a></li>"; } }

Often the "documentation" for third party modules is in the first post of the associated forum thread. Sometimes this is very similar to what's in the Readme file or in the text in the modules directory, but often it is much more detailed. That would be my suggestion for you at the moment, but I would agree that all module authors should do a better job of ensuring the text in the modules directory entry is more complete. Actually thinking about this, I think one of the problems is that the modules directory doesn't support images at the moment so we can't add screenshots here whidh is why I tend to think of the forum thread as the main spot for documentation. Ryan - any chance we could add support for images in the modules directory?

I assume you are talking a front-end form using the API? You can make it transparent to the front end user. Have your form processing code save the page using whatever field you want for the title/name of the page, then $newpage->save(), then process the rest of the form fields including the file upload and then save again. Does that make sense?

Thanks for the feedback guys - I hadn't tested thoroughly yet, although maybe the size of the .app file should've rung some alarms - pretty huge for a text editor!

You just have to change the Label Field from Title to Name and you'll be good!

Thanks for giving me yet another tool to try Just when I was thinking about switching from ST to Brackets I have another option to try. Have you guys seen this: http://blog.brackets.io/2013/05/31/better-javascript-debugging-with-theseus/

I just set up a page field with parent of Admin > Access > Users and it works fine. Do you get that error when saving the field in the admin, or a page with that field on it, or saving the page via the API?

But not easy