We're seeing a similar problem as the video at the top of this issue - I'm referring to it for the nice video.
https://www.drupal.org/node/2842260

In our case the image stays the same until you actually click preview after having changed the focal point and saved. So if any of our editors want to change where the focal point is set, they need to:

1. Edit the article where the image is displayed
2. Click edit to open the media entity form
3. Move the focal point, click save on the media entity
4. Click edit again to open the media entity form, click Preview that somehow forces regeneration of the image styles
5. Profit

The goal is naturally that they can jump directly from 3 to 5, skipping the Preview step.

This problem is reproducible on several environments - and I guess it makes sense to mention that the image field itself is not marked as translatable at the moment, even though the media entity has fields on it that are translatable.

To try and solve this problem I first upgraded crop from 1.0 to 1.2, and then focal point from 1.0.0-beta4 to dev-1.x and then I added the patch from https://www.drupal.org/node/2842260 - and none of those updates seemed to help.

Any ideas?

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

badrange created an issue. See original summary.

bleen’s picture

Status: Active » Closed (duplicate)

This seems to be a duplicate of #2842260: Updating the focal point position does not update the cached image for anonymous users

Can you please add your comments to that issue so that we can fix this all in one place.

badrange’s picture

You are right bleen that I should have made a comment in that issue. I actually created this one after trying out the patch in #2842260; what happened for me was that I got new itoks but the images did not change after moving focal point until previewed them after first having saved a new focal point.

badrange’s picture

Status: Closed (duplicate) » Active

Reopening this after discussion in #2842260.

dermario’s picture

We are also facing that issue. My first research pointed me to focal_point_entity_presave() where it comes to the following condition:

<?php
      if ($value->getType() == 'image' && $entity->hasField($value->getName())) {
       // skip ....
      }
?>

In our case we do not have a field of type image, but a field of type entity_reference, as we are referencing media entities.

awolfey’s picture

I'm also seeing this. When I edit the media and replace the image, the focal point is used in the new image in the media preview on the node edit form, but further editing of the media does not update the focal point.

bleen’s picture

@awolfy I'm not 100% following ... can you put a step-by-step to reproduce this? Im assuming you are using media library (not a generic image field)?

vgadjali’s picture

Hello! I was seeing this issue as well, but it turns out it's a browser cache issue.

I am using media library with image styles and focal point. If you change the focal point and don't click preview, you need to refresh the cache on the image.

To recreate the issue:
Open the media item in the media library, and adjust the focal point +. Save without clicking preview. When you view the page where the image is being used, the image will not have the new focal point applied.

My resolution:
I was able to resolve it by flushing image styles (Administration/Configuration/Media/Image Styles, click the arrow of the image style that the image is using > Flush), then viewing the page on an incognito window.

Hope this helps!

aaron.ferris’s picture

I'm seeing this also, although preview doesn't seem to work either. The work around is to remove and re-add the image which is far from ideal UX.

Edit: as above flushing image styles also works.

enjoy_interpol’s picture

Same problem. In my case, it was because of webp module. A patch resolve the issue with this module : https://www.drupal.org/project/webp/issues/3153137

heddn’s picture

We are seeing this issue, but only with Panthon. Not on localdev. I can't prove it yet. But it seems like caching layer of pantheon is causing our issues.

heddn’s picture

Status: Active » Needs review
StatusFileSize
new816 bytes
new816 bytes

I couldn't reproduce the problem on local. And I'm not fully convinced this 100% solves the problem. As I mentioned in #11, I could only reproduce this on pantheon. And even there it didn't seem to be consistently producible. But the actual changes in the patch make sense and seem to solve the problem, albeit only on pantheon.

jeffm2001’s picture

Version: 8.x-1.x-dev » 2.x-dev
StatusFileSize
new849 bytes

Re-rolling this patch for 2.x

robbdavis’s picture

I am seeing this behavior also. I am using media-library_media_modify so that I can alter the focal point only on this particular reference field.

When I go to configure the block where this image exists, then try to change the focal point, the change only applies if I view the preview first.

The patch from 13 does not seem to fix.

robbdavis’s picture

Just did some more testing and the TLDR is that the only way the focal point change applies is if the preview image option is enabled AND the user actually previews the image.

If preview is not viewed, the changes do not apply.

This is on my local machine with caching off.

martijn de wit’s picture

jim.shreds’s picture

No cacheing enabled.
Previewing image after focal point change did nothing and flushing cache also does nothing.

datawench’s picture

FWIW, this is happening for me, too, on both local (ddev) and remote (AWS environment). The specific context is media library. The focal point widget appears and is operable when adding an image in the media library modal, but the setting doesn't "take" unless you edit the image and reset it. I observe that when editing, I'm editing the media entity directly, rather than through the media library wrapper.

Drupal is at 10.1.1. The suggested patch doesn't appear to help, nor does flushing cache.

gwenweb’s picture

The patch didn't work for me either. I'm using Drupal 9.5.9 and attempting to enable the focal point feature by modifying the media after uploading it.

I also gave this a try: https://www.drupal.org/project/focal_point/issues/2906631#comment-15052967 but unfortunately, it doesn't appear to solve this issue either.

brunomolica’s picture

StatusFileSize
new840 bytes

I made some adjustments in the ".module" file and it worked as expected for me.

gwenweb’s picture

I've tested the focal_point_2906631.patch on Drupal 9.5.9, and it's working fine! I'm not marking it as "Reviewed & Tested by the community" because it would be great if someone could verify that the cache is flushed only for the updated image (not all images on the website).

cedric_a’s picture

Just a precision on @gwenweb comment (we discussed the patch together at DC Lille) she mean that we need someone to review the code to ensure that only image styles using the updated focal point are flushed.

rayand’s picture

@brunomolica your patch Failed to Apply. Can you fix it please? I will test this patch with D10 when it's done.

den tweed’s picture

StatusFileSize
new700 bytes

Rerolled patch in #20
Applies now but couldn't test due to unrelated error

siramsay’s picture

Status: Needs review » Needs work

I am getting the same as #18
Drupal 10.2.3
Focal Point 2.0.2

Using with Media with the media library edit button. The media library edit button opens the media/22/edit page in a modal.
Focal point does save, and the preview does work in the same manner as described in the original post.
You can visit the /media/22/edit from the /content/media page and the focal point is saved, and the preview is working as above.

I need to flush the image style for the crop to take effect.

I am using it with in a Responsive image style.

ahmad abbad’s picture

I'm facing the same issue that was mentioned in #25 but I'm using Drimage.

mohammedodeh’s picture

StatusFileSize
new759 bytes

Rerolled patch in #24
to support Image Optimize (Webp)

siramsay’s picture

Status: Needs work » Needs review

Beautiful. I forgot to mention that I was using an optimization pipeline with WebP in my comment yesterday, and had thought this may have been the issue since.

This works on my site as described by the original poster @badrange

Now wondering if we should open a new issue or work on this one, as the workflow is strange if you want to use the preview button. I.e you need to click save on the modal which closes it and then re-open the edit to use the preview.

rayand’s picture

I have tried this patch: focal_point_2906631-24.patch and I use drupal 10.2.2. @Den Tweed . It work strangely. I change the focal point on my media type edition with one click on img but it doesn't change. BUT, if i double-click on my media-type to change focal point, a field appears and i save. I go on my content, img doesn't change but after i change my current breakpoint, img is update. If i go in other page and i back, img is not update again.

watergate’s picture

I stumbled upon the same problem and can confirm that the patch solved our problem.

arialblack’s picture

#27 works fine, solved my issue with .webp, thx!

alexiane dapsens’s picture

Drupal 10.2.2
Focal Point 2.0.3

The patch #27 not working for me. After changing focal point, I need to make a clear cache to have the updated image in DOM and even then it's still the old image that's displayed. And if I refresh the page, the old image in displayed & is in DOM (the cropped image no longer appears anywhere).

kissfm’s picture

StatusFileSize
new793 bytes

Updated patch #13

amandeep123’s picture

"Hi @bleen, @Rajeshreeputra , I had replicated the aforementioned issue, implemented the necessary patches, and thoroughly tested Patch !24. It is now functioning properly, resolving the previously mentioned error. We can now move the ticket to RTBC. +1. Please review

akz’s picture

This is my opinion/review on the available patches:

Patch #13, also contains a code style enhancement ([$x, $y] = explode(',', $focal_point);) which a) is already implemented in module's latest version (2.1.0) and b) is not related to this issue. Patch should be ignored, as patches should only address one issue at a time.

Patch #33 is the correct version of patch#13 (without the code enhancement), but it does not solve the problem (at least in my env: Focal point 2.1.0, Drupal 10.2.7).

Patch #20 solves the aforementioned problem. This is the one that should be accepted. @gwenweb I verify that only the updated image gets flushed/regenerated and not all images.

Patch #24 is practically the same code as in patch#20, only the paths to the module file are different. People complained that patch#20 could not be applied to their envs, hence the re-roll with different paths.

Patch #27 is the same code as in #20 and #24, plus it addresses the issue of updating webp generated images as well. Yes, it solves the problem with the webps, but it falsely assumes that there are webps to update. Webp and ImageAPI Optimize WebP modules are not related to this module and they are definitely not prerequisites for it. So, any fix related to webps, should be addressed by those modules' end and not from this one. This patch should be ignored.
- Webp module issue/patches: https://www.drupal.org/project/webp/issues/3153137
- ImageAPI Optimize WebP module issue/patch: https://www.drupal.org/project/imageapi_optimize_webp/issues/3213379

martijn de wit’s picture

Thank you! ok then let's set focus to #20.

Hide all other files...

sokru’s picture

Status: Needs review » Postponed (maintainer needs more info)
Issue tags: +Needs steps to reproduce

Unfortunately I was not able to reproduce the issue with steps mentioned on the issue summary.
I was using the page cache + Drupal 11 + focal_point 2.1.1 (with #3462165: Preview results in Error: Call to a member function getDefinitions() on null) + Crop API 2.4.
So even without clicking preview link the page cache got MISS and the image got updated also for anonymous users.

I'm marking this as postponed until there's steps to reproduce on vanilla Drupal installation.

Regarding to #27/#35 about webp support, core has supported webp -format out-of-box for quite long time (#2340699: Let GDToolkit support WEBP image format), so if this issue is still valid, we should make sure it works with webp format.

jeffm2001’s picture

StatusFileSize
new1.25 KB

This is still a problem we're having. I can't reproduce it locally, but it happens on Pantheon. I suspect that using a CDN makes a difference.

None of the patches in this thread are solving this issue for me on their own. This new patch is a combination of the approaches in #27 and #33, which is working for me if I also add patch #4 from crop #3293782: Crop API is not appending a hash when the image styles are converted to WEBP

Leaving status as Postponed, because I can't actually provide definitive steps to reproduce the issue or explain exactly what's happening. Just wanted to share what's working for me.

yevko’s picture

I wasn't able to reproduce the issue.

  1. Install Drupal 11.0.1 with the standard profile
  2. Install Focal point with composer require drupal/focal_point (gets 2.1.1). Enable it.
  3. Enable Media library
  4. Change widget to Image (Focal point) foe the Media library form, leave default settings
  5. Configure a new image style to use Focal Point Scale and Crop
  6. Use this image style on the Article's image field.
  7. Create article, add image and save with default focal point
  8. Edit article, move focal point, save.
  9. It gets re-cropped.

Save result with adding a new Media reference field and changing a focal point in the media library after attaching the media t the article.

yevko’s picture

Issue tags: +Barcelona2024
tommasorandazzo’s picture

I am still experiencing this issue with:

  • Drupal Core 10.3.5
  • Focal Point 2.x-dev + Patch #38 above
  • Crop 2.4.0 + Patch #14 from the related Crop API issue

Here are my steps to reproduce:

  1. Add an Image media type, with image styles.
  2. Upload a new Image media and save.
  3. From the full Media Listing (/admin/content/media), edit the new Image media. You should be redirected to the entity's full edit page, where the preview is displayed correctly.
  4. On a form using the Media Library (I'm adding a block in Layout Builder), select your image. The widget should populate the image in the field.
  5. Go to edit a media item from the Media Library widget, and the preview image does not render correctly. I am noticing that the image src is correct (devtools displays its preview), but still not rendering.
rajab natshah’s picture

Priority: Normal » Major
gwenweb’s picture

I tested the patch from comment #20 on Drupal 10.5.9 with focal_point 2.1.2 and cweagans/composer-patches.

The patch available on this issue uses paths like docroot/modules/contrib/focal_point/focal_point.module, which are relative to the Drupal root.

When using cweagans/composer-patches, patches are applied from the package root (i.e. the module directory itself), so those paths cause the patch to fail with "can't find file to patch".

If you're using cweagans/composer-patches and the patch fails, you need a local copy with paths relative to the module root:

diff --git a/focal_point.module b/focal_point.module
--- a/focal_point.module
+++ b/focal_point.module

instead of:

diff --git a/docroot/modules/contrib/focal_point/focal_point.module b/docroot/modules/contrib/focal_point/focal_point.module

The actual code change works correctly on 2.1.2 — the fix flushes the image cache after saving the crop entity, so derived images are regenerated immediately when the focal point is updated.