Open gyurmey2 opened 1 year ago
@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.
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.
@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.
@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?
@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.
It's a bit hard for me, so I'll wait for WordPress 6.3. Thank you for your engagement.
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.
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.
@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.
@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/
@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.
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
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 snippetadd_filter('wp_lazy_loading_enabled', ' __return_false');
Step-by-step reproduction instructions
loading="lazy"
attribute has been removed.Screenshots, screen recording, code snippet
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