Media: Rename HEIC companion metadata key to source_image#79307
Conversation
During the wordpress-develop backport review (WordPress/wordpress-develop#11323), the metadata key recording the sideloaded source-format original was renamed from the generic 'original' to the dedicated 'source_image', and the size token and the key were promoted to controller constants so the sideload schema and the metadata writer cannot drift apart. Port those changes back so the plugin and core agree on the key, and align the delete_attachment cleanup hook with the core implementation. Add PHPUnit coverage for the renamed key and the cleanup hook.
adamsilverstein
added
[Feature] Client Side Media
|
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. |
|
Flaky tests detected in c743b90. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27748330360
|
adamsilverstein
deleted the
worktree-update+heic-companion-source-image-key
branch
2 participants
What?
Brings back improvements made during the wordpress-develop backport review of the client-side HEIC companion-file handling (WordPress/wordpress-develop#11323).
The headline change: the metadata key that records the sideloaded source-format original (the HEIC kept next to its web-viewable JPEG) was renamed from the generic
originalto the dedicatedsource_image. This PR ports that rename to Gutenberg so the plugin and core agree on the key.Why?
The key name was settled during the core backport review, so Gutenberg has to follow it. If the plugin keeps writing the companion filename under
originalwhile core's cleanup readssource_image, the two diverge: the companion file is no longer found on attachment delete and lingers on disk. Keeping the key identical in both places is required for the feature to behave consistently once it ships in core.The generic
originalkey was also a poor choice on its own - it sits uncomfortably close to theoriginal_imagekey that the scaled-sideload flow owns.source_imageis deliberately specific so the two can never collide.How?
originaltosource_imageinGutenberg_REST_Attachments_Controller::finalize_item().original-heic) and the metadata key (source_image) to class constants (IMAGE_SIZE_SOURCE_ORIGINAL,META_KEY_SOURCE_IMAGE) so the/sideloadroute schema and the metadata writer reference a single source of truth and can't drift apart - mirroring the constants added in the core PR.delete_attachmentcleanup hook (gutenberg_delete_heic_companion_file()) with the core implementation: it now readssource_imageand returns whether a companion file was deleted.Testing Instructions
source_image(e.g. viawp_get_attachment_metadata()or Query Monitor).composer test -- --filter Gutenberg_Delete_HEIC_Companion_File_Testpasses.Related core PR: WordPress/wordpress-develop#11323; original feature PR: #76731.