WordPress.org

Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 8:47 pm on October 4, 2013 Permalink | Log in to leave a Comment  

    Featured Content, 10/4 Update 

    I finally put a bunch of work into the coding of the plugin, and I think it is fairly robust at this point. Whether it makes it into core ( or whether it even should) is up for discussion, but I would like to share what I have.

    First, check out the latest code in trunk here: http://plugins.svn.wordpress.org/wp-featured-content/trunk/

    To guide development, I made the following list of requirements. It should also be easier for people to follow along when we can all agree on an initial set of facts:

    UI

    Wherever possible, existing WP functionality and screens will be used. The user should be able to associate posts with Featured Content theme areas as easy as selecting a category or making a post sticky, but, to be more robust, the user should be able to override certain features of a post when it is displayed as a Featured Item in a theme. Example: different title when featured vs what is displayed for a the full post, different image when in a featured module vs the featured image for the post when displayed in single.php.

    Post Type / Taxonomy

    1. A Featured Item uses the featured_item post type
    2. A featured_item belongs to a Featured Area
    3. Each Featured Area is a term in the featured_area taxonomy
    4. Post types can opt in to featured content by adding featured_area taxonomy support
    5. Themes can opt-in by supporting  ’featured-content’  (the plugin currently brute-forces it)

    Creating / Deleting

    1. Add a post with featured area(s), make sure featured item(s) are created
    2. Trash the post, delete permanently, make sure featured item(s) are deleted
    3. Featured item should not have a title when created, it should inherit from the parent post when empty – view in list tables to verify
    4. If a featured item’s title is edited, it should show that in the list table, unless it is empty
    5. Add a post with a featured area, item is created. Edit post to belong to a featured area, 2nd featured item should be created.
    6. Delete one of the featured items, the other should remain, the post should be linked to only one featured area.

    Transitioning Post Status

    1. Add a post in draft status, make sure featured item is in draft status
    2. Move a post in draft to publish, make sure featured item is moved as well
    3. If a post was created with 2 featured items and one is trashed: if the term is re-linked to the post, the item in the trash should be untrashed, instead of creating a 3rd item

    Trash / Untrash

    1. Trash a post, make sure the featured item(s) are deleted
    2. Untrash a post, make sure the featured item(s) are not created
    3. Trash an existing featured item, make sure post loses tax association
    4. Untrash an existing featured item, make sure post regains tax association
    5. Permanently delete existing featured item, make sure post loses tax association

    Quick Edit

    1. The Taxonomy box for featured items should be present in Quick Edit
    2. All saving logic should fire in AJAX save routine for Quick Edit

    Sorting/Re-ordering

    1. All featured items should be re-orderable via the Re-order items screen
    2. menu_order should be set when items are reordered, only those that change should be sent
    3. When new items are added to a featured area, they should be appended to the end of the list, not the beginning

    Returning Data

    1. By default, featured item contains the post data of the post it belongs to
    2. If any fields have been overridden(post_title, post_excerpt), the post data is a merge of the 2
    3. If the featured item has a featured image, the theme can override by using the property ‘image_id’ to grab the featured image on one of the decorated $posts that is returned when applicable

    Yeah, so that is a mouthful. All of these use-cases are listed in the comments at the top of the plugin file as well. There’s been a lot of discussion about new UI. If someone wants to think way outside of the box and introduce new screens, keep the above in mind.

     

  • Sam Sidler 7:15 pm on September 30, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Making preparations for 3.8 

    As mentioned previously, 3.8 development officially opens shortly after 3.7 ships. With the first beta of 3.7 behind us and the final release scheduled for mid-October, it’s time to talk about what’s expected of feature plugins.

    @nacin mentioned at last week’s dev chat that 3.7 will likely branch at the WordCamp Europe contributor day, on October 7. At this point, most core developer focus will be on shipping 3.7. However, feature plugins that want to be considered for 3.8 should be ready by October 14 to give everyone time to review them.

    What does being ready mean? Here’s what will be examined:

    • a strong and well-tested user experience
    • fully-baked design
    • positive feedback from the community
    • core-quality code
    • no major bugs or issues
    • a belief that the feature belongs in WordPress core

    Some of the above is subjective and will vary from feature to feature. If you have questions, look to a lead developer for guidance.

    Of the feature plugins listed, the furthest along are MP6 and global admin search, with Dash not far behind. Plugins in the “feedback” stage should be prepared to answer the question “Why should we include this in core?” As of today, they should prepare their code for core, removing anything unnecessary and making the feature into a patch that can be easily merged with core.

    tl;dr

    • Feature plugins wanting consideration for 3.8 should be ready for presentation and inclusion by October 14.
    • Feature plugins will undergo review shortly after 3.7 ships.
    • Plugins must be ready to merge when the merge window opens.
     

    • Weston Ruter 7:24 pm on September 30, 2013 Permalink | Log in to Reply

      We’ve also been making great strides with the Widgets UI Refresh, specifically with the customizer integration (from my perspective). The plugin project for this is Widget Customizer, and development is happening on GitHub. I’m hoping that we’ll have the remaining issues addressed by October 14th.

      /cc @shaunandrews

      • Bryan Petty 8:06 pm on September 30, 2013 Permalink | Log in to Reply

        Hi Weston, it appears like the widgets team working on this decided to switch the plugin being used for development on this effort entirely just 6 days ago… this shouldn’t happen honestly. If your team has decided on a direction to go in, it should be integrated back into the officially tracked plugin as listed on the core plugin tracking page.

        That aside though, it’s usually a good sign that the plugin is not really “ready for core” when major decisions like that are being made even in the last week here. Nothing new there has had time to be discussed, tested, and generally baked – and it’s really hard to get that feedback when development isn’t even being done on the official plugin where it’s supposed to be.

        • shaunandrews 11:57 pm on September 30, 2013 Permalink | Log in to Reply

          We haven’t switched. We’re developing multiple concepts and testing them simultaneously.

          That being said, I don’t think we have (or will have) “a strong and well tested user experience” by October 14.

        • Weston Ruter 5:28 am on October 1, 2013 Permalink | Log in to Reply

          OK, thanks. I’m obviously over eager. Sorry to jump the gun.

    • Jonatan Santos 8:32 pm on September 30, 2013 Permalink | Log in to Reply

      One point that could be seen would be a button to turn the text to uppercase and minuscule vise versa in menu text editor

      • Mark-k 3:43 am on October 1, 2013 Permalink | Log in to Reply

        As far as I know non latin langs, which are used by more people then latin ones, don’t have uppercase/lowercase distinction, therefor IMO this kind of feature should not be in core

  • Mufasa 4:22 am on October 2, 2013 Permalink | Log in to Reply

    It’d be really great if there was a way to collapse menus in 3.8 (or 3.7). If you look at the following image you can see that in order for me to drag the menu at the bottom to the top I have to do quite a lot of dragging.

    If I could collapse the encyclopedia menu so that I can’t see all those children it would be useable… well if the page didn’t grind to a halt with that many menu items it would ;)

    So I was thinking you could either have a button to collapse them OR when the user starts dragging they close. Which is something we executed in another app and its quite nice to use. I’ve thought the same UI would be nice on the widgets admin page too.

    Thoughts?

    Menu Pain: http://files.kiwijs.org/dan/arghhh.jpg

    • Sam Sidler 5:01 am on October 2, 2013 Permalink | Log in to Reply

      I’d recommend filing a ticket (perhaps there’s already one on file). Fixing that in the way you suggest isn’t something that would be covered by a feature plugin, though there was a (now on-hold) proposal for merging pages and menus.

  • 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.

     

    • Hassan 2:05 pm on September 26, 2013 Permalink | Log in to Reply

      Perhaps not really important, but why specifically five days before sending the reminder email? Any significance? Or just a “reasonable” random number?

  • Shapeshifter 3 5:39 pm on September 27, 2013 Permalink | Log in to Reply

    Has this release been postponed for a while?

  • Mattias Tengblad 7:13 pm on September 27, 2013 Permalink | Log in to Reply

    Please provide at least pot files for the language teams

  • 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.

    • Sebastien 6:00 pm on September 24, 2013 Permalink | Log in to Reply

      This is an interesting feature. I will add this to the custom config setup in the next update for my WordPress Online Installer, WPSetup.

    • 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!

     

    • ← 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