Fix incorrect width and height in core/image block #5776
Conversation
addresses incorrect w/h values in core/image block img tags
remove preamble comment, remove informal test
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5776 +/- ##
=============================================
+ Coverage 31.67% 31.81% +0.13%
- Complexity 5035 5048 +13
=============================================
Files 299 299
Lines 22119 22152 +33
=============================================
+ Hits 7007 7048 +41
+ Misses 15112 15104 -8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
fix-block-img-tag-sizes.php
Outdated
| // Add the width and height attributes to the img tag | ||
| $block_content = preg_replace( | ||
| '/<img ([^>]+)>/', | ||
| '<img foo="bar" $1 width="' . esc_attr($width) . '" height="' . esc_attr($height) . '">', |
There was a problem hiding this comment.
Is this foo="bar" thing really necessary? :-)
There was a problem hiding this comment.
Also, can the <img> tag contain other attributes (say, alt)? If so, is it possible to avoid overwriting them?
There was a problem hiding this comment.
Oops, that foo is a testing leftover! Thanks for the spot. And yeah, the img and figure tags can contain other values and classes too.
There was a problem hiding this comment.
See the first commit: it has the now-removed add_block_bits, which I was using for as an informal test for extra values in the tags by filtering a bunch of extra stuff into the block markup just upstream.
fix-block-img-tag-sizes.php
Outdated
| $height = $metadata['sizes'][$size_name]['height']; | ||
| $new_file = $metadata['sizes'][$size_name]['file']; | ||
|
|
||
| if ($resizearg) { |
There was a problem hiding this comment.
This condition is always false because we don't seem to set $resizearg to true anywhere.
There was a problem hiding this comment.
Indeed, we don't set it true anywhere - yet. I'm deferring to y'all as to how we should let the user set this (if we include it at all).
fix-block-img-tag-sizes.php
Outdated
| } | ||
| return $block_content; | ||
| } | ||
| add_filter('render_block', 'fix_img_block_sizes', 10, 3); |
There was a problem hiding this comment.
Since we're only handling core/image blocks, perhaps we can hook into render_block_core/image here? https://github.com/WordPress/wordpress-develop/blob/50af37a9083f003f8e98d089091d2cc428797cc5/src/wp-includes/class-wp-block.php#L581
There was a problem hiding this comment.
Good point - Should behave exactly the same on that filter, since it's right after the first one and uses the same values. Will give that a try too.
There was a problem hiding this comment.
Works well and makes the function smaller. Nice, thx!
I'd left a foo=bar in the returned img tag from testing on non-VIP envs, so I took it out.
|
Looking at the |
removed resizearg switch, used render_block_core/image filter, added skip for fullsize, prepended vip to function name to avoid collisions with existing fix_img_block_sizes filters in use
|
Removed |
|
|
|
This pull request has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed. This is an automation to keep pull requests manageable and actionable and is not a comment on the quality of this pull request nor on the work done so far. Closed PRs are still valuable to the project and their branches are preserved. |
|
Bumping out of stale to discuss |
|
Refactored to use HTML API as discussed in Slack. Verbose with comments on purpose, since I haven't used the HTML API much and I wanted to make sure the flow was followable. Thoughts? |
|
|
This pull request has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed. This is an automation to keep pull requests manageable and actionable and is not a comment on the quality of this pull request nor on the work done so far. Closed PRs are still valuable to the project and their branches are preserved. |
rinatkhaziev
changed the title
|
| @@ -104,6 +104,9 @@ public function __construct() { | |||
| $this->schedule_update_job(); | |||
| } | |||
| } | |||
|
|
|||
| // Add filter to fix image block sizes | |||
| add_filter( 'render_block_core/image', array( $this, 'fix_img_block_sizes' ), 10, 3 ); | |||
There was a problem hiding this comment.
| add_filter( 'render_block_core/image', array( $this, 'fix_img_block_sizes' ), 10, 3 ); | |
| if ( ! is_admin() ) { | |
| add_filter( 'render_block_core/image', array( $this, 'fix_img_block_sizes' ), 10, 3 ); | |
| } |
and remove is_admin() check in fix_img_block_sizes().
| // Don't fire in wp-admin, image blocks are fine there | ||
| if ( is_admin() ) { | ||
| return $block_content; | ||
| } | ||
|
|
There was a problem hiding this comment.
| // Don't fire in wp-admin, image blocks are fine there | |
| if ( is_admin() ) { | |
| return $block_content; | |
| } |
a8c-files.php
Outdated
| $update_tag_processor = new WP_HTML_Tag_Processor( $block_content ); | ||
|
|
||
| // Set width/height for img | ||
| if ( $update_tag_processor->next_tag( 'img' ) ) { | ||
| $update_tag_processor->set_attribute( 'width', esc_attr( $width ) ); | ||
| $update_tag_processor->set_attribute( 'height', esc_attr( $height ) ); | ||
| } | ||
|
|
||
| // Get the result ready | ||
| $block_content = $update_tag_processor->get_updated_html(); |
There was a problem hiding this comment.
Do you think we can reuse $img_tag_processor here?
| if ( $is_admin && ! defined( 'WP_ADMIN' ) ) { | ||
| define( 'WP_ADMIN', true ); | ||
| } | ||
|
|
There was a problem hiding this comment.
I don't like it because it might affect other tests.
I suggest moving the is_admin() check around the add_filter() call.
| if ( $metadata ) { | ||
| $this->assertStringContainsString( 'width="300"', $actual, 'Width attribute should be present' ); | ||
| $this->assertStringContainsString( 'height="200"', $actual, 'Height attribute should be present' ); | ||
| $this->assertStringContainsString( 'class="wp-image-123"', $actual, 'Image class should be preserved' ); | ||
| $this->assertStringContainsString( 'class="wp-block-image size-medium"', $actual, 'Figure class should be preserved' ); | ||
| remove_filter( 'get_post_metadata', $filter, 10 ); | ||
| } else { | ||
| $this->assertEquals( $expected, $actual ); | ||
| } |
There was a problem hiding this comment.
Maybe we can make $expected a string or an array? If $expected is a string, we call assertEquals(). Otherwise, we invoke assertStringContainsString() for every array item. This will make the code cleaner.
There was a problem hiding this comment.
@sjinks there's no guarantee order of arguments will stay in the same order (hence the THIS IS FLAKY comment). With this approach it's less flaky
There was a problem hiding this comment.
@rinatkhaziev we will have [ 'width="300"', 'height="200"', ... ] etc and then
if ( is_array( $expected ) ) {
foreach ( $expected as $substring ) {
self::assertStringContainsString( $substring, $actual );
}
}This will move all hardcoded checks out of the test into the data.
| if ( $metadata ) { | ||
| $attachment_id = 123; // Matches the wp-image-123 in test data | ||
| $filter = function ( $meta_value, $post_id, $meta_key ) use ( $metadata, $attachment_id ) { | ||
| if ( '_wp_attachment_metadata' === $meta_key && $attachment_id == $post_id ) { | ||
| return [ $metadata ]; | ||
| } | ||
| return $meta_value; | ||
| }; | ||
| add_filter( 'get_post_metadata', $filter, 10, 3 ); | ||
| } |
There was a problem hiding this comment.
Should this go to setUp() and tearDown()?
|
Hi folks - we have a customer who is interested in using this solution when we release it. I see we've moved into a reviewing stage but I know we're still in active development. Is there a rough estimate for when this is expected to be in the pipeline to production? The customer has been trying to adapt this concept to their own custom plugin, but if our version will be available in a few weeks, they'd prefer to wait for our version, so I wanted to check in. |
Co-authored-by: Volodymyr Kolesnykov <[email protected]>
|
Description
Addresses incorrect
imgtagwidth|heightvalues incore/imageblocks by filteringrender_block, where it can get the attachment ID and intended size from the classes of theimgandfiguretags.From there it looks for the intended size's w|h values in the attachment's postmeta, and add them to the
imgtag for the return.Also fixes incorrect srcsets for block images without having to touch them, since it's upstream of them and supplies the values they need.
Returns original safely and silently on failure. Matches narrowly, and can operate on already-filtered blocks as long as they have the required size and ID classes.
Optional switch for
resizeargs can be omitted, but it could be nice to give folks the choice. I defer to plat as to how to make this switchable (or if we should just lose it for simplicity and brevity).Changelog Description
Added
fix_img_block_sizes filterforrender_blockFixed
Pre-review checklist
Please make sure the items below have been covered before requesting a review:
Pre-deploy checklist
Steps to Test
widthandheightvalues and srcset should all be congruent with its intended size