Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#50137 closed defect (bug) (worksforme)

New IMG sizes (1536x1536 & 2048x2048) names fail in JS/REST

Reported by: bahia0019's profile bahia0019 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: javascript, rest-api Cc:

Description

Additional sizes were added in 5.3. This was a very important fix.

However because the names were named the actual dimensions as integers, and not strings, the names create invalid syntax errors in JS.

For example the first variable below works properly. But the second kicks out a syntax error due to the integers. However, that is the actual endpoint.

  const largeSource = slide.media_details.sizes.large.source_url
  const fullscreenSource = slide.media_details.sizes.1536x1536.source_url

The solution would be to remove the dimensions, and provide names as strings.
I've proposed the names to be Oversize and Fullscreen in the past.
But open to additional ideas.

Change History (3)

#1 @bahia0019
4 years ago

  • Focuses javascript added

I had a thought that if I couldn't access the sizes with JS, than Gutenberg may not be able to access them either.
To test, I opened a new Post and inserted an Image block, and the 1536x1536 & 2048x2048 don't appear as available in the size drop down (medium-square and fullscreen are sizes added by me).

https://i.postimg.cc/L82DWNG0/Screen-Shot-2020-05-09-at-1-11-54-PM.png

#2 @ocean90
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed
  • Version 5.4.1 deleted

Hi @bahia0019, thanks for the ticket. To access the property you have to use the bracket notation: slide.media_details.sizes['1536x1536'].source_url.

The new sizes are not meant to be selectable in the UI as they are only used to generate more suitable srcset attributes.

#3 @bahia0019
4 years ago

@ocean90 Thanks! Your explanation made me do a little googling to learn about the difference between dot and bracket notation.
Is this the only place in the REST api where bracket notation would be needed?
Not being as familiar with the usage, I think having a consistent approach to nomenclature would be important.

Note: See TracTickets for help on using tickets.