Skip to content

Gutenberg-Based Media Editor: Add Media Level Focal Point Selector #75221

Open

Description

@eric-michel

What problem does this address?

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.

What is your proposed solution?

We're currently using this excellent plugin to implement this functionality in our sites, and it's critical to a lot of our custom carousel and gallery ACF blocks. With @andrewserong's work on recreating the media editor in Gutenberg, now is the perfect time to fold this functionality into core.

Activity

  1. andrewserong commented on Feb 4, 2026

    @andrewserong
    Contributor

    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 👍

  2. fontaholic commented on Aug 16, 2026

    @fontaholic

    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. :)

    Image

    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.

  3. Ta5r commented on Oct 14, 2026

    @Ta5r

    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:

    1. 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.
    2. Media Fields & DataViews: Added a focalPointField in @wordpress/media-fields utilizing @wordpress/components's FocalPointPicker and registered it into ORDERED_MEDIA_FIELDS.
    3. 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:

    1. 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.
    2. 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?
    3. 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?

    Looking forward to your thoughts!

  4. andrewserong commented on Oct 14, 2026

    @andrewserong
    Contributor

    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.

  5. ramonjd commented on Oct 15, 2026

    @ramonjd
    Member

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Feature] MediaAnything that impacts the experience of managing media[Type] EnhancementA suggestion for improvement.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions