WordPress.org

Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 2:36 am on September 28, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JSON REST API: Version 0.6 and The Future 

    We’ve finally come to the end of Summer of Code, so it’s time for the final GSoC release in this slightly late update (hey, would it be a post by me if not?). This release is mainly a stability release, so there are only minor changes:

    • Huge documentation update – Guides on getting started and extending the API are now available for your perusal
    • Add generic CPT class – Plugins are now encouraged to extend
      WP_JSON_CustomPostType and get free hooking for common actions. This
      removes most of the boilerplate that you needed to write for new CPT-based
      routes and endpoints (#380)
    • Use defined filter priorities for endpoint registration – It’s now easier to
      inject your own endpoints at a defined point
    • Update the schema – Now includes documentation on the Media entity, plus more
      (#264)
    • Add better taxonomy support – You can now query for taxonomies and terms directly. The routes here might seem strange (/posts/types/post/taxonomies/category for example), but the intention is to future-proof them as much as possible (#275)
    • Ensure the JSON URL is relative to the home URL (#375)
    • Check all date formats for If-Unmodified-Since (#378)
    • Register the correct URL for the JS library (#376)
    • Correct the usage of meta links (#379)
    • Add filters for post type and post status data (#380)
    • Separate parent post and parent comment relation (#330)

    The big feature for this final week is a bunch of documentation changes. I’ve created guides and documents on how to use the API, intended for both beginners and experts. I’d especially like to highlight the Getting Started guide, as well as the Extending the API guide for plugin developers. The documentation in the past has been less than fantastic, so I’ve made a concerted effort towards it this week. In addition, I’ve also fixed up all the remaining bugs reported via Trac.

    Now that GSoC’s over, what’s next? The aim with the project is to now move it from a solo project to a team one, and to that end, I’ve been working on assembling a fantastic team to work on the project with, with aim to integrate the API into core in the future. 3.8 time is fast approaching, so we’ve elected to aim for 3.9 as a more realistic target, although the advantage of the Feature as a Plugin method of development is that we’re not locked down here.

    We’re held two meetings so far as a team, and I’ll announce a proper office hours time next week, but I’m also looking to try something new with the organisation of the team. More to come on that in the next team update, but in the meantime, you can check out the internal team discussion site. Anyone looking to get involved in the team is welcome to join as always, but I’d ask that only those serious about working on the project join, as there are a fair few people committed already.

    Thanks to everyone, especially my mentors and Jen, for making this project a joy to work on so far. Here’s hoping we can keep the momentum as we push forward with the project.

     

  • Andrew Nacin 7:38 pm on September 25, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Meeting today: Road to WordPress 3.7 Beta 1 

    For the meeting today (starts in ~20 minutes), we need to work on getting to 3.7 Beta 1. I think if all goes well, we can release Beta 1 tonight or tomorrow morning. @dd32 has been doing some incredible work on automatic updates. If you haven’t read his post on them, please do!

    So, there are a few things we need to discuss and make decisions on:

    1. Search results ordered by relevance, #7394. Do we take a chance on this?

    2. Should we begin to require that users supply their current password in order to change their password? #20140.

    3. Should we consider a slightly more conservative different approach to transient garbage collection? We do not want updates to be blamed for breaking sites. #20316. What would this approach look like?

    4. How should individuals be notified via email when it comes to automatic background updates? #10787.

    5. How should individuals be notified their own dashboard that their site will be safe if there is a security release?

    Proposal for points 4 and 5: A green checkmark on about.php and update-core.php will let them know their install is OK and good to go for automatic background updates for security releases. (We can easily verify this without prompting the user.)

    If for some reason we attempt an automatic background update and it fails to complete, then we need to email get_site_option( 'admin_email' ). We need text for this email.

    If they don’t have a green checkmark, we should wait five days, after which we email them reminding them a security release is available. A timestamp five days from the point of release will be pushed via the API. Once that time is crossed, an email will be sent. (For a particularly critical situation, we could shorten the timeframe. For a non-security minor release, we might avoid having an email sent all together). We also need text for this email (which will be a fairly nice email).

    This does not accomplish all of #10787 (“Email administrators that an update is available for core, plugins, and themes”) but it seems to be a good security balance.

    ***

    My target is Beta 2 early next week, and Release Candidate 1 as early as next Friday. Here is our current progress on tickets:

    • There are no more enhancements or feature requests open on the 3.7 milestone.
    • There are under 20 tasks remaining for 3.7. Many of these are near completion. These need to be cleared by Beta 2.
    • There are 150 bugs open on the 3.7 milestone. We need to reduce this number to about 75 by Friday, and to zero by the end of next week. As in, these need to be cleared by RC1.

    We’ll likely branch 3.7 at the WordCamp Europe contributor day on October 7, which means anything that is punted out of 3.7 can still make it into 3.8 starting in just two short weeks from now. A reminder, this is a very short release cycle, and 3.8 is just a few months away and begins in earnest very soon. Here is what our philosophies document says about fast, agile release cycles with crisp deadlines:

    The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

    If we’re not confident that three weeks is long enough for something to properly soak in trunk, let’s not be afraid to wait until 3.8.

     

  • Scott Taylor 7:38 pm on September 24, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Featured Content Update 

    Sorry for no meeting this week, it’s been busy at my j.o.b. In addition to the weekly IRC meeting, we now have a Skype conversation going. Add me as a contact on Skype if you want to join in. My Skype username and Trac username are the same.

    The plugin is in the repo:
    http://plugins.svn.wordpress.org/wp-featured-content/trunk/

    Last week, I made a screen to sort featured items within their respective areas. The logic to save the order when sorting still needs to be hashed out.

    Currently, one person is doing the coding (me). This is not ideal, and I could use help. There have been a bunch of mockups, but I don’t currently have time to build a prototype for all of them. If would like to help with coding, please let me know in the comments.

     

    • notaternet 8:35 pm on September 24, 2013 Permalink | Log in to Reply

      Hello, I would love to help with the coding.
      I have just added you to skype.

    • Robert Dall 8:58 pm on September 24, 2013 Permalink | Log in to Reply

      I am working on the UI today… Regardless of my work scheduled…

    • Robert Dall 1:41 am on September 25, 2013 Permalink | Log in to Reply

      The Feature Content Mockups

      Introduction

      My proposed UI for the Featured content is based on the fact that we have already set a lot of the variables up in the content. We already have a field for: The Content, The Excerpt and the Featured Image all in the post editor. So using this to our advantage we only need to tell the featured content what why want in the plugin.

      What Twenty Fourteen did was to call a featured image, the except, categories and put all of that on the front page. This was a great for this one theme. But what if we wanted the full content or only the title and the excerpt?

      First we need to create a featured content area. This can be done in the featured content main screen (also available in the drop down from the main menu on the left)

      Then we need to tell WordPress which posts it will be part of. We can one of two ways.

      1. We hit the Feature this content check mark box in the post editor window and that then shows a drop down of all featured content area’s available. (Which was suggested by Tammie Lister) We should also have the ability much like the tags and the categories to create a new featured content block from with in the post editor.
      – But this could be problemattic if we want to add multiple posts to a featured content area that have already been created.

      2. We can also select the featured content in bulk from the edit posts screen using the bulk actions. We could then assign which posts or pages we want added to the post format. ( I still need some feedback or am fuzzy on how this would actually work but we should have the ability to bulk add / remove from the edit post screen imho. )

      Ok now we can decide what to call in the featured content area. I have learnt that WordPress development is more about Design Decisions rather then Design Choices but to create different featured content we need to give those choices to the user.

      In this example we have the Bread Feature Content. Which we can then choose what featured content we want via check boxes. (I am still looking for a better word then everything)

      • If people wanted to add only a title and the featured image that is available to them. If they want the title and the content area also available.

      • I haven’t added tags and categories because those don’t exsist for pages in my example. But they could easly be shown for posts.

      • If we want add a description like we do for categories / tags that would be an easy add on.

      • Like the WordPress menus / widgets we just drag and drop what post we want in what order.

      • A short code would then be created and put into any page or post you desired (Although I am not sold on the short code solution I don’t know how we would implement different featured content blocks)

    • Scott Taylor 5:05 pm on September 25, 2013 Permalink | Log in to Reply

      Your mockup completely ignores the overrides, which we have discussed ad nauseum, and was in the first iteration of the plugin.

      • Robert Dall 5:51 pm on September 25, 2013 Permalink | Log in to Reply

        Hi Scott

        A little confusion on my part here. In the last meeting you told us to download the latest version of the plugin and install it and get familiar with it. I did that. There is no reference to the overrides that you spoke of already in the plugin. I made some mockups on integration of how I though the latest version of plugin would integrate best into the WordPress core.

        I also couldn’t find reference to the word overrides in the #WordPress-core-plugins or the channel.

      • Robert Dall 6:23 pm on September 25, 2013 Permalink | Log in to Reply

        I wasn’t able to accomplish the interaction of the “overrides” you speak of in the plugin.

        All I get is:

        This is meta box to display fields, etc about the featured post that does exist.

        I can edit my mockups… But with out seeing this functionally it would be a guess on my part as to how it operates…

  • Dion Hulse 3:35 am on September 24, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Automatic Core Updates, an update 

    Over the last few weeks I’ve been working on bringing Automatic Core Updates to WordPress 3.7 through #22704, Up until now it’s been disabled in trunk while development in progress – today however, that all changes.

    As of [25598] WordPress 3.7+ installs will begin updating themselves without the need of user input every time a new security release has been released, or in the case of all us development users, it’ll update daily to the latest nightly if possible.

    Automatic Updates are unattended, and by default, will only update WordPress to security releases (for example, from 3.7 to 3.7.1, but not from 3.7.1 to 3.8). Great lengths will be taken to ensure that no site will break as the result of an Automatic update.

    Note: Filter and constant names may change pending feedback and discussion.

    In order for Automatic Updates to be enabled, there are a few simple requirements:

    1. If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled
    2. If the install is running as a SVN or GIT checkout, automatic updates are disabled
    3. If the constants DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED are defined, automatic updates are disabled
    4. If the constant WP_AUTO_UPDATE_CORE is defined as false, automatic updates are disabled
    5. Your WordPress install also needs to be able to contact WordPress.org over HTTPS connections, so your PHP install also needs OpenSSL installed and working
    6. Wp-Cron needs to be operational, if for some reason cron fails to work for your install, Automatic Updates will also be unavailable

    We’ve also been working on a bunch of related features to make updates even more bulletproof than before, including HTTP, Filesystem, and File verification enhancements, amongst many other things.

    How do I test it?

    If you’d like to test this out, the simplest way is to simply create a new non-svn checkout of trunk and visit the site regularly to make the cron task run.
    If you’d like to test this out, and you’re running SVN/GIT, you can use add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' ); in a mu-plugin to make it ignore the checkout status, note, that you’ll lose any modifications you’ve made to core files.

    After each update, you’ll receive an email with a summary of the actions taken, which will let you know if the upgrade completed, or encountered any problems – the emails are still a work in progress, the email currently in trunk is designed for developers, and may not be the same in the final release.

    I don’t like the sound of this, How do I turn it off?

    1. If you’re using a deployment system that uses SVN or GIT, it’s disabled by default
    2. The simplest way to disable it is to add define( 'AUTOMATIC_UPDATER_DISABLED', true ); to your wp-config.php file
    3. You can also make use of the auto_upgrader_disabled, or, auto_upgrade_core filters

    Are there any more hidden features?

    This is WordPress we’re talking about, of course there’s a bunch more that it can do!

    1. If you’re using a non-English install, this will also automatically update any plugin/theme Language Packs which are installed, hopefully resulting in a better i18n experience, See #18200 for more information on Language packs, there’ll be a follow up post in the near future explaining how and when Language packs will work
    2. Plugin & Theme Updates! – You can hook into the 'auto_upgrade_plugin' or 'auto_upgrade_theme' filters to enable auto-updates of one, or many plugins/themes note: Plugin/Theme updates will not be enabled by default in WordPress 3.7
    3. By default, Core Auto-Updates will only apply to WordPress Security & nightly releases, that is, from 3.7.0 to 3.7.1, 3.7.1 will not automatically update to 3.8.0 – This can however be changed,  you can simply add define( 'WP_AUTO_UPDATE_CORE', true ); to your wp-config.php file and it’ll happen automatically!

    What can I do to help?

    Please test it out and report any bugs you find! Triggering automatic updates can be a little bit difficult since it currently relies upon a twice daily cron job, so the easiest way is to just create a new nightly install and visit the site once a day to cause the cron to be initiated, If you’re game to run it on a production site, please be aware that WordPress will go into Maintenance mode during the upgrade.

    You can also head over to Trac and check out report/48, which is a temporary 3.7 report containing anything related to automatic updates and Language packs (more on that in a few days)

     

    • Joseph Scott 3:43 am on September 24, 2013 Permalink | Log in to Reply

      One small thing: AUTOMATIC_UPDATER_DISABLED is an odd constant name. I thought at one point we were going to stop using negative options.

      I would have expected something more like define( 'AUTOMATIC_UPDATER', false ); instead.

      • Dion Hulse 3:47 am on September 24, 2013 Permalink | Log in to Reply

        That constant was actually inherited from the Automatic Updater plugin. The WP_AUTO_UPDATE_CORE constant is the best one to use to disable core updates, but that doesn’t affect Languages, Plugins, or, Themes.

        I should’ve mentioned it above, but Constants and Hooks are not finalised and probably will change before final release, so feel free to head over to #22704 to give some feedback

      • Franz Josef Kaiser 9:55 am on September 24, 2013 Permalink | Log in to Reply

        Just some thoughts: AUTOMATIC_UPDATER_DISABLED really isn’t the best naming decision. Hope that changes to something that’s telling more precisely what exactly will or won’t be updated if that is set to true. I’d also prefer to get all the WP constants prefixed with WP_. Even ABSPATH isn’t a unique constant in PHP world and can cause conflicts.

        Another thing that would be nice is to have an argument on the filters: Theme or (mu-)plugin name. So authors can exclude their plugins or themes from updates as easy as possible – think about alpha or beta releases and testing candidates.

        • Dion Hulse 10:29 am on September 24, 2013 Permalink | Log in to Reply

          All of the filters pass a) What it is (core, plugin, theme, language), and b) the details about the update + slug, upon re-checking, there are a few that don’t pass as much context as they could (‘auto_upgrade_ignore_checkout_status’ is the first one i noticed) which I’ll get updated.

          This post didn’t actually cover all of the filters included either, there’s a bunch more in there at almost every logic statement, you can even opt-out of receiving a summary email after the upgrade is completed. Closer to release time once all filters/constants are locked down with their naming, we’ll update a codex page, or make a post, or something :)

          I’ll get a list of filters / constants up on the Trac ticket tomorrow and let a discussion evolve over naming from there.

    • Shapeshifter 3 4:02 am on September 24, 2013 Permalink | Log in to Reply

      Howdy,

      I’m been using this plugin from Gary Pendergast: http://wordpress.org/plugins/automatic-updater/ for the past week or so, and really like it.

      Should I now uninstall it, to prevent conflict or duplication of code?

      Will I still have the options to turn on/off updating of themes and/or plugins?

      Will the plugin be discontinued?

      • Dion Hulse 4:07 am on September 24, 2013 Permalink | Log in to Reply

        There should be no conflict between core and the plugin, that being said, the plugin is mostly superseded. @pento will be able to let you know the future of the plugin, I suspect it may end up as a UI for the core features rather than implementing them itself though.

        There are no built in options in core to enable automatic updating of Themes / Plugins at present, only filters (Which i’ve been using for all my testing). A plugin can easily enable it as needed.

        To enable Automatic Updating of Plugins and themes, I use this code in a mu-plugin:

        // Upgrade Plugins and Themes
        add_filter( 'auto_upgrade_plugin', '__return_true' );
        add_filter( 'auto_upgrade_theme', '__return_true' );

        • Gary Pendergast 3:20 pm on September 24, 2013 Permalink | Log in to Reply

          As @dd32 suggested, the plugin will live on as a wp-admin UI for the update options, and perhaps some advanced options, too.

          If you’re comfortable using @dd32‘s mu-plugin, there’s no need to keep Automatic Updater installed.

          • Trifon 9:06 pm on September 24, 2013 Permalink | Log in to Reply

            If the plugin will stay to provide a UI for the function, I’ll stick to using that in favour of the trimmed down mu version.

    • lgladdy 7:05 am on September 24, 2013 Permalink | Log in to Reply

      In production installs for clients, we use DISABLE_FILE_MODS to stop them being able to break things too much.

      is there a way to enable automatic security upgrades, but keep the user from doing anything manually?

      • Dion Hulse 7:24 am on September 24, 2013 Permalink | Log in to Reply

        For the record, I accidentally referred to DISALLOW_FILE_MODS as DISABLE_FILE_MODS in the post (and the code), both are now corrected.

        However, at present there isn’t a way to have both the constant defined, and allow the automatic updates.
        DISALLOW_FILE_MODS is designed for a scenario where WordPress is being used in a Deployment environment, in that environment you don’t want any file modifications to take place to core files, as such, it disables all updates (+notifications), plugin/theme installs, and plugin/theme editors.

        Disabling Plugin updates is potentially worse than not having core updated, although both need to be kept up to date, plugins are also often exploited due to vulnerabilities.

        If you just want to disable the Plugin/Theme editors, and leave updates/installations alone, you can use the DISALLOW_FILE_EDIT constant instead, if you want to get rid of all user-facing update notifications, prevent installations, etc, then you can also make a custom User Role which lacks the capability to perform those actions.

        Also worth noting, #25219 which aims to re-enable Update notifications (but not updates) for users who have DISALLOW_FILE_MODS defined.

        • RicaNeaga 7:27 am on September 24, 2013 Permalink | Log in to Reply

          Why should users be forced to look into the code for this? Of course it’s easy to add, but still… why not an option in the settings? Something like ”Enable Automatic Updates? True (default) / False” :)

          • Knut Sparhell 9:07 am on September 24, 2013 Permalink | Log in to Reply

            1. Users are not forced to look into the code. There will be plugins for this, even the current Automatic Updater will probably let you disable minor core updates.

            2. Decisions, not options principle How should a user decide what is the best and/or safest option? Displaying this as an option says there is a risk of some kind to let it stay on. WordPress would have to express a warning not to disable this, so then, why is it there?

            3. Introducing an option defeats the whole point of this enhancement. The enhancement was not just to add a new option, but to automatically do minor updates, since they are most security related.

            If, and when, WordPress enables Core Major as an automatic update, such option can be discussed again. Core Major may introduce new features than can alter plugin or theme functionality, so this may not be desired.

            But my idea, if and when Core Major is offered, and the next major is in RC, WordPress will ask the user if he is ready to upgrade automatically when released? (Y/N). This answer will be valid for one major release at time.

            If and when WordPress is offering automatic updates to theme and plugins, this could be as an option for each plugin or theme, eanbled by the plugin/theme author.

            For now, Core Minor is the target, without an UI option to turn it off.

            • RicaNeaga 8:03 pm on September 24, 2013 Permalink

              Ok, now I understand. Thank you for the explanation. :)

    • Simon Wheatley 8:28 am on September 24, 2013 Permalink | Log in to Reply

      I hope you at least considered using `define( ‘UPDATE_ALL_THE_THINGS’, true );`? :)

      • Dion Hulse 8:37 am on September 24, 2013 Permalink | Log in to Reply

        During initial patches, the Cron callback actually was wp_auto_upgrader_upgrade_all_the_things :)

        Still considering a constant by that name to enable Plugin+Theme+Core Major release updates though :)

        • Knut Sparhell 8:44 am on September 24, 2013 Permalink | Log in to Reply

          Please don’t. Enabling updates other than Core Minor should remain plugin territory (filters) in 3.7, even if core is able to perform the actual updates.

          • Dion Hulse 9:06 am on September 24, 2013 Permalink | Log in to Reply

            Curiously, Why do you see a Constant as being worse, than a user installing a plugin or using a filter?
            A plugin could simply define the constant, which would effectively be the same thing.

            Honestly though, we’re trying to avoid constants like this, instead relying upon filters, so Update-it-all is better suited to a plugin at this point.

            • Knut Sparhell 9:14 am on September 24, 2013 Permalink

              Mostly because, as you say, it’s better to let a plugin add filters than constants.

              And a constant makes it tempting for more (end) users to alter their wp-config.php to add yet another constant, when what they would need is a UI so they can see what extras are enabled.

              Constants in wp-config.php, if any, should be a thing for developers.

            • Knut Sparhell 9:21 am on September 24, 2013 Permalink

              Last sentence of my previous comment should be:

              Constants in wp-config.php, if any, should be a thing for developers having to restrict things for the site (but restrictions should also go into mu-plugins, when possible).

    • Knut Sparhell 9:48 am on September 24, 2013 Permalink | Log in to Reply

      This implementation looks to be even better than I hoped for. This is great! WordPress may proudly announce this new enhancement (not feature) for 3.7. From now on, when a serious vulnerability is discovered, WordPress may patch millions of sites in a few hours, making WordPress a far more robust platform and a real “set-it-an-forget-it” platform. This is the way WordPress is actually used by millions, while WordPress, until 3.7, haven’t really supported this approach and still remaining a safe platform.

      WordPress used to come with a warning, you MUST check for updates, but this is widely ignored. May site owners don’t visit their admin area (log in) for many months, as they may be satisfied with quite static “home page” type of site. And if they go into admin, they don’t dare to change anything if they are not completely sure that there is no side effect. So they leave without updating, just to be sure they didn’t do anything wrong, anything at all. Their site “works”, and that’s all they care about for now, not knowing their site may be vulnerable to attacks.

      From 3.7 there will also be possible to update the previous major release, if I understand it correctly. (After 3.8 is released, sites still on 3.7 may receive critical updates, if the lead committers decides this should be done?)

      I just wonder, what is the priority when both WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED are true? I guess AUTOMATIC_UPDATER_DISABLED will decide, correct?

      • Dion Hulse 10:09 am on September 24, 2013 Permalink | Log in to Reply

        From now on, when a serious vulnerability is discovered, WordPress may patch millions of sites in a few hours, making WordPress a far more robust platform and a real “set-it-an-forget-it” platform.

        That’s one of the hopes, We also have the ability to control when an auto-update is released, for example, 3.7.1 might be announced/released as normal, and the auto-update would roll out 12 hours later if there’s been no reported injuries from the update – Not that there are often dramatic issues with security releases, which is why we’re confident we can launch with that.

        From 3.7 there will also be possible to update the previous major release, if I understand it correctly. (After 3.8 is released, sites still on 3.7 may receive critical updates, if the lead committers decides this should be done?)

        Whenever possible, WordPress has attempted to keep the previous branch up to date.
        For example, when 3.6 was released, the 3.5 SVN branch was “up to date” security wise, There’s stuff in the 3.5 branch that was never released as a 3.5.3.
        We could’ve released it the same day as we released 3.6, but there was no need to.. WordPress would just prompt users to update to 3.6 completely skipping over it. Many people who run large WordPress networks are aware of that and will pull in the branch updates while they continue to test the next major release.
        Come 3.8 though, as you realise, that can change, we can continue to patch 3.7.x and have users benefit from it. There’d probably be a cut off for back ports of security updates (ie. when 3.9 is released, 3.7 would stop getting security updates or something like that) but that isn’t something that’s been discussed yet.

        I just wonder, what is the priority when both WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED are true?

        You’re right, the Disabled status will prevail, In the case of the Disabled constants, as soon as it’s hit, it stops even considering doing something, it’s a big red sign that says “Don’t do anything” – It’s really a kill switch.
        WP_AUTO_UPDATE_CORE (along with the filters which act upon it) is really just a preference if the upgrader isn’t disabled

        • Ian Dunn 4:14 pm on September 24, 2013 Permalink | Log in to Reply

          We also have the ability to control when an auto-update is released, for example, 3.7.1 might be announced/released as normal, and the auto-update would roll out 12 hours later if there’s been no reported injuries from the update

          …or maybe 12 hours earlier? That’d give us a little jump on anyone looking to exploit the vulnerability between the time it’s announced and the time the auto-update happens. Having a 12 hour window where a vulnerability is known-but-not-patched makes me uncomfortable, and lately I’ve been patching my installs within ~60 minutes of the new tag hitting the repo.

          Obviously attackers could setup a script to e-mail/SMS themselves when the SVN repo gets a new tag, but not all of them will, so it might help a little.

          • Dion Hulse 3:29 am on September 25, 2013 Permalink | Log in to Reply

            A 12-hour window would still be better than the several days/weeks that many people don’t update their installs at present.

            The timeframe was simply a example, there’d be no reason it couldn’t be made available at the same time as an official release if the core developers were confident in it.

        • Milan Dinić 9:29 pm on September 25, 2013 Permalink | Log in to Reply

          From now on, when a serious vulnerability is discovered, WordPress may patch millions of sites in a few hours, making WordPress a far more robust platform and a real “set-it-an-forget-it” platform.

          But will .org servers survive this? :)

    • Marcus 10:03 am on September 24, 2013 Permalink | Log in to Reply

      Very nice feature, great work Dion!

      There’s so many ‘static’ sites out there that get created and forgotten (I actually stumbled across a 3.1 site only yesterday!), this is perfect for those situations.

      Whilst the idea of doing this to business-critical sites somewhat makes me feel uneasy (mostly due to the fact that unecessary problems like plugin/theme jQuery incompatibilities with newer library updates), this’ll make the web a slightly safer place overall!

      • Dion Hulse 10:23 am on September 24, 2013 Permalink | Log in to Reply

        mostly due to the fact that unecessary problems like plugin/theme jQuery incompatibilities with newer library updates

        The good news is, such libraries would rarely be updated in a point release, It would only be if there was a particularly bad cross-site-scripting vulnerability or similar in the Javascript library which would cause it to be done – and even then, we’d not update to the latest version of the library, we’d simply update to a compatible security release (ie. 1.7.0 to 1.7.1).
        WordPress’s backwards-compatibility mantra also means there’s very rarely a break in compatibility, and if there is, it’ll be in a major release with a LOT of thought put in to it, and every possible alternative considered.

        • Knut Sparhell 1:01 pm on September 24, 2013 Permalink | Log in to Reply

          This not just good news, is part of the foundation of WordPress release policy: Point releases should only fix what’s needs to be fixed this way, that is security and regression. No stuffing in all the latest and greatest of external libraries, even how well tested. Minimal to no risk of breaking compatibility with whatever. Everything that does not have the purpose of making the branch more stable will have to wait to the next main release. This has always been the policy, as far back as I know.

          Even core hacks will probably survive, as the updates are incremental on file basis. Right?

          I hope the sceptics, the “no-automatic-updates” people, reads and understands this policy, and the main reasoning behind this enhancement. And then, if still sceptic, just see how easy they can avoid the whole thing by a introducing some constant, or, even better, installing a simple plugin.

    • Andrew Nacin 1:59 pm on September 24, 2013 Permalink | Log in to Reply

      Just adding something here: It will be against the policy of the plugin and theme directories for a plugin or theme to forcibly update themselves using the filters outlined here.

      • Knut Sparhell 2:28 pm on September 24, 2013 Permalink | Log in to Reply

        Seriously?

        So “Automatic Updater” will not comply with the policy? It auto updates itself. Will it be ok to auto update other themes or plugins, except itself? Can’t believe this.

        • Gary Pendergast 3:23 pm on September 24, 2013 Permalink | Log in to Reply

          It doesn’t specifically update itself, and it doesn’t force the update – it only updates itself when you enable updates for all plugins.

          I’ll be releasing an update soon that uses the core automatic upgrade routines, so it will quite literally be a wp-admin checkbox for the core functionality.

        • Ipstenu (Mika Epstein) 3:44 pm on September 24, 2013 Permalink | Log in to Reply

          No, the plugin is complying with our policy. It’s automating the update process for everyone, not ‘just’ itself. I know it sounds like hair-splitting, but this is clearly not ‘a plugin that only updates itself’ and instead is ‘a plugin that automates updates.’

          We’ve had ‘em before, like the old WP plugin that would let you update WP inside WP (before that was in core), and they’ve always been allowed :) What isn’t would be if, say, Akismet automatically updated itself, and ONLY itself, when it had a new version.

          • Knut Sparhell 11:43 pm on September 24, 2013 Permalink | Log in to Reply

            Thanks for the clarification. I still think this rule is silly, though. I can see the need for rules that stops plugins from silently and forcefully take away some control the admin expects to have. But a plugin, that in its description says it will update itself, I would consider creative, whatever method used. Anyway, this “aside” discussion should probably be taken elsewhere.

    • Ipstenu (Mika Epstein) 3:46 pm on September 24, 2013 Permalink | Log in to Reply

      If the install uses FTP for updates (and prompts for credentials), automatic updates are disabled

      My install uses FTP for updates, but I have an FTP userID and password in my wp-config. So am I right in assuming this will work as expected and update me?

    • George Stephanis 4:38 pm on September 24, 2013 Permalink | Log in to Reply

      Love it.

      I personally won’t be using it, but for folks that it’d be useful for:

      https://github.com/georgestephanis/update-control

      It adds in tickboxes to the Settings > General for folks that need to be able to specify them manually through the UI.

      It’s already submitted for consideration on the plugin repo, it’s open to pull requests or changes wherever.

    • Mike Schinkel 6:11 pm on September 24, 2013 Permalink | Log in to Reply

      +1 for disabling updates when using SVN and Git.
      -1 for omitting the same check for Hg/Mercurial.

  • aronwp 4:11 pm on September 26, 2013 Permalink | Log in to Reply

    Ok, I was all for the automattic core upgrades after finding out it would not be major WordPress releases since people say that minor releases don’t break anything. Yesterday I upgraded a site to 3.6.1 from 3.6 and the site broke. (i had a backup so no big deal) but if this would have been an automattic update on a production environment the client would of been real mad. (this guy is not a happy camper) The site broke due to a plugin that worked fine on 3.6 but not on 3.6.1. It’s a woocommerce gravity forms product addon extension and here is the change log.

    “2013.09.12 – version 2.4.6
    * Fix: Remove wp_get_referer() in constructor for compatibility with WordPress 3.6.1 load order. ”

    This proves that anyone saying that a minor release cant break a website is dead wrong. Don’t get me wrong. I would love automattic upgrades but it’s not ready for mainstream yet. At least not that I can see.

    Aron

  • Ryan Hellyer 8:59 pm on September 26, 2013 Permalink | Log in to Reply

    This is a truly awesome addition to WordPress. Thanks to all of those who assisted with hammering out the plan and implementing it.

  • kevinjohngallagher 1:42 am on September 27, 2013 Permalink | Log in to Reply

    Friends,
    Shockingly I have an issue, but I think we can clear it up.

    As of [25598] WordPress 3.7+ installs will begin updating themselves without the need of user input every time a new security release has been released

    Although not a fan of automatic updating, I can understand the desire to implement it (the horse has bolted, so I’m not complaining). My challenge is the definition of “SECURITY RELEASE”. That’s not the same as x.1 release.

    In fact, every x.1 and x.2 release WordPress has had since 2.6 has included more than security fixes (bug fixes, functionality, small things that have been worked on, and presentation changes). If we limit this updating to SECURITY releases, then I’ll crawl back into my cave – but that is not something we’ve done so far.

    3.6.1, for example, had 22 code changes, of which 4 of them were presentation changes. Don’t get me wrong, bug fixes are great, but fixing a presentation bug for TinyMCE in iOS5 only… not security!!
    (http://core.trac.wordpress.org/changeset/25187)

    To stress, I think the code developed here is incredible, and it’s an awesome step forward. But I feel that the processes behind it are taking a very very huge leap without notice or in-depth edge-case planning.

    • Have we solved the process problem before the coding one?
    • Are we tagging security releases AND updates as separate minor releases?
    • Are we prepared to not release bugs we’ve fixed until the next major version?

    I’ve looked for the answers to these questions, and I can’t find them.

  • Kat Hagan 1:47 pm on September 23, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Post By Email: OPW is over! 

    I can hardly believe it, but my summer internship is drawing to a close.

    This week, I released version 1.0.4 of the Post By Email plugin, comprised of minor bugfixes, tests, and documentation as I prepped the project for its evaluation phase.  I’ve added quite a bit of info to the readme page, including better installation and configuration instructions.

    Those of you following along on Trac may have noticed that I’ve kind of run out of tasks.  :)

    Today is the official end of the OPW and GSoC programs, so I’ll be taking a short break from development work during the evaluation period.  But this isn’t goodbye!  I definitely plan to stick around and continue working on and supporting this project in the future — so keep those bug reports coming!

    I do want to take a second to thank all of you for being here for me as I learned the ins and outs of WordPress this summer.  I feel really good about where this project landed, and I know it’s because I had so many amazing resources every step of the way.  So, to everyone who left me comments, answered my questions on IRC or Twitter, reviewed my code, tested, reported bugs, offered suggestions, spoke at WCSF, or even just edited a Codex page or wrote a quick tutorial now and then: THANK YOU.  It really made the difference in those moments when I felt frustrated or overwhelmed.

    I don’t know exactly what the future holds, but I do know that I love being a part of WordPress, and I’m excited to continue working with y’all.  Let’s keep in touch.  :)

     

  • Lance Willett 11:10 pm on September 20, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    Twenty Fourteen project update 

    We’re continuing regular office hours on Tuesdays and Thursdays at Tuesday 17 UTC) as well as general “Bundled Themes” bug scrubs, Fridays at 18 UTC.

    Done since last time:

    • Accent color theme option added: #25220
    • Added a “Contributor” page: #24863
    • Lots of layout and style fixes
    • Fixing how Genericons are loaded: #25085

    In progress:

     

  • Alexander Hoereth 10:02 pm on September 17, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Code Revisions: Last Week 

    The code revisions plugin reached version 0.95 - just leaving enough space for some final readme updates and hopefully no more bugfixes (because of no more bugs).

    But still, some final important enhancements got into this update. Mainly to ensure that all related revision data is removed when a package (theme or plugin) is uninstalled (#395).

    Last week now is about creating a screencast for you, the community and wrap up the documentation.

     

  • Brian Richards 9:49 pm on September 17, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Inline Docs Progress for 3.7 

    After last week’s weekly Inline Docs meeting we decided to begin doing a weekly ticket triage on Wednesdays.

    As of last Wednesday, we’re happy to report that 19 patches have been committed to core from 12 different contributors. We’ve also updated the original make/core post to reflect the files that have been completed (please go claim some!). You can see the full report of last week’s triage on Trac. It’s really spectacular, and you should show some gratitude towards Drew for putting the report together.

    Finally, beginning this week, our weekly inline-docs office hours are moving to #wordpress-sfd on Freenode. They’ll continue to be held on Wednesdays at 18:00 UTC, and we hope you can join us!

     

  • Aaron Jorbin 9:10 pm on September 13, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JavaScript Unit Tests for Core 

    Recently WordPress added QUnit as a JavaScript unit testing framework and added its first JavaScript unit tests. I thought I would walk through how to run the tests and how to write tests so that we can increase our JavaScript test coverage. All of these are based upon using the develop.svn.wordpress.org checkout which is where the JS unit tests live.
    (More …)

     

    • Ryan McCue 1:37 am on September 14, 2013 Permalink | Log in to Reply

      For anyone who’s wondering what the hell is going on on Windows: You have to run grunt via the Windows command line, and you cannot run it via Cygwin. If you do run it via Cygwin, you’ll see random inexplicable errors and missing output. It’s pretty annoying (in fact, it stops me from using Grunt), but you can’t really do anything about it.

    • adamsilverstein 6:17 pm on September 14, 2013 Permalink | Log in to Reply

      Great post, thanks for keeping this moving!

    • K.Adam White 5:50 pm on September 16, 2013 Permalink | Log in to Reply

      For those on Windows, the “msys” shell that installs as “Git Bash” when you download the official Windows build of Git should work fine once you install the Windows build of Node.

  • Ryan McCue 8:27 am on September 12, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JSON REST API: Version 0.5 

    This week, I finally have a new release for you! Version 0.5 is now available, with the following changes (and more!):

    • Add support for media – This has been a long time coming, and it’s finally at a point where I’m happy to push it out. Good luck. (#272)
    • Separate the post-related endpoints – Post-related endpoints are now located in the WP_JSON_Posts class. When implementing custom post type support, it’s recommended to subclass this.

      The various types are now also only registered via hooks, rather than directly in the server class, which should make it easier to override them as well (#348)

    • Add page support – This is a good base if you’re looking to create your own custom post type support (#271)
    • Switch from fields to context – Rather than passing in a list of fields that you want, you can now pass in a context (usually view or edit) (#328).
    • Always send headers via the server handler – Endpoints are now completely separate from the request, so the server class can now be used for non-HTTP/JSON handlers if needed (#293)
    • Use better error codes for disabled features (#338)
    • Send X-WP-Total and X-WP-TotalPages headers for information on post/pagination counts (#266)

    As always, the full changes are available if you’re interested.

    This week finally brings media into the fold. The process for uploading media is a little different to creating normal posts, so here’s how you do it.

    First, upload the file via a POST request to /media. This can either be as a standard HTTP multipart body, with the name field set to file, or as a raw file in the body with the Content-Type header. (You can also optionally send a Content-MD5 header if you’d like the server to check the consistency of your file.) This will give you a 201 Created status, and point you to the new resource. You can now update that resource with the correct post data.

    This multistep procedure is required to enable raw file uploads, and I’m not entirely pleased with it, but it’s the only way without requiring multipart requests. I’d love to have feedback on this system, as I think practical use will eventually reveal the correct method here.

    So, it’s time to start winding up the Summer of Code portion of the project. There’s still one week left for the Summer of Code project, so you may still see a release next week, but most likely in the form of smaller updates, especially with documentation and testing. As I finish up, it’s time to look forward to the future of the project. The plan is to form a Feature as a Plugin team as we work towards core integration in future releases. People have already volunteered for the team back in the 3.8 scoping days, and I’ll be getting in contact with them shortly, but it’s not too late to nominate yourself for the team; let me know if you’re interested.

    Thanks to everyone for testing and for your feedback. Stay beautiful.

     

  • vusisindane 8:41 pm on September 20, 2013 Permalink | Log in to Reply

    tried to wp_enqueue_script (“wp-api”) on localhost (windows + xampp) and I get my url + fullpath + wp-api.js

    seems to be a bug.

    something like this:
    http://localhost/dbeblog/wp-content/plugins/C:/Users/Vusi Sindane/Documents/Devlopment/dbeblog/wp-content/plugins/json-rest-api

  • vusisindane 9:17 pm on September 20, 2013 Permalink | Log in to Reply

    I forked the project and fixed it: https://github.com/vusisindane/WP-API

    • ← 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
    shift + esc
    cancel