[wp-trac] [WordPress Trac] #28634: Upload images. does not clear Thumbnails metadata (+30kb from camera for each thumbnails)
WordPress Trac
noreply at wordpress.org
Fri Mar 4 18:44:53 UTC 2016
#28634: Upload images. does not clear Thumbnails metadata (+30kb from camera for
each thumbnails)
--------------------------+------------------------
Reporter: alexufo | Owner: joemcgill
Type: defect (bug) | Status: accepted
Priority: normal | Milestone: 4.5
Component: Media | Version: 3.5
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
--------------------------+------------------------
Comment (by joemcgill):
[attachment:28634.5.diff] is a refresh of [attachment:28634.4.diff] after
the changes to `WP_Image_Editor_Imagick ` that landed in r36700 with a few
notable differences:
* The `strip_meta()` function is run by default but can be overridden via
the `image_strip_meta` filter.
* I've left `strip_meta()` as a protected method for now but am open to
making it public.
I prefer this way of clearing data in since it relies on better supported
`Imagick` methods instead of `Imagick::deleteImageProperty()` and
`Imagick::setImageProperty()`, which was making the whole resize process
fail silently on a test environment for me using older versions of Imagick
(v2.2.2).
A few next steps:
Should we handle required methods separately inside this method so Imagick
can be used even if stripping meta isn't supported for some reason of
should we just add `'getimageprofiles'`, `'stripimage'`, and
`'profileimage'` to the required methods array in
`WashU_Image_Editor_Imagick::test()`? I suspect the former.
Should we give users the ability to filter a whitelist of protected
profile types that won't be stripped or should we keep this as a simple
on/off switch for now?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/28634#comment:42>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list