@nikolay shapovalov : sorry for that, after nearly 2 month, I have presume it be ok for you ...
@nikolay shapovalov :
"Do you think we can add interface for these new methods?"
I don't know ...
The purpose of the RM is simply to separate the processing/generation of the derivatives from the various validation/authorisation operations linked to this generation.
@oily : I don't know either what @deviantintegral want to say, when it create the issue.
I just done my best when @smustgrave ask me to update summary to the "good template"
I have my use case "with mediaContextualCrop, we want to create a new image delivering methodebased on 80% of the ImageStyleDownloadController" for the others I don't know their motivations.
With the good patch, it works better
Reroll patch for 10.0.x
Can you check the MR, if changing parameter type is enought
drdam â made their first commit to this issueâs fork.
The "Null" label is created by the "->label()" method because at this stage (node creation) the "title" ( targeted by the method) is null. I.E. there is no "saved title" for the current entity.
fixed in 1.0.0@alpha2
fixed in 1.0.0@alpha2
Create MR for 11.x and reroll #16 on it
+1 for closing
Released in 2.1.4
For test coverage, I don't what it need to be tested, it just code management, no new functionnality.
I have rework the "association loop" for trying to manage mixte between not-upscaling / upsaling.
The association between size and imageStyle are "not optimal" because of #10 and #11, but it doesn't really matter because the derivative will be the same, just not in the "best folder" on the disk
Exemple as a native src-set image :
The "tiniest" size ( 100px) better fit for the thumbnail image style are associate with the "wide" image style because it's the "last" of the list.
The problem is that the imageStyle stack does not provide a simple way of finding the âexpected size of the derivative if the source image is large enough not to be upscaledâ for an image style.
In fact, it is not possible to âclassifyâ image styles by this âexpected sizeâ and therefore to find the âsmallestâ image style that is most suitable.
The anomaly is present in native ResponsiveImages too.
In fact, this case is not natively covered by nativ responsiveImage because of the possible mixe between "allow/no-allow" upscaling.
But if you editing the media, you change it on all its usage
OK for RTBC
drdam â changed the visibility of the branch 3496234-better-handling-of to active.
@deepali sardana : thanks for the merge Request, but I'll close it, because there is a lighter way to acheive that.
Merge Request available
drdam â changed the visibility of the branch 2685905-refactor-imagestyledownloadcontroller-so to hidden.
drdam â changed the visibility of the branch 3228376-cant-delete-a to hidden.
grimreaper â credited drdam â .
It's the case
Can you make the MR for the 2.x branch ?
the 1.x branch are minimaly maintained now
thanks
released in 1.0.0-alpha1 â
grimreaper â credited drdam â .
RTBC
diag : the point here is the same as many (many) other Crop/Image anomalies, Drupal Core don't know how handle multiple "version" of the same derivative ( I.E. couple ImageStyle x ImageFile ).
There is no real solution base of maintening the current implementation of the "focal point preview" feature.
2 solutions are possibles :
- Simulate the rendering (by CSS/html style manipulation) instead using the full derivative generation
- Add some "context" to the derivativ generation (I.E. hack some core process in order add this feature)
MR created
drdam â changed the visibility of the branch 3214798-crop-effect-can to hidden.
You need to install the 2.3 and make the db update first, and after update to 2.4.
If it's the case, maybe a better "message/communication my be better"
When using media, you need some configurations :
- in the "host content type" (node)
- in the form mode : media library as widget
- in the view mode : display media with a specific render mode "foo"
- in the "media image"
- in the form mode : the image widget crop widget
- in the view mode "foo" : render image with a specific image style using a crop
Did you check about media_contextual_crop â ?
This module provide a way to wire crop and medias
Waiting completion of #3293782
drdam â made their first commit to this issueâs fork.
I have split the doTestFileUriAlter method in order to have "clean" code separation
Merge in 3.0.2
Fix reviews & add test
I think this two issues (phpstan & phpcs) may be merge BEFORE other merge resquests
Ok for me
And at first sight it looks like methods: getCropFromImageStyle, getCropFromImageStyleId, cropExists, findCrop should be moved away from CropInterface. Maybe we need to make bigger refactor to impove developers expirience.
I totaly agree, but without knowing the history of the implementation, it's not clear how far the refactor can go.
The question is whether the current behavior is âintentionalâ or a case that was not anticipated.
Thanks @hartsak, I pass the ticket to RTBC
We are hosting on Pantheon which sits behind the Fastly CDN. Sounds like disabling flush_derivative_images is recommended with this setup?
that's what I would recommend. The "derivative cache" are supported by the CDN, so no need to "force drupal" to handle it.
I've read this a couple of times and I think that you are missing the word "no" in the above sentence, that "... there is no way to detect...". Can you clarify ?
You are right, I fix my message. There is no way
Fix in release 2.0.7
I have create a second merge-request for 2.x branch
Fixed in release 2.0.6
drdam â changed the visibility of the branch 3270150-can-media-library-2x to hidden.
In Drupal 10.3+ , we have a new static method to do that
$converted_original_uri = ImageStyleDownloadController::getUriWithoutConvertedExtension($original_uri);
I'm open a merge request to add this
As a note, I think it's necessary to question the need to have 250 different image styles in the project, just for the issue of storage space consumption (green-it / eco-design / cost / greenwashing...).
Did you use sort of CDN or S3-like storage services ? In this case, the disabling of the flush_derivative_images, in settings are the way to fix the issue.
In crop entity perspective, there is way to detect if the newly created crop is created from a "new uploaded image" or because someone change the ImageStyle configuration to adding crop in it (and a derivative image already exist for the source and must be flushed).
I have made the MR on 1.x branch
You can check : https://www.drupal.org/project/crop/issues/2617818 âš Support multiple crop variants per URI and crop type Needs work
or the media_contextual_crop â collection
I agreed for breaking the loop for performance issues.
If the style have 5 effects and if the crop are the first, there are no use to check all others.
Seems like https://www.drupal.org/project/crop/issues/3293782 đ Crop API is not appending a hash when the image styles are converted to WEBP Needs review
Check https://www.drupal.org/project/crop/issues/3228376 đ Can't delete a crop type Needs review in order to purge and delete all crop entities
[replace patch by a cleaner one]
Some update here and a "redo" of the patch for Drupal 11
Fixed in 1.1.4
Waiting ImageWidgetCrop Drupal 11 release
Released in 2.0.2
Released in 2.0.5