Recent Updates RSS Toggle Comment Threads | Keyboard Shortcuts

  • Peter Westwood 10:18 pm on December 10, 2009 Permalink | Reply  

    Suggest Agenda Items for Dec 17th Dev Chat

     

    • Chip Bennett 9:18 pm on December 11, 2009 Permalink | Reply

      Disclosure of api.wordpress.org data transfer/retention policy: consider adding in some conspicuous location (e.g. options-privacy.php) the following disclosures:

      1) State that core update notification requires sending WordPress version number to api.wordpress

      2) State that plugin update notification requires sending list of plugins with version numbers to api.wordpress

      3) State that theme update notification requires sending list of themes with version numbers to api.wordpress

      4) State how often api.wordpress is queried, what additional data are sent to api.wordpress, what data are retained by api.wordpress, how long those data are retained, and what is done with those retained data.

      • Denis de Bernardy 12:18 am on December 12, 2009 Permalink | Reply

        What I’d like to see instead, personally, is a page on wp.org that actually lists part or all of the information (minus the urls, for obvious security reasons).

        • Matt 3:18 am on December 12, 2009 Permalink

          Agreed, the intention was always to expose as much aggregate data as possible. It could also be useful for plugin authors.

        • Denis de Bernardy 10:40 am on December 12, 2009 Permalink

          Well, in case you haven’t written such a page yet, you’re welcome to reveal the schema used, as well as the existing scripts that take advantage of it. Surely someone will pick it up and write part or all whatever is missing to distribute it in the wild.

      • Matt 3:16 am on December 12, 2009 Permalink | Reply

        The data is retained forever. In addition to every theme and plugin, we’ve developed an algorithm to figure out what blood type you are by the PHP and MySQL version. Plugin data has proved surprisingly useful when paired with spidering your blog posts because by the TV shows you talk about we guess your age and then whether you say “soda” or “pop” tells us your location and bing we have your social security number.

        That makes the data super easy and profitable to sell, which we do. Or rather, did. The main customers buying the plugin/SSN information were some insurance company AIG and Lehman Brothers (sp?) who used it to tweak credit tranches but… apparently that didn’t work or something? Anyway congrats to all the Akismet and All-in-one-SEO users who bought a house last year!

        The not-so-secret plan (I talked about it at WordCamp SF!) is to use the data to predict which plugins are going to become popular before they become popular so we can replace the core team including myself with a script that just auto-merges plugins into core (and removes whitespace from the end of lines).

        Oh, and don’t worry about the organ donor checkbox in 3.0, my liver is probably going to last at least until I’m 28.
        ;)

        • Jeffro 8:22 am on December 12, 2009 Permalink

          Ouch. This response is a Public Relations nightmare. Those bringing up the privacy issues I believe have legitimate reasons for doing so. Shutting down the noisy minority like this is pretty bad. Wouldn’t it have been better to just answer the questions posed with regards to Chips suggestions, especially number 4. I mean, if the types of data, data retention period, and how the data is used were all added to the privacy policy, that would be a step in the right direction. I’m also for telling users up front when they install the software the privacy policy. They might not read it and skip it but then they have no reason to complain.

          I don’t think it’s a good idea to opt-out of any updates. Rather, I would hope that opting out just provides a way to send less data such as blog url and such but still be able to do upgrades.

          I hope the other WordPress enthusiast sites don’t pick up on this or there is going to be another negativity ****storm.

          I’m beginning to wonder when WordPress.org will hire a PR firm lol.

        • Len 8:32 am on December 12, 2009 Permalink

          I’m afraid I have to agree with Jeffro. Although personally I have no problem with either the data sent or data retention (I really don’t care either way) Chip and others have brought up a valid point and responses such as this leave them feeling as if their concerns/opinions are stupid and worthless.

        • Ryan 8:36 am on December 12, 2009 Permalink

          Lol. Amusing response.

          It might pay to add a disclaimer saying you still take their suggestion seriously on the end of stuff like that in future as it could come back and bite you in the rear at some point otherwise. Those speaking up about this topic seem to be quite aggressive about it and they may not see the funny side.

        • Matt 11:48 pm on December 12, 2009 Permalink

          Yes, it was meant as a satire to lighten up the discussion a bit, people seem to be getting a bit serious.

          As to Chip’s specific question about what data is stored, I took a look and it looks like we currently store the latest update sent but no historical info. However I do want to keep historical aggregates for everything so we can tell plugin and theme authors how many people actually use their stuff over time and we can get away from using easily-spammed downloads as a metric for popularity. I believe this is fully covered under the Aggregated Statistics section of the WP privacy policy.

        • Ken 12:07 am on December 13, 2009 Permalink

          While I don’t really care what info you farm, store, and use, responding in this way to people who have a valid concern may provoke them to fork WordPress into something Automattic doesn’t use as a data-farming operation. And perhaps this is the solution: a branch of WordPress without any connection to Automattic, by api call, ownership, direction or input. Would the project survive that? And all this over an issue that has such an easy solution.

          This type of spiteful rebuttal lends credibility to those who have a concern for how this data is used. Who does own that data, and the rights to that data? Is WordPress.org equal to Automattic? Does Automattic have the right to access, without permission or reservation, non-published database information from WordPress run blogs too? How about credit-card and social security numbers, and form emails processed by plugins? Are you worried that how you are really using the data is in fact harmful if publicly known? Is making a disclosure a liability for Automattic? Does some other 3rd party pay a lot for that information?

          Why provoke people just for emotional gratification? The solution isn’t heinous. Disclose what information, how its gathered, how its used, and why its necessary. It’d be nice to have an option for not participating in non-essential data, but not absolutely required, as long as its disclosed what this info is, why its collected, and how it would be used, etc. Besides, next to no one would opt-out I believe.

      • Ryan 8:42 am on December 12, 2009 Permalink | Reply

        For those of you who haven’t read it already and don’t agree with Chip’s stance, I suggest reading through the following trawl of posts:

        http://www.wptavern.com/forum/general-wordpress/1085-wordpress-phone-home.html

        That topic is overly long, but there are some good points raised in there which have solid arguments for and against Chip’s suggestion.

        This is paranoia by those worried about it for their own site. But I’m guessing there is probably a legitimate legal concern too since WordPress.org is storing potentially private data without permission (and yes, some of it is private – read through the forum topic for a better explanation).

      • Ken 7:01 pm on December 12, 2009 Permalink | Reply

        Disclosure somewhere is enough to address the issue. Opting out can be achieved by not using WordPress, or finding/making a plugin. An option in the core is a bad/unnecessary thing. As long as the info is provided, and the user makes an informed decision, there is no problem, no controversy.

        • Chip Bennett 7:22 pm on December 12, 2009 Permalink

          First, not disclosure “somewhere”, but rather, disclosure *within WordPress* (thus, my suggestion of options-privacy.php).

          Second, how can a user make a decision, when that decision (opt-in) is made for the user, with no ability to *change* (opt-out) that decision?

          One can “opt-out” of data transmission by “not using WordPress”? Seriously? How asinine.

          Or, finding/making a plugin? No. The data transmission is built into WordPress, therefore so must be the mechanism to opt-out (again, I am referring to data transmitted for the purpose of *retention*, not for the purpose of update-checking).

          With respect to data *retention*, to say that “an option in the core is a bad/unnecessary thing” demonstrates capricious disregard for the users’ right to control their own data.

          Again, I direct you to stopbadware.org guidelines for transmission of user data to a third party.

          Look at Mozilla’s privacy policy for Firefox: all data transmission is fully disclosed. No data are retained for update checks. A means to opt-out is provided.

          Why should WordPress be any different?

        • Matt 11:50 pm on December 12, 2009 Permalink

          I just spent 5 minutes clicking around Firefox and I can’t find a privacy policy anywhere within the application, nor can I for any of my extensions. Of course on their website it’s easy to find, just like it is on ours.

        • Chip Bennett 1:56 am on December 13, 2009 Permalink

          To find the Firefox Privacy Policy (from within Firefox):

          Help -> About Mozilla Firefox -> Licensing Information (or, open about:license) -> Know Your Rights (or, open about:rights) -> Privacy Policy (link)

        • Mark Jaquith 2:54 am on December 13, 2009 Permalink

          Rather a convoluted process. And the policy is only on their site. Would a “Privacy policy” link in an obscure wp-admin page (we were thinking of a “credits” page) be an acceptable solution? It would be equivalent to Firefox’s communication of their privacy policy.

        • Chip Bennett 4:05 am on December 13, 2009 Permalink

          Oh, I agree, it’s pretty convoluted. I would prefer a more conspicuous location, but I think the implementation is fine. Something along the lines of:

          “WordPress sends certain user data to api.wordpress.org. See the WordPress Privacy Policy for more information.”

          p.s. I’m working on a draft. What should I do with it? Put it up on Trac?

        • Chip Bennett 5:15 am on December 13, 2009 Permalink

          So, here’s my attempt at a draft Privacy Policy for WordPress. Thoughts?

      • Ken 11:19 pm on December 12, 2009 Permalink | Reply

        What I’m saying is enabling a feature in the core to disable updates is “asinine”. Whatever data is necessary for updates should NOT be optional, to be enable/disabled as an option in the core. It should be explain what and why this is. My comment was in support of your numbered list (the above one about disclosure, not the below one about opt-out).

        Non-essential data should be optional. What I was attempting to say, is that disclosing what info is involved here solves the problem. The problem is gathering info without knowledge, and therefor consent. There is no requirement to be able to turn off data transmission because that is technically optional by use or not use, as long as it is made known that use includes such communication. This observation is not “asinine”, its a reality, not matter how distasteful it seems. Your tone is unappreciated. This is the area that seems related to “PR”; that Automattic, a private company, uses data collected from an open-source community project. I believe it is a valid concern. And yet the primary issue can be solved separately with disclosure.

        “First” “Somewhere” does not preclude options-privacy.php, and if you heart is so set on that, then I wish you the best.

        “Second”, if informed of what’s involved, users have a choice in whether or not to participate, and that is the concern here. Not using WordPress is a valid option, not “asinine”. Stating otherwise severely weakens what position your argument has. As far as your numbered list, the only optional information is in number 4 (retention). My statement is that it’s merely unnecessary to solve the problem. I’ve said else where I support a choice on participating in optional data, and agree about data retention, but upgrading should not be optional. It’s still irrelevant to the main concern here.

        I was primarily responding to the thread this comment is in. The one with “disclosures” as the qualifier for the 1-4 list. Your list below is the opt-out list 1-4 of which I am vehemently opposed to 1, 2 and 3. I can only agree with the 4th position, while I am for 1, 2, 3, and 4 above (again, I’m for disclosure 1-4, and against opt-out for points 1-3, while 4 is fine with me).

        So, in summary, opting out of “api.wordpress data retention” would be a desirable option, disclosure in my opinion is all that is absolutely required here.

        • Chip Bennett 11:48 pm on December 12, 2009 Permalink

          “Somewhere” could be taken as http://www.wordpress.org, or essentially, anywhere. My point was that the disclosure needs to be made *to the user*, and therefore, *within WordPress*. Whether that’s during installation, or on the Privacy Options page, or wherever is fine, provided that it’s *within WordPress*.

          And, yes, I do find the assertion that “if you want to use WordPress, your data *will* be transmitted to and retained by api.wordpress; if you don’t like it, don’t use WordPress” to be asinine. It’s along the same user-unfriendly lines of, “if you don’t like it, fork.”

          However, it seems that we’re in agreement on data retention being optional, and I’m not wanting to engage the battle on opting-out of core/theme/plugin updates, having seen the comments here. I already conceded those points. So, I think we’re in agreement on the 4 opt-out points below.

          (And for the record, even if an option to opt-out of update checks were put in, I wouldn’t set it. I like update checks.)

          I pretty much agree that, for the most part, disclosure will solve the problem.

          “So, in summary, opting out of “api.wordpress data retention” would be a desirable option, disclosure in my opinion is all that is absolutely required here.”

          If we had those two: full disclosure and a mechanism to opt-out of data retention, I think the entire matter would go away.

    • Chip Bennett 9:20 pm on December 11, 2009 Permalink | Reply

      Opt-out option for api.wordpress data transfer/retention. On the Privacy Options page (options-privacy):

      1) Allow users to opt-out of core updates
      2) Allow users to opt-out of plugin updates
      3) Allow users to opt-out of theme updates
      4) Allow users to opt-out of api.wordpress data retention

      • Denis de Bernardy 12:16 am on December 12, 2009 Permalink | Reply

        I think you’re beating a dead horse. Users should not be allowed to opt out of updates without a plugin. Period. Those that do can and usually do get hacked, just like they deserve.

        Re the data that is send, I think you’re misunderstanding how the data is used in the first place. Some plugins and themes have identical names. At least the file, author, and url are needed. Working around this issue would require all themes and plugins stored on wp.org to add a unique identifier. That would be a carnage.

        Seriously, the only point that makes any sense in all of this is removing the site url. But even for this, I can see compelling arguments to keep it — in particular if it’s used to weed out spammy plugins used by spammy blogs that then send ping notifications to pingomatic.

        • Chip Bennett 12:40 am on December 12, 2009 Permalink

          Hey, I’m just throwing it out there for consideration.

          As for allowing or not allowing opting-out of core update checks in core, I’m open to that argument. That’s why I split the four out into separate points. I don’t buy it quite so much for plugins and themes, however.

          On the other hand, an opt-out option for data *retention* (as opposed to sending data needed for update checks) simply *must* be included in core. I find no compelling reason presented thus far, against such an option.

          And, if opting-out of data retention were entirely separated from sending data necessary for update checks, I imagine that very few people would have reason not to let WordPress send data for update checks – thus eliminating the security risk associated with disabling update checks.

        • Alex M. 12:42 am on December 12, 2009 Permalink

          I see no reason why it “must” be included. The data is stored and used to determine what minimum version of PHP we should support and the URL is used as the unique identifier.

          It’s not like it’s your SSN being sent. It’s just a URL and some server info.

        • Chip Bennett 12:45 am on December 12, 2009 Permalink

          It *must* be included because it is the right thing to do. WordPress – just like every other application (be it from Microsoft, Google, Apple, Ubuntu, Sony, Nintendo, or anyone else) must respect users’ right to control of and privacy with respect to their data.

          The data being sent by WordPress does not belong to api.wordpress; it belongs to the user. Even short of a legal requirement (which, in some cases, there may be), it is the ethical, respectful thing to do.

        • Jane Wells 4:04 am on December 12, 2009 Permalink

          “Users should not be allowed to opt out of updates without a plugin. Period.”
          +1

        • Jane Wells 4:07 am on December 12, 2009 Permalink

          @Chip: Plugins and themes are just as capable of introducing security risks that need to be closed with updates.

        • Chip Bennett 4:19 am on December 12, 2009 Permalink

          Again, I am most concerned about users’ right to opt-out of data *retention*.

          I am fundamentally opposed to not having opt-out options for all of the above (because, as the owner of the application, the user should have this control), but I’m not wanting to engage in that fight. I suggested them for discussion, but can see where that will go.

          So, conceding the update-check opt-out option in core, what of the data-retention opt-out option in core?

        • Elpie 4:44 am on December 12, 2009 Permalink

          @jane – +1 BUT private, (ie. custom code that is not released to the public or not hosted by wordpress.org) plugin and theme data is being collected. This is nobody’s business except the site owners and should not be reported back to WordPress.

          At the moment, if anyone wants to keep private plugin and theme data private, or if they don’t want their URL associated with the data being collected the only option is to disable update checks completely. If privacy concerns are resulting in deactivating a core feature and WordPress wants users to keep update checks then perhaps it is wise to remove the obstacle.

          Giving users a reason, regardless of whether anyone else feels its a valid reason or not, to disable update checks defeats the purpose of providing them.

          I agree that users should not be able to opt out of update checks without a plugin. But they should be able to control what information is sent and restrict the sending of personal information if they wish or if laws in their own countries require this.

          If WordPress is all about freedom then it should also be about users having freedom to control their own personal information.

      • Alex M. 12:22 am on December 12, 2009 Permalink | Reply

        That’s UI bloat for sure.

        I think a constant in wp-config.php would be much better. Can’t be changed by a hacker who compromises the login and allows blocking before the site is even installed. Then again I’ve never understood these paranoid people who want this stuff blocked.

        • Chip Bennett 12:43 am on December 12, 2009 Permalink

          Is it “UI bloat” for every other application in existence, that must disclose to users when data are sent to a third-party server, and that must provide an opt-out mechanism?

          Why is WordPress exempt?

          And every time I hear someone call people with legitimate concerns “paranoid”, I am going to assume that the speaker is acting arrogant and condescending.

        • Alex M. 12:47 am on December 12, 2009 Permalink

          There is no need to start throwing around insults. Please remember that your opinion is just that — an opinion. Someone is not wrong just because they disagree with you. I for example don’t consider it a legitimate concern.

          Anyway, I’m stepping out of this conversation.

        • Chip Bennett 12:55 am on December 12, 2009 Permalink

          Indeed.

          And incessantly referring to people who express concerns as “paranoid” is no less insulting than calling those who dismiss those concerns “arrogant” or “condescending”. It’s not directed specifically at your comment. I’ve seen that term thrown around here, and on wp-hackers, and at WPTavern.

          Mutual respect gos a lot farther.

        • Matt 12:01 am on December 13, 2009 Permalink

          To clarify, Chip, I think any and all privacy concerns are completely valid to the person making them. I’m passionate about privacy myself, for example I Truecrypt encrypt all my drives.

          Fortunately WordPress is completely open source and you can read every line of code that sends every bit of information, everywhere. (Not possible with most applications!) You can modify the code directly, or use or create a plugin to modify or prevent anything from being sent.

          If you consider your blog URL to be sensitive information, which is exceedingly rare but certainly conceivable, but still want updates I would recommend hashing the URL before sending it. (And also disabling Ping-O-Matic updates.)

          If you consider server IP to be sensitive information, which is exceedingly rare but certainly conceivable, I would recommend either disabling updates with a plugin or by modifying core per above or putting all external requests through some sort of proxy which can be done at the server level or perhaps through extending WP’s HTTP class.

          For the truly cautious, many of these precautions are best handled at the server level, for example using an iptables firewall to block all outgoing connections from a server or anything on it, including WordPress.

          We’re lucky that WordPress is software you can download and configure yourself because it gives you 100% control over every aspect of its operation, and you can run it under any environment you can imagine.

        • Chip Bennett 2:13 am on December 13, 2009 Permalink

          Matt, I greatly appreciate that WordPress is open source, and that everything “under the hood” is available.

          That said, my own PHP skills are marginal at best – and, I would imagine, far above that of the average user. I do not believe it is sufficient to expect an average user to figure out what data are sent to api.wordpress only by looking through the PHP files.

          Further, knowing what is *sent* to api.wordpress in no way provides insight into what is *retained* by api.wordpress.

          And, again, the nature or sensitivity of the data being sent is irrelevant. What is relevant is that the *user* owns the data, and therefore WordPress must still respect that ownership. I have linked (several times) the StopBadware.org guidelines for applications that transmit data to third parties – guidelines that require up-front disclosure, and an option to opt-out. This really isn’t about paranoia; it is about adopting industry standards for regard of user data.

          (Thinking farther ahead, it is also about building trust and goodwill from users, so that you might in the future be able to have users opt-in to having even more data collected, that would prove to be even more useful.)

          I honestly believe that almost everyone would be placated with up-front disclosure of the data transmission (both what is sent, and what is retained), and the ability to opt-out of data *retention*.

          As for the other examples you have given (e.g. Ping-O-Matic): a) the user has complete control over sending data to POM, and b) POM doesn’t *retain* those data (AFAIK).

          Besides, it is not the URL *alone* that would normally be considered sensitive or especially valuable, but rather the cross-reference of other, far more sensitive/valuable data that can be tied together by the URL.

          I don’t particularly understand the push-back on the issue of disclosure. It would be incredibly simple. I’ll even offer to write something up (though I’m sure it would need to be quality-checked, as I’m sure I wouldn’t get everything right wrt the data retention, and it would probably need legal review). Regardless: we write something up, drop it on options-privacy.php (or wherever is most appropriate), and it’s done. Maybe point the user to the location at the end of installation. But that’s it. That’s all that’s needed.

          I do understand, though, that it would require some work to separate update check data from historical/aggregated data, since much of the data are the same, and would have to be sent differently if the user is allowed to opt out of data retention.

          I still think the goodwill/PR gains will far outweigh whatever developer time is required to make such a change.

          Please don’t get me wrong. I LOVE WordPress. I want to be able to praise WordPress as being a leader on the issue of respecting user data, while also being able to use those data for the betterment of both WordPress and the WordPress community.

        • Brad Potter 5:24 am on December 13, 2009 Permalink

          The argument that WordPress users concerned about privacy should seek out a plug-in is flawed in my opinion. That makes the assumption WordPress users are aware that private information is being sent in the first place which is unlikely the case. Second, in order to ensure privacy on future versions of WordPress, the plug-in would likely have to be maintained to ensure compatibility, would it not? If a compatible plug-in was not available say after a significant upgrade then privacy is once again not assured.

          A notification screen viewed at time of WP install and a privacy document with the download package would be a good start.

        • Matt 8:15 pm on December 13, 2009 Permalink

          People concerned about privacy are just fine today — there is nothing we send or do that compromises anyone’s privacy. The information we send is public and regardless we don’t publish anything potentially personally identifiable, like URL, we only publish and use the numbers in aggregate for purposes of improving the software and user experience. This is like how browsers send your IP address with every request, it’s appropriate for 99.99% of the audience and if you’re a political dissident or government employee where that is considered sensitive then you should use a proxy or anonymizer plugin.

          Also Chip’s objections don’t seem to be with anything we send, it’s with the data being retained which isn’t explained anywhere except my comment above, which we can probably put somewhere. In January or February I’ll talk with our legal folks about a revision to the WP.org privacy policy.

    • Denis de Bernardy 1:32 pm on December 12, 2009 Permalink | Reply

    • Elpie 2:11 pm on December 12, 2009 Permalink | Reply

      Please discuss contacting the Software Freedom Law Center for advice (which is free) on what data is legal to collect, how, whether opt-in is necessary given the cross-jurisdictional nature of WordPress distribution, the nature and length of time for retention, whether data matching is permitted, and the type of disclosure that needs to be made.

      http://www.softwarefreedom.org/

      Discussion about these issues is now impossible. It was impossible in 2007 and every privacy concern that has been raised in the past two years has met with similar responses. The only practical way to put this issue to bed is for the team to obtain legal advice and act on it. The SFLC is free to projects like WordPress.

      • Pulse 4:37 pm on December 14, 2009 Permalink | Reply

        Agreed with Elpie on this.

        This entire argument comes down to what you feel is private information and what you feel is not. As an IT guy, I don’t see any of the information that they send as “private”. IP addresses are public domain, so no point in hiding those.

        Plus, as far as users opting out, why should the option even be allowed? I can’t opt out of the Federal government accessing my records of telephone calls, e-mail conversations, or anything to that regard? I can’t opt-out of Verizon Wireless knowing my location at all times? I can’t opt out of publix tracking my spending habits to know when to stock things?

        Disclose how and what data is sent, sure. Just put a link to the privacy policy on WordPress. Beyond that, seriously? come on. Make a plugin if you feel that strongly about it.

        These are realities one must realize in this digital age, and in all honesty, if you don’t like it, Don’t use WordPress. That’s not asinine to suggest, considering that if you don’t like it, find another cms that doesn’t.

    • Denis de Bernardy 3:24 pm on December 12, 2009 Permalink | Reply

      Other ideas that might be worth discussing while on the topic of call home:

      http://core.trac.wordpress.org/ticket/11407

      http://core.trac.wordpress.org/ticket/11280

    • Jane Wells 3:52 pm on December 12, 2009 Permalink | Reply

      The update that sped up the opacity fade in/out on alerts has made it into wordpress.com. Wow, is it annoying. It’s so fast it’s like a flicker and I’m almost worried it will induce a seizure. Okay, that was hyperbolic, but it *is* annoying and eye-catching, feeling very frenetic in comparison to the overall feel of the WordPress admin otherwise. I’d vote for getting rid of the fade in/out. The placement and color differentiation (which is visible even with color blindness) act as ‘this is an alert’ visual cue. I would like us to add an icon or something, maybe, to bring it home, but would suggest waiting until 3.0 for that so we have time to work out proper iconography (an error message should get a different graphic than a simple confirmation message, for example).

      https://core.trac.wordpress.org/ticket/11267

    • Denis de Bernardy 7:37 pm on December 12, 2009 Permalink | Reply

  • Peter Westwood 10:17 pm on December 10, 2009 Permalink | Reply
    Tags: minutes   

    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 | Reply

      Alternatively plugin authors can whitelist sites themselves using the wp_oembed_add_provider() function.

    • Chip Bennett 11:04 pm on December 10, 2009 Permalink | Reply

      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 | Reply

        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 | Reply

      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 | Reply

        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 | Reply

        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 | Reply

        Another possible solution is to have discovery enabled for the [embed] 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.

  • Peter Westwood 8:37 pm on December 10, 2009 Permalink
    Tags:   

    Agenda for Dec 10th Dev Chat 

    * 2.9 Status – Peter/Mark/Jane/Ryan/Matt
    * Oembed discovery enable by default or not – Alex M (Viper007Bond)
    * “Canonical Plugins” – Jane
    * Visibility of Trashed Images (including post thumbnails etc.) #11149 – Peter

     

  • Jane Wells 12:59 am on December 8, 2009 Permalink | Reply  

    Posted on dev blog re canonical plugins, and posted poll to weigh in on what to call them. http://wordpress.org/development/2009/12/canonical-plugins/ #wordpress

     

    • Shane 5:31 am on December 8, 2009 Permalink | Reply

      I still have my reservations about “canocial” plugins. Why there might be more than one developer and they be 100% complaint with WordPress when we go to debug code and then an author is having plugin trouble how can we be sure the plugins are not the ones causing it if we say ‘They work with wordpress 100%’ in which they don’t.

      It would be opening more holes to finding problems and I am afraid that it’s going to staunch growth once we create official plugins that already exist.

      Maybe a certification process instead, that we can say “This meets the security requirements of x.x.x version.” I know we do that with the new “Compatibility” box, but that is no way of saying that a plugin is secured.

      Plus these types of plugins should not be full feature items. Some things are better in core, but that would be decided once the plugins that are going to be developed are known.

      • Alex M. 5:49 am on December 8, 2009 Permalink | Reply

        I found your comment highly confusing, but the purpose of canonical plugins is so that rather than having 10 plugins that all do the same thing (say announce new posts on Twitter), the authors of those plugins combined their forces and develop one common, officially supported and promoted plugin. This is much like WordPress itself — we could all develop our own blogging softwares, or we can combine forces to create a single great project. Nothing is stopping anyone from continuing to make their own version of a plugin, but by making a canonical version, it ensures it’s up to date, keeps working, receives bug fixes, etc.

        A really good example of why this is needed is podPress. It has over a quarter million downloads, but the author is no longer able to maintain it and a lot of people didn’t upgrade their WordPress because podPress didn’t work with the new version. This is bad. Forking it or having someone else take over also aren’t ideal solutions as what’s stopping it from happening again?

        Instead we could make podPress (or something like it) a canonical plugin where it’s officially maintained and contributed to by multiple authors. It’s a plugin that’s really needed by a lot of people (podcasters) but isn’t really something that should probably be in core (lotta users, but they make up a low % of overall users).

    • TobiasBg 10:05 am on December 8, 2009 Permalink | Reply

      I’m not really sure what to think of this concept of “Canonical Plugins”.

      With the concept you presented, I have the fear that we are moving towards a “two-tier plugin society”, where non-canonical plugins will be valued less than they are now. This somehow sounds like an “App Store” for plugins, though not with all of [large computer company]’s restrictions. Questions that I see: What are the minimum technical requirements to be “canonical”? What are functionality requirements (i.e. a small plugin that filter “the_title” is most probably secure, but what’s its value)? Who decides which plugin is considered “canonical” and when? Are there any candidates right now?

      I would like to view “canonical plugins” more as core functions that are not in core but in a plugin. (This, for me, would lead to the name “Core Plugins”.) That way, people could be using/activating only what they need, with the purpose of running a WP that only loads what it needs. Examples for this could be the new image editing functions. They could be in a plugin and people who absolutely want to use [fance desktop graphics program] can disable the plugin. Those plugins would/could still be maintained by core developers (or/and strongly connected developers). Another example is Akismet, which I see as a Core Plugin, as it shows the way how those plugins could be added to core. (Yet there could be an additional screen on the Plugins page with “Core Plugins”, to more emphasize that they are activily maintained.)

      • Jane Wells 2:43 pm on December 8, 2009 Permalink | Reply

        What you’re suggesting is pretty much exactly what we envision.

        • TobiasBg 7:42 pm on December 8, 2009 Permalink

          Now that I read your post again, I don’t really know anymore what triggered me to write the above entry. :-) So, I guess, that’s a good thing :-)
          Let’s see how it turns out.

      • Matt 5:16 pm on December 8, 2009 Permalink | Reply

        Yes, one of my suggestions was to make a new “anti-spam” plugin that’s included with core download instead of Akismet, and have Akismet be one of the services it supports as well as Typepad, etc.

      • Daniel Nautré 6:13 pm on December 8, 2009 Permalink | Reply

        It would be a good thing that some “heavy” features of WordPress would be present as “canonical” plugins to allow WordPress to be “lighter”.
        Another thing that I would like to see, is the ability for plugins to have switches to turn on/off their features. This would allow users to have only the features they need turned on, and WordPress would only load these features while being executed.

        How about porting some features of WordPress to these plugins to make the core engine lighter ?

        • Matt 5:37 pm on December 9, 2009 Permalink

          Light is a function of user interface and speed. We can and have made WordPress lighter without removing functionality before.

    • Aaron Brazell 6:37 pm on December 8, 2009 Permalink | Reply

      @jane I prefer “Plugin Frameworks” over canonical, but I know many in the WP community shy away from the word framework because themers have turned it into a dirty word. ;-)

    • Eric Marden 8:31 pm on December 10, 2009 Permalink

      Framework is not a dirty word… A framework is what you used to build something useful. A plugin framework would be used to build other plugins, not to be used as a plugin directly.

      Either way, framework only says ‘developer tool’ to most folks

  • Jane Wells 11:03 pm on December 7, 2009 Permalink | Reply  

    Does anyone have any question they would be interested in asking the collected group of Matt, Ryan, Andrew, Mark, Peter and me? I was thinking maybe we should do a short video Q&A tomorrow before we all head back to our corners of the world. Who knows when we’ll all be in one place again, right?

     

    • Michael Pretty 2:51 pm on December 8, 2009 Permalink | Reply

      I probably missed my chance of getting this in before everyone started heading home, but I have a concern about the post thumbnail handling. Both support for pages and posts are both tied to ‘post-thumbnails’ support by the theme. Wouldn’t this be better suited if it were post_type specific? Not all themes will have a need for thumbnails for both posts and pages or any other post_types that emerge and if we tie the support of all post_types to one setting the admin will automatically add the post-thumbnail meta box for a post_type even if it’s not supported. Just trying to cut this off before 2.9 is official since changing it in the future would break any themes that depended on ‘post-thumbnails’ support working for both pages and posts.

    • Denis de Bernardy 6:25 pm on December 8, 2009 Permalink | Reply

      I’ve three…

      Firstly: is WP 3.0 really going to merge WP and WP MU?

      Secondly: given that, if it does, a rather large number of plugins (and themes) might break or have serious quirks, what are the odds that we can do some suitably massive re-engineering of the bug-prone parts of WP at the same time? (i.e., steering the WP query towards a better MVC implementation, enhancing the way permalinks work, cleaning up the widgets API, etc.)

      Thirdly: I’ll actually pass on it. I feel like I’m just beating a dead horse…

      • Matt 6:28 pm on December 8, 2009 Permalink | Reply

        1. Yep!

        2. I don’t think it’ll break plugins or themes with how it has been proposed. Regardless, we’ll probably experiment in a separate branch.

        • damien 7:54 pm on December 14, 2009 Permalink

          ouch .. merging is for the 3.0 ? Not for the 2.9 thus … ?

    • arena94130 11:10 pm on December 8, 2009 Permalink | Reply

      ” Frame-pressed plugins ” is ok for me !

  • Matt 8:27 pm on December 5, 2009 Permalink | Reply
    Tags:   

    I caught up on some of the website-specific WordPress.org filed on Trac:

    http://core.trac.wordpress.org/report/26

    If you’ve got a request, suggestion, or patch for the website drop it on Trac under the “WordPress.org” component.

     

  • Ryan 10:37 pm on December 3, 2009 Permalink | Reply
    Tags:   

    Strings are frozen for 2.9 as of the beta 2 release. Happy translating.

     

  • Peter Westwood 10:01 pm on December 3, 2009 Permalink | Reply  

    Suggest Agenda Items for Dec 10th Dev Chat.

     

    • Alex M. 11:30 am on December 5, 2009 Permalink | Reply

      Discuss if oEmbed discovery should be enabled by default or not.

      Pros

      * Better user experience. “Wow, my URL automatically turned into a video from site XYZ.com!”

      Cons

      * Less secure. What if a user posts the URL hackmysite.com/xss-attack/ for some crazy reason. Might be better to have the user opt in since there’s no HTML validation done on the oEmbed result.

      • Eric Marden 8:32 pm on December 10, 2009 Permalink | Reply

        Alex, I think the list of default oEmbed providers is done via whitelist, the API won’t even function for any thing else without a plugin.

        • Alex M. 10:01 pm on December 10, 2009 Permalink

          That’s incorrect. Users with unfiltered_html can currently use oEmbed’s discovery API to embed from unknown websites if the checkbox is checked at Settings -> Media.

          (PS: I wrote all the oEmbed/Embed code that went into the core. ;) )

    • Jeffro 4:57 pm on December 5, 2009 Permalink | Reply

      Regarding the email that went out to all plugin authors, I talked to a couple who had a bunch of plugins on the repository but never received any email. This email needs to be published on the dev blog with clear instructions on how to receive future emails if they didn’t get the first one.

      • Matt 8:27 pm on December 5, 2009 Permalink | Reply

        I didn’t get the email either.

        • Matt 7:57 am on December 6, 2009 Permalink

          Actually I did it just went to my lists folder.

        • Brian Layman 9:12 pm on December 7, 2009 Permalink

          I never end up submitting mine to the repository. So, I can hardly complain. I should probably put one or two out there…

      • Barry 9:27 pm on December 5, 2009 Permalink | Reply

        Could you please email me their details so I can see what happened? barry at automattic dot com. Tx.

        • Brad 9:13 pm on December 7, 2009 Permalink

          I never received the email and I verified the email on my Plugin Directory account is correct: brad at webdevstudios dot com. I also checked spam and my list folders but never found it

      • John Turner 9:14 pm on December 7, 2009 Permalink | Reply

        I did not receive and email as well.

    • Jane Wells 11:04 pm on December 7, 2009 Permalink | Reply

      Canonical plugins. What’s left to ship 2.9.

    • Peter Westwood 12:23 pm on December 8, 2009 Permalink | Reply

      Visibility of Post Thumbnails – In what situations should they not be visible – e.g. Image is Trashed, Parent post is Trashed, Parent Post is Draft, Parent Post is Private.
      http://core.trac.wordpress.org/ticket/11149

  • Andrew Ozz 9:14 pm on December 3, 2009 Permalink | Reply  

    WordPress Developer News: WordPress 2.9 Beta 2 

    WordPress 2.9 is currently in beta and is expected to be ready in several weeks.

    Major new features for developers:
    - comments meta table
    - improved support for custom post types
    - register_theme_directory() for additional theme locations
    - back-ported JSON encode/decode for both PHP and JavaScript

    and for users:
    - oEmbed support
    - “Trash” for posts, pages and comments
    - post thumbnails support
    - basic image editor

    More details are available in the Codex http://codex.wordpress.org/Version_2.9 and on trac.

    New feature in the plugin repository: logged in users can enter compatibility information about all plugins – works / doesn’t work for several recent versions of WordPress. It is still in beta and in data collection mode. When it’s released, the collected information will be available from the wordpress.org API.

    As with every release there are hundreds of improvements and bug fixes. 410 tickets have been closed so far for the 2.9 milestone.

    One significant change is the new “trash” status for posts and comments. It works by changing the post_status or the comment_approved field to ‘trash’. If the post or the comment is restored from the trash that field is set back to it’s previous value. By default items in the trash are deleted after 30 days.

    If you use direct SQL queries you may need to exclude posts and comments that are currently in the trash. Simple example: http://core.trac.wordpress.org/changeset/12254

    Please ensure that your plugin(s) or theme(s) work as expected in WordPress 2.9-beta-2. If you have questions or comments please post them on the wp-hackers mailing list or in the Alpha/Beta forum on wordpress.org.

     

  • Andrew Ozz 8:51 pm on December 3, 2009 Permalink | Reply  

    Agenda for the December 3rd Dev Chat 

    • How do we handle security releases in the admin – Matt Martz
    • Create a post on the wp.org dev feed that highlights what breaks to plugin devs – Denis de Bernardy (we’ve started the WordPress Developer News email announcements as discussed here couple of months ago that cover this)
    • Shall we remove Gears support now or in 3.0
    • Minimum intervals between first beta and final release and between first RC and final – demetris
     

Older Posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel