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).
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
Some more ramblings for consideration.
We have precedent for sending parameters to image styles without building images with a URL, which is Crop API.
I'm thinking something along the lines of 'Adjustments API' similar to Crop API that could handle other types of adjustments like brightness, contrast, masks or a parameter for detecting subjects and cutting them out.
I came across Media Contextual Crop group of modules but I haven't taken them for a spin yet, https://www.drupal.org/project/media_contextual_crop → . I think there is a distinction between content images where contextual information is available and more control is desirable and meta images that may be used for things like teasers and the context is not known by the content.
A reason to steer away from generating images with URLs is that even if width and height can be handled effectively we see from problems with facets https://www.drupal.org/forum/support/post-installation/2025-02-20/drupal... → how the permutations multiply rapidly and it would leave us unable to extend the system.
Hi folks. Here's an outline of my thoughts based on the discovery and feedback I have been involved with since last summer.
There are a lot of things on the wishlist in the description. Not all of these should be configurable per instance by editors. We will arrive at a difficult to use UX. They shouldn't be concerned with the filetype, lazy loading and so on. Most of these things should be in other settings away from the edit screen (or at least tucked away in 'advanced').
I am not concerning myself with how one would go about deleting files but - from the UX end in the editor - the important things for editors to be able to control in the content pane are:
Select size (max width or height) - grids and containers the image is positioned in are ideally known by the system from the layout to set an upper limit.
Select orientation from portrait, square or landscape (to limit the aspect ratio list)
Select aspect ratio
Crop (automatic with focal point, then tick a box to manually cropping controlled by the selected aspect ratio + allow freeform)
Brightness, contrast adjustments
Rotation / angle using a dial widget
Override alt text (once we have made adjustments like cropping, the description of our image changes from that stored in the library).
I don't think it's enough to only set these things for all instances of a component but defaults for the component are good. Administrators should be able to have some control to toggle these being available - in some cases, for example, the aspect ratio should be locked but cropping to that aspect ratio enabled. Editors really want to be able to make adjustments specific to their image for the context it is being used in without affecting other instances.
I don't believe that the 'legacy Drupal' image style system can accommodate this. But live adjustments could be generated with CSS to hand over to be generated with PHP based on the parameters on save.
I was there
I was there
In attendance myself, @finn lewis @stephen-cox @rupertj
tonypaulbarker → created an issue.
@finn lewis and I were present
tonypaulbarker → created an issue.
@ivnish thank you for raising this. @phenaproxima - I am keen to see how we might incorporate these with experience builder but we are not ready to get stuck into how that may look. I am categorising this under the media track for now, as we have discussed and it's a long term aim to have some gallery features. In the meantime people can use Project Browser to add a range of gallery modules and we can discuss and give feedback. I've added a few notes below for how I might go about approaching it.
There are many different gallery formats - I would lean toward best-in-class solutions for each of the formats that may be different modules, tools and components for each rather than a module that supports them all. Evaluating solutions for accessibility will be key.
At the moment Splide is my favoured go to for carousel formats, it is pretty strong on accessibility. https://www.drupal.org/project/splide →
For a gallery format of grids of images, I would envisage this to be a combination or recipes and either a Single Directory Component or making use of some base grids.
We need to consider how to go about displaying images and their accompanying information in modals in an accessible way (and likely consider other formats) too.
We might use carousels, grids and modals for other things so we should consider the roadmap for other features.
liampower → credited tonypaulbarker → .
liampower → credited tonypaulbarker → .
liampower → credited tonypaulbarker → .
liampower → credited tonypaulbarker → .
liampower → credited tonypaulbarker → .
No probs Finn! :)
In attendance myself, @finn lewis @stephen-cox
tonypaulbarker → created an issue.
I was there. Fab presentations. Thank you everyone.
aaron.hirtenstein → credited tonypaulbarker → .
finn lewis → credited tonypaulbarker → .
tonypaulbarker → created an issue.
Made suggestions and tested the instructions.
I attended.
tonypaulbarker → created an issue.
Great. Thanks for catching my mistakes in the first place!
I think we can ship the release notes.
@greg boggs
1:1 | 300x300 | Focal Point | WebP is not updated in this MR it was already fixed in 1.0.1 https://www.drupal.org/project/cms/releases/1.0.1 →
Please check the release notes added to the Issue Summary accurately describe the steps.
Marking 'Needs work' for #20
100% @pameeela - we need to take all of that into consideration.
@catch
Given the viewport width and the container width are identical in both cases, the selection in the dropdown allows an editor to choose an image that will render as either up to 300px in width (small) or up to 720px in width (medium).
The bit that I don't think we can hand over to responsive images to handle at the moment is that user input.
@heyyo
It seems possible to set focal point on a newly uploaded image, I was not able to replicate an issue with that. It's true that it's not possible to edit the focal point from the CKEditor widget.
Thanks for the suggestion, we'll give it a look.
As stated in #17, resizing in CSS doesn't impact the image files that we load. We do want to have better tools at our disposal but I would like to conclude that discussion on this thread given that at the current time we don't have a workable option for those enhancements in scope of this particular issue.
Please review and test the code for #7 on the MR, which is ready to ship or adjust if we like the direction of those changes and should be a tangible improvement for editors in the earliest versions of Drupal CMS.
Sending back to 'Needs review'.
nicxvan → credited tonypaulbarker → .
#7 is ready for review on the MR
Also worth checking preprocessing. e.g. We might have used a preprocess because there wasn't a template, but later a template gets added. We could roll that into this issue.
It would be great to have a proof of concept of the 'styles' approach and I will update the roadmap to look at it.
Since we can make a quick improvement to reduce the list for the current implementation I am looking at #7.
I think that would work. Summary feels accurate.
A tagline is a marketing device for an organisation. If you have company profiles it could be a field there but not for generic content or fields.
A title and a subtitle is a content field.
A heading of various levels are HTML elements that can be applied to content.
A button is an HTML element. A link should be labelled as a link. A class of button-styled-link may be applied, but still it’s a link.
The call to action is the whole component, part of the call to action is the description of what will happen when you follow the link.
So I would use naming along these lines:
Title
Call to action text
CTA Link
CTA Link text
This seems to work well.
The name field is present for document, remote video, image and svg image.
After uploading a file through featured image field or the CKEditor media widget, the name field auto-populates with the filename and is editable.
Marking RTBC.
I'm un-assigning myself to look at another task if someone would like to pick this up.
A couple of configuration / mark up notes. It looks as though we want to go with a layout builder 2 column with 25% 75% widths. Set the global title block to be hidden for profiles/* and add the name field to the right hand column in LB. Ensure that the name is using an H1 tag.
The logo looks likely to be above the fold according to the design so it should probably have eager loading?
I see you beat me to it. Thanks!
Comparing with other similar config I will delete lines referencing layout builder and try again.
I see some block plugin was not found warnings in the logs, e.g. "The "field_block:node:project:field_content" block plugin was not found" but I don't see a problem editing content or on the front end. Will investigate more tomorrow.
Hmmm @pameeela is it only the pipelines? did you get to have a look around or did you see problems?
@mortona2k @catch I agree #9 sounds well worth exploring to improve this particular situation. CKEditor is not the only context we need to consider but it’s an important one, particularly in version 1.
A possible drawback I can see is that it could make it more difficult for non-technical users to customise the options but on the other hand, it could make the out of the box experience better.
Could these requirements be met?
A dropdown lists the aspect ratio options
A separate dropdown lists the size options
These two selections in combination map to the view modes.
The editor sees live feedback in CKEditor on changing the selection.
Setting the tabindex to -1 on this element is the right approach and I tested and can no longer open the select element with my keyboard so marking RTBC. Great job!