Goals

• 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.

Questions

• 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 doing WP_Attachment over a WP_Image?
• Should methods for manipulating image files be contained within a WP_Image class, or should those belong to another class that accepts a WP_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 to WP_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?