Full size CoreImageAttributes.width & .height are null

[johnboylesingfield]

Full size CoreImageAttributes.width & .height are null

[theodesp]

Hey @johnboylesingfield. Thank you for the report.

This is the default behavior. The block editor uses the media details slugs for the default image sizes like medium,large or full. If you override any of the width or height it will store it as a custom style.

Here is how it works:

If you use any of the default image sizes then querying the width and height is null. Instead it uses the sizeSlug attribute:

{
              "apiVersion": 2,
              "name": "core/image",
              "renderedHtml": "\n<figure class=\"wp-block-image size-full\"><img src=\"http://mysite.local/wp-content/uploads/2023/03/3F3F3F3F3F3F_3F3F3F3F3F3F3F-1.webp\" alt=\"\" class=\"wp-image-12\"/></figure>\n",
              "attributes": {
                "sizeSlug": "full",
                "width": null,
                "height": null
              }
            },

If you manually change the width for example it will store it in the width attribute:

{
              "apiVersion": 2,
              "name": "core/image",
              "renderedHtml": "\n<figure class=\"wp-block-image size-full is-resized\"><img src=\"http://mysite.local/wp-content/uploads/2023/03/3F3F3F3F3F3F_3F3F3F3F3F3F3F-1.webp\" alt=\"\" class=\"wp-image-12\" width=\"620\"/></figure>\n",
              "attributes": {
                "sizeSlug": "full",
                "width": "620",
                "height": null
              }
            },

We recognise that this won't be ideal in your case. However we do have a ticket in our backlog to expose the mediaDetails of the particular image resource from the database. This way you will have access to the full size details of the image.

{
              "apiVersion": 2,
              "name": "core/image",
              "renderedHtml": "\n<figure class=\"wp-block-image size-full is-resized\"><img src=\"http://mysite.local/wp-content/uploads/2023/03/3F3F3F3F3F3F_3F3F3F3F3F3F3F-1.webp\" alt=\"\" class=\"wp-image-12\" width=\"620\"/></figure>\n",
              "attributes": {
                "sizeSlug": "full",
                "width": "620",
                "height": null
              }
            mediaItem: {
             "id":"cG9zdDoxMg==",
             "databaseId":12,
            "mediaDetails": {
              "file": "woocommerce-placeholder.png",
              "height": 1200,
              "width": 1200,
              "sizes": [
                {
                   "sizeSlug": "full",
                  "file": "woocommerce-placeholder-1024x1024.png",
                  "fileSize": 98202,
                  "height": "1024",
                  "mimeType": "image/png",
                  "name": "large",
                  "sourceUrl": "http://mysite.local/wp-content/uploads/woocommerce-placeholder-1024x1024.png",
                  "width": "1024"
                }
              ]
            }
          },
}

[justlevine]

This is the default behavior. The block editor uses the media details slugs for the default image sizes like medium,large or full. If you override any of the width or height it will store it as a custom style.[....]. However we do have a ticket in our backlog to expose the mediaDetails of the particular image resource from the database. This way you will have access to the full size details of the image.

I love the additive approach of exposing a MediaItem connection as a workaround.

Would it also make sense to populate a null width and height on the Model? Getting the dimensions of a size slug on the server is a lot more performant than a db query , and would make it easier to design frontend components (e.g. using next/image with a fixed size) without needing to fall back from sizesSlug => width=> mediaItem?.mediaDetails?.sizes( $sizeInput* )?.width.

This "default behavior" feels like a DX bug in Gutenberg, due to common REST endpoint patterns, so it might be worth diverging in this particular case.

(* Not sure offhand if an a secondary connection input can get set server-side, if not the frontend would have the extra step of filtering the sizes array by the sizeSlug).

[theodesp]

Sure we could also explore that option but we will have to make sure that we do not mess up with custom width or height.

[theodesp]

@johnboylesingfield we added the mediaDetails field in CoreImage block. It will be available in the next release version.

[theodesp]

I will post any updates here when this is supported.

[johnboylesingfield]

Thank you!