[wp-trac] [WordPress Trac] #47782: REST API Media returning blank

[WordPress Trac]

#47782: REST API Media returning blank
--------------------------+-----------------------
 Reporter:  CHEWX         |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  Media         |     Version:  5.2.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  rest-api
--------------------------+-----------------------
Changes (by lukasbesch):

 * status:  closed => reopened
 * resolution:  invalid =>


Comment:

 While working REST-based themes I also noticed this behavior.

 In my opinion it is inconsistent with the way traditional themes work:

 If one uses an image attached to a post on multiple posts, then delete the
 original post, the image will be still visible in the other posts (both as
 featured image or embedded in `post_content` via Gutenberg or Classic
 Editor).

 For REST-based themes, `post_content` is still working as URLs are used in
 HTML and the direct access to the image is not affected by the (parent's)
 `post_status`.
 But, the featured image (retrieved with the `_embed` parameter) will show
 empty.

 As a solution I can think of multiple ways:

 1. As a user, don't attach any media to posts, instead upload via media
 screen and then insert.

 2. An option (or feature plugin) that will force attachments to not have
 an inheriting `post_status`. This can have side-effects I did not research
 yet – especially with plugins that rely on the relation to the
 `post_parent`'s `post_status`.

 3. As media can be used in multiple posts, and the information which image
 is used in which posts is valuable (think of deleting unused media to
 reduce storage), I propose a **many-to-many** relationship between these
 entities. This should be its own table (e.g. `wp_postrelations`) and could
 also be used for different kinds of post to post relations if planned
 accordingly. This of course would be a big change in functionality, but
 the data could easily be migrated. On the other hand, for sites with many
 attachments and posts, this would also result in a larger database
 (similar to the `wp_term*` tables).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47782#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform