🇨🇷Costa Rica @rigoucr

looks good

rigoucr → made their first commit to this issue’s fork.

Thank you everyone, and sorry for that typo :/

rigoucr → made their first commit to this issue’s fork.

I'm Providing a Merge request with a fix to this issue, it is basically replacing the [] empty array with empty string '' for the file_validate_extensions parameter over the file_save_upload fucntion, this will ensure that the module keep working as expected in drupal 10.2 + versions and this was caused be this core issue: https://www.drupal.org/project/drupal/issues/3420802 🐛 file_save_upload broken by 10.2.x Needs work

you can get the patch file directly from the merge request: https://git.drupalcode.org/project/file_management/-/merge_requests/4.patch

rigoucr → made their first commit to this issue’s fork.

rigoucr → created an issue.

I took a look over the propoused code and make sense but I do Have a question , Does it makes sense to keep the support for Drupal 8 and Drupal 9?

The automated patch has been applied and also we dropped support for d8.

rigoucr → changed the visibility of the branch project-update-bot-only to hidden.

rigoucr → made their first commit to this issue’s fork.

Providing patch file for version 2.0.x

rigoucr → made their first commit to this issue’s fork.

Provinding static Patch file

rigoucr → created an issue.

I Took patch #36 and replaced the old (deprecated) hook gnode_field_widget_media_library_widget_form_alter with gnode_field_widget_single_element_media_library_widget_form_alter and also now using this route , entity.group_content.create_form instead of entity.group_relationship.create_form.

So, MR117 it's a reroll of #36

rigoucr → made their first commit to this issue’s fork.

Patch #3 worked for me and also de code makes sense , thank you!

Solved

rigoucr → created an issue.

Drupal CS issues fixed and also main module files renamed to match module folder name

rigoucr → created an issue.

Bingo , it was it

That's Weird , I tried it on local from scratch and it was working , but I think that has to do with the way in that gitlab automatically build the patch files , I'm proving a patch that I build in local following the official guidelines:
https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... → , for us to try it again

nagy.balint I agree with you , I think option A is the best approach, so I already sent the new code to meet that requirement

Thank you for your Feedback @nagy.balint , I applied those suggestions into my code .

Providing a very basic views integration in merge request #3

it would be nice to have it for the version 3 of the module, updating version tag to : 3.0.x-dev

The Submitted code is working as expected

rigoucr → created an issue.

Fix Merged , closing ticket

rigoucr → created an issue.

Hi @ccjjmartin thank you for your feedback, I did it in that way because I thought that in that will be easier to remove in the future (this is a tmp solution for the real issue ) , but you made me think about about it and I'm changing the approach , I'm moving the code into the main .module file , that will be easier for the maintainer to remove this code later when is not longer need it .

And to answer your question , yes , the image styles are not being flushed when the crop entity gets updated .

Coming back at this because this was not really my issue , I dig a little bit more I discovered that I was having some issues with crop module. So I created this issue https://www.drupal.org/project/imageapi_optimize_webp/issues/3362476 🐛 Webp Image not being updated when the Focalpoint/crop entity is Updated Needs review , so more details there

Switching status to needs review, I provided the possible solution for this issue , as you can see into the Merge request , this provides a new submodule `imageapi_optimize_webp_crop`, so , to test this , go into the merge request, extract the patch from it , apply it into your code and enable the new submodule.

Why a submodule,? well when the core issues that it's related to this is done , you could easily remove this from the code base .

rigoucr → created an issue.

I'm experiencing exactly the same issue:
drupal version: 9.5.8
module version: 2.0.0
imageapi_optimize_webp_responsive module : enabled.

steps to reproduce:

- Create a imagepi pipeline (configure it as global)
- add to that Pipeline the WebP processor
- now Add the Resmush.it processor
- Save your config

- Now go to any existing node with a media field, update the image (to try to regenerate the img style)
- Now go to your node FE , you should be able to see your image ,but if you inspect the markup you can noticed that the image being shown is original image uploaded by the user not the webP

Thank you @brtamas the patch worked for me!, There error was removed , code makes sense for me and the module stills working as expected for me, so I'm marking the Issue as RTBC .

Sorry I uploaded the wrong version of that patch in #4, now uploading the right one

Creating a patch for being able to apply it via composer ( Just with one line of context `U1`). The Merge request and original patch makes sense and work when you use them with the `dev` version, but when you try to apply this to the none-dev version the patch doesn't apply, more info here about how to create patches for .info.yml files.

https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... →

Creating a patch for being able to apply it via composer ( Just with one line of context `U1`). The Merge request and original patch makes sense and work when you use them with the `dev` version, but when you try to apply this to the none-dev version the patch doesn't apply, more info here about how to create patches for .info.yml files.

https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... →

And since is the same patch content but with less context I'll keep the RTBC, thx.!!

The patch Reroll in #7 worked for me, thx @afsch