Pete

Are you then going to run into issues elsewhere though as other pages could also potentially be using data from that page? I guess if you put a note next to that option explaining any potential issues then that would work. What would be great in theory is if there was some way to track wherever a $pages->find call (or other such bits of code) is made in a template file that returns in it's results the page you're saving, as well as any pages that use InputPageSelect (and other such field types) and clear the cache for those pages as well - so basically any page that makes use of the data in the page you're saving should have it's cache cleared. Unfortunately that's impossible in practice for the template file side of things (should be do-able for fields) unless you to a preg_match call on every template... ...maybe that wouldn't be so hard to do actually...? It would require looking for any code inside PHP tags that's selecting pages to list and working out which ones relate to the current page you're saving. Actually no, I think that would get quite messy and depending on the number of templates could take a bit of time. It also wouldn't be fool-proof - the minute you start putting common template bits into other files that you might include that PW doesn't know about (think header.inc, but yourname.inc <- PW wouldn't know that even existed). So yeah, ignore my train of thought

I think that the best thing for this now that I've thought about it a bit more would be to manage this stuff with some sort of languages module further down the line (think I read that a future version is going to have a multilingual focus in terms of translations). In that case, aside from being able to translate the admin language it would be helpful if there was a section that you could configure through a configuration page for replacements for title-to-url, so that for each language pack you can specify characters and their replacements on that config page rather than doing it in a file. On second thoughts, maybe do it all in a file as it's probably easier to have the rest of the language strings in a file...? Just have an array for title-to-url -specific stuff and an array for language strings maybe? Just thinking out loud

I think I've pretty much given up on this one as "a Windows thing". I used XAMPP 1.7.4 and upgraded it to 1.7.5 to try and overcome this, so the versions of PHP et al are: Windows (1.7.4): Apache (2.2.17) MySQL (5.5.8) PHP (5.3.5) Windows (1.7.5-beta5): Apache (2.2.19) MySQL (5.5.15) PHP (5.3.7) Pretty sure it's not the versions to blame though as if you Google "PHP Windows unlink" and "PHP Windows rename" you'll find a raft of issues dating back to the dawn of time (well, 2003 was the furthest back I remember seeing it). Apparently, though I don't know how accurate this is, rename essentially just uses PHP's copy() function and then uses unlink() to delete the original so someone on the web has suggested the problem is in unlink() on Windows. The bit that makes it impossible to resolve is that if I leave it long enough the file disappears (the original image file that's aborted halfway through the rename process it seems). What you get is the resized large version of the file - so if it's an over-sizes portrait image you get the 1200px high version in my case. PW then tries to rename this over the original which is where it fails, so you end up with the 1200px high version still in the folder and a corrupted (or rather broken - you can't open the image) "original" filename version. Just to satisfy my curiosity ryan, is there any way we can change the code just as a test so that if an image needs resizing, the image that's been uploaded never gets moved to the page's folder in the first place? I.e., is there a quick way to test if we can get around this by not copying the original uploaded file to the folder if it needs resizing? The reason I ask is that PHP on Windows seems fine and dandy when it's dealing with copied images, or even original image files that don't need to be resized but have been copied to the page's folder, but it just falls over when it tries to manipulate the original. So in my sleep-deprived brain, it would check the uploaded file's dimensions and, if it needs resizing create a new image and copy that across to the page's folder with the original filename, else if it doesn't need resizing copy it over to the page's folder as it is. Also, due to tiredness, I realise I've been saying this is PHP on Windows, whereas actually XAMPP is still Apache, just sitting on a Windows machine which I think is where it's hitting some weird permissions issues. I did even try setting the entire website folder and temp folder so the "Everyone" user has full access to do anything they like which didn't help, so I don't know whether it is so much a permissions issue but rather a file locking issue on the Windows file system. Anyway, my head hurts. If it can't be resolved then I'll just leave copying this site across until I've uploaded PW to the actual server (inside a dev folder) where it seems quite happy to perform this simple function It's just stupid as it just seems Windows likes to randomly lock files for a random period randomly

I'd be ecstatic if this was in version 2.1 - so much better than the decade-old way of doing file uploads on the web

It has to be done that way because essentially what it's building is a database query. It's technically a bit more efficient too as you're excluding that template so it's not placing the pages you don't want into an array then.

Hmm... so there is an issue overwriting or deleting the original file it seems. What I did based on the above error was change InputfieldImage.module so that the ___fileadded function looks like this: protected function ___fileAdded(Pagefile $pagefile) { $filename = $pagefile->filename; $pagefile2 = null; if($this->maxWidth && $pagefile->width > $this->maxWidth) { $pagefile2 = $pagefile->width($this->maxWidth); rename($pagefile->filename, $pagefile->filename . '1'); unlink($pagefile->filename . '1'); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); // force it to reload it's dimensions } if($this->maxHeight && $pagefile->height > $this->maxHeight) { $pagefile2 = $pagefile->height($this->maxHeight); rename($pagefile->filename, $pagefile->filename . '1'); unlink($pagefile->filename . '1'); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); } if($pagefile2) { $this->message("Resized '{$pagefile->basename}' to {$pagefile->width}x{$pagefile->height} fit within max dimensions of {$this->maxWidth}x{$this->maxHeight}"); } parent::___fileAdded($pagefile); } What I've effectively done is renamed the original image before renaming the resized image to the original name of the original image (with me so far? ). What it still refuses to do is delete the now-renamed original image and cites permissions as the issue. It's very weird because I've triple-checked permissions on the whole web folder on my hard drive so I know they're fine. I'll continue investigating - I think it'll be easier now I'm looking in the right file at last! EDIT: Okay, so I changed the function again to the one below: protected function ___fileAdded(Pagefile $pagefile) { $filename = $pagefile->filename; $pagefile2 = null; if($this->maxWidth && $pagefile->width > $this->maxWidth) { $pagefile2 = $pagefile->width($this->maxWidth); rename($pagefile->filename, $pagefile->filename . '1'); unlink($pagefile->filename . '1'); rename($pagefile2->filename, $pagefile->filename . '2'); unlink($pagefile->filename . '2'); $pagefile->getImageInfo(true); // force it to reload it's dimensions } if($this->maxHeight && $pagefile->height > $this->maxHeight) { $pagefile2 = $pagefile->height($this->maxHeight); rename($pagefile->filename, $pagefile->filename . '1'); unlink($pagefile->filename . '1'); rename($pagefile2->filename, $pagefile->filename . '2'); unlink($pagefile->filename . '2'); $pagefile->getImageInfo(true); } if($pagefile2) { $this->message("Resized '{$pagefile->basename}' to {$pagefile->width}x{$pagefile->height} fit within max dimensions of {$this->maxWidth}x{$this->maxHeight}"); } parent::___fileAdded($pagefile); } Essentially this is now creating another copy of the file and then unlinking it. I wanted to see if the script could at least delete the image it created and it can, it can also rename the original image. It just cannot delete it for some reason I must have checked all my folder permissions a dozen times now as well :(

Aaaand, we now have a backtrace Here's the errors at the top of the screen: Warning: rename(C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.1600x0.jpg,C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.jpg) [function.rename]: Access is denied. (code: 5) in C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldImage\InputfieldImage.module on line 43 Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 115 Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/jlandscape.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 121 and ehre's the backtrace: TemplateFile: for backtrace #0 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldImage\InputfieldImage.module(44): Pageimage->getImageInfo(true) #1 [internal function]: InputfieldImage->___fileAdded(Object(Pageimage)) #2 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #3 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('fileAdded', Array) #4 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(130): Wire->__call('fileAdded', Array) #5 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(130): InputfieldImage->fileAdded(Object(Pageimage)) #6 [internal function]: InputfieldFile->___processInputAddFile('jlandscape.jpg') #7 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #8 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInputAdd...', Array) #9 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(185): Wire->__call('processInputAdd...', Array) #10 C:\xampp\htdocs\sc11\wire\modules\Inputfield\InputfieldFile\InputfieldFile.module(185): InputfieldImage->processInputAddFile('jlandscape.jpg') #11 [internal function]: InputfieldFile->___processInput(Object(WireInputData)) #12 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #13 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array) #14 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): Wire->__call('processInput', Array) #15 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): InputfieldImage->processInput(Object(WireInputData)) #16 [internal function]: InputfieldWrapper->___processInput(Object(WireInputData)) #17 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #18 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array) #19 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): Wire->__call('processInput', Array) #20 C:\xampp\htdocs\sc11\wire\core\InputfieldWrapper.php(261): InputfieldWrapper->processInput(Object(WireInputData)) #21 [internal function]: InputfieldWrapper->___processInput(Object(WireInputData)) #22 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #23 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array) #24 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(579): Wire->__call('processInput', Array) #25 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(579): InputfieldForm->processInput(Object(WireInputData)) #26 [internal function]: ProcessPageEdit->___processInput(Object(InputfieldForm)) #27 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #28 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('processInput', Array) #29 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(147): Wire->__call('processInput', Array) #30 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(147): ProcessPageEdit->processInput(Object(InputfieldForm)) #31 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(94): ProcessPageEdit->processSave() #32 [internal function]: ProcessPageEdit->___execute() #33 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #34 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('execute', Array) #35 C:\xampp\htdocs\sc11\wire\core\ProcessController.php(194): Wire->__call('execute', Array) #36 C:\xampp\htdocs\sc11\wire\core\ProcessController.php(194): ProcessPageEdit->execute() #37 [internal function]: ProcessController->___execute() #38 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #39 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('execute', Array) #40 C:\xampp\htdocs\sc11\wire\core\admin.php(42): Wire->__call('execute', Array) #41 C:\xampp\htdocs\sc11\wire\core\admin.php(42): ProcessController->execute() #42 C:\xampp\htdocs\sc11\site\templates-admin\controller.php(13): require('C:\xampp\htdocs...') #43 C:\xampp\htdocs\sc11\site\templates\admin.php(13): require('C:\xampp\htdocs...') #44 C:\xampp\htdocs\sc11\wire\core\TemplateFile.php(88): require('C:\xampp\htdocs...') #45 [internal function]: TemplateFile->___render() #46 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #47 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('render', Array) #48 C:\xampp\htdocs\sc11\wire\modules\PageRender.module(194): Wire->__call('render', Array) #49 C:\xampp\htdocs\sc11\wire\modules\PageRender.module(194): TemplateFile->render() #50 [internal function]: PageRender->___renderPage(Object(HookEvent)) #51 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #52 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('renderPage', Array) #53 C:\xampp\htdocs\sc11\wire\core\Wire.php(289): Wire->__call('renderPage', Array) #54 C:\xampp\htdocs\sc11\wire\core\Wire.php(289): PageRender->renderPage(Object(HookEvent)) #55 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('render', Array) #56 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageView.module(73): Wire->__call('render', Array) #57 C:\xampp\htdocs\sc11\wire\modules\Process\ProcessPageView.module(73): Page->render() #58 [internal function]: ProcessPageView->___execute() #59 C:\xampp\htdocs\sc11\wire\core\Wire.php(267): call_user_func_array(Array, Array) #60 C:\xampp\htdocs\sc11\wire\core\Wire.php(229): Wire->runHooks('execute', Array) #61 C:\xampp\htdocs\sc11\index.php(170): Wire->__call('execute', Array) #62 C:\xampp\htdocs\sc11\index.php(170): ProcessPageView->execute() #63 {main} I think the newest comment here might hold the answer for Windows: http://php.net/manual/en/function.rename.php I suspect that rather than sleep() as that comment suggests, simply delete the original file before renaming the other file to it.

No worries, I'll try that shortly. It seems to just be any image that needs to be resized, whether portrait or landscape. I careated some landscape and portrait images in Photoshop (big green rectangles) and saved them in jpeg, png and gif formats and it happens to all of them. Also it seems that if I stop execution at the end of the ImageSizer resize() function just before it returns, the images it's created up to that point are fine, so it's at some point after this - I think resized images go through this twice maybe? Anyway, I'll try your code and see if it helps pin this down.

I thought the @ might be an issue as chmod won't have any affect on Windows so wasn't sure it would cause an issue or not but it doesn't (or a lot of gallery scripts would struggle on Windows!). It's definitely something that only affects images that are being resized - it seems to corrupt the original image now that I'm looking into it further, but generates the resized version just fine. I'm basically going to put en exit; command in the ImageResize file after every action it performs on the original file one by one and see if I can pinpoint exactly where it causes the issue.

Just a note to say that whilst I've been trying to solve this, I've noted a few things in PW's code. 1) Wherever chmod() is used, it's inconsistent as to whether there is an @ before it (so @chmod() ) or not. Guess all occurences should be @chmod to avoid possible issues in Windows??? 2) ImageFilledRectangle in wire/core/ImageSizer.php should be lowercase, so imagefilledrectangle (2 occurences here). Minor things I know, but thought I'd bring them up whilst I'm hunting for a solution

Okay, so it's not memory-related. Increased memory limit for PHP to 512mb and increased max filesize and post time etc. It's very odd indeed. I've managed to get it working on my live server - didn't have to change a thing. My local server is XAMPP on Windows though so it's a totally different environment anyway. The error message I get from trying to upload one of the bizarrely-affected images is: Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/ufoam_alien222.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 120 Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/ufoam_alien222.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 120 Warning: getimagesize(C:/xampp/htdocs/sc11/site/assets/files/1130/ufoam_alien222.jpg) [function.getimagesize]: failed to open stream: Permission denied in C:\xampp\htdocs\sc11\wire\core\Pageimage.php on line 120 Which points to permissions being the issue. Any idea why it would be having trouble on image permissions for some images and not others? I'm just going to hazard a guess that it works on my live server as it's a Linux box whereas on XAMPP on Windows PHP is having trouble with Windows permissions (not that there's any reason it should). I even went as far as saving one of the images in Photoshop then did a Save for Web and gave it a totally different name with no luck. Oh, and I updated XAMPP to the latest version too so new version of the GD library theoretically, but the errors I get above aren't to do with GD anyway I don't think. EDIT: Also worth noting - I've checked the permissions on the file before uploading and they're fine. I also noticed that it DOES manage to create the newly sized image, but then fails to create a thumbnail - so I've got an image called ufoam_alien222.0x1200.jpg but no thumbnail. Looking at it it seems that it's only images that larger than the max width and height I've set so I wonder if we're getting some sort of weird Windows-only error here?

This mightwork: <? echo $page->map ? $page->map : ''; ?>

Bah, you don't have to stay awake through meetings do you?

Must spam to catch up (kidding). I was just looking for some examples of multi-level menus for another project so this is yet another useful thread I've now got bookmarked!

Really looking forward to this - keep up the good work, but yes - remember to sleep

Yup, I think it must be memory related. I'll change some setting in the morning. Cheers for checking Ryan - it always helps if someone else tests it even if it's not an issue that can be reproduced.

I wonder if it's because some of the filenames have dimensions in them already before uploading? Doesn't explain the alien image not uploading for me though. Attached are three that wouldn't upload (these are original size and original filenames). I'll try increasing memory and so on on my test server later as that might be it if these work for you.

Hi guys I've encountered what I think is an error with Image fields. Change the settings of your image field so that the max width is 1600 and the max height is 1200. Upload a picture in landscape orientation that's larger than this and it works, Upload a picture in portrait orientation that's larger than 1200 and it breaks. So for me it's failing with errors when uploading large portrait-orientation images. Can anyone else reproduce this? Feel free to change those values to smaller ones if you've not got any huge images to hand

I'm just creating the pages manually. Perhaps if it's a potential issue with other languages then having that as some sort of config option would be the way to go with it disabled by default?

Keep up the good work - I'm looking forward to giving this one a test

I think a better way would be to write a module that hooks into the template itself and simply makes all the fields that aren't in their language hidden, then hide the surrounding DIV so the label and input fields don't show. Of course, I'm not sure how to do that

This one's for ryan, but obviously open for discussion to all. Whilst porting a reasonably large site over to PW I noticed that the ampersand character (&) gets stripped out when a URL is automatically created from a page title. Is there any chance this could be automatically converted to the word "and" instead? Sure it's not amazingly important, but it allows for more legible URLs.

Wow. There's the majority of the need for Flash/Java uploaders gone for good On sites where I'd be creating forms for other admins to use on one of my sites I would probably speciify that they have to update their browsers to use the CMS. It will obviously be a few years before the majority of folks have updated to a HTML5-compatible browser however I'm looking forward to using some of these features down the line to make life easier. In fact, I'm sure I saw a jQuery-based upload script a few weeks back (before my laptop died ) that used HTML5, fell back to Flash if your browser didn't support it and fell back to doing things the old-fashioned way if you didn't have either. That one was just for uploads, but one that was just HTML5 that might be good for getting ideas from is mentioned previously here: http://processwire.com/talk/index.php/topic,351.0.html

Wow! And it's taken them this long to roll HTML5 out because...? Seriously, if we'd had the file API about 5 years ago so many of my projects would have been so much simpler

Nice ideas, especially since it sounds like it just degrades gracefully on older browsers.