Pete

I thought I'd ask a question about copyright, and whilst I'm at it thought I might as well ask a less popular question about whitelabelling software Am I right in assuming that when altering the admin templates, we can do pretty much anything we like aside from removing the copyright in the footer? So I can take off the Processwire logo at the top and put in the logo for the company whose website it runs if requested to do so by a client? And now on to the less popular question - is a white label version allowed? As in, without the copyright in the footer, but obviously leaving all copyright in the files themselves? I've personally not had this request crop up yet, but I have heard of companies wanting to take any branding off CMS admin templates before and stick their own logo at the top - purely to use it on their own site from what I gather and not to redistribute as "their own" work. What's your stance on this ryan? Most folks don't allow this but I thought it was worth asking whilst I was asking about the templates. Another CMS I've worked with actually made money working with honest*1 companies this way by selling a license to allow removal from the admin templates. Again, we're talking the templates and not touching the copyright in the code itself. *1By "honest", I think that what they were doing was removing branding and replacing it with links to their internal support department's contact pages in some cases, though I have no doubt that a useful side-effect of this for them is that people would then assume that they've built the software in-house. You'd have to hope they were being honest with their users and management as well and giving credit to the actual authors when asked who built the software.

I use IPB purely because I've used it since version 1, back when it was a bit simpler (and free). It's probably a bit overkill for a lot of sites, but they've been trying to streamline it a bit in 3.2 and you can turn a lot of extra stuff off. it's a very solid product anyway and I like the new, more streamlined default skin as well as built in anti-spam in the new version (they have a central server a bit like the StopForumSpam website). I guess I've just used it so much that setting it up, configuring it and maintaining it doesn't bother me, but to a newcomer it's so big in the admin area I imagine it can be a bit daunting. In terms of free forum software, I've used MYBB - very good product and feature set, and the code was easy enough to manipulate on one site I used to have so that I could do integration like I'm doing here without the need for a third-party set of classes (pretty sure I was able to initialise an instance of MYBB inside my custom CMS at the time so could probably do it again with ProcessWire if the need ever arises again. No worries on the skin issue Ryan - that's just me fiddling with the stylesheet

This is just something I'm doing for one of my sites that's possibly too complicated to release as a module as it requires a third-party module that I've had to squash bugs in myself (), but it is a bit nifty even if I do say so myself. Basically what I've done (or rather re-done as I lost the original code when my hard drive died) is written a module to use my forums as comments for news articles that are written in PW. I'll give you the link first and explain it all later: http://screencast.com/t/TvCg6lHUZ1L So, I created a new page in ProcessWire using the News template. My module knows that anything using the News template that's under the News page will create a topic in a specific forum. Upon first save it creates the topic and puts in some text that links to the news article page on the PW site (when I get the right link... seem to have linked the forum topic to itself there in the vid ). At first, the forum post is "Queued" - as in hidden from non-forum-staff - as the page is not yet published. I debated whether to copy the article content into the topic, but the point of the exercise on my site at least is that this News Desk forum is hidden away from all but site staff (it's just a container for news comment topics) - it could easily contain something more interesting like an intro with a link to the full article so people browsing your news forum click through to your news section if they see something interesting. You'll see as the page is published, the topic is made live (Queued status removed) so all can see it (but in this test case it's still just in a staff-only forum ). Moving the news page to the trash causes the forum topic to be Queued again to the public can't see it - very important I thought! Restoring the page, or in fact moving it anywhere after it's been out of the trash makes the topic visible again. Deleting the page deletes the forum topic as well. That's it so far and it suits my immediate needs Something that's important to note is that as I'd previously logged in to the forum software it knew to create the news post as me - I'll tie in PW and forum logins at a later date, or at the very least throw up a warning if you try and create a news page but PW detects you're not logged into the forum software - since it's only a handful of admins who will use this I'd like to do the former as I can just tell them to use the same username and password for both and create a login form that logs them in to both systems. Also, the forum software I use is IPB - www.invisionpower.com if anyone is interested, and the class that I used to talk to it is www.ipbwi.com , but as I say I had to fix a few bugs in IPBWI as IPB did a major release not so long ago that means IPBWI isn't too happy with it at present.

I know what you mean - to be honest without a proper Windows server (IIS with PHP and mySQL) to test this on it could still just be an issue on my XAMPP installation/some weird permissions issue/only an issue on my machine It's only a development platform after all and not designed as a proper server platform, so yeah, not a good idea to start radically re-thinking how files are handled, especially as the way they're handled presently is perfectly good OOPHP with one class for uploads and another one for image transformations. I tested that bit of code and it didn't work unfortunately, but to be honest it's really not a big deal for me and I've wasted enough time trying to solve it now I reckon I think the solution for me is to just set the galleries up, finish the rest of the site off, upload it to the live server in a /dev folder or something and upload the gallery images then when it's on a real server. It's certainly not worth more hours of head-scratching that I could have spent on porting the rest of the site across to PW. Thanks for the assistance though ryan - much appreciated and at the very least I've learned another bit of code which I can use to track bugs in PW, not to mention I know some classes a lot better now!

Cheers ryan, I'll check that out

Ah, now that 4th option sounds interesting. You could have options on a page to clear a list of other pages then as you say, but another approach is from the template side of things where for each template you could say something like ANY page using this template clears all other pages using this template when saved. I guess I've got a few scenarios in my head, but we'd need to jot down all possible scenarios to get this right. Problem is when you start clearing the cache on entire sections of the site then like you say, you may as well clear the whole thing! Maybe a better way would be to have a per page or per template option to stop a page and it's children, or evey page using a template from being cleared from the cache and approach it from that angle? Clear the cache for everything but the pages/templates you specify when a page is saved? Might be less hassle, I don't know - might also be less intuitive but I was thinking that you probably know of sections/pages that, once they're up on the site, will rarely/never change or certainly that they shouldn't have an impact elsewhere.

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?