#11536 closed defect (bug) (fixed)
Rotate image buttons don't show up on PHP installs without imagerotate()
Reported by: | husky | Owned by: | |
---|---|---|---|
Milestone: | 2.9.1 | Priority: | normal |
Severity: | normal | Version: | 2.9 |
Component: | Editor | Keywords: | has-patch image-edit |
Focuses: | Cc: |
Description
The two new 'rotate image' buttons in 2.9 depend on the imagerotate() function from the PHP GD library to work.
Unfortunately, that function is only available with a pre-compiled version of the GD library, which my host (and i suspect many others) don't have because it's apparently not a popular way to use the GD library. For example, the 'php5-gd' package on Ubuntu 8.06 doesn't have it.
End users expect this behaviour to work (it is shown as a major new feature of 2.9) so we should at least have a message that their host doesn't support the rotate buttons.
A better solution would be to offer an alternative imagerotate() function to use (might be slow though). Many examples can be found at php.net: http://nl3.php.net/manual/en/function.imagerotate.php
Attachments (3)
Change History (23)
#1
in reply to:
↑ description
;
follow-up:
↓ 2
@
15 years ago
#2
in reply to:
↑ 1
;
follow-up:
↓ 3
@
15 years ago
Replying to miqrogroove:
A better solution is to totally disable image editing on any host that doesn't support the full feature set, with an appropriate message. If you want that feature, you have to install it. Period.
Wow. No. WordPress should not cripple an entire feature just because one component cannot be supported.
#3
in reply to:
↑ 2
;
follow-ups:
↓ 5
↓ 8
@
15 years ago
Replying to nacin:
Replying to miqrogroove:
A better solution is to totally disable image editing on any host that doesn't support the full feature set, with an appropriate message. If you want that feature, you have to install it. Period.
Wow. No. WordPress should not cripple an entire feature just because one component cannot be supported.
I'd lean towards miqrogroove's idea, myself: if the host sucks, user should be told it does, and user should get the feeling that it really does.
#4
@
15 years ago
There's another alternative: use ImageMagick when available. It seems it's not as widely supported as GD but quite a few hosts provide it. Perhaps a good way to do that would be to set a constant early and have all image manipulation functions in the editor call the appropriate function (GD) or method (Imagick).
#5
in reply to:
↑ 3
;
follow-up:
↓ 7
@
15 years ago
Replying to Denis-de-Bernardy:
Replying to nacin:
Replying to miqrogroove:
A better solution is to totally disable image editing on any host that doesn't support the full feature set, with an appropriate message. If you want that feature, you have to install it. Period.
Wow. No. WordPress should not cripple an entire feature just because one component cannot be supported.
I'd lean towards miqrogroove's idea, myself: if the host sucks, user should be told it does, and user should get the feeling that it really does.
This isn't a 'host sucks' problem. From what i've heard, the problem is that Ubuntu 8.04 (Hardy) shipped the standard GD library instead of the PHP one, which didn't include imagerotate(). It doesn't help that Hardy is one of the most widely used Linux distributions for LAMP servers. If an alternative to imagerotate() doesn't suck up much resources it might be viable.
#7
in reply to:
↑ 5
;
follow-up:
↓ 14
@
15 years ago
Replying to husky:
... If an alternative to imagerotate() doesn't suck up much resources it might be viable.
Tried that already, kind of usable for images up to about 600x800 but very slow/high CPU for larger.
#8
in reply to:
↑ 3
@
15 years ago
Replying to Denis-de-Bernardy:
Replying to nacin:
Replying to miqrogroove:
A better solution is to totally disable image editing on any host that doesn't support the full feature set, with an appropriate message. If you want that feature, you have to install it. Period.
Wow. No. WordPress should not cripple an entire feature just because one component cannot be supported.
I'd lean towards miqrogroove's idea, myself: if the host sucks, user should be told it does, and user should get the feeling that it really does.
Yes, but shouldn't be made even more disabled because of that.
#9
@
15 years ago
This ticket needs an executive decision, and should be treated as a feature request. Opinions so far are a wash.
Is the plan for WordPress to leverage the GD library, or to reinvent Photoshop?
#10
@
15 years ago
- Milestone changed from 2.9.1 to 3.0
Me thinks this isn't something which can be addressed properly in a maintenance release. Punting to 3.0 until at least a working patch is submitted.
#11
@
15 years ago
- Milestone changed from 3.0 to 2.9.1
Agree that a working fix is probably something for 3.0. However, we can be nice to people who don't have a clue why the rotate buttons don't show up. I've added a patch that shows the buttons, but in a disabled state with a tooltip that tells them that their host doesn't support rotating images.
#14
in reply to:
↑ 7
;
follow-up:
↓ 20
@
15 years ago
Replying to azaozz:
Replying to husky:
... If an alternative to imagerotate() doesn't suck up much resources it might be viable.
Tried that already, kind of usable for images up to about 600x800 but very slow/high CPU for larger.
Which alternative have you tested, can you reference it please, I'm missing it.
#16
follow-up:
↓ 19
@
15 years ago
Replying to hakre:
Which alternative have you tested, can you reference it please, I'm missing it.
There are generally two ways to mimic rotation: set each pixel in the rotated image according to the corresponding pixel in the original (very slow) or copy the image pixel by pixel (slightly faster but still too slow for larger images).
There was an imagerotate() substitute function in trunk for a while but didn't stand testing and was removed [11746].
#19
in reply to:
↑ 16
@
15 years ago
Replying to azaozz:
Replying to hakre:
Which alternative have you tested, can you reference it please, I'm missing it.
There are generally two ways to mimic rotation: [...]There was an imagerotate() substitute function in trunk for a while but didn't stand testing and was removed [11746].
Implementation in [11746] is pretty similar to the one I picked from the PHP manual, just compared both. Both are pure PHP code and do not scale very well. No wonder that this does not pay out with larger images. Was just curious if there's a chance to have a fallback. Then maybe imagemagick but I'm not an expert with that one. But that would be on another ticket then.
#20
in reply to:
↑ 14
@
15 years ago
Replying to hakre:
Replying to azaozz:
Replying to husky:
... If an alternative to imagerotate() doesn't suck up much resources it might be viable.
Tried that already, kind of usable for images up to about 600x800 but very slow/high CPU for larger.
Which alternative have you tested, can you reference it please, I'm missing it.
Well, none really, i just noticed there were lots of alternatives on php.net :)
I guess for 3.0 we might open a new ticket for hosts that don't support the imagerotate() GD function. Thanks for cleaning up my patch!
Replying to husky:
A better solution is to totally disable image editing on any host that doesn't support the full feature set, with an appropriate message. If you want that feature, you have to install it. Period.