Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the Change
In PR #19, we fixed a bug around calculating the height and width of an SVG to properly use the
height
andwidth
attributes and then fallback to theviewbox
attribute. This was definitely a bug that was good to fix but the issue here is for any previously uploaded SVGs that had different dimensions in theheight
andwidth
attributes as compared to theviewbox
attribute, this can cause wrong image dimensions to now be used.For instance, if an SVG had a viewbox of
0 0 32 32
and awidth
of 200 andheight
of 200, even though we look atheight
andwidth
first, because of the bug, those values were never used and instead, 32x32 would be used as the SVG dimensions (and stored as image meta). With the bug fix introduced in #19, we now properly use theheight
andwidth
attributes but in this example, we still have 32x32 stored, so we end up with two different image dimensions. This can cause the SVG to be either too big or too small and we also output two separateheight
andwidth
attributes on the resulting<img>
tag. This PR reverts that particular change. This does re-introduce the originally reported bug, which we'll need to still solve.In PR #23, we fixed a bug around overriding the height and width values of an image to be
false
, when those values are expected to be of the type integer. This was causing an issue with certain aspects of Full Site Editing (the logo block in particular) and could potentially cause issues elsewhere. This is again a legitimate bug that should be fixed but this introduced some issues.In particular, if directly using
wp_get_attachment_image
, the size requested will now be used for the image tag, instead of the actual size of the SVG. As an example, an SVG with dimensions of 30x30 but a requested image size of medium (default to 300x300), 300x300 will be used on the resulting<img>
tag, making that SVG larger than expected. This PR reverts that change and thus brings back the original issue but resolves backwards compatibility.Checklist:
Changelog Entry