🇺🇸United States @mariohernandez

damienmckenna → credited mariohernandez → .

I was seeing a bunch of weirdly named themes in my site's appearance page and it was cased by this line in my settings.local.php:

$settings['extension_discovery_scan_tests'] = TRUE;

I changed it to FALSE and that fixed the issue for me.

The two ways in which CSS is involved include:

1. Using the following global rule: img { max-width: 100%; height: auto; }. This rule is pretty much best practice on most projects. It ensures the image never exceeds the width of the container it is in, and the image width will never be upscaled beyond its original image size.
2. Other part where CSS plays a bigger part is in layouts. With the CSS rule above, the image will work in most cases as long as your layouts have been properly established using any of the available methods such as CSS Grid, Flexbox, plain'ol dimension settings on containers.
3. Using CSS' aspect-ratio property can help the browser predict what the image approx size or aspect ratio will be.

It's not common practice to resize the actual <img> tag only using CSS. The recommended approach is to manage layouts around the image and images should naturally adapt to the layout containers.

The last point about using CSS for image dimensions, yes, it is true that you can actually resize images to the desired dimension with CSS, but just like images, CSS also need to be fully available during the page load process for those rules to kick in.

I feel like the issue is not so much the size of the image, the browser is already taking care of that for us, but just as important, is assigning the right width/height values to the img tag at load time (ideally the same dimensions the browser selected), to avoid affecting Largest Contentful Paint

On smaller images, using a fixed image may work just fine and we wouldn't even need responsive images. This is the approach I take when images are intended to be rendered at a relatively small size across all breakpoints. However, when it comes to large images such as Hero images or full width images, this is when responsive images shine and using the fallback image approach would result in either upscaling images with CSS which is not recommended, or, using extremely large images as fallback which in turn will affect performance and maybe even UX.

Yes, this is not an easy issue due to your last point of the server not knowing what the browser will do.
This may be a silly question, but based on the code examples in my previous comment, how were the width/height set?

As far as the browser selecting the best image, we provide a list of images to the browser and let the browser know how big each image is using the `w` descriptor. Then in the sizes attribute we tell the browser how big/small we want the image to be rendered allowing the browser to select the best image based on viewport width, screen resolution, network speed, etc.

In my opening comment at the beginning of this issue you will see a screenshot for the configuration I just described. However, in my code example in the previous comment, the width and height values are present in the img tag. How did they get there? Was that Drupal after the page was rendered?

@damienmckenna, certainly. The HTML does not look much different before/after the patch is applied. I've cleaned it up for better readability.

Before

<img loading="eager" 
  srcset="small.webp 360w, medium 480w, large.webp 768w" 
  sizes="(max-width:768px) 100vw, 720px" 
  width="480" 
  height="360" 
  src="medium.webp" alt="Image alt text">

After

<img loading="eager" 
  srcset="small.webp 360w, medium 480w, large.webp 768w" 
  sizes="(max-width:768px) 100vw, 720px" 
  width="768" 
  height="512" 
  src="small.webp" alt="Image alt text">

The difference after the patch is applied is that the width and height of the img tag is set/forced to be that of the fallback image rather than using the dimensions of the image the browser has selected. As you can see, each image in the srcset has a width defined (i.e. 768w, this value is to instruct the browser how big this image is and in combination with the query in the sizes attribute, the browser is able to select the best image to meet the developer's intended rendering goal.
By using the fallback image dimensions as the img width/height, we are bypassing the concept of responsive images.

Here are before/after screenshots which show the issue when the fallback image is smaller than the size of the intended image. Some may say: "Why not use a larger fallback image?", true, but again, the whole goal of responsive images is for the browser to analyze the environment and select the best image for the job. In addition, what if I am dealing with an image that is, say, 2600px? this means my fallback image would need to be that large which I don't think is the best approach.

Before

After

Hey there! I wanted to share some clarifications about this patch that might be helpful:

1. Just a friendly reminder that the fallback image isn't meant to be your primary image solution. It's simply a safety net for browsers that don't support the srcset and sizes attributes (which is quite rare these days!). Since all major browsers have supported these features since 2017 (you can check out https://caniuse.com/?search=srcset for details), you probably won't need to rely on the fallback much at all.
2. When you're using srcset and sizes, the browser automatically handles the image's width/height values. Each image in the srcset includes its width information, which helps the browser make smart decisions and apply the right dimensions to the image tag.
3. When we force responsive images to use fallback image dimensions, we're actually undoing all the benefits of responsive design. The whole point is to let the browser choose the best image based on the user's device, screen resolution, and network conditions. By forcing a specific size, we're essentially going back to the pre-responsive era when we had to use one-size-fits-all images.
4. If you're noticing layout issues, it might be worth revisiting your overall layout strategy. Ideally, your markup and CSS should work together to create flexible layouts for different breakpoints, with images naturally fitting their containers. A simple CSS rule like img { height: auto; max-width: 100%; } can ensure images never exceed their containers. Remember that your layouts should determine how images appear, while responsive images deliver the most appropriate file for each situation.

I hope this helps understand what's in play here.

Yes @agarzola, my answers remains the same. The width/height values for the HTML attributes should be those of the image selected by the browser. My argument is that what is the point of configuring responsive images with specific loading criteria, if they will be overriden by using fixed values from a fallback image?

As for issue 3359421 🐛 (Re-)Add width / height also on fallback image Fixed , If thats where the breaking changes were introduce, then I would think they need to be implemented differently.

I appreciate your feedback and I hope with the help of the community we can come up with a solution that will work for everyone while adhering to the standards of responsive images.

This patch removes the fallback image dimensions so they are not forced into the width/height attributes of the img tag.

@agarzola, I see what you mean. I think the width/height should be the one from the image selected by the browser. The browser analyzes the srcset and sizes attributes values then picks the best image that meets the rendering criteria, among other things. Up to this point, this has been the default behavior until I started seeing issues with fallback image width/height being applied to the img tag (thus this issue). By the way, this only seems to be an issue with srcset/sizes and not <picture>.

@agarzola, that a great question and that's the beauty of using srcset and sizes image attributes. The srcset lets you define a set of images each which includes its width, allowing the browser to select the best image based on its width and the desired rendering size which is provided as part of the sizes attribute.

I did additional research and testing using vanilla installations of Drupal 10.x.

First test - Using fallback image width and height

Expected behavior, image should render large on desktop (max 1290px), and full width on mobile.

1. First I configured responsive images (resp-img.png)
2. While inspecting the image, visually it looks tiny and that's because it is using the fallback image dimensions (dimensions.png)
3. However, looking at the Network tab in the dev tools, we see the right image is loaded, but because Drupal is changing the width and height of the img tag based on the fallback image dimensions (network.png)

Second test - Not using fallback image

1. Same responsive image configuration as above
2. Inspecting the image this time, reveals the right width/height on the image tag which is provided by the Sizes configuration in item #1 above.
3. The Network tab in inspector's console displays the right image dimensions and visually the image also looks correct (dimensions2.png)

Conclusion

Drupal is able to provide the right width and height to the img tag without resourcing to the fallback image. Hoping this can be resolved to be able to effectively use responsive images.

mariohernandez → created an issue.

Coming a little late to this discussion because I recently started experiencing issues when I use the img tag with srcset and sizes attributes. By default, the width and height attributes of the img tag is being updated to use the fallback image dimensions, which means my responsive images configuration is being totally ignored.
I am having the same issue as @sergey-serov ( #11 🐛 Responsive image width/height values are not used from fallback image style Needs work ).
I typically use a medium or small image as my fallback image so if everything fails at least I get a decent image to render. However, this is breaking all my existing responsive images configuration because the width and height of the img tag is now the fallback image.
Everything seems to work if I use <picture>, but this is not always the recommended approach for responsive images. I use resolution switching as my default method.

Anyone else having this issue?

damienmckenna → credited mariohernandez → .

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

Tested and merged.

I was able to test the patch and confirmed that if "Repeats on every" is set to 1 or higher, the setting is preserved in the node's edit form. However, when I click on Add to Calendar (any of the links), the "Repeat" value is not included and only the individual date I clicked on is added to the calendar.

It looks like the issue referenced above has been closed. Any updates on whether recurring events can be done with Calendar_link?

Thank you, @vladimiraus. I successfully tested changing settings options for fontawesome.

Yes, that was it. Thanks, @vladimiraus. I was able to install and enable the fontawesome module in Drupal 11. However, when I go to FontAwesome's settings page (admin/config/content/fontawesome), I get the following error:

ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /var/www/html/web/modules/contrib/fontawesome/src/Form/SettingsForm.php on line 30 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 43 of core/lib/Drupal/Core/Form/ConfigFormBase.php).
Drupal\fontawesome\Form\SettingsForm->__construct() (Line: 39)
Drupal\fontawesome\Form\SettingsForm::create() (Line: 36)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (Line: 48)
Drupal\Core\Controller\HtmlFormController->getFormObject() (Line: 58)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Instruction in #4 did not work for me on a new vanilla Drupal 11 installation. I get the following error:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/fontawesome dev-3465765-drupal-11-compatibility, it is satisfiable by drupal/fontawesome[dev-3465765-drupal-11-compatibility] from vcs repo (git https://git.drupalcode.org/issue/fontawesome-3465765.git) but drupal/fontawesome[dev-1.x, dev-2.x, 1.1.0, ..., 1.x-dev (alias of dev-1.x), 2.0.0-alpha1, ..., 2.x-dev (alias of dev-2.x)] from composer repo (https://packages.drupal.org/8) has higher repository priority. The packages from the higher priority repository do not match your constraint and are therefore not installable. That repository is canonical so the lower priority repo's packages are not installable. See https://getcomposer.org/repoprio for details and assistance.

I am experiencing the same issue when searching for icons, the icon images are not displaying. I thought the Fontawesome team had fixed this issue for Pro accounts. Any thoughts on what I can do to get search to work properly with Pro? Thanks.

I experienced the same issue and @juamerico's solution ( #5 🐛 Cannot crop based on original image after initial crop has been set Active ), worked for me.

mariohernandez → created an issue.

I created a new issue for conditional_fields not working inside layout_paragraphs.
Hoping we get some solution to it.
https://www.drupal.org/project/conditional_fields/issues/3390509 🐛 Not working in layout_paragraphs Active

This issue is also present in Drupal 10.2+

I appreciate your review, @ressa and I am happy you found the content useful. Maybe an update to the DDEV post would be more useful now that you mention it. Good luck with your responsive images and if there is anything I can do to help feel free to ping me in Drupal slack.

Thank you very much, @apaderno and @ressa. Not sure if you've noticed but two weeks ago I published 7 new articles all related to Drupal. I appreciate your assistance with my request.
p.s. Working on my next blog post which I am planning to publish sometime next month.

Hello @apaderno, Is the work that is needed to be done by me or someone else? I'm not clear on whether there is something on my end that needs to be done or not. Thanks.

Hello @apaderno, does you comment mean my blog has been added to Planet Drupal? I am expecting to publish a few blog posts this week. Thanks.

Great! Thank you. I actually have 7, yes 7, Drupal specific articles coming up. I am finishing up a blog series about responsive images in Drupal (a complete guide). Thanks for your prompt response.

Has anyone been able to create template suggestions for the directions link?

mariohernandez → created an issue.

slucero → credited mariohernandez → .

mariohernandez → created an issue.

After additional testing, I found that the provided patch for the "Controlled-by" field works as expected in paragraphs. The issue I am experiencing is probably caused by the fact that we are using Layout Paragraphs for adding paragraphs content rather than adding our paragraph types as an entity reference field within another entity (i.e. Content type).

I have applied several of the patches provided in this issue and I am still having the issue with the "Controlled by" field not working in a paragraph type. I am running the 4.0.0-alpha3 version of the module in a Drupal 9.5.11 and PHP 8.1 environment. How is it that the patch works for some people and not others? Thanks to everyone who has helped on trying to solve this issue, but I don't know what else I can do to make this work in a paragraph type. If anyone has any idea as to what the issue might be I'd appreciate your feedback. Thanks.

Closing after merging MR.

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

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

These items have already been fixed in the 3.0 beta 1 release

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

Added reference to a fixed bug.

Fix has been merged.

Please use MR #79 if you wish to test this fix.

Patch #3 worked on Drupal 10.1.0 with PHP 8.1.16.
+1 RTBC

Updated error message and steps to reproduce.

Adds example of error message.,

Added twig's docs reference.

Updated headings.

mariohernandez → created an issue.

Applied patch provided by the community to make simplify_menu Drupal 10 compatible.

Added fixed bug issue number to parent issue.

Closing issue after merging the bug fix.

mariohernandez → created an issue.

This bug has been fixed for D9 and D10.

Expanded on how Twig can be used when working with components or variables defined in YML.

mariohernandez → created an issue.

I reviewed and successfully tested the fixes in this MR on a new clean Drupal 10 site.