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!
I think this is for the Publishing workflows track. I haven't looked at anything to do with scheduling but I don't think that the ability to schedule media is useful. Feels likely a default setting that we want to turn off.
@phenaproxima even the best of us make a mistake or have a slip of the finger. If that happens our CI can deploy the code to a production site, also mitigated here by tagged releases.
@pameeela we use draft state for merge requests at Annertech until something is approved to merge. The reason for that is that it is a safety measure against accidentally triggering a merge. It needs review.
Love this solution. Thanks @rikki_iki
One option could be to make medium a little larger and then we could get rid of 30% of the options in this list. We don’t need to make wholesale changes to achieve that because we can leave large in place but not turn it on for ckeditor.
Look forward to your thoughts.
To remove these, it's a case of simply deleting the option from the yaml file filter.format.content_format.yml in the content type base recipe.
Now that we have restricted the content width to narrow, 'large' image widths render close to the size of 'medium' image widths. I suggest that we remove 'large' options.
I'm trying to think of what might not make sense and it could be 'Small, 'Medium' and 'Large' labels, we could add view modes named 'Small (uncropped)' and 'Medium (uncropped)' instead of using view modes that give us labels 'Small' and 'Medium' (we shouldn't simply rename those, because video uses them too and can't be cropped).
For deciding which aspect ratios we may want to remove, these are options offered from the discovery and proposal and we already removed 2:3 and 3:2. The UI here is not ideal and we have to find a balance between the length of this list with the frustration editors might feel when they can't present images as they would like.
The configuration is ready for review.
I went with 5:2 because this very closely matches the images in the designs and calculates nice round numbers. On mobile I went with using 16:9 image styles already in place, which gives the images a little more substance when the image is small.
tonypaulbarker → changed the visibility of the branch 2025_w1_featured_image_config_front_end to hidden.
Note to self: The blockquote breaking out of the container seems to kick in only when using ‘narrow’ instead of ‘medium’ layout class and that breaks some other stuff.
Have pushed work in progress that targets grid column rules at the blocks. Haven't tested yet so leaving marked as 'needs work'.
A more robust way to accomplish this might be to unset the parent grid and then use layout builder section layouts.
@pameeela I’ve been experimenting with our options for the hero, setting up configuration and testing.
Although we may not need a switch to achieve the hero visually, without a switch of some sort it leaves us with the same field and thus same responsive image style for the contained version of the image and the wide version.
We can put switches in templates, but we’d require twig tweak to set a different image style and it will break when the theme is switched so I think those options are potentially messy and complex.
A path I’m not keen to go down is considering using JavaScript to manipulate things, as these images should be eagerly loading and affect many pages including the home page so should load cleanly.
If I were to recommend a solution, it would be a separate ‘section home page’ content type so there was full control of this and any other things that should be presently differently on the home page and section home pages. Given the project structure considerations of adding another content type I’m not sure it’s an option to turn that around rapidly.
The best compromise I can think of is to only allow the hero to expand to some sensible width and then to become elegantly spaced.
I am pursuing this last approach for now and welcome any guidance.
@pameeela it seemed to work for me for basic pages. I did expect that if teaser cards were present that it would not be narrow with these rules. I’ll see what we can do and I’ll have a deeper look across all the contexts.
Reviewers please test the following:
Review the previous issues for teasers and the layout.css file on the MRs https://www.drupal.org/project/drupal_cms/issues/3491807 📌 Style blog/news teaser as cards Active and https://www.drupal.org/project/drupal_cms/issues/3491817 📌 Implement designs for event teaser/listing page within Olivero Active
Check the teaser pages (e.g. events teasers, blog teasers) with various numbers of items. The CSS change for this issue should retain the layouts applied by the two above issues to teaser cards.
Check full node content in CKEditor with a blockquote and images to the side of text . Confirm that the narrower width is restored and matches the designs as intended (see the related issues #3491813, #3491811, #3491814 and #3491816 for the designs). The quotation mark of the blockquote should break out of the container to the left.
Generally check that layouts look good.
To workaround the issue I am using yarn in ddev instead of npm and using the --no-open flag. The --no-open flag seemed to have no effect for me when using npm.
Problem 1 was the additions to development.settings.yml was not being loaded as expected. From the issue earlier in the year it seems to be a common problem for people so could be added to troubleshooting.
Problem 2 was that after problem 1 was overcome the whole web page was being loaded in the storybook pane instead of isolated components. Adding the following snippet at line 3 to both .storybook/preview.js and .storybook/main.js solved the problem for me, although it may have been some combination of clearing caches and resetting that cleared out the problem.
server: {
url: process.env.STORYBOOK_SERVER_URL || 'https://mysite.ddev.site/storybook/stories/render',
},I followed the thread on this issue where there is a similar report https://www.drupal.org/project/storybook/issues/3438389 💬 Problem with initialising project Closed: works as designed . Maybe like those cases something is overriding development.services.yml
I am trying to set up by following the documentation and tutorials and see this failed to fetch output too. I am using ddev. I don't have multisite.
I tried to configure some different ways and have the optional ddev configuration described in the documentation.
The url in the json file is
https://mysite.ddev.site/storybook/stories/render
Storybook is being served at
https://mysite.ddev.site:6006/?path=/story/components-component-name--te...
One thing I don't understand is why the url should be set to https://mysite.ddev.site/storybook/stories/render when nothing is served at that path.
lostcarpark → credited tonypaulbarker → .
@penyaskito I must take tugboat for a spin!
With all these tools and different use cases, we should define which tools we intend to use for which purposes and what we mean by Visual Regression Testing.
A pro is - they can help to discover problems earlier.
A con is - they require planning, set up and maintenance resource.
The value comes in the scenarios where a) a developer is working on one component or global style and unintentionally affects something else that they did not think was in scope of the change. c) a component is used in a way not intended by the designer or developer and layout issues occur as a result.
Some names to throw into the discussion:
Backstop.js - and it would be great to support the project.
Another very good tool is Percy by Browserstack, has an Open Source programme I believe.
Storybook has ddev support and helps to maintain design system integrity. I believe it also ships with comparison tools.
I think we might be able to implement this way:
Check in the node template whether we are on the front page and conditionally display the featured image above the title with the full width hero or below it with the contained image.
I'll look to try that approach and we can review it. I'm open to other suggestions.
@ckrina thanks for pointing that out! I’m looking at both cases and I’ll update the title and description to reflect it.
I am figuring out the hero image styles across the content types at https://www.drupal.org/project/drupal_cms/issues/3495584 📌 Implement hero images to match designs Active
and the classes to set the content widths of the node content across the content types at https://www.drupal.org/project/drupal_cms/issues/3495583 📌 Implement full node content widths to match designs Active
I am figuring out the hero image styles across the content types at https://www.drupal.org/project/drupal_cms/issues/3495584 📌 Implement hero images to match designs Active
and the classes to set the content widths of the node content across the content types at https://www.drupal.org/project/drupal_cms/issues/3495583 📌 Implement full node content widths to match designs Active
I am figuring out the hero image styles across the content types at https://www.drupal.org/project/drupal_cms/issues/3495584 📌 Implement hero images to match designs Active
and the classes to set the content widths of the node content across the content types at https://www.drupal.org/project/drupal_cms/issues/3495583 📌 Implement full node content widths to match designs Active
I am figuring out the hero image styles across the content types at https://www.drupal.org/project/drupal_cms/issues/3495584 📌 Implement hero images to match designs Active
and the classes to set the content widths of the node content across the content types at https://www.drupal.org/project/drupal_cms/issues/3495583 📌 Implement full node content widths to match designs Active
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
That looks good to me! Thanks @debrup.
The image is now looking sharp, let's move it on.
@debrup I left a comment in the MR. The updated proposed resolution suggests 220px, which should be close to the rendered image size. This will help speed up loading of the media library when there are many images.
We can probably set the default display to use an image style to get around this.
@catch it’s not a true hero but a content image high up the page. I’m not sure there’s too much we can do about that without granular control of an instance. I’ll add a bullet point for looking at it to an existing checklist.
Did some more debugging and replicated the same behaviour below the fold so let’s steer away from the lazy loading theory.
I can recreate this issue in Safari but it doesn't happen in Chrome.
It doesn't only happen after installation but also if I flush the image styles.
I can never seem to reproduce the issue once I have published the content but I wouldn't say that I can reliably reproduce that behaviour. I could not reproduce it on some new content I created.
This is an image in the body content so it's lazy loaded, it's above the fold that's bad form. I moved the image further down in the content and the image loaded.
The lazy loading of responsive images is quite a new feature and if it's a bug with loading lazy images above the fold feels like something that's potentially one to look at upstream.
Thank you so much for finding this one and working on a solution. It looks as though with our current configuration the squarer the image the sharper it will render.
It so happens that some of the images in this case are much wider than taller so the aspect ratio of these images lays bare a problem. Our rendered image appears as a square but in fact it’s a rectangle of tiny height with some CSS applied to set the image as a cover and fill the area.
If we crop to a square of 240px x 240px (or 220px x 220px would probably do) rather than only scaling then we can have sharp images and optimise for the thumbnail we want to present.
I suggest we use try applying a ‘focal point scale and crop’ instead of the ‘scale’ to Media Library thumbnail image style and try applying that. If we use a media library specific image style then image styles can be edited in future with clarity over what’s affected.
A very rough test with 220px focal point scale and crop looks as though that might do the trick.
Will give this a test and report back. Blurriness of thumbnails will be more apparent on retina devices so may not be an issue for everyone. Speed of loading the media library and disk space usage are considerations because we will generate thumbnails of many images as users browse their media libraries.
@phenaproxima perfect!
News was originally created as a clone of Blog so how this happened, I am not sure.
Trying to give a little insight into this. I checked and updated every instance I had knowledge of but some work in progress like this one likely slipped through the net.
The configuration should probably match blog, so I think this should be set to use ‘’Small’ view mode. This happened because the configuration was created without knowledge of stuff that wasn’t merged yet and didn’t have functional tests. As far as git was concerned, there were no conflicts.
Marking as nice to have for the release, since it’s ready to go.
This one would be nice to work out in time to include in the release, tagging as such.
@pameeela I think that people are struggling to understand my description, which was written way back in June and we have moved on a long way since then.
For a single non-technical evaluator experiencing Drupal for the first time, the administrator role doesn’t make a lot of sense (to me at least) and I think we should re-imagine this because:
- The UI has a lot of complexity and will be off-putting to some people.
- The permissions system in particular doesn’t make a lot of sense in the context of an in browser trial experience - the evaluator can make changes to the permissions but if they have elevated privileges nothing will change in the UI for them.
For a trial experience, I think the areas of the UI that are available should be curated and the easiest way I could think to accomplish this was to assign a role that has a subset of the permissions, with some means to elevate the role.
An entirely different way to solve the same problem would be to make all areas of the UI intuitive and comprehensible to anybody of any level of experience that chances upon them.
This is also true if comparing the drag and drop resize to the current state i saw in the Drupal CMS media track where you have like a dozen image styles to select from. If the goal is to make things easier for people that don't know Drupal, then selecting image styles is the wrong path to take IMO.
Competitor CMS make available cropping to some common aspect ratios. The UI in Drupal CMS is not ideal just now because we don’t have a way to separate orientation from aspect ratio from resizing and that means there are too many options presented in the dropdown. I think we can have the best of all worlds. To be able to crop to an aspect ratio (selectable first by orientation) and to be able to go custom.
Approved. @phenaproxima please would you do the honours?
I think having this as an option could be good for many people but I do also think it’s not for everyone.
The case for editors to have control is clear but the case why some people might not want this feature might be less than clear, such as:
Those site owners who want consistently sized images across pages and don’t want editors to have easy custom control.
Performance (if resizing a large image file could still serve a large image file)
Cases where CSS and layout restrict or alter the size of images so results are unexpected.
I think most likely those sites where control is important are using structured content for images rather than CKeditor.
I am interested to learn more about how this works.
liampower → credited tonypaulbarker → .
Thank you for your work on this issue @nitesh-sethia
The format matches the other media types. What distinguishes the svg_image from a regular file upload is that it uses svg_image module to sanitise and to provide an option to display it as an image. We have some preconfigured view modes but it could be extended and used in various unknown ways. It would be nice to find a way to convey the difference whilst being precise about the part the media entity itself is playing. We want to keep a short description so it is easy to understand for any non-technical users.
Perhaps something along the lines of:
"A locally hosted SVG file that can be displayed as an image."
tonypaulbarker → created an issue.
Sounds good!
@phenaproxima if we move this issue to core, how do we make sure the initiative doesn't lose sight of it? This issue is as much about UX as code and could span multiple core and contrib projects.
@thejimbirch @pameeela @the_g_bomb I would welcome your thoughts on what fields (if any) we should include on media entities.
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
tonypaulbarker → created an issue.
I think it is definitely a Drupal CMS issue. Core does not have a concept of a trial experience for evaluators and is geared to developers who know how to configure complex sets of permissions. It’s not for core because it’s not for everyone. It’s needed to be considered for the market of Drupal CMS.
@lauriii I think you have linked to this same issue?
I think the holistic view comes in three main parts for the UI
1. Initiating the upload / URL or library as discussed here.
2. Interacting with the media library
3. Enabling editor to set transformations and properties of an instance that uses a media field and getting some live feedback.
and under the hood I think these will be the main considerations to achieve it:
1. Field Widgets.
2. Entity usage.
3. System handling of transformations and image styles.
I am doing some work to map out those problems and possible approaches, but I expect big changes that can take a while so in the meantime if we have the opportunity to improve the experience with smaller changes I think we should try to do it.
@plach I have had a little look (in fact I did take a look at media widget a little while ago) and these modules are on the way to finding solutions for features we were discussing that we would like to have so I intend to look in lots more depth at these. Here are some very early notes for myself and they may offer you some early insights. I will go through in more detail and take some screenshots / produce a few wireframes to better describe some of the discussion points. I began a meta issue to list the upcoming opportunities for media management, which is at https://www.drupal.org/project/drupal_cms/issues/3488393 🌱 [META] Vision for Media Management Active
- Media can begin from a URL (as in the case of remote video) as well as an upload.
- I think we should be able to use the media library to use existing media.
- Bulk uploads is a consideration.
So I think we have three cases of initialisation that we should support (new upload, new URL and existing media). This may lead us to end up with something similar to the media library UI, except that there should be no need to pre-select a media type before uploading (it's at least one click that we can save). As a bonus, bulk uploads would be possible along the lines of https://www.drupal.org/project/simple_media_bulk_upload → and the media types of the bulk uploads would be detected. In the long run, I would love to have some detection that a file already exists if the same is re-uploaded.
We should be able to handle custom media entities that may share some filetypes with other media entities.
Once the media entity is place, there is some UX / UI work because the I think the out of the box experience is currently quite confusing. I think we should be able to get to edit the media entity. We plan to have a small number of additional fields on media entities for filtering the library and for SEO.
In the case of allowed URLs, content security policy comes to mind. Modules like Seckit are not easy to configure but by installing or approving only certain URLs / providers in the UI we can improve the situation. We might consider a validation of known and approved providers instead of rendering a link.
liampower → credited tonypaulbarker → .
Thanks @plach. I will take these for a spin.
tonypaulbarker → created an issue.
@phenaproxima current conflicts are resolved. Re-tested some things and all looks well.
@pameeela this goes beyond the scope of this particular issue, but I think a great rule of thumb would be to make it pain free to add media whilst editors are working on their node content (requiring minimal input like alt text for images) and for the full form / edit screen to be the place to add more rich metadata. For SEO and categorisation it's envisaged to have a few more fields on media entities in the future, but only the minimum required because during discovery people told us they don't want lots of fields to manage. We could provide some additional views for people to see an overview of how complete that data is without making the library interface itself difficult to work with.
So following those principles I think your suggestion is perfect for both the short term and the long term aims.