yellowled

Usually, I would say "No", especially since he successfully managed to upload other images up to 2,5 MB in size in huge image dimensions. Then again there's the fact that I could upload images he couldn't upload, so this might indeed be the solution. I'll check that. I am, however, pretty sure that whatever causes this issue, it's not related to PW, browser or OS. It has to be related to those specific images and/or the way he uploads them.

Quoting and translating the client here: It doesn't make a difference whether he uses drag 'n' drop or classic upload, besides the fact that drag 'n' drop is "way cooler". It's probably related to the particular images. He also stated that he tested it with different images in the meantime, and it worked, so the upload process in general seems to be fine.

The images are http://dl.dropbox.co...4/IMG_0067.jpeg and http://dl.dropbox.co...052012 074.jpeg I don't know if he's using d'n'd or "old school" upload, but I've asked. Might take until tomorrow to get an answer given local time. But why would it try to create a png image if the uploaded file is a jpg image with jpeg suffix? Edit: Im my ImageSizer.php, in line 137, it says case 'jpg': $image = @imagecreatefromjpeg($source); break; I wouldn't know how this is related to creating a png image …?

The error.txt has an older entry for a similar error: ("x" denotes user data which might be sensible.)

Unfortunately, I was "wise" enough to not save those error messages, but I can ask the client to reproduce the errors. DPI: 72x72, RGB colorspace with sRGB IEC61966-2.1 color profile (Hewlett-Packard), they seem to come from the same digital camera. Due to the image dimensions, I would assume this is either a low-budget consumer camera or even a smartphone, but I don't know exactly. No EXIF data available. Those look pretty normal to me. Besides, I used the exact same images and the upload went well …

I have copies of both images he tried to upload. Both are JPEG images: 1281x680, 323 KB 1280x854, 414 KB So they're not even that large in dimensions or size. As of now, the only difference I know of is that the client's working on a Mac, so the cloud directory/app theory might actually be a possibility.

So today I got a looot of emails from a client's PW installation containing "out of memory" and "imagesizer". Since unfortunately the site is running on a rather crappy server, I thought "Damn, PHP mem size limit" (server has 90M). Turns out that wasn't it. My client can not upload images using Safari/Mac or Firefox/Mac (still waiting to hear about the exact version numbers he used), he says the upload process stalls at 100% in Safari or 99% in Firefox. I can upload images just fine, however, using Chrome 18/Ubuntu or Firefox 14/Ubuntu. I also never ran into any memory limit messages building the site. Any ideas as to why and how this is possible?

Pete's http://modules.processwire.com/modules/minify/ does just that (with a little manual work in the template required).

Fun fact: one of my first projects ever was a web site which ran multiple nested Joomla installations. The guy who built it obviously had never heard of something like sections before, so he just use one Joomla installation for every friggin' section of the site. (I flat out refused to work with the current "system", so it was rebuilt using a different CMS. Now it's waiting to be moved to PW.)

Shall we just agree that the first rule of ProcessWire is: you do talk about ProcessWire? Because I think that will bring much more attention to the system in the long run than a high ranking on a web site which actually considers Joomla to be CMS …

By the way, this „I don't think I need this, I don't see the benefits of it.“? Me, about a year ago. Actually, everyone now using a preprocessor said so before giving it a try. Give it a try. We promise you'll love it.

First of all: I get that it's hard to "just switch" from something that works. It took me 3 attempts to switch my text editor, so … I don't think it's about being cool, it's about not having to type the same goddamn thing over and over again. (It really does save a lot of typing.) It can, yes. Let me briefly describe how I work with Sass/Compass, but note that it's not they only way to use it (in fact, it might not even be the most common one): I have a boilerplate config.rb file, which contains some configuration options for Sass projects, most notably locations for scss/css/img/js files. So basically it "tells" Sass where to find files needed and where to put files created. I set up a project folder which contains all the files required, including the Sass files. In that folder, I run "compass --watch" from a terminal. That's it. The compass command runs in the background (if you don't use Compass, "sass --watch" is just the same) and every time a sass file in said project is changed (i.e. saved), it re-compiles the resulting CSS file(s). No notable delay, but that might depend on the machine it's running on and the complexity of the project, i.e. the number of files involved.

I can only speak for Sass here, but I'm wondering what the hassle involved actually is. You need to set it up once, yes. It's not that painful on Linux, I assume it's about the same on OSX, but I have no idea how easy it is to set up Ruby on Windows. You mentioned working in teams – not my expertise, but I would assume that any team nowadays uses some kind of versioning system, so you would compile CSS from Sass files in the repository. So the team would only edit Sass files, and a Sass or Compass compiler running in the background would compile it to CSS files your project uses. Then there's the syntax – are you aware you don't have to use Sass/SCSS syntax at all? You can just convert your current .css files to .scss files, and the preprocessor will compile them properly right away. Of course, you'll want to use Sass/SCSS syntax to make use of its benefits, but you can do that step by step. I would recommend starting by splitting up CSS files the way Martijn outlined above. I think we all love to work with small, maintainable files, and this is actually possible with Sass @imports (doesn't work well with plain CSS @imports). The next steps would probably involve using variables and nesting (beware, nesting can result in very bloated CSS results if applied where not necessary). Then one would probably get into using functions, calculations and mixins.

Although Sass and Compass make it easier to keep (vendor-prefixed) CSS3 up-to-date, it's (in my humble opinion) not its main benefit. For me, it's stuff like this: http://jsfiddle.net/yellowled/xMx5X/ This fiddle demonstrates a mixin in Sass which makes it pretty easy to create rather complex CSS constructs with one @include line. It also makes it easy to change said construct just by changing some variables. Of course, this can be done with an editor which supports snippets, but that requires a lot more work on your end, I guess.

Funny thing: I use Sass/SCSS because (for me) it's less hassle to use over LESS or Stylus. I have yet to manage setting up a local nodejs server on my Ubuntu machine. Setting up Ruby is very easy, so my choice of using Sass was not at all related to the actual features of the preprocessor. As far as I have looked at other preprocessors, it doesn't really make a big difference anyway. Stylus has a much more concise syntax, which might be the reason I'll check it out one day. Sass has the Compass library, which I use, but not extensively. I prefer to write my own mixins and only use Compass for the complicated stuff and for CSS3 features which are still subject to change. My workflow probably wouldn't change much if I had to use LESS or Stylus from now on. Personally, I wouldn't want to go back to writing plain CSS, but that's another option, of course. I feel it has simplified my workflow massively, but like everybody else, I was sceptical at first, but now I can only recommend giving it a try. It really makes a lot of things much easier and less time-consuming.

Local LAMP. Ubuntu 12.04, Apache 2.2.22, PHP 5.3.10, MySQL 5.5.24.

Yay, success! I just installed this in a not-up-to-date installation, it did report an available update and the update to 2.2.3 did work. So the basic functionality seems to be working just fine. However, I think there's room for improvement in terms of usability in addition to the GitHub/major release setting. It would be great if this could display a changelog so people could see what actually changed in new versions. I have yet to experience a PW update which was mandatory, so it would be great if there was some kind of way to check out whether an upgrade is actually necessary. Not sure how to implement this, but I can not help with that anyway. Also, after successfully performing an upgrade, the AutoUpgrade page still says "Click on 'Upgrade' to start the upgrade. etc." That's pointless. If there's no newer version, the page should just say "No upgrade available." or something. Another configuration detail: it would be great if it could be configured to display or not display the upgrade notifier on every page. This can get quite annoying. Still, a very handy module!

Okay, feature request before even testing the module (which I will do locally): this should be configurable. In a production environment, one might not want to be notified of any small change in GitHub. It's perfectly valid to only want to do the major version upgrades, I guess.

I just installed this locally to evaluate it. The datepicker only offers the option to set a date, but if I set the date, the datepicker input field is set to "08.08.2012 hh24:08:ss" … and I have a feeling this is not intended behaviour?

Does this check for actual releases of PW announced on processwire.com or does it check Ryan's GitHub version for updates? Because if it checks for major version numbers, this test could take some time.

That's interesting, it didn't even occur to me that this was maybe an option. I don't have access to my Windows machine right now, but I'll check it out later.

You're right: http://caniuse.com/#search=file api – according to caniuse.com, even IE10 doesn't have full support for the FileAPI.

Yes, he does. (Other web servers like IIS or lighttpd have rewrite engines as well, but they have different names.)

Funny story: I already tested this twice today. I stumbled across the issue during a CMS training with a client. I had to use their machine since they couldn't add my laptop to their LAN. Confirmed it on my own Windows 7 machine at home to rule out issues with their setup. If they had been able to give me network access, I probably wouldn't have noticed since my laptop is an Ubuntu machine, and I almost never use my IE VM, either – except to test frontend CSS stuff. While we're at it: uploading images to an image field does work in IE9, but it doesn't work "on the fly" showing the upload progress bar. You have to select an image (or file, I assume; didn't test it) and save the page to upload it. I wouldn't consider this a critical issue, though; the functionality is there, it's just not as comfortable as in a "real" browser.

Just add /processwire/ at the end of your URL. This is the default value, it is possible to changes this, i.e. to /cms/ or whatever you prefer.