Make WordPress Core

Opened 5 years ago

Closed 2 years ago

#47782 closed defect (bug) (duplicate)

REST API Media returning blank

Reported by: chewx's profile CHEWX Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.2.2
Component: Media Keywords:
Focuses: rest-api Cc:



Just noticed an issue where an image returns empty.

If you go to a post, upload an image. Then delete that post.

The image will still be in the media lib which is correct.

If you then it will return empty.

If you restore post that was deleted the image will return.

I would expect the image to return regardless of the post it was uploaded to as if the post was deleted, that image may be re-added within another post, as you wouldn't re-upload as it's already in the media lib.


Change History (5)

#1 @Otto42
5 years ago

  • Focuses javascript removed
  • Severity changed from blocker to normal

An attachment's post_status is "inherit", meaning that it inherits the status of its parent post.

This code over in class-wp-posts-rest-controller.php checks the status of the parent to determine if the post's parent is readable:

		// Can we read the parent if we're inheriting?
		if ( 'inherit' === $post->post_status && $post->post_parent > 0 ) {
			$parent = get_post( $post->post_parent );
			if ( $parent ) {
				return $this->check_read_permission( $parent );

If the parent post is trashed, then it is not readable, which makes the attachment item also not readable.

#2 @SergeyBiryukov
5 years ago

  • Component changed from REST API to Media
  • Keywords close added

Hi @CHEWX, welcome to WordPress Trac! Thanks for the report.

Yes, the current behavior is intentional, per comment:1.

If you upload an image from the Edit Post screen, then it becomes attached to that post and depends on its status.

If you upload an image from the Media Library screen, then it does not depend on any post.

Last edited 5 years ago by SergeyBiryukov (previous) (diff)

#3 @desrosj
5 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Closing out since there has been no further reporter feedback and this is the intended behavior.

@CHEWX if you feel this is incorrect, feel free to reopen with clarification.

#4 @lukasbesch
3 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.
  1. 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.
  1. 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).

#5 @lukasbesch
2 years ago

  • Resolution set to duplicate
  • Status changed from reopened to closed

Duplicate of #41445.

Note: See TracTickets for help on using tickets.