WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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)

11536.patch (2.0 KB) - added by husky 5 years ago.
Show the rotate buttons, but disable them and add tooltip
11536.2.patch (1.9 KB) - added by hakre 5 years ago.
Streamlined husky
11536.3.patch (1.9 KB) - added by hakre 5 years ago.
Streamlined husky's patch and fixed a typo

Download all attachments as: .zip

Change History (23)

comment:1 in reply to: ↑ description ; follow-up: @miqrogroove5 years ago

Replying to husky:

A better solution would be to offer an alternative imagerotate()

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.

comment:2 in reply to: ↑ 1 ; follow-up: @nacin5 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.

comment:3 in reply to: ↑ 2 ; follow-ups: @Denis-de-Bernardy5 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.

comment:4 @azaozz5 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).

comment:5 in reply to: ↑ 3 ; follow-up: @husky5 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.

comment:6 @husky5 years ago

  • Cc huskyr@… added

comment:7 in reply to: ↑ 5 ; follow-up: @azaozz5 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.

comment:8 in reply to: ↑ 3 @waclawjacek5 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.

comment:9 @miqrogroove5 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?

comment:10 @scribu5 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.

comment:11 @husky5 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.

@husky5 years ago

Show the rotate buttons, but disable them and add tooltip

comment:12 @scribu5 years ago

  • Keywords has-patch added; rotate imagerotate removed

comment:13 @hakre5 years ago

+1 for husky's way to solve that. in doubt, let the user decide. good choice.

comment:14 in reply to: ↑ 7 ; follow-up: @hakre5 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.


Related: imagerotate alternative (from php manual).

@hakre5 years ago

Streamlined husky

@hakre5 years ago

Streamlined husky's patch and fixed a typo

comment:15 @hakre5 years ago

Typo reference: #11488

comment:16 follow-up: @azaozz5 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].

comment:17 @azaozz5 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [12555]) Show disabled image rotation buttons when imagerotate() is missing, props husky and hakre, fixes #11536

comment:18 @azaozz5 years ago

(In [12556]) Show disabled image rotation buttons when imagerotate() is missing, props husky and hakre, fixes #11536 for 2.9

comment:19 in reply to: ↑ 16 @hakre5 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.

comment:20 in reply to: ↑ 14 @husky5 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!

Note: See TracTickets for help on using tickets.