Media item published status is inherited from parent post. This can cause issues when adding media to published posts

[sean-dunwoody]

Media items essentially inherit the post status of the first post that they are assigned to.

If you look in the wp_posts table. Media items have a value of "inherit" under the "post_status" column.

This can cause problems though, for example the following situation:

• You create a new draft post and add some media items to it
• You create another post, add the same media items, and publish it
• The frontend will use the rest API to try and retrieve information about the media items, but because they are draft (due to their parent post being draft) the rest API will return an error message (it just returns 401: "Sorry, you are not allowed to do that.")

This can cause unusual bugs in certain situations, and it will be difficult for the user to understand why this is happening.

[simonrjones]

This is a WordPress issue in that WP does not expose media items which inherit status from an unpublished post. Not sure what to do about this one, since it is expected behaviour.

[sean-dunwoody]

It is expected behaviour yes, but it can be confusing for the user because there is no way for them to see which post a media item inherits its status from.

As a user, if I add a media item to a page and publish it, I expect the media item to be visible on the frontend, regardless of which other pages it is also attached to.

As far as I can tell, usually this wouldn't be a problem in WordPress, but because we are using the Rest API, it is returning 401 responses for the media items that are set to unpublished.

Appreciate this is a difficult and frustrating issue though as this is core WordPress behaviour that is probably a bit difficult to fix. I think there are two routes we can take:

1) Log a bug report with WordPress for this issue and see if they will acknowledge it and fix it 2) Try and implement a custom workaround that changes the parent ID for media items in situations like this. This would fix the issue, but may be difficult to implement.

How do you think we should proceed @simonrjones ?