Use best fitting embed aspect ratio if exact match doesn't exist #10213
Conversation
|
This is great! It works well. Twenty Seventeen front:
Backend:
However that above is after a reload. There seems to be an issue with the Vimeo video where the 2nd and 3rd time you embed it, it's not properly sized:
I did a little inspecting, and as it turns out, the 2nd and 3rd vimeo embed is correctly identified same as the first one. However the right classes are not applied. Compare, this is the
Now compare with the
Note how the first one has all these CSS classes:
the 2nd and 3rd one only has this one:
Note that if you save the post, then reload, evertything is fine, as you can see in the first screenshot. The missing classes happen only on the first edit. The important CSS class we need to have is Any idea why the classes go missing the first time but appear after a reload? |
That's really strange because this contains a fix specifically for that. I'll take a look again. |
|
Uhm, let me also clear cache and try again. |
|
Ugh, ok, so this does set the classes correctly, but it doesn't make it through to the edit's render. The front end published post is fine, but the edit has problems. |
|
Okay I'm not insane. It feels like we're 99% there, though ❤️ |
|
Yeah, it's just that there are a number of issues with React components and the type of data updating we do here. I'm considering a refactor to make the edit component very simple, and move most of the logic into the part where we select the data from the store. But, looking at this now. |
|
Fix for the issue is in another PR, which currently has a conflict with master and so can't be reviewed and merged. I'll fix that PR, but there's nothing we can do in this one to fix the issue, it's to do with passing around attributes when the embed block changes type (which happens when you paste a URL) and there's a refactor in #10035 to fix that. |
|
In that case I think this is definitely an improvement over we have, especially given how rare embedding the same thing twice is. Expanding for a quick code review. |
|
The other PR will be fixed today and opened up for core review. |
There was a problem hiding this comment.
Code seems fine, just comments about the loop used and function names, but just ping me if my comments are unclear. If they make sense feel free to modify+merge 😄
There's talk of issues here but they're resolved in other PRs so if the UX here is better by @jasmussen I'm cool with the code.
| componentWillUnmount() { | ||
| // can't abort the fetch promise, so let it know we will unmount | ||
| this.unmounting = true; | ||
| receivePreview() { |
There was a problem hiding this comment.
receivePreview seems a bit of an odd name for what it arguably rendering or changing attributes of the preview. I don't know what this.maybeSwitchBlock does because it's another weird maybe function name, but would this be better-named as this.updatePreview? 🤷♂️
That or maybe just use this.setAttributesFromPreview() in place of calling this.receivePreview() and add this. .maybeSwitchBlock() to the end of setAttributesFromPreview. Hope that makes sense!
There was a problem hiding this comment.
It's code we need to run whenever we receive a preview, and to keep things small and the functions easy to read, setAttributesFromPreview and maybeSwitchBlock are split. handleIncomingPreview perhaps?
maybe means that calling that method might do what it says, but the conditions are complex and there's no guarantee. The method is short and documented. You can find the maybe prefix in the parser, in the popover component, in the async-generator middleware, in the block list, and in the format toolbar. And in WordPress core PHP code.
There was a problem hiding this comment.
I know it's elsewhere, but it breaks my brain. I think I want to launch a campaign to improve it. As @aduth has said elsewhere (I'm paraphrasing): "Just because we do it less optimally elsewhere doesn't mean we should here." 😏
But yes, it's not isolated to this patch. I like handleIncomingPreview, that makes more sense to me. 🤷♂️
There was a problem hiding this comment.
I was under the (possibly wrong) impression that it was an established pattern, as it's in both WP core and G, with some of the usage in G being added as recently as last week.
I'll change receivePreview to handleIncomingPreview, that does make it clearer :)
|
It's a good step forward and since the final step is in progress separately, 👍👍 |
|
I'll defer to others more knowledgeable than I, but I don't necessarily agree with the premise of this pull request in assigning an aspect ratio to an element which is not in-fact of that ratio. |
If we know for sure it's a video, then it needs SOME aspect ratio, all videos have them. If the video element behaved like an img, the height would be intrinsically applied. We use this detected aspect ratio to apply a padding that's relatively easily calculated from the dimensions. So as an alternative to css classes we could apply this padding inline. But in the past, inline styles have caused headaches with themes, which is why we went this route. |
Description
This picks the best fit of the common aspect ratios if an exact fit does not appear in our list, for responsive content.
Fixes: #8383 (comment)
How has this been tested?
Embed https://www.youtube.com/watch?v=XT13ijUfSts and check it has the 16-9 style.
Embed https://www.youtube.com/watch?v=uAE6Il6OTcs and check it has the 4-3 style.
Embed https://vimeo.com/139290912 and check it has the 21-9 style.
Embed https://vimeo.com/139290912 again in the same post, and check the new embed has the 21-9 style.
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: