stephanreiter

@huiz: Nicely done!

Danke, Tom!
Frohe Weihnachten!

Thanks, this is on my radar. To be honest, though, I’m thinking about stopping maintenance of Scissors.
The functionality at its heart – image editing – has been integrated into the WordPress core based on a patch by me (which will also allow undo/redo, just to name one new feature). And the rest, like watermarking and on-demand image resampling, is something that I’m not even using on my own blog, it was added based purely on user-feedback.
So, the incentive in going for WP2.9 compatibility for me personally is quite limited.

There’s a new option in the media settings for configuring this in Scissors 1.2.5.

The Scissors plugin version >= 1.2.6 adds support for cropping of medium and large images to the specified dimensions … if you still need a solution after all these months.

Hi guys!
Starting with version 1.2.6 of the Scissors plugin this is supported. You can now configure medium and large images to be cropped to the exact dimensions you specified.
Stephan

You answered your own questions: Whenever a processing operation is performed on the full-size image, EXIF data is lost. Avoid processing and you’ll be happy.

Check out the function ‘image_get_intermediate_size’ in the WordPress codex that allows you to retrieve an intermediate size of your choice, e.g. medium or thumbnail, for a given post-id (identifier of the image).

The problem is that the path ($filename) returned by get_attached_file doesn’t point to the image. Check the forum if there are any known bugs. Maybe you can also spot a difference between said $filename and the actual path on the server, which might give us a clue as to what is going wrong here.

Thanks!

Please note that commenting out anything is not suddenly going to fix this. What we’re trying to do here is to figure out which of the conditions is not satisfied. Therefore, please tell me what minimal set of ifs needs to be commented out for the controls to appear. Thanks!

Only comment out those if-blocks (e.g. if(…) return …;), the other lines in between are still required.

I’ve had another user report a similar problem but I still haven’t been able to figure this out. Could you take a look at the function scissors_media_meta in scissors.php and determine which of the checks in the head of the function pass and which (if any) fail, e.g. if the file exists? You could also try commenting them out after which the controls should appear on every image …

… depends on the server load, unfortunately.

I think the program you use for rotating your pictures only sets a flag in the image header for viewers to display it as intended and does not actually modify the image itself (Preview on OS X behaves like that). The GD library obviously ignores that additional information just like the GNOME file information dialog …

Alright, get the current dev version and witness your rotate-button disappear (I forgot to hide the button in addition to the rotate-pane, whoops). So, I’m sorry but your system DOES NOT support rotation because the function ‘imagerotate’ is not available (as the error you posted says).

From the imagerotate documentation on php.net: “This function is only available if PHP is compiled with the bundled version of the GD library.”