-
Notifications
You must be signed in to change notification settings - Fork 20
Enhancement: reuse the current content regex #23
Conversation
Some (small) optimizations and name tweaks. Return early if there's nothing to do, etc.
- Filter all found img tags. - Tweak/fix functions and vars names to make them more self-documenting. - Introduce wp_image_tag_add_srcset_and_sizes_attr()
Still TODO:
|
Add `add_filter( 'wp_image_tag_add_srcset_and_sizes_attr', '__return_false' );` to bypass adding of the attributes for now. Should probably revisit after merge to core.
In 060288b also removed passing the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azaozz This is looking great. I have a few follow-up comments. Let's discuss and address these, but afterwards I think this is good to be merged. At minimum, one unnecessary piece of code needs to be changed here :)
$add_loading_attr = wp_lazy_loading_enabled( 'img', $context ); | ||
|
||
if ( false === strpos( $content, '<img' ) || ( ! $add_srcset_sizes && ! $add_loading_attr ) ) { | ||
if ( false === strpos( $content, '<img' ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion here, but by removing the $add_srcset_sizes
condition we actually change the behavior of where srcset
and sizes
are added (currently only supported for the_content
). This is kind of an unintended side effect (this is only about loading
), therefore I would rather have us keep the current behavior to only do that in the_content
. Changing that is for another discussion IMO.
If we keep it, then having this condition can avoid unnecessary execution of the heavier logic below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, went back and forth on this a few times. If we keep it, it makes wp_filter_content_tags()
a bit harder to use for a "random" HTML string/content. It is possible to use wp_make_content_images_responsive()
like that.
If we remove $add_srcset_sizes
, by default this will run on the_content
, the_excerpt
, and widget_text_content
(after removing comment_text
). Thinking wp_make_content_images_responsive()
should have been running on both the_excerpt
, and widget_text_content
from when it was added. It makes sense to add srcset, sizes, and loading attributes to images there.
...can avoid unnecessary execution of the heavier logic below.
It will (most likely) be running the preg_match_all()
anyway. Then the difference would be preg_match( '/wp-image-([0-9]+)/i', $image, $class_id )
on the img tags which should be really fast as these would usually be few short strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with this change (also supporting the other filters for srcset
and sizes
), but we need to clarify that when talking about the core patch (and if we keep it also in the dev note).
From a technical standpoint it makes sense, I just wonder whether it will result in unrelated discussion and overcomplicate these efforts. But we can change still change it back if undesirable per core patch discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to clarify that when talking about the core patch
...
I just wonder whether it will result in unrelated discussion
Yeah, might happen. Thinking to separate this into another trac ticket. Just want to avoid hard-coding it there.
if ( $filtered_image !== $image ) { | ||
$content = str_replace( $image, $filtered_image, $content ); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I really like the single loop here used here.
wp-lazy-loading.php
Outdated
* @param string $context Additional context about how the function was called or where the img tag is. | ||
* @param int $attachment_id The image attachment ID. | ||
*/ | ||
$add = apply_filters( 'wp_image_tag_add_srcset_and_sizes_attr', true, $image, $context, $attachment_id ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure whether we should introduce a filter like this. I get the idea and am generally not opposed, but this is an unrelated change and would raise further discussion points that don't actually help what we want to achieve here.
I'd say let's simplify this function to only be the part within the below if clause.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, still on the fence about it too.
Having a filter somewhat matches wp_image_tag_add_loading_attr()
(and eventually wp_iframe_tag_add_loading_attr()
). It also lets plugin disable srcset and sizes depending on $context
, which might be useful in some edge cases but not strictly necessary.
Not having a filter makes introducing wp_image_tag_add_srcset_and_sizes_attr()
somewhat questionable as the same code may as well be inside the loop where that function is called...
Perhaps can keep it for now and revisit when making the core patch? Then there will likely be more people looking and helping :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually revisiting this, we should probably have this filter if we make the other change from above (supporting more than the_content
here). With this filter, we'll allow developers to opt out for other contexts than the_content
(not sure anybody will wanna do that, but at least it allows someone to get back to the previous behavior if they have some random reason to do so).
That sounds good to me, let's remove it. |
- Improve function names. - Remove left-over code. - Do not run on `comment_text` filter.
Based on #20. This is another "patch" for #2 with some changes and enhancements.
Additions/changes compared to pull/20:
loading
attribute to all img tags in the content, not just tags that havewp-image-####
class names.wp_image_tag_add_srcset_and_sizes_attr()
to go withwp_image_tag_add_loading_attr()
. It makes it possible to bypass adding of srcset and sizes attributes on a per-image basis, before doing anything else. This also prepares it for adding filtering ofiframe
in the future (wp_iframe_tag_add_loading_attr()
, etc.).wp_filter_content_tags()
to only add srcset and sizes when$context
is set tothe_content
(i.e. only when run as callback tothe_content
filter). This makes the function useful for filtering any HTML string and adding all supported img tag attributes.