Expose height and width attributes to 'wp_get_attachment_image_attributes' filter

[divinenephron]

The filter 'wp_get_attachment_image_attributes' allows you to alter the attributes of embedded images. However the height and width attributes aren't passed to this filter. These would be useful to have – I'm making a theme with a fluid layout where I have to remove all height and width attributes to ensure that the browser maintains the attribute of images when they're resized.

I've attached a patch with a fix. In it I've also changed the function 'get_image_tag' so that I could remove the immensely pointless 'hwstring' function.

[divinenephron]

Patch to give the 'wp_get_attachment_image_attributes' filter access to the heigh and width attribues.

[nacin]

I see no reason to move around so much code for such a simple request.

[divinenephron]

Only the changed that are essential to the enhancement.

[divinenephron]

Evidently it's rude to refactor code in an enhancement request – sorry about that.
I've attached "wp_get_attachment_image_shortened.diff" – a file that contains only the changes that are essential to the enhancement. Is that more acceptable.

[nacin]

Sorry, wasn't trying to be rude. It's just really hard to see what's going on when there's a ton of unrelated red and green.

This code looks fine, aside from the coding whitespace. (We use tabs, not spaces.)

[nacin]

I think this has the potential to break the filter, for those who receive an array through wp_get_attachment_image_attributes and build their own, not expecting additional keys.

[scottconnerly]

I too would like to be able to access the image's height/width information from within the wp_get_attachment_image_attributes filter.

[Sam_a]

+1. When I added the wp_get_attachment_image_attributes hook (#8732), I omitted the height and width attributes because wp_get_attachment_image() had used image_hwstring() to format those. But it really doesn't make any sense that they're left out.

[Sam_a]

Replying to nacin:

I think this has the potential to break the filter, for those who receive an array through wp_get_attachment_image_attributes and build their own, not expecting additional keys.

That's true. I wonder how common that is.

[Sam_a]

Let plugins filter image dimensions via wp_get_attachment_image_attributes filter (*props divinenephron*). Restore image dimensions if they're missing after applying the filter (consistent with the wp_get_attachment_image()'s previous behavior). Pass $icon to the filter too. Move esc_attr closer to output. Update documentation. Whitespace.

[Sam_a]

Replying to nacin:

I think this has the potential to break the filter, for those who receive an array through wp_get_attachment_image_attributes and build their own, not expecting additional keys.

Attached wp_get_attachment_image.2.diff should cover that.

Patch may look bigger than it is. ;)

[wpsmith]

Minor modification to lines 695-6, restore null as empty strings

[wpsmith]

Wouldn't it make more sense to "restore" height/width ($attr['width']/$attr['height']) attributes as empty strings rather than their full value?

[Sam_a]

Hi wpsmith,

Under WordPress's current behavior, the width and height attributes don't go through the wp_get_attachment_image_attributes filter, so a plugin that builds its own $attr array and returns it without width and height doesn't actually intend to remove them (as nacin noted in ​#5).

So if we also expose width and height in the filter, we want to continue that behavior — if the width and height keys are missing after applying the filter, restore them to their original values, as if they hadn't been removed.

Plugins that really want to empty width and height can set them to '' or false through the filter to get that.

[anatolbroder]

Maybe you should combine the functions ​get_attachment_image and ​get_image_tag. They try to do similar things, but are both not flexible enough for using in plugins.

We need one low level function lowlevel_image for just creating an image tag from an attribute array.

<img
    alt='Image'
    class='image'
    data-image='{JSON}'
    height='456'
    id='123'
    src='image.png'
    title='Image'
    width='789'
    …
/>

And we need a high level function highlevel_image for own attachment images. The highlevel_image should collect the attributes from image meta an pass them to the lowlevel_image.

[ericlewis]

1. Why were we setting the image width/height attributes to begin with?

2. Why would you need to override this for responsive design? max-width: 100% (or something like it) doesn't suffice?

[wonderboymusic]

No reporter feedback in 4 months.

[SergeyBiryukov]

#30525 was marked as a duplicate.

[hereswhatidid]

+1. Is this being closed simply due to lack of feedback?

[johnbillion]

#20358 was marked as a duplicate.

[dd32]

#20358 was marked as a duplicate.

[puggan]

+1 ReOpen?

[SergeyBiryukov]

Replying to puggan:

+1 ReOpen?

Would be good to have answers to comment:15.

[puggan]

Replying to SergeyBiryukov:

Replying to puggan:

+1 ReOpen?

Would be good to have answers to comment:15.

If you define a max-width, and don't have the height-attribute, it keeps the ratio.
If you define a max-width, and have a height-attribute, it keeps the height.

<style> img { max-width: 100%; } </style>
<div style="width: 150px">
<p>
Image with attributes
</p>
<img src="https://www.google.se/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png" height="92" width="272" />

<p>
Image without attributes
</p>
<img src="https://www.google.se/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png" />
</div>

[divinenephron]

I don't recall the details of exactly why I needed this, but comment:23 (maintain image aspect ratio) sounds like my original reason for opening the ticket.

Apologies for the strangeness of the original patch – I had never committed to an open source project when I wrote it and didn't know about these unwritten norms.

[puggan]

The bugfix that worked up to 5.0.5 stoped working at 5.1.1 :-(
​https://github.com/SpiroAB/WordPress/commit/a56e91190e49befc6a37ac36e317121a0168d8a5

Maybe just an bad merge.

Any news about reopening this ticket?

Trac ticket: https://core.trac.wordpress.org/ticket/14110