Add image editing functionality to REST API for media attachments - #78458
the-hercules wants to merge 1 commit into
Conversation
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @the-hercules! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
|
Superseded by #81803 |
What?
Closes
Closes #78077
What?
Add lineage tracking for cropped media created through the Gutenberg/REST image edit flow by storing
_source_attachment_idon newly created derivative attachments.Why?
When Gutenberg crops an image, it creates a brand new attachment instead of updating the existing one. While the generated attachment metadata already stores the immediate source in
parent_image, there is no stable root/original lineage reference across crop-of-crop chains.This makes it difficult to:
This PR adds a minimal backward-compatible MVP for derivative lineage tracking using attachment post meta.
How?
This PR adds a compatibility helper,
wp_get_original_attachment_id(), that returns the root/original attachment ID for an attachment derivative tree, or the attachment’s own ID when no lineage meta exists.It also overrides the Gutenberg REST media edit flow in
Gutenberg_REST_Attachments_Controller::edit_media_item()so that when a new cropped attachment is created, it stores_source_attachment_idon the new attachment. The stored value is always the root/original attachment ID, not the immediate parent crop.This keeps the two lineage concepts separate:
_source_attachment_idstores the root/original attachment IDparent_image['attachment_id']in_wp_attachment_metadatacontinues to store the immediate source attachment IDThe change is limited to newly created cropped attachments and does not backfill or migrate existing media.
Testing Instructions
_source_attachment_idrow inwp_postmetapointing to the original attachment ID._wp_attachment_metadatastill containsparent_image['attachment_id']pointing to the immediate source attachment._source_attachment_idstill points to the original root attachment ID.parent_image['attachment_id']points to the first cropped attachment, not the original._source_attachment_idmeta entry.