Closed reefdog closed 9 years ago
Bumping this. In summary: would you guys be okay with me nixing the 600/620px defaults above and letting WordPress's own default embed widths/heights be the initial default? So precedence goes:
That seems ok to me.
This makes sense to me, too.
While adapting the plugin for oEmbed, I wanted to maintain 100% backwards compatibility with existing defaults and shortcode attributes. Here are the current size defaults:
(Quick aside: oEmbed services, including ours, expect
maxwidth/maxheight
, but WordPress standardized onheight/width
for its embed shortcodes, so it does a dance to mapheight/width
tomaxwidth/maxheight
right before the oEmbed provider is called. I'll support both, with a priority preference forheight/width
out of deference to WordPress.)The existing plugin has this priority order (lower number = higher priority):
[documentcloud width="…"]
)get_option()
above)Normally, in the absence of user input, WP applies the theme's own content width to the embed's width (and applies a standard multiplier to set a height). You can track this back from
WP_oEmbed->fetch()
towp_embed_defaults()
to the$content_width
in a theme'sfunction.php
file. But we never fall through to that case because of the plugin defaults.I'd like to recommend we remove the plugin defaults and, absent an explicit shortcode or user-defined default, let WordPress push through its theme-specific default embed sizes.
Impact: any existing plugin user who hadn't set widths explicitly (either in a shortcode or in their default settings) and then upgraded the plugin might be surprised to have their existing embeds "upgraded" to the theme's idea of a proper embed width/height. (Though presumably they'd have to open and save the post to have the shortcodes reprocessed.)
@eyeseast / @aschweigert, y'all know this landscape far better than me. What do you think?