- Mimic the properties of WP_Post, and include additional metadata that's stored for images
_wp_attached_file
_wp_attachement_metadata
_wp_attachment_is_custom_background
(maybe?)
- Include methods for retrieving data associated with an image, possibly replacing the
wp_get_attachment_image_
family of functions. - Save any reused data that would be used across functions so it's not calculated multiple times (e.g.,
wp_upload_dir()
, see: #34359). - Maintain backwards compatability with the media.php image functions.
- Should this be extended to all attachments in the media library or should we do a base
WP_Attachment
that can be extended for each type (image, document, video, audio, etc.)? Does the fact that WP saves all media in the DB as an attachment post type make any difference in the pro/cons for doingWP_Attachment
over aWP_Image
? - Should methods for manipulating image files be contained within a
WP_Image
class, or should those belong to another class that accepts aWP_Image
object as a parameter? For instance, Marko started on this version of WP_Image in order to have a better way to send Image data toWP_Image_Editor
(see ticket #23424]) - Can we take the opportunity to clean up some back-compat hacks in media.php by leaving the compat shims in the old functions while moving cleaner logic to new class methods?
- How do we start to think about an opinionated way to store image variations of an image that is associated with a parent image, and create a roadmap where those variations aren't mixed up with 'sizes' of the original?
- What inspiration can we take from the way media is being modeled in the
wp.media.model.Attachment
backbone object in JS?