#Amsterdam2019

Adding a request to also look at this issue for the new 6.x branch.

Would love to have a little more control over the >3,000 daily simple_oauth errors in the logs on our high volume site.

@cjunior already MR is available please convert your patch into the MR.

Uploading updated version of patch

@chhavi.sharma, thanks for converting to an MR. Unfortunately, the changes to the test file were lost in the conversion. That is probably why the tests are failing. Can you add those changes to the MR?

Seems to have lost test coverage.

Applied the changes of patch manually and created an MR against 11.x branch.

As I noted in #9, this certainly does not meet the definition of critical → and I don't believe it fits major either.

Hey guys. I'm attaching here the latest version of this fix.

Wondering if this improvement will also work for images stored in cloud storage options such as S3, Azure, etc. via modules such as the S3 File System → and Flysytem → ?
Once the images are stored in the external cloud storage, will this still work in capturing exif data on demand for already loaded/saved images and media?

Usability review

We first discussed this issue at 📌 Drupal Usability Meeting 2024-09-27 Active . The link to the recording is https://youtu.be/cWtwA63z-IE. For the record, the attendees at the usability meeting were @amazingrando, @anmolgoyal74, @benjifisher, @rkoller, @simohell, and @zetagraph.
We revisited this issue at 📌 Drupal Usability Meeting 2024-10-04 Active . The link to the second recording is https://youtu.be/JPxvcpNXY0Q. For the record, the attendees at the second usability meeting were @AaronMcHale, @avani.bhut, @benjifisher, @rkoller, @shaal, @simohell, and @zetagraph.
Yesterday we revisited this issue for a third time at 📌 Drupal Usability Meeting 2024-11-15 Active . The link to the recording is https://www.youtube.com/watch?v=8DqSpKVK768. For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell.

After taking a look at the current state of the MR, we’ve mainly focused on the points raised in #138 → , since those cover most of the remaining open questions from an UX perspective, and we’ve assessed their validity and relevance.

1. First, we went through the different scenarios that might happen aside a successful update:

Scenario A (No changes and therefore nothing to update):
It was considered as a nice to have but optional, not a blocker at this point, since it is a difficult task to determine if a media item is changed or not. So we leave it up to the people working on this issue if they want to cover scenario A already within the scope of this issue or if they would prefer to move it to a followup issue. Our consensus for the status message was:

Nothing to update. Media item [x] remains unchanged.

In contrast, the other two scenarios should definitely be covered within the scope of this issue, since in both cases content might be removed and/or lost. As Laura Klein stated in her book “Build Better Products” -

Good design doesn’t lose data or state just because a user has performed an action in a surprising way.

. To prevent any potential data loss, like missing thumbnails in the frontend, the group agreed on adding a confirmation step to each of the two scenarios. So that the user becomes aware, that something is off and that they might experience a potential subsequent data loss, when the metadata of a media item is updated from the source. In the case of remote media items, the source might simply be temporarily unavailable due to an outage, just as, for example, source files where the file folder is being mounted from a file system and that file system is unavailable - without a confirmation step, the data would get removed when the metadata is getting updated. Our recommendation for those two cases are as follows:

Scenario B (The local source of the media item is missing):

Description:
The source file for media item [x] is missing, unable to refresh.

Buttons:
Remove thumbnail
Cancel

Status message after...
…the Remove thumbnailbutton is clicked: Thumbnail removed for media item [x].
…the Cancel-button is clicked: Canceled. Media item [x] remains unchanged.

Scenario C (The remote media item the source is unavailable):

Description:
The remote source for media item [x] is unavailable.

Buttons:
Retry
Cancel

Status message after...
…the Retry button is clicked and the refresh was successful: Updated metadata on media item [x], while if the refresh fails, the confirmation form is shown again.
…the Cancel-button is clicked: Canceled. Media item [x] remains unchanged.

It has to be noted that we had a clear consensus about the importance of having a status message after a button on a confirmation form was pressed. There is always the possibility that someone is clicking a button on a confirmation form, either absent-minded or by a stray mouse click. The subsequent status message keeps the user in the loop and informed about the made choice.

Aside from the refresh of a single source, there is also the case of refreshing more than one source at once via bulk actions. Question is, how to handle things with more than one case of scenario B, more than one case of scenario C, or even a mix of both? You can’t run someone through a chain of tens of single confirmation pages. One option is that the confirmation pages for scenario B might be combined into a single page, the same as the confirmation pages for scenario C, or all confirmation pages for scenario B and C might be combined into a single confirmation page. But due to the fact that there is no existing UI pattern in Drupal Core yet, we don’t want to hold back the current issue, and we would recommend moving the bulk refresh of media items into a follow-up issue.

2. In regard to the microcopy, we considered the term Refresh as suggested in #10 → to be the more clear and accurate choice. Update is a loaded term, in combination with the fact that all the other options (edit, delete, translate) on the Operations drop-down point to forms on other pages. That way, the user’s assumption might be that Update also points to a dedicated page or dialogue that entails an active manual interaction. In addition to that, all the other options in the Operations drop-down are single-worded verbs. Therefore, we would recommend the following change to the Operations drop-down option:

Update metadata -> Refresh

The term metadata is also sort of an abstract and ambiguous term in regard to its scope in this context. It is not clear what kind of data is getting refreshed by the option Update metadata. Is it only the associated fields or also something like the thumbnail, as already mentioned in the issue summary. To make things more explicit we would recommend the following change to the bulk action option label in the follow-up issue (again in line with the suggestion in #10 → ):

Update metadata -> Refresh from source

3. We also checked if there were already help topics for the other options available on the media page, but we were unable to find any. So we had the consensus that it wouldn’t be necessary to add any instructions about the Refresh option to the help topics at this point.

4. One additional detail we’ve noticed during our testing. If you are manually replacing an image in the file system, then hit the Update metadata option, the thumbnail is properly updated on admin/content/media. But if you now click the Edit-button for the media item and then click the link to the source file, the old replaced image is still shown. Could that be a caching issue? We haven’t had the time to investigate in more detail.

I am setting the issue back to Needs work and remove the Needs usability review tag. If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.