[wp-trac] [WordPress Trac] #42663: Imagick support for stream wrappers
WordPress Trac
noreply at wordpress.org
Fri Sep 18 09:54:15 UTC 2020
#42663: Imagick support for stream wrappers
-------------------------------------------------+-------------------------
Reporter: calin | Owner:
| mikeschroder
Type: enhancement | Status: assigned
Priority: normal | Milestone: 5.6
Component: Media | Version:
Severity: normal | Resolution:
Keywords: has-patch 2nd-opinion has-unit- | Focuses:
tests |
-------------------------------------------------+-------------------------
Comment (by mikeschroder):
> 1. should I add support for very old versions of the imagick extension
as @calin's patch did? Pros: works with old PHP; Cons: adds some code
bloat.
I did a bit of research here (both on @calin and your proposed Imagick
functions to use).
After that, I’m not clear which versions of the Imagick extension we’d be
dropping if we go with the approach in the PR, as the new function,
`readImageBlob`, seems to be available from 2.0.0.
A couple of datapoints to help the discussion:
- Right now, [https://github.com/WordPress/wordpress-
develop/blob/master/src/wp-includes/class-wp-image-editor-imagick.php#L35
2.2.0 is required].
- This might not be representative, but as a spot check, looks like the
majority of [https://make.wordpress.org/hosting/test-results/ recent test
reporters] that support Imagick have 3.4.4.
I'm guessing I'm missing something here -- Could you please explain what
you've found so far?
> 2. should I try and call `make_image` from `_save` like @calin's patch
did. Pros: ??; Cons: convoluted code.
`make_image()` was added to the class specifically to separate file stream
concerns, so that's the reason I gave the earlier feedback.
As an example, [https://github.com/WordPress/wordpress-
develop/blob/master/src/wp-includes/class-wp-image-editor-gd.php#L508 this
is how GD handles it].
Would you mind going into a little detail on why you think it's a better
not to use it in this case?
> 3. should I add a dummy stream wrapper for testing like @calin's patch
did instead of testing with `file://` URLs? Pros: more likely to pick up
future bugs if the code relies on features like seekable streams; Cons:
bunch of extra code in the tests for the fake stream.
I think that the more tests the better if it will improve coverage, since
this is a less commonly used feature that has had a series of bugs. But of
course, any tests you have the time to include are appreciated.
Thanks again!
--
Ticket URL: <https://core.trac.wordpress.org/ticket/42663#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list