You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Gutenberg-Based Media Editor: Add Media Level Focal Point Selector #75221
Media library images can be output in a variety of different ways, including templates, custom blocks, shortcodes, etc. It would be really helpful to be able to set a global focal point (similar to the one found in the Cover block) for a given image.
This focal point would be output in the bevy of functions that output images, such as wp_get_attachment_image for use by site, theme, and plugin developers as-needed (usually when images are set to object-fit: cover; or as a background). The global focal point could then be the default when the image is used in a Cover block and overridden on a block-by-block basis.
Thanks for opening the issue! I've just added this as a sub-issue of the main (parent) media library tracking issue. That way, if/when the work to build out parity with the core media library is complete, we won't lose track 👍
once upon a time there was a plugin called 'my eyes are up here' that cropped thumbnails based on face detect and by letting the user set focal points on any image via the media gallery. i saw it demo'ed at wordcamp boston a deacade or more ago.
recently the need for this arose ability with on a site where we wanted very granular control of the display of her images in thumbnails and mobile views for large images like heroes and backgrounds. my robot friends helped me get it working for my tools (elementor) on WP 7.0.1. but on 7.0.3 things aren't working as well, so it's not at all ready for prime time nor tested by anyone but me. :)
a nice thing about the original plugin is that it let you set multiple focal points so you can define the boundaries of the focus. i think it's important to have multiple face to define or want a certain section of the image to display.
I've started exploring an implementation for media-level focal point support. We have a working proof-of-concept that connects the REST API, @wordpress/media-fields, and block consumers:
REST API & Persistence: Storing _wp_attachment_focal_point as post meta with normalized { x, y } float coordinates (0.0 to 1.0) and exposing focal_point on the attachment REST endpoint.
Media Fields & DataViews: Added a focalPointField in @wordpress/media-fields utilizing @wordpress/components's FocalPointPicker and registered it into ORDERED_MEDIA_FIELDS.
Block & Template Integration: Seeding the Cover block's focalPoint attribute from attachment.focal_point when media is inserted, and filtering wp_get_attachment_image_attributes to expose --wp--focal-point-x/y CSS variables and object-position.
Before opening a PR, I'd love feedback on a few architectural decisions:
Media Editor UX Placement:
Option A (Field in Details): Rendering the focal point control as an expandable panel within the Details tab (DataForm). This works out-of-the-box across both the Media Editor and DataViews media library views.
Option B (Dedicated Sidebar Tab): Adding a dedicated Focal Point tab in the Media Editor modal sidebar alongside Crop and Details ([ Crop | Focal Point | Details ]).
Option C (Canvas Overlay Tool): Adding a toggleable focal point reticle directly onto the main canvas/toolbar in MediaEditorCanvas.
REST API Field Location:
Should focal_point be a top-level property on the attachment REST response (e.g., { focal_point: { x: 0.5, y: 0.5 } }), or should it be nested inside media_details?
Template Function Output (wp_get_attachment_image):
For wp_get_attachment_image(), is injecting object-position directly into the style attribute acceptable when not already defined, or would you prefer only exposing CSS custom properties (--wp--focal-point-x/y) and data-focal-point attributes to prevent unexpected layout shifts on existing themes?
Thanks for the ping! Also just an FYI to @ramonjd who's also been working on the media editor of late.
As for adding in a focal point selector, I'm not convinced that we're ready to add this feature in core yet. The media editor is progressing well, but still has many parity gaps between the classic / existing editor in core, and I think adding in support for focal point control to all images is a bit premature.
Additionally, media fields are in the process of being refactored (#83368), and it isn't clear to me how and why we're planning to store global focal point information alongside the media item itself. (E.g. if we're storing a focal point, why only one?)
As a feature (right now) this seems pretty niche to me, but I think it could be worth revisiting further down the track, once the media editor in core has been replaced with the new editor. But before then, adding focal point to just the new media editor would create an odd imbalance where the feature only appears in some situations.
In the meantime, if you're keen to continue working on the feature, I think it's a reasonable idea for a plugin — that might also help get a better sense of what the user expectations are surrounding how it all works.
Agree with @andrewserong - for attachment-level defaults it'd be a feature we could add after there's a stable replacement for the current media editor (in the media library), and for the Fields API to settle, which allows registering fields.
Another thought I had was that it could be approached from a block supports standpoint too.
Image, Cover and Media & Text each have their own focalPoint. #73113 proposes to add it to Featured Image.
A shared block support could unify them first. That would address blocks, and not accompanying generated thumbnails however.
Mind you, I'm coming at this from a block editor perspective. Any proposals to add this to the media library could be done in a core trac: https://core.trac.wordpress.org/newticket
Activity
andrewserong commentedon Feb 4, 2026
Thanks for opening the issue! I've just added this as a sub-issue of the main (parent) media library tracking issue. That way, if/when the work to build out parity with the core media library is complete, we won't lose track 👍
fontaholic commentedon Aug 16, 2026
hello from wordcamp contributor day. :)
once upon a time there was a plugin called 'my eyes are up here' that cropped thumbnails based on face detect and by letting the user set focal points on any image via the media gallery. i saw it demo'ed at wordcamp boston a deacade or more ago.
recently the need for this arose ability with on a site where we wanted very granular control of the display of her images in thumbnails and mobile views for large images like heroes and backgrounds. my robot friends helped me get it working for my tools (elementor) on WP 7.0.1. but on 7.0.3 things aren't working as well, so it's not at all ready for prime time nor tested by anyone but me. :)
a nice thing about the original plugin is that it let you set multiple focal points so you can define the boundaries of the focus. i think it's important to have multiple face to define or want a certain section of the image to display.
Ta5r commentedon Oct 14, 2026
Hi @andrewserong and team!
I've started exploring an implementation for media-level focal point support. We have a working proof-of-concept that connects the REST API,
@wordpress/media-fields, and block consumers:_wp_attachment_focal_pointas post meta with normalized{ x, y }float coordinates (0.0 to 1.0) and exposingfocal_pointon theattachmentREST endpoint.focalPointFieldin@wordpress/media-fieldsutilizing@wordpress/components'sFocalPointPickerand registered it intoORDERED_MEDIA_FIELDS.focalPointattribute fromattachment.focal_pointwhen media is inserted, and filteringwp_get_attachment_image_attributesto expose--wp--focal-point-x/yCSS variables andobject-position.Before opening a PR, I'd love feedback on a few architectural decisions:
Media Editor UX Placement:
DataForm). This works out-of-the-box across both the Media Editor and DataViews media library views.CropandDetails([ Crop | Focal Point | Details ]).MediaEditorCanvas.REST API Field Location:
focal_pointbe a top-level property on theattachmentREST response (e.g.,{ focal_point: { x: 0.5, y: 0.5 } }), or should it be nested insidemedia_details?Template Function Output (
wp_get_attachment_image):wp_get_attachment_image(), is injectingobject-positiondirectly into thestyleattribute acceptable when not already defined, or would you prefer only exposing CSS custom properties (--wp--focal-point-x/y) anddata-focal-pointattributes to prevent unexpected layout shifts on existing themes?Looking forward to your thoughts!
andrewserong commentedon Oct 14, 2026
Thanks for the ping! Also just an FYI to @ramonjd who's also been working on the media editor of late.
As for adding in a focal point selector, I'm not convinced that we're ready to add this feature in core yet. The media editor is progressing well, but still has many parity gaps between the classic / existing editor in core, and I think adding in support for focal point control to all images is a bit premature.
Additionally, media fields are in the process of being refactored (#83368), and it isn't clear to me how and why we're planning to store global focal point information alongside the media item itself. (E.g. if we're storing a focal point, why only one?)
As a feature (right now) this seems pretty niche to me, but I think it could be worth revisiting further down the track, once the media editor in core has been replaced with the new editor. But before then, adding focal point to just the new media editor would create an odd imbalance where the feature only appears in some situations.
In the meantime, if you're keen to continue working on the feature, I think it's a reasonable idea for a plugin — that might also help get a better sense of what the user expectations are surrounding how it all works.
ramonjd commentedon Oct 15, 2026
Agree with @andrewserong - for attachment-level defaults it'd be a feature we could add after there's a stable replacement for the current media editor (in the media library), and for the Fields API to settle, which allows registering fields.
Another thought I had was that it could be approached from a block supports standpoint too.
Image, Cover and Media & Text each have their own
focalPoint. #73113 proposes to add it to Featured Image.A shared block support could unify them first. That would address blocks, and not accompanying generated thumbnails however.
Mind you, I'm coming at this from a block editor perspective. Any proposals to add this to the media library could be done in a core trac: https://core.trac.wordpress.org/newticket