Media Editor Modal: track the original attachment id for edited images

[ramonopoly]

This ticket tracks the work for the following issue:

​Media: Tracking the relationship between original images and their cropped derivatives

And PR:

​Media: track the original attachment id for edited images- #81803

When Gutenberg crops an image, Core's /edit creates an entirely new attachment with no stable pointer back to the image the lineage started from.

parent_image records only the immediate source; there is no root/original reference across crop-of-crop chains.

That means we can't navigate a crop back to its original in a performant way, that is, without getting each post up the change where parent_image exists.

​Media: track the original attachment id for edited images- #81803 proposes to add a dedicated postmeta key _wp_attachment_original_id stores the root id.

There's no conflict with the current "restore image" functionality in the media library, which is file-based.

## What? Why?

When Gutenberg crops an image, Core's /edit creates an entirely new attachment with no stable pointer back to the image the lineage started from.

parent_image records only the immediate source; there is no root/original reference across crop-of-crop chains.

That means we can't navigate a crop back to its original in a performant way, that is, without getting each post up the change where parent_image exists.

This PR adds original_attachment metadata under media_details to track the lineage.

Trac ticket: https://core.trac.wordpress.org/ticket/65987

## Use of AI Tools

To create the backport of ​https://github.com/WordPress/gutenberg/pull/81803 and its tests

One other question I had, and I don't think it's a blocker for this PR but would be good to consider, is what should happen for importers / WXR exports.

Thanks for flagging this! I had a bit of a dig around and found something else that looks interesting:

_thumbnail_id is ​collected during post meta import and ​rewritten to the new ids afterwards in remap_featured_images().

So maybe a follow up to the simpler, skipping could be to remap in a similar way. I think your idea of skipping is probably the best, first version: it'll avoid bad relationships after import, e.g., if an attachment with the same id already exists

I think your idea of skipping is probably the best, first version: it'll avoid bad relationships after import, e.g., if an attachment with the same id already exists

Draft PR here when/if we need it:

• ​https://github.com/WordPress/wordpress-importer/pull/270

[peterwilsoncc]

In 64118:

Media: Track the original attachment for edited images.

The block editor's image editor creates an entirely new attachment with no stable pointer back to the image the lineage started from.

This change records the attachment an edit chain started from in _wp_attachment_edit_root_id postmeta, reads it back with wp_get_edit_root_attachment_id(), and exposes it as a top-level edit_root field on the attachment REST response:

• the ID of the edit root, or,
• 0 when the image was not created by editing another one.

The field is included in the REST API's edit context only, alongside an embeddable wp:edit-root link so clients can hydrate the edit root with _embed.

The link is only added when the edit root is published or the user can read it. The edit_root field still reports the recorded ID.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/13303

Props ramonopoly, andrewserong.
Fixes #65987.