-
Summary of Dec 10th Dev Chat
-
2.9 is getting close with about 30 tickets remaining.
- The majority feel that the new default post is too verbose and blurs the line between content and documentation too much so we are going to remove it from this release and revisit the concept of better post-install user experience for 3.0
- We are going to remove the Trash support from Media because it does not have a consistent experience and the moment. You can easily end up with images that have been Trashed still visible in the content of your site and there is no easy fix at the moment – we probably need to switch from direct image links in posts to using shortcodes and make other changes before this part of the Trash feature is rock solid.
- Oembed discovery of unknown sites will be disabled by default and the admin ui option to turn this on will be removed and replace by filters/hooks to make it easy for a plugin to do if a user wants to opt for this unsafe option – we would rather they let us know of other sites that should be whitelisted by default as they are trusted.
- Jane filled us in on the current status of the “Canonical” plugins name vote current numbers Core: 1130, 34% Official 818, 24% Canonical 563, 17% Validated 399, 12% Other 215, 6% Standard 175, 5% Premium 55 2% In the Other bucket, there were a lot of votes for certified, verified, recommended, approved and a bunch of others meaning generally the same thing. Also a couple suggesting we use “core extensions’” instead of core plugins. The general favourite among those present was also with the core name. We will wait until the poll has finished and then review the overall results.
Alex M. 10:19 pm on December 10, 2009 Permalink
Alternatively plugin authors can whitelist sites themselves using the wp_oembed_add_provider() function.
Chip Bennett 11:04 pm on December 10, 2009 Permalink
Is it not self-contradictory to call *any* plugin “core”, since by definition a plugin is an extension to, rather than a part of, core?
Further, to what are such plugins “core”? I assume thewy will not be installed by default, thus they are neither part of the core code nor part of the core download package.
We are setting ourselves up for headaches and confusion if we call such plugins “core”.
caesarsgrunt 12:18 pm on December 11, 2009 Permalink
I agree with this. I think the best terms are Certified and Official.
Dre 3:21 pm on December 11, 2009 Permalink
Core plugins is going to confuse people.
Official being second in the vote would be most appropriate if we based it on the poll results.
Ben Huson 3:34 pm on December 11, 2009 Permalink
I agree, Official is a better description.
Plugins are not ‘core’ – that’s why they are pugins.
Otto 6:27 pm on December 11, 2009 Permalink
Ugh. I’m really, really not happy about eliminating the usefulness of oEmbed by making no easy way to turn it on.
I *highly* recommend that a canonical plugin be created to allow easy enabling of this. I’ll even write the plugin if necessary.
Chip Bennett 7:41 pm on December 11, 2009 Permalink
Doesn’t the change just impact oEmbed *discovery*? All whitelisted oEmbed sites would still work as expected, right? (Or am I misreading the change?)
Otto 8:29 pm on December 11, 2009 Permalink
You’re correct, but IMO, discovery is the best part of oEmbed. To be able to simply plug any sites URL in, without specific support for that site, and have it magically work… That’s very cool.
Using a whitelist system implies a lack of trust in the admin (or anybody with unfiltered_html capabilities). The admin owns the site, if he wants to post embedded code from an untrusted site, then that’s his business.
I have no problem with limiting discovery to unfiltered_html. I do have a problem with disabling discovery by default and not having any way to enable it.
Peter Westwood 10:16 pm on December 11, 2009 Permalink
The change is only to remove the option to skip the whitelist.
Due to the way oEmbed works and the trust you need to place in the sites you are embedding I strongly believe that a whitelist is the only secure way for this feature to work out of the box. The hooks are there to make it easy for a plugin to override the whitelist or add sites to the whitelist.
Otto 5:33 pm on December 14, 2009 Permalink
Yes, I know. That’s exactly the change I don’t like.
I, as an administrative user, have the ability to post unfiltered_html code, and I don’t want to use any sort of “whitelist”. Making me have a plugin to disable this part of the WordPress code is asinine.
If you don’t support oEmbed discovery, then IMO you aren’t really supporting oEmbed. You’re removing the best part of the whole thing and intentionally crippling it to just a few selected sites.
And the whole idea of making somebody install some kind of “per-site” plugin to modify the whitelist is equally silly. The thing doesn’t need a whitelist to function correctly.
You want to be safe by default, fine. Leave the option there and put a big “warning, not safe” label on it. I’m perfectly happy driving without training wheels.
Alex M. 11:50 pm on December 14, 2009 Permalink
The option would still be there, there’d just be no UI for it. A plugin would have to enable the discovery.
Alex M. 12:19 am on December 12, 2009 Permalink
Another possible solution is to have discovery enabled for the shortcode but disabled for the URL-on-it’s-own-line. There’s a chance someone could accidentally embed something by posting it on it’s own line, but if they go to the trouble (via a UI or manually) of wrapping it in the shortcode, then we can be sure they want to embed from that site.
Otto 5:34 pm on December 14, 2009 Permalink
So now I need a plugin to eliminate the need for the shortcode? Equally silly.
I want full oEmbed. I don’t want some crippled half-assed version of it.
Lari 9:51 pm on December 16, 2009 Permalink
Great that you post a summary now, thanks.