Make WordPress Core

Opened 6 years ago

Last modified 6 years ago

#44704 new defect (bug)

`` and `oembed/1.0/proxy` don't work as expected

Reported by: 7studio's profile 7studio Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.9.7
Component: Embeds Keywords:
Focuses: Cc:


It seems that and the REST route oembed/1.0/proxy don't respect the maxwidth oEmbed parameter in all cases.

To Reproduce

Steps to reproduce the behaviour:

  1. Create a new post.
  2. Click on "Add Media" button.
  3. Choose "Insert from URL" interface.
  4. Paste a valid YouTube URL:
  5. See the YouTube <iframe> with a 600px width.
  6. Click on "Insert into post" button.
  7. Publish post.
  8. Edit the YouTube video.
  9. See the YouTube <iframe> with a tiny 200px width.

Expected behaviour

The embed contents from Facebook or other services should have the same width when you add or edit them.

Reason found

After some researches, it seems that the problem comes from media-view.js and this part of code:

this.dfd = wp.apiRequest({
        data: {
                url: url,
                maxwidth: this.model.get( 'width' ),
                maxheight: this.model.get( 'height' )
        type: 'GET',
        dataType: 'json',
        context: this

I don't know why the embed content this.model.get( 'width' ) is egal to 0 when we edit it :/ As a result, the default value for the maxwidth argument of the REST route oembed/1.0/proxy can't be used like the first time.

Here is the requested URL:

  1. when we try to embed YouTube video: http://v10.helloprojets.test/wp-json/oembed/1.0/proxy?
  2. when we edit the YouTube video: http://v10.helloprojets.test/wp-json/oembed/1.0/proxy?

This problem is a bit weird and complex. I hope I was clear in my explanations ;)

Attachments (2)

insert-embed.png (109.2 KB) - added by 7studio 6 years ago.
edit-embed.png (25.3 KB) - added by 7studio 6 years ago.

Download all attachments as: .zip

Change History (4)

6 years ago

6 years ago

#1 @swissspidy
6 years ago

Sounds to me like oembed/1.0/proxy works as expected though. It's just the model data that isn't set correctly.

#2 @7studio
6 years ago

@swissspidy I preferred to talk about oembed/1.0/proxy too because the REST route could not accept zero/empty value for parameters and replace them by default values.

IMHO, it doesn't make sense to request content via oEmbed API with empty parameters (especially for YouTube and Dailymotion which return very small version of embeds without them). WordPress could handle/fix this developer mistake ;)

But you are right, the model data of isn't correctly set and it's the main problem.

Note: See TracTickets for help on using tickets.