tonypaulbarker → created an issue. See original summary → .
Patched and tested. This looks good to me.
Postponed until we are down the way with https://www.drupal.org/project/ai_initiative/issues/3545343 🌱 AI Media Discovery: Investigate JavaScript scanners as a method of extracting information from images Active
The main reason is it confuses contributors, if someone sees a patch they may start contributing fixes via patches again rather than the MR. It then becomes hard to track which changes have been made and whether they have been pushed to the MR or not. It's also very frowned upon in the core queue as it can confuse the needs-review-bot which will put an issue into needs work if the patch no longer applies even if there is an MR, therefore I usually discourage it.
Good to know! Thanks :)
I see the guidance → (Making changes locally point 18) still says this is okay: "Consider uploading a patch file to the issue in addition to making a merge request, especially if your changes solve a problem. Although the recommended way to contribute source code changes is via merge requests, patches can be easier for others to install via Composer."
Including the file here.
@acbramley thank you for resolving those conflicts. Regarding guidance in #107 - any reason for us not to upload a patch from the diff here for folks to use ( as was the case with previously in #79 ) ?
+1
+1
tonypaulbarker → created an issue.
+1
tonypaulbarker → created an issue.
+1
tonypaulbarker → created an issue.
+1
I was there
tonypaulbarker → created an issue.
I was there
tonypaulbarker → created an issue.
+1
+1
+1
+1
+1
+1
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
Thank you for this work everyone. As #95 it looks as though old patches cannot apply to 1.12.0. Is this ready for a new patch after the latest commits from @RajabNatshah or still needing some more work before review?
zoocha will → credited tonypaulbarker → .
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
Was there
Forgive me if I don't have the logic correct in my mind.
If we add a conflict and release it, what will prevent projects getting the latest resolved version that contains the bug but not the conflict entry?
Interesting that @gt-harrison also experiences an issue with media dependencies.
Further insights:
In the LocalGov Drupal case that @millnut and @stephen-cox has raised, test results are certainly different between 11.1 and 11.2.
We might make some distinction between tests and a full installation. One reason is that in test scenarios container rebuild doesn't appear to get the opportunity to run between steps at all?
Moving image type configuration to 'install' directory instead of 'optional' means that tests pass.
Has something changed in 11.2 with configuration validation?
I could not find any deprecation notices running the same in 11.1 and I couldn't pinpoint a change that tallies with observations.
I wondered if the suite of changes mentioned in https://www.drupal.org/node/3362879 → have some bearing - that some new validation can have been activated that misses the 'optional' cases. Something with media type validation?
tonypaulbarker → created an issue.
I am also was there
I was there
I was there.
I was there.
tonypaulbarker → created an issue.
Created an issue for this against the Github project https://github.com/localgovdrupal/localgov_guides/issues/194
Thanks for raising and reviewing this @joachim @julio_retkwa . Development of this project is currently taking place on Github and mirrored here whilst the migration to drupal.org is taking place. I have created an issue against the Github project so we can see about getting the change made there https://github.com/localgovdrupal/localgov_scarfolk/issues/52
Created an issue for this against the Github project https://github.com/localgovdrupal/localgov_scarfolk/issues/51
I was there
I was there.
I was there
I was there.
I was there.
I was there.
I was there
+1
This is a duplicate of https://www.drupal.org/project/localgov_contribution/issues/3531046 🌱 Tech Drop-in, 19/06/2025 Active where other people have commented, we need to ensure credits are correctly assigned.
This is a duplicate of https://www.drupal.org/project/localgov_contribution/issues/3531046 🌱 Tech Drop-in, 19/06/2025 Active where other people have commented, we need to ensure credits are correctly assigned.
I was there
I was there
@rachel_norfolk I don't think so. My concern is about the frequency of these transactions so optimising and marginal gains seem worthwhile where they can be made. There are already good measures in place. Actions (if any) will come out in testing and review.
@wim leers
A lot of things are encouraging here but this I'm not so sure about.
we don't need to support the image_desaturate (grayscale), image_rotate etc. effects, because we just do them in CSS nowadays
A consideration is how will this appear in search engines like Google shopping and Google images?
What's in that ~5% and does it matter?
To me this reads like a contradiction. Especially without designs, wireframes or even just links to prior art elsewhere. Could you please elaborate?
@wim leers
In the absence of some designs and wireframes just for now I would recommend looking at Wix Studio image editing tools (see https://support.wix.com/en/article/studio-editor-editing-and-customizing... ), iPhone native image editing for UI of image adjustments. These UIs are intuitive and easy to use even if the Wix optimisation is poor on the front end. iPhone gives us an easy way to make adjustments and then save adjustments to the original 'entity' or to create a clone.
Cropping is the real pain point. In a recent focus group, several people told us that they use Photoshop or similar to pre-crop their images instead of using Image Widget Crop because they find Drupal too confusing and they can't tell what crop will be used in what context.
Adjusting brightness and contrast in an image style is of little use to an editor - these operations should be able to be set on a per image basis within the media library.
I think that there are some operations where we should be able to generate a clone of a media entity, for example @marcus_johansson wonderful work on image to image AI transformations https://www.drupal.org/project/ai/issues/3531212 ✨ Create Image-To-Image operation type Active https://www.youtube.com/watch?v=ekyu52ARPdU - given the operation is available to our site, we should be able to click to process the image at the point of upload and save to a clone as well as the original if we want.
Images used in the pages of content are different to teasers used in views. Giving people control of instances where views is used is much more difficult. But, if we know that a content context requires a 16:9 image we need a way for editors to intuitively be able to control a 16:9 crop at the point of placing it in the content.
What I envisage is that we give the impression of transforming by leaving the original media entity intact and referencing the entity and / or file from a transformation entity that contains the transformation data and can in some cases - like the AI transformation where processing is too heavy to do on the fly - also save the derivative as a file.
If combined with developers setting expected / allowed aspect ratios (or other transformations) on media fields this could make it easy for editors to crop, maintain consistency and also help with the views teasers scenario.
tonypaulbarker → created an issue.
zoocha will → credited tonypaulbarker → .
I attended
tonypaulbarker → created an issue.
I attended.
I was there.
I was there.
I was there.
I was there.
I was there.
I was there
This is a nice idea. Developers should not be editing config live on production either, really so they should also see a warning. The simple environment indicator module already warns of the environment. Perhaps this could be used in combination with that.
I should probably not only see this warning on forms but as soon as I land on the config, views, block layout or metatag area.
It feels as though a check of every form could be expensive.
How about a block with a customisable message that is placed by checking against a list of pre-defined, customisable routes? It may (or may not be) as straightforward as /admin/structure, /admin/config and so on.
That makes me think it would be worth trying less opinionated image styles that rely on sizes - so that they work better across different themes, even if they're less customized for drupal_cms_olivero.
Using sizes over breakpoints doesn't provide the missing key piece of information required to perform optimised calculations: the container sizes in the theme CSS are unknown.
How much is it possible for the art direction to actually work across arbitrary different themes though?
All of these image styles are opinionated and based on Olivero container sizes so the answer is that the art direction images will work as well as the others - with mixed results.
Why don't we postpone this until Mediacurrent delivers the Drupal CMS design system
We will have a different flavour of the same problem we have now: If you want to use some other theme then you're stuck.
I am hopeful that we can make some radical advances with the media system so I see this as a ring fenced problem for anyone using today's Drupal CMS.
@catch mostly that would work but we do have some art direction so it would not get us out of the dependency issue unless we make changes and if we did it would lock us out of being able to use the features.
#6 seems like a solid suggestion to me.
Thinking forward we could install contrib components to this type of theme so that any theme could include them from there or override them from their custom theme, so it's not the only use case for an installed but inactive theme.
drupal_cms_image theme might be useful as a self-contained thing or it could be drupal_cms_appropriately_named_middle_theme for other things (given that to provide the breakpoint no dependency on the image recipe is required).