Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cover Block + Featured Image: Lazy Loading attribute is not removed #46789

Open
gyurmey2 opened this issue Dec 26, 2022 · 12 comments
Open

Cover Block + Featured Image: Lazy Loading attribute is not removed #46789

gyurmey2 opened this issue Dec 26, 2022 · 12 comments
Labels
[Block] Cover Affects the Cover Block - used to display content laid over a background image [Type] Bug An existing feature does not function as intended

Comments

@gyurmey2
Copy link

Description

The featured image used in the cover block always has the loading="lazy" attribute and is not skipped when it's first on the page (although it should be). It can't even be removed by adding the code snippet add_filter('wp_lazy_loading_enabled', ' __return_false');

Step-by-step reproduction instructions

  1. Add a block cover as the first block on the page.
  2. Set the featured image (screenshot).
  3. Check in the console that the loading="lazy" attribute has been removed.

Screenshots, screen recording, code snippet

screen

Environment info

Theme: TT3
Gutenberg: 14.8.1, 14.9.20221224 and without.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@Mamaduka Mamaduka added [Type] Bug An existing feature does not function as intended [Block] Cover Affects the Cover Block - used to display content laid over a background image labels Dec 26, 2022
@felixarntz
Copy link
Member

@gyurmey2 After testing this myself, I can verify that this happens today, regardless of whether you use a core/cover block in post content or in a block template or template part content.

https://core.trac.wordpress.org/ticket/56930 is scheduled to fix at least the first scenario (using core/cover in post content) in the upcoming WordPress 6.2 release. The other scenario is more complex to address and will require a more thoughtful approach. The team will keep looking into that as well, but that may realistically have to wait for 6.3.

The point that you can't remove lazy-loading even with add_filter('wp_lazy_loading_enabled', ' __return_false'); is a great catch, I can replicate that as well. That is a simple oversight, I have opened a core ticket https://core.trac.wordpress.org/ticket/57490 to address it in 6.2 as well.

@gyurmey2
Copy link
Author

Hi @felixarntz, In 6.2-beta2 (latest nightly too), I noticed that the loading="lazy" attribute is not added if images were added from the Site Editor. Please take a look.

@felixarntz
Copy link
Member

@gyurmey2 Thanks for sharing that example! I took a look and found the reason why those bottom images don't have loading="lazy": As of what https://core.trac.wordpress.org/ticket/56930 addressed, that part is separate: In general (also for classic themes), loading="lazy" is only added for in-content images. That is because for a regular template (whether classic or block theme) it is more challenging to know where an image is displayed because it's essentially the entire page HTML.

Right now, the loading="lazy" attribute is only handled in block template parts because in those we have more concrete context available (e.g. header or footer).

To summarize: What you're describing is right now an expected issue, but definitely something that we can fix in the near future. I'll add it to my notes for the remaining issues with lazy-loading that I have been researching. Aiming to get those fixed in WordPress 6.3.

@gyurmey2
Copy link
Author

@felixarntz Thanks for the clarification. And is there any way to enable loading="lazy" manually? For example, some function by adding a class to a block?

@felixarntz
Copy link
Member

@gyurmey2 A class-based approach doesn't work, but I think there's a way to do it more directly through setting the loading attribute. It's not super straightforward, but you should be able to use the wp_content_img_tag filter introduced in 6.0 to manually add the loading="lazy" attributes.

When using the filter, make sure to only touch the image if $context === 'template', which is the context value for when the images in the overall block template are being modified. You can then selectively add loading="lazy" to certain images, however you must be careful not to add the attribute to the hero image, which unfortunately is part of this overall content as well and intentionally does not have a loading="lazy" attribute.

I'm hopeful we can improve that experience out of the box for WordPress 6.3 though.

@gyurmey2
Copy link
Author

It's a bit hard for me, so I'll wait for WordPress 6.3. Thank you for your engagement.

@JustinLindsayChapman
Copy link

I can confirm that this problem still exists today version 6.2.2 using 2023 theme, cover block image does not respond to any php function trying to target attributes, site wide disabling of lazy load (add_filter( 'wp_lazy_loading_enabled', '__return_false' );
) has no effect either, 6.3? When is that supposed hit the repository? Just read it should be on the 8th of August. 5 days away. I read some of the notes on what has changed for targeting images and changing the loading attribute, I am not sure it is going to help. A simple way would be in the editor, place a checkbox lazy load image or not set by default to lazy. Anyway that is the only thing stopping me from getting all green scores on my streamlined 2023 themed project.

@webfolkcreative
Copy link

Maybe just add an option in the block settings to toggle lazyload on/off. That way the user can define if it should or should not lazy load. Rather than trying to determine if it's the first block, etc. Just seems easier to allow the user to control it via a field or toggle. Default it to on so that by default no one is impacted.

@JustinLindsayChapman
Copy link

@webfolkcreative , absolutely what I am saying make it super simple to toggle that baby on and off. I have the feeling that the code for the gutenberg blocks is just a bit too vexing for the WP core to deal with.

@felixarntz
Copy link
Member

@JustinLindsayChapman Thank you for the feedback. As the changes are only implemented in WordPress 6.3, I would encourage you to please do another test using that release.

You can test it in advance of the 6.3 stable release, by using the latest WordPress 6.3 release candidate in a test or development environment: https://wordpress.org/news/2023/08/wordpress-6-3-rc3/

@JustinLindsayChapman
Copy link

@felixarntz No worries, that is how things get better. I will take a look but my time is over allocated at the moment and I probably won't get a chance before the 8th rolls around. Will get back to here if I have some success.

@schlotterer
Copy link

schlotterer commented Mar 3, 2024

I addressed this issue by adding custom attributes to the image and cover block that is a boolean "Enable Lazy Loading" with a default to true. If it's set to false I filter the block content output and strip the loading="lazy" attribute.

of course there is code setting up the custom attributes and admin interactions but this is the filtering of the content

if ( $block['blockName'] === 'core/cover') { // Check if your custom attributes are set and not empty if (isset($block['attrs']['enableLazyLoad']) && !$block['attrs']['enableLazyLoad']) { $searchString = 'loading="lazy"'; $replaceString = ''; $block_content = str_replace($searchString, $replaceString, $block_content); } }

This way if I start with a cover block i can just toggle that off, and if that is done in a template or page or hero pattern then i'm good.
Seems to work so far.
https://github.com/schlotterer/flexline/tree/lazy-loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Cover Affects the Cover Block - used to display content laid over a background image [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

6 participants