REST API: Record the source attachment of an uploaded image edit.

[adamsilverstein]

Companion to WordPress/gutenberg#82362.

Claude Code wrote this up from the Gutenberg change:

With client-side media processing, image edits (crop, rotate, flip) made in the editor are moving from the server media/<id>/edit endpoint into the browser: the edit is applied with libvips and the result is uploaded through POST /wp/v2/media as a new attachment. The one thing /edit records that the upload endpoint could not is where the new image came from.

This adds an optional parent_image integer parameter to the media create endpoint. When set it must reference an existing image attachment the current user can edit (the same check the /edit endpoint applies), and after the upload the new attachment's metadata gets what edit_media_item() writes for its new attachment: the parent_image entry (attachment_id and the source's relative file), the source's EXIF image_meta for any field the new file lacks, and an orientation reset to 1. Without the parameter nothing changes.

Tests cover the recorded metadata and response, the no-parameter case, a parent_image that is not an image (400), and an author who cannot edit the source attachment (403).

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

AI Use

Code and description both written with 🤖 Claude Code. I will review and test.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props adamsilverstein, ugyensupport.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[dugyen]

Manually tested against a local WP 7.1-trunk install (Studio site, real DB/uploads, no git checkout available so I hand-applied this diff — context matched cleanly).

Ran the PR's own scenarios via wp eval-file directly through the REST dispatcher (rest_get_server()->dispatch()), same as the added PHPUnit tests:

Scenario	Result
Upload with parent_image set → metadata + response carry parent_image, EXIF credit copied from source, orientation reset to 1	✅ 201
Upload with no parent_image → nothing recorded	✅ 201, key absent
parent_image points at a non-image post	✅ 400 rest_invalid_param
parent_image points at another user's attachment the current user can't edit	✅ 403 rest_cannot_edit_image
Schema exposes parent_image (type: integer, minimum: 1) in CREATABLE args	✅

All 5 passed. php -l clean. Behavior matches the ticket description and mirrors edit_media_item()'s handling faithfully.

🤖 Generated with Claude Code