WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from September, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 9:32 am on April 15, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Last Week in WordPress Core 

    Hello there! This is Last Week in WordPress Core for the week of April 8-April 14. Similar to last week, commits are included up to RC2, which was released today. In addition, maintenance releases 3.8.3 and 3.7.3 are available, and automatic updates are rolling out.

    Customizer

    • Widgets: Properly handle widget settings when activating a previewed theme. [28124] #27767
    • Widgets: Account for a sidebar with no container to which classes can be added. [28100] #27780
    • Custom Headers: Fix image ordering. [28102] #27791
    • Custom Headers: Fix cropping when working with large images. [28101] #27790
    • Add color scheme support for widget choosers. [28122] #27793

    Theme Installer

    • Improve route handling and make ?theme= work. [28123] #27708
    • Revert to proxying through PHP for WordPress.org API requests to ensure we have valid installation nonces. [28126] #27798

    TinyMCE

    • Update TinyMCE to 4.0.21.1. [28066] #27744
    • Update TinyMCE paste plugin to the latest development version. Improves Pasting from Word to remove inline comments and change tracking. [28089] #27771
    • Ensure vertical resizing and menubar show/hide are set to default for each TinyMCE instance. [28059] #27724
    • Stabilize MediaElement within TinyMCE, and avoid adding undo steps when the body of a wpView changes. [28084] #27389
    • Improve fallback compatibility for wpViews with IE7 and 8. [28062] [28063] #27546

    Media

    • In the Image Details modal, remember the last state of the advanced toggle. [28125] #27366
    • Add hooks for wpeditimage TinyMCE plugin and Image Details modal. Includes wp.media.events, which is intended to be a global media event bus. [28095] #27698
    • Apply new add_image_size() cropping preferences to all sizes when image is saved in editor. [28072] #19393
    • Fix tabbing out of the title field on Media->Edit Media screen. [28069] [28070] #27750

    Internals

    Externals

    For the complete list of commits to trunk, check out the log on Trac. Release is scheduled for this Wednesday, so, the best way to help is to test! Please let us know if you run into problems in the Alpha/Beta forums or on trac.

    Thanks to @azaozz, @dd32, @DrewAPicture, @ehg, @GaryJ, @gcorne, @helen, @jesin, @johnbillion, @kerikae, @kpdesign, @mattheu, @matveb, @melchoyce, @morganestes, @nacin, @ocean90, @Otto42, @pavelevap, @redsweater, @ryelle, @scottlee, @SergeyBiryukov, @siobhan, @westonruter, @wonderboymusic, and @yoavf for their help this week!

     
    • Stagger Lee 5:03 pm on April 15, 2014 Permalink | Log in to Reply

      I am using WP Beta tester plugin, latest nightly and video playlist is still missing. Audio playlist is there. Is it normal for this beta moment ?

      • Mike Schroder 6:44 pm on April 15, 2014 Permalink | Log in to Reply

        Have you uploaded any videos? The “Create Video Playlist” option should appear on the left in the “Add Media” modal after you have videos uploaded to compile into a playlist.

    • Stagger Lee 8:23 pm on April 15, 2014 Permalink | Log in to Reply

      Yes i see now, thank you. Tried to upload it with FTP client first. (C/P, localhost) Still a bit confusing for beginners.

      Do you plan to make same styled playlists for Youtube videos ? I know there are plugins for it, but it is core code, style is fine and URL option is already there.

  • Mike Schroder 7:33 pm on April 9, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Last Week in WordPress Core 

    Howdy everyone! This is Last Week in WordPress Core for the week of March 31-April 7. I’m including all of the commits up to RC1 this week, which was released yesterday. Things are looking good, with very few remaining tickets open.

    3.8.2 and 3.7.2 were also released with security fixes, and automatic updates are rolling out.

    Developers, please test with your plugins and themes and let us know if you find issues.

    TinyMCE: As a quick note, since I’ve seen this brought up in the forums — in this release, TinyMCE no longer uses wpdialogs. This means it now needs to be enqueued by any plugin that wants to use it. As of [28024], there is a clarified warning that will appear in the JavaScript console if you attempt to use it, and it’s not enqueued.

    IE8 & wpview: Due to IE7/8 compat being necessary in TinyMCE (to resolve caret issues), IE8 and wpview are not currently the best of friends. Post RC1, fixes landed for #27546 that make wpviews degrade more gracefully.

    Media:

    • Playlists: Make elements in playlists responsive and fix playlist advancement on mobile. [27894] [27895] #27625
    • Playlists: Set preload='none' for the empty <audio|video> tag. [27974] #26779
    • Playlists: Make tracks keyboard-accessible. [28023] #27644
    • A/V Shortcodes: Remove support for a caption in audio and video shortcodes. This was part of a UX iteration for the related MCE views, but these captions have since been excluded. See [27640]. [27979] #27320
    • Edit Image Modal: Make the calculation of the aspect ratio more robust. [27942] [27948] #27366
    • Do not show featured images for image attachments; remove post_supports_thumbnails() and theme_supports_thumbnails() for now. [28051] #27673

    HTML5 Galleries:

    • Remove <br> elements for HTML5 galleries; see #26697. [27914] #27637
    • Twenty Thirteen and Fourteen: Update styles to support the new HTML5 line-break-less galleries. [27926] #27637

    Admin:

    Theme Installer:

    Widgets

    • Trigger jQuery events for widget updates. widget-added when a widget is added to a sidebar and widget-updated/widget-synced for widget soft/hard updates. [27909] [27969] #19675; #27491
    • In WP_Widget, introduce is_preview() method to allow widgets to check to see if they’re currently being previewed via the customizer. [27966] #27538
    • Widget Customizer: Improve compatibility with plugin custom scripts and styles for widgets. [27907] #27619
    • Widget Customizer: Rename inject_preview_css to print_preview_css. [27968] #27534
    • Widget Customizer: Use postMessage to highlight widgets in preview or sections/controls in Customizer. [27892] [27893] #27622
    • Widget Customizer: Refactor and clean up WidgetCustomizer as wp.customize.Widgets, and make available widgets panel a Backbone view. [27985] [27986] [27988] [27995] [28034] #27690

    TinyMCE

    • Update TinyMCE to 4.0.21. [27897] #24067
    • Image Details Modal Improve look-and-feel, and add a Custom Size option to the size drop-down that reveals fields for soft-resizing the inserted image. [27918] #27366
    • Image Details Modal: Move all advanced options under a single toggle, bring back the field for CSS Class, and optimize CSS for responsive layout. [27898] #27366
    • Drag and Drop Uploading: Add new argument to wp_editor() to enable. [27901] #27465
    • Gallery Views: Avoid JS errors when image attachments lack metadata. [28008] #27691
    • Return to loading /langs/[locale].js and /langs/[locale]_dlg.js from PHP to prevent errors with missing translation files when requireLangPack() is used without its second argument. Back to using ISO 639-1 (two letter) locales. #24067; [27922] #27610
    • Clarify error when wpdialogs is not enqueued. Add wp_enqueue_editor action fired when scripts and styles for the editor are being enqueued. [28024] #16284
    • Update translatable strings. [27927] #27453, #24067
    • Tighten up toolbar and tab styles. [27978] [27983] #27279
    • Expose toolbar keyboard shortcut in Help documentation for TinyMCE, and clean up TinyMCE help dialog, removing duplicated text and leaving only Keyboard Shortcuts. [28029] #27024; [28032] #27100

    Database:

    • Fall back from ext/mysqli to ext/mysql if the connection fails. This allows us to avoid breaking a site that works under ext/mysql but is misconfigured for ext/mysqli. [27935] #21663
    • Add $allow_bail argument to wpdb::check_connection() to match the connect method. [27925] #27240
    • Don’t pass a second argument to mysqli_fetch_field(). [28002] #27693
    • Rename USE_EXT_MYSQL to WP_USE_EXT_MYSQL. [28022] #21663

    Internals:

    • Updates: Record Plugin & Theme update statistics like we do for Core updates. [27905] [27906] #27633
    • Pingbacks: Forward pingback IP during verification. [27872] #27613
    • Dashicons: [27989] [28005] [28013] #26936
      • New icons: .dashicons-external, .dashicons-editor-contract and .dashicons-universal-access-alt.
      • Updated icons: .dashicons-code, .dashicons-universal-access, .dashicons-arrow-x-alt and .dashicons-arrow-x-alt2.
      • Restores .dashicons-post-trash as an alias for .dashicons-trash, which is the new one.
      • Use new icons in Widget Customizer.
    • Don’t try to resolve symlinks for single-file plugins. plugins_url() should not be used in this context anyway. [27999] #16953
    • Remove old links_recently_updated_* DB options that never had a UI. [27916] #27649
    • Deprecate wpmu_current_site(). [28009] #27702

    Many thanks to @adamsilverstein, @andykeith, @avryl, @azaozz, @bramd, @chiragswadia, @davidmarichal, @dd32, @dpe415, @duck_, @DrewAPicture, @DrProtocols, @ehg, @eightface, @empireoflight, @gcorne, @helen, @jackreichert, @jdgrimes, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @jond3r, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @matveb, @mcsf, @melchoyce, @michael-arestad, @nacin, @Nessworthy, @norcross, @obenland, @ocean90, @pento, @plocha, @rachelbaker, @rmccue, @sdasse, @SergeyBiryukov, @siobhan, @sonjanyc, @tellyworth, Tom Adams, @vancoder, @westonruter, and @wonderboymusic for their help this week!

    For the complete list of commits to trunk, check out the log on Trac. Since we’re getting very close to release, the best way to help is to test! Let us know if you run into problems in the Alpha/Beta forums or on trac.

     
  • Mike Schroder 10:29 am on March 13, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week in WordPress Core 

    Hi there! Welcome to Last Week in WordPress Core for the week of March 3–9. By now, you’ve heard that WordPress 3.9 Beta 1 is available! Thank you for your hard work this last week. Now we’re done adding new enhancements, and on to bugs. Your help is appreciated as we continue to test and squash bugs on the way to a stable RC.

    There are a couple important things that landed on Monday that are not covered in this post, but shipped in beta. Namely, please test the Theme Install screen refresh and the ability to crop headers from within the Customizer.

    Admin:

    • Widgets: Add widget management to the customizer. This brings in the Widget Customizer plugin. [27419] #27112
    • Admin Menu: Introduce a .dashicons-before CSS class and use it in the admin menu. Lets you use a Dashicon before an element without copying the entire .dashicons styling to your :before styling. [27418] [27425] [27444] [27482] #26630
    • Editor: Show “View Post” for any post the author can read. This expands it to private posts and matches the logic in the toolbar. [27483] #27059

    Media:

    • First pass at bringing the Image Editor into the media modal. Please test me! [27445] #21811
    • First pass adding a loading indicator to the Media Library. [27438] #24859
    • Allow $crop in add_image_size() and set_post_thumbnail_size() to receive crop anchors (top, left, right, bottom, center). [27472] #19393.
    • Add subtitle support to Video editing in the Media Modal. [27481] #27016
    • Do not output default gallery styles if the theme has opted into HTML5 galleries. [27396] #27045; see #26697
    • Add a class attribute to the caption shortcode to allow additional classes to be specified. [27404] #25295
    • Add playlist_styles and wp_playlist_scripts filters to allow users to roll their own playlist themes. [27486] #26631 & [27488] #26631

    TinyMCE:

    • Update TinyMCE to 4.0.18. [27387] #24067
    • Add TinyMCE placeholders for audio and video shortcodes and provide a UI to both edit shortcode attributes and replace the src media file in an audio or video shortcode. Also, a flurry of improvements and fixes to them, visible in the full changelog. [27411] #27016
    • Add a Ctrl+K shortcut to open the linking dialog, which is the “de-facto standard”. [27449] #27305
    • Add the <hr> plugin and button to the toolbar. [27428] #27159
    • With drag-and-drop uploading, support multiple editor instances, limit to IE10+, and other small fixes. [27378] [27372] [27464] #19845
    • When parsing a caption shortcode, recreate missing width attributes using the image tag’s width. [27426] #23103
    • Restore the “link” button state to disabled by default and enabled when text or image is selected. Remove the (recently added) default link plugin; not needed. [27447] #27309

    Templates:

    • Add has-post-thumbnail as a post class. [27429] #18804
    • Rename the new page_templates filter to theme_page_templates, and pass it a post object for proper context. [27470] [27471] #13265
    • Introduce get_the_permalink() as an alias for get_permalink(). This better aligns it with other the_* and get_the_* function pairs. [27409] #24164
    • Let get_the_date() accept a post object. [27380] #13771
    • Add the ability to short-circuit wp_nav_menu() via the pre_wp_nav_menu hook. [27386] #23627
    • Better plural handling for labels in wp_generate_tag_cloud() / wp_tag_cloud(). [27376] #27262, see #7989, #14424

    Multisite:

    • Incremental improvements and bug fixes with the multisite load process. Please test your networks! [27406] [27439] [27407] #27003
    • Fix bulk activation of network-only plugins. [27413] #26487

    Query:

    • Add has_password and post_password query variables to WP_Query. has_password true means posts with passwords, false means posts without. post_password can query for posts with a particular password. [27395] #20308
    • Allow a posts_per_rss query variable to be set to override the posts_per_rss option. [27456] [27455] #25380
    • Allow get_page_by_path() and get_page_by_title() to accept an array of post types. [27423] #24763

    Internals:

    • Allow for custom authentication handlers for all requests. Turn the logic used by wp_get_current_user() into a determine_current_user filter. [27484] #26706
    • Allow the role attribute in kses for all elements. [27388] #24098
    • Add a pre_set_theme_mod_$name filter to set_theme_mod(), modeled after pre_update_option_$option in update_option(). [27393] [27402] #14721.
    • Improve HHVM compatibility by eliminating some of our last remaining create_function() calls and making OBJECT a case sensitive constant. [27373] [27374] [27465] #14424 [27377] #27231
    • Pass $reassign parameter to delete_user and deleted_user actions. [27462] [27466] #23057
    • Bail early from shortcode functions if no delimiter is present. It’s the little things; performance results on-ticket. [27394] #23855
    • Update PHPMailer to 5.2.7 from 5.2.4. Includes two trivial modifications for WordPress (no impact to plugin developers); see the commit message. [27385] #25560
    • Use SSL when linking to WordPress.org. [27469] #27115

    For the complete list of commits to trunk, check out the log on Trac. Interested in joining in? Write or test a patch for 3.9.

    Thanks to @adamsilverstein, @akeda, @avryl, @bassgang, @bigdawggi, @bobbravo2, @bpetty, @bradt, @celloexpressions, @coffee2code, @danielbachhuber, @dd32, @DJPaul, @DrewAPicture, @empireoflight, @ericlewis, @ericmann, @frank-klein, @gcorne, @genkisan, @gradyetc, @hakre, @Hanni, @Jayjdk, @jenmylo, @johnregan3, @jorbin, @JoshuaAbenazer, @kadamwhite, @kasparsd, @Kopepasah, @kovshenin, @kpdesign, @lpointet, @markjaquith, @mcadwell, @melchoyce, @michael-arestad, @mikecorkum, @mordauk, @nacin, @obenland, @Otto42, @pavelevap, @Rarst, @rhyswynne, @ricardocorreia, @rmccue, @robmiller, @seanchayes, @SergeyBiryukov, @shaunandrews, @simonwheatley, @sirzooro, @tanner-m, @TobiasBg, @tomauger, @topher1kenobe, @topquarky, @toszcze, @westonruter, @wokamoto, @wonderboymusic, @zbtirrell, and @zodiac1978 for their efforts this week!

     
  • Andrew Nacin 7:51 pm on January 3, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    The email used for notifications on Trac is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.org profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

    We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loop could possibly boost engagement.)

    That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filter Trac emails; you just might need to make some adjustments.

    As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

    NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

    Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

     
    • Ionel Roiban 7:55 pm on January 3, 2014 Permalink | Log in to Reply

      Sounds good.

    • Ryan Duff 7:57 pm on January 3, 2014 Permalink | Log in to Reply

      Is there an ETA on the time this will be changed?

      I’ll have to update my email filters on my .org acct and would like to have it ready to test so my phone doesn’t blow up some night when I’m sleeping.

      That’s why I used a specific “list” acct ;)

      • Ryan Duff 7:59 pm on January 3, 2014 Permalink | Log in to Reply

        Err wait, this is the notification email, not the list email. I may be fine as I think that goes to the same email on my .org profile already.

        Heads up may still be nice for the handful that will have to adjust though.

      • Andrew Nacin 8:00 pm on January 3, 2014 Permalink | Log in to Reply

        Sometime in the next 1-72 hours.

        Note — you have the same email address in both Trac references and your WordPress.org profile. If you were referring to the firehose mailing list, that’s not affected. I’ve added a note to the bottom of the post.

        • Ryan Duff 8:13 pm on January 3, 2014 Permalink | Log in to Reply

          Yup. I’m using a separate address for the svn/trac mailing lists. When I went to verify email filters I realized that the ones that come through as trac notification went to the email on file for .org.

          This week has been a bumble from the start. At least it’s Friday. Thanks for following up!

    • Andrew Nacin 8:08 pm on January 3, 2014 Permalink | Log in to Reply

      Here is a short list of names I recognize who this will affect: @westi @dd32 @viper007bond @sterlo @coffee2code @chmac @eddiemoya @kawauso @lloydde @mrmist @ptahdunbar.

      In most cases, though, the user updated their WordPress profile but never bothered to update Trac. That’s why we’re doing this!

    • Eddie Moya 7:38 am on January 4, 2014 Permalink | Log in to Reply

      I did use “+trac” in my email address to filter for it, so I really appreciate that you went through the effort of figuring out who might specifically affected by it. Otherwise I would have been confused about why my filters stopped working, since this is something I haven’t touched in a very long time.

      Idk if the list is just really that short of people affected – but maybe it would make sense to send out a blast email on trac to let everyone know that way in case they aren’t lucky enough to be the 11 names you listed. Just a thought.

      Thanks again for the heads up.

  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

     
  • Andrew Nacin 5:24 pm on October 26, 2013 Permalink
    Tags: ,   

    New plugin: Background Update Tester, from @dd32 and me. It does what it says… Most sites are able to apply updates in the background. This plugin checks your site for compatibility and explains any problems.

    After activating this plugin, visit the Dashboard → Update Tester screen. (If you are using multisite, visit Updates → Update Tester in the network admin.)

    Feedback and enhancement requests welcome. (I think we should add the ability to send a test email to see that your install can email you.) This is an early rough cut.

     
    • saulsolorzano 5:37 pm on October 26, 2013 Permalink | Log in to Reply

      Excellent! This is greatly appreciated. I’ll check it out. Cheers

    • George Stephanis 6:11 pm on October 26, 2013 Permalink | Log in to Reply

      needs moar textdomain

    • ScreenfeedFr 6:15 pm on October 26, 2013 Permalink | Log in to Reply

      “WARNING: Couldn#8217;t retrieve a list of the checksums for WordPress 3.7. This could mean that connections are failing to WordPress.org.”

      Han! :(

      url: https://api.wordpress.org/core/checksums/1.0/?version=3.7&locale=fr_FR
      response body: [body] => {“checksums”:false}

      • Andrew Nacin 6:46 pm on October 26, 2013 Permalink | Log in to Reply

        You’re likely OK. The plugin can’t tell the difference between get_core_checksums() failing, and simply not receiving any checksums. (Local builds don’t have them currently.) We can fix this by A) converting this warning to a simple ‘info’, and B) always query en_US for now (or avoid showing the warning when not using en_US).

        • Dion Hulse 11:53 pm on October 26, 2013 Permalink | Log in to Reply

          I’d lock it to using en_US, as it’s actually only using it as a 2-fold check to a) make sure communication works, and b) to know which files it needs to check are writable by PHP

    • Ipstenu (Mika Epstein) 9:08 pm on October 27, 2013 Permalink | Log in to Reply

      Wish list – Check if cron is working.

    • Fab1en 9:47 am on October 28, 2013 Permalink | Log in to Reply

      I tested this with a localhost install : 3 green PASS, but one Warning `Couldn#8217;t retrieve a list of the checksums for WordPress 3.7. This could mean that connections are failing to WordPress.org.`. Could it be because I do not have a ssl certificate to sign outgoing https requests ?

      • Dion Hulse 1:43 am on October 30, 2013 Permalink | Log in to Reply

        The Warning is only a warning, it’s not a failure.

        As of right this instant, I don’t think checksums are available for non-english installs, so that’s one possible reason for the notice. Running a Development version may also result in that message, and finally, the HTTP connection to the API timing out would also hit that message.

        So it’s not a sign that Background Updates won’t work, and it’s most likely not a issue, so don’t worry about it unless you can’t update / don’t receive an autoupdate in the next few days ( Background Updates are being rolled out to sites at a slow and steady pace ).

    • DreadLox 1:24 am on October 30, 2013 Permalink | Log in to Reply

      My sites do pass the tests and I know I can update directly without FTP. BUT, it keeps showing that 3.7.1 is available but it doesn’t seems to auto-update itself.

      No error message is showing up, only that 3.7.1 is available. I use a the french version

      • Dion Hulse 1:39 am on October 30, 2013 Permalink | Log in to Reply

        Background updates occur at 7am/7pm Local time (whatever the timezone your blog is set to).

        Background updates are being rolled out at a slow pace to all sites, it may be a few hours before your site has been given the autoupdate offering, and then it’ll wait until the next 7am/7pm timeslot before it attempts the update.

        You’ll receive an email when the autoupdate completes (or if it encounters an error which prevents it from updating)

        • DreadLox 9:51 pm on October 30, 2013 Permalink | Log in to Reply

          24 hours passed, it is now 8am. Still no upgrade. Are localized versions of wordpress supported by that feature ?

    • DreadLox 9:40 pm on October 30, 2013 Permalink | Log in to Reply

      24 hours passed. None updated on its own (yet?), no email received.

      It concerns two websites, on two different hostings. Both had success reported by the Background Update Tester plugin. I’ll report back here, but it seems like the feature fails to me …

      • Ipstenu (Mika Epstein) 10:28 pm on October 30, 2013 Permalink | Log in to Reply

        Are you using non-english WP?

        • Naoko Takano 1:48 am on October 31, 2013 Permalink | Log in to Reply

          I have 2 installs of Japanese version with UTC+9 setting and neither of them has received background update.
          One of them has 3.7-ja (upgraded using Upgrade Now button), the other one is a test site that has been getting successful updates for beta & RC. I’ve turned off the Beta Tester plugin for this one.
          Both are tested for Background Update Tester plugin & on the same server.
          Hope that information helps.

      • Dion Hulse 1:56 am on October 31, 2013 Permalink | Log in to Reply

        Localised (non-english) installs are currently not receiving Background Updates.

        3.7.1 Background updates will be enabled for localised builds shortly, there’s just been some unexpected WordPress.org infrastructure work that needs to happen first.

        They’ll be enabled in the near future (next few days for sure) but in the meantime you can either update manually, or, if you’re not being affected by any of the bugs fixed in it (there’s no security fixes in this release) simply wait a few extra days for it to kick in.

        • Naoko Takano 3:21 am on October 31, 2013 Permalink | Log in to Reply

          Thanks for the update! I’ll let users know & share it on polyglots P2.

        • Chouby 8:29 am on October 31, 2013 Permalink | Log in to Reply

          Could this wordpress.org infrastructure issue explain that core languages packs are not updated? (I mean on an English install with manually added languages packs). According to my tests, it works for themes (tested with twenty twelve) but not for core.

          • Andrew Nacin 8:39 am on October 31, 2013 Permalink | Log in to Reply

            Auto updates require a lot of things on WP.org, while localized builds go through an entirely separate system. It’s taking some time to make sure everything is ready and proper. Will happen this week. Core language packs aren’t enabled yet (also part of the “ready and proper” piece), so that’s probably why they don’t work for you. :-)

            • Rootside 9:44 am on October 31, 2013 Permalink

              I have always installed the default version, but set the language to en_GB in wp-config.php. Does that mean the system is looking for a localised en_GB version?

            • Ipstenu (Mika Epstein) 1:36 pm on October 31, 2013 Permalink

              Rootside, yes.

            • Chouby 2:39 pm on October 31, 2013 Permalink

              Thanks for your clarification Andrew. I’ll be patient.

        • daveshine (David Decker) 10:00 am on November 1, 2013 Permalink | Log in to Reply

          Thanks for the info!
          I fully understand the reasons for it!

          However, what I cannot understand why this info wasn’t communicated upfront from the start of the 3.7.1 release. It currently confuses a lot of users why they don’t get their auto updates. For some of those users the confidence in auto-updates is already “damaged” which is really bad. We all work to convince users to rely on those important security/fix releases and auto background updates are really important. A little info update would have been really helpful.

          • Andrew Nacin 6:03 pm on November 1, 2013 Permalink | Log in to Reply

            From the announcement post: “we will start rolling out the all-new automatic background updates for WordPress 3.7.1 in the next few hours“. In all, it took us about 3 days to fully roll things out. Future releases will be quicker.

            I guess the tester plugin could have also made that clear, but the main way for them to have found that plugin would have been the very next sentence in the announcement post.

        • Rootside 12:29 pm on November 1, 2013 Permalink | Log in to Reply

          I’m with daveshine:

          What’s particularly confusing is that you do get the update notice (“3.7.1 available”), but the auto update doesn’t seem to click. Then the tester plugin reports that everything’s super great, and you immediately start wondering if your system is hooked up right.

          I understand that the delay to the 3.7.1 updates is a one-off, but I think the plugin would be a good place to tell people that the auto-updates run on a schedule and don’t necessarily kick in the second the update is released.

    • Muhammad Aftab 11:42 am on October 31, 2013 Permalink | Log in to Reply

      Nice…

    • kwdavids 12:21 am on November 2, 2013 Permalink | Log in to Reply

      So where does one go if the plug-in says everything passed, but the default-language sites don’t update?

  • Andrew Nacin 4:50 pm on October 25, 2013 Permalink
    Tags: ,   

    The definitive guide to disabling auto updates in WordPress 3.7 

    There are a lot of ways to adjust automatic background updates. A number of constants and filters offer a range of control, from the fine-grained to the heavy-handed. I will readily admit there are a few compelling reasons to disable auto updates, including:

    • You manage your site using version control
    • You implement your own deployment mechanism (potentially to multiple servers)
    • You are a managed WordPress host and feel confident in pushing timely updates yourself

    I’d argue that “I don’t want them” is not a compelling reason for disabling updates. If you don’t keep your site up to date, you are making the web a less safe place for you and everyone who visits your website.

    Background updates are incredibly, incredibly safe. Sites already running WordPress 3.7 have attempted more than 110,000 updates without a single critical failure, thanks to a number of verification steps that have made updates that much more reliable. A background update for a minor or security release (which is all they are enabled for, by default) means downloading and copying over just a few files. We’ve gotten really good at that. We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

    Automatic updates also support older branches. If the current version is 3.8.1, and we release a new 3.8.2 security release, we now have the option to release a 3.7.2 package with those fixes so 3.7 and 3.7.1 installs can automatically update to a secure version. (You’ll still be told to update to 3.8.2, of course.) Yes, automatic updates will definitely change how we approach maintenance releases and security fixes. We’d love the opportunity to keep lagging installs secure. I’d also expect more frequent maintenance releases for the current branch of WordPress, since update fatigue is much less of an issue now.

    Updates are also really fast. Installs take about 24 seconds to update on average, but that includes downloading and unzipping the package. A core update should put your site into maintenance mode for only a few seconds.

    What if you want automatic updates, but your site is telling you it is unable to apply these updates automatically? [Updated:] There is a new plugin, Background Update Tester, that will explain exactly why your site doesn’t support automatic background updates, and if necessary, what to ask your web host. This didn’t ship in core because it’s a pretty complicated flowchart and most options for recourse are complicated and technical. We think about 80 percent of installs support automatic updates. Most common reasons why they don’t work: your install’s file permissions require us to use FTP, and we don’t know your password; you have it disabled (or are using version control, see below); the WordPress cron (which also handles things like scheduled posts) doesn’t work on your server; or your install doesn’t allow for secure communication with WordPress.org. There are also situations (like inconsistent file permissions) where WordPress thinks it can do an update, but when it tries to, it finds out it can’t. (Your install will email you in that case.)

    It’s worth noting that the “automatic updater” controls more than just WordPress core. If the updater finds it can’t or shouldn’t update, it’ll still send site administrator an email. (Want to disable only that? It’s also covered in this post.) The automatic updater also supports themes and plugins on an opt-in basis. And by default, translations (for themes, plugins, and eventually core) are updated automatically. At some point in the future, the WordPress.org plugin security team will be able to suggest that installs automatically update malicious or dangerously insecure plugins. That’s a huge win for a safer web.

    It’s pretty clear that disabling the entire updater also disables some pretty nice features! Selectively disabling only what you want is going to be best. So, here’s the different ways to disable automatic background updates:

    1. Use version control.

    If WordPress detects a version control system, it recognizes you know what you are doing and avoids automatic updates of any kind. It looks for Subversion, Git, Mercurial, and Bazaar, and it looks everywhere.

    It works by searching two directories (ABSPATH and whatever you are updating, like WP_PLUGINS_DIR, or WP_LANG_DIR) for VCS directories (.svn, .git, .hg, .bz). And it looks a level up, too — and keeps looking until it reaches the root of the drive. So if you are running a single Subversion checkout at / or /var/www/ or /var/www/mysite.com/, the WordPress install at /var/www/mysite.com/public_html/wordpress/ will be blocked from receiving updates. Clearly, it errs on the site of caution.

    There is a filter, automatic_updates_is_vcs_checkout. If you’d like to use automatic updates anyway, you can just return false through that filter. The filter is also passed the directory it is searching in addition to ABSPATH, so if you wanted to update languages even though you were running a Subversion checkout, this would work:

    function update_languages_vcs( $checkout, $context ) {
    	if ( $context == WP_LANG_DIR )
    		return false;
    	return $checkout;
    }
    add_filter( 'automatic_updates_is_vcs_checkout', 'update_languages_vcs', 10, 2 );
    

    If WordPress can’t update due to version control, the admin email will still get notified of new minor releases.

    One technique that may interest some is to allow automatic updates even when using version control, with the intention of then checking in the changes once you get around to it. For the personal site of a busy developer, it’s an intriguing idea.

    2. Disallow all file changes, period.

    Most people are not going to want to use this one (honestly, please don’t), but if you are already doing your own deployments or are managing multiple servers, you might already be.

    The DISALLOW_FILE_MODS constant blocks any kind of filesystem changes, not just by background updates but by all users as well. So, gone are the file editors; the ability to update core, themes, or plugins; and the ability to install new themes or plugins. This is crazy stupid to use unless you know exactly what you are doing. I am only mentioning it because I wanted to make it clear that automatic updates is smart enough to avoid breaking any custom deployments.

    This will also block the update notifications sent via email for minor core releases.

    3. Disallow the entire automatic updater.

    The constant AUTOMATIC_UPDATER_DISABLED can be used to disable the automatic updater entirely. It’s like DISALLOW_FILE_MODS — no changes allowed at all — but it’s specific to the auto updater.

    Don’t use this to block only core updates! You’ll also be blocking a lot of other functionality. You won’t get translation updates (language packs) for core, themes, and plugins. You won’t receive update notifications sent via email to alert you of new WordPress releases. It also disables all opportunity for fine-grained control.

    There are very limited use cases for disabling the automatic updater but not disabling all file changes with DISALLOW_FILE_MODS. Just remember it disables everything, not just core updates, which are just one component.

    There’s also a filter by the same name, automatic_updater_disabled. (It overrides the constant.)

    4. Disable only core updates.

    The easiest way to manipulate core updates is with the WP_AUTO_UPDATE_CORE constant:

    # Disables all core updates:
    define( 'WP_AUTO_UPDATE_CORE', false );
    
    # Enables all core updates, including minor and major:
    define( 'WP_AUTO_UPDATE_CORE', true );
    
    # Enables core updates for minor releases (default):
    define( 'WP_AUTO_UPDATE_CORE', 'minor' );
    

    There are also some filters you can use for even finer control, which override the constant if used: allow_dev_auto_core_updates (like updating from 3.7-RC to 3.7-RC2), allow_minor_auto_core_updates (updating from 3.7 to 3.7.1), allow_major_auto_core_updates (3.7 to 3.8). Return true through these filters to allow such updates, false to disallow.

    5. Manipulate core, plugin, theme, and translation updates as they are prepared to be run.

    The previous configuration options are all-or-nothing. You may, however, want something more fine-grained. The auto_update_$type filter (auto_update_core, auto_update_plugin, auto_update_theme, auto_update_translation) is fired for specific updates, as they are ready to be updated. This filter is passed the actual update object that describes what WordPress is about to update. This means you can selectively enable individual plugins or themes to update, for example, or whitelist upcoming core updates.

    6. Manipulate whether notification emails are sent

    Emails are sent in three situations: a result email after a core auto update, a notification email when WordPress can’t update irself, and a debugging email when running a development version of WordPress (alpha/beta/RC).

    The result email comes in three forms:

    • A successful update. Nice!
    • An update that couldn’t occur. As in, WordPress tried to update, but failed early, like an inconsistent permissions error it was able to catch.
    • A critical failure, when the update failed in the middle of copying files.
    • (Note, we’ve yet to see a single critical failure in the wild. Yeah, it’s that reliable.)

      You can stop these emails from being sent by returning false via the auto_core_update_send_email filter:

      /* <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> bool   $send        Whether to send the email. Default true.
       * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> string $type        The type of email to send.
       *                            Can be one of 'success', 'fail', 'critical'.
       * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> object $core_update The update offer that was attempted.
       * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> mixed  $result      The result for the core update. Can be WP_Error.
       */
      apply_filters( 'auto_core_update_send_email', true, $type, $core_update, $result );
      

      Next, the core notification email is controlled by the send_core_update_notification_email filter. By default, administrators are notified when the update offer received from WordPress.org sets a particular flag — of course, only if the install is unable to update. It’ll only email you once per new version, unless the admin email changes. Returning true means the install will always email you when there is a new update, even if the API has not yet instructed the install to do so. Returning false prevents the email from ever being sent.

      Finally, the debugging email is a complete log output of all auto updates performed — core, translations, plugins, and themes. It is as if you clicked update yourself and watched the text scroll by; it also includes additional error data if something went wrong. This email controlled by the automatic_updates_send_debug_email filter. Returning false will prevent this email from being sent when running a development install, while returning true will send this email to all versions, including when you’re on a stable release.

      ***

      In the end, please choose wisely. If you’re going to block core updates, use WP_AUTO_CORE_UPDATE.

      I’ve gotten this question a few times now: should hosts that offer WordPress update services be disabling self-updates? I have no qualms with hosts who plan to reliably provide their own updates in a timely manner to do updates on their own. Because they have full, unadulterated access to the server, they can do it much more effectively than WordPress can. They can also offer support services. It’s also much more awesome to have a hosting company on board, than to lean back and rest on WordPress’s laurels. Many hosting companies are also setting the bar high and paving the way forward by pushing out major releases after a few weeks of testing, which is fantastic. Of course, this means the host must act immediately and responsibly to push out maintenance and security releases. This is something most of them are already doing, even inside the first 12 hours. (That’s how often installs check WordPress.org to see if there is a pending update.) Honestly, I’m just really excited about how much the community is embracing all of this!

      So, if you’re a managed host that handles your own updates, consider using WP_AUTO_CORE_UPDATE versus completely disabling the entire automatic updater. (If you want to send your own emails, block the ones WordPress sends using the send_core_update_notification_email filter.) There’s a lot more to come here, and it would be a shame if users were cut off from its full potential.

      If you are a developer who wants to learn more, start with the WP_Automatic_Updater class in wp-admin/includes/class-wp-upgrader.php. Also check out @dd32‘s previous post.

     
    • Scott Kingsley Clark 4:58 pm on October 25, 2013 Permalink

      Sort of losing my “stuff” about this:

      “Automatic updates also support older branches. If the current version is 3.8.1, and we release a new 3.8.2 security release, we now have the option to release a 3.7.2 package with those fixes so 3.7 and 3.7.1 installs can automatically update to a secure version. (You’ll still be told to update to 3.8.2, of course.) Yes, automatic updates will definitely change how we approach maintenance releases and security fixes. We’d love the opportunity to keep lagging installs secure. I’d also expect more frequent maintenance releases for the current branch of WordPress, since update fatigue is much less of an issue now.”

      Just wow, that’s *amazing*!

    • Aaron D. Campbell 5:10 pm on October 25, 2013 Permalink

      On the flip-side of this, if you want to enable the awesomeness that is background updates for major releases as well, you can use http://wordpress.org/plugins/update-control/ to play with the various options or https://github.com/OpenRange/background-updates-for-major-releases for a no-options “activate and ignore” approach. I added the latter to all my family’s sites so I won’t have to keep upgrading them.

    • Nile Flores 7:24 pm on October 25, 2013 Permalink

      Thank you for sharing this. For me, I like to manage ALL of my updates personally. It’s not that I don’t update, but I don’t want to have what happened this morning even on a security update. I understand the ease of allowing this, but I just had a minor issue with updating with 3.7 this morning…and that hasn’t happened since 2.7 for me.

      I don’t care about 110,000 or whatever number or more, I just know what I have for my own website and what my own process is. I understand WordPress is trying to make it easier and love that, but I prefer to keep all control of my updating in my hands.

      Again, thank you for sharing this and Mika shared the Master List and the Codex page on this too this morning shortly after I had issues with my update.

      • Ipstenu (Mika Epstein) 7:39 pm on October 25, 2013 Permalink

        Keep in mind, auto-updats are for MINOR versions over. So don’t compare this process to 3.6.x to 3.7. Compare it to how your 3.6 to 3.6.1 upgrade went.

    • niklasbr 9:02 pm on October 25, 2013 Permalink

      If I choose to keep auto update active how can I be sure that updates won’t break compatibility with anything installed?

      • Andrew Nacin 10:25 pm on October 25, 2013 Permalink

        I would read the post. :-) We’re talking about security and maintenance releases, not major releases.

        We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.

        Very simply: Don’t be concerned. Minor releases don’t break things. We have your back.

        • niklasbr 7:31 am on October 26, 2013 Permalink

          I should have phrased my question differently:

          I simply don’t believe (from experience with 3.6.1 and 3.5.1 and 3.3.2 have all had trouble with plugins) you when you write that you won’t break anything. What assurances do I have that what you say is true and not just some words on a blog?

          • niklasbr 5:30 pm on October 26, 2013 Permalink

            Addendum: The reason I am asking is that I want to use automatic updates, but I don’t fully trust the WordPress code base enough, even tough I want to trust it.

    • IgniteWoo.com Team 9:30 pm on October 25, 2013 Permalink

      Extremely bad idea to not have a simple switch in the settings to turn off automatic updates. How many WP users can write PHP code to do it themselves? Not many. Geez even my high tech phone prompts me to install updates, which I can decline if I so choose ( I don’t have to write a single line of code either ) – e.g. my freedom of choice is hi-jacked by WP. WTH?

      • Andrew Nacin 4:06 am on October 26, 2013 Permalink

        WordPress has prompted users to install updates for years. I don’t know how many declined as much as didn’t pay attention or consider it a priority. Your phone buzzes in your pocket; it’s something you can choose right then to act on. If you don’t use your phone for a while, it’s probably not a big deal if you wait for an update. But running a site on the Internet carries some responsibility, and they don’t buzz in your pocket. (Out of sight, out of mind.) For the betterment of the web, we made a conscious decision to avoid a UI option. You’d be out of your mind to consciously avoid updating to fix a critical bug or security issue. We think the vast majority of users (many who don’t even know what PHP is) will celebrate this as a win in usability and security.

        We very strongly pride in our core philosophies, including designing for the majority, making WordPress work out of the box with little configuration or setup, choosing decisions instead of adding options, and striving for simplicity. (Incidentally, that last section needs updating to emphasize we’ve now made updates even simpler.)

        There are 27,000 plugins in the directory. Your freedom of choice is unscathed.

    • Andrew Nacin 10:48 pm on October 25, 2013 Permalink

      There was a question about minor versus security releases on WP Tavern. I answered it. My comment:

      In practice, minor releases are rare. The .1 release will always be needed to fix some bugs. Pretty much all others are security releases. Sometimes, the .1 also contains security fixes. A .2+ release is only going to happen for security reasons if there is a serious regression that somehow wasn’t discovered before the .1 release (which implies it probably wasn’t that serious).

      Generally, then: .1 is a minor release with serious bug fixes. .2 is a security release and/or a critical regression fix. If you’re on 3.7, you’re going to want a regression from 3.6 fixed on your site. There’s really no reason to decline either of those releases. No, there is no differentiating in terms of how we version them, and we don’t plan to do so.

      Finally: We have the ability to push out a minor release without having it auto-updated. We also have the ability to slowly roll out auto-update instructions. Essentially: We have a lot of tools at our disposal to ensure your site is getting exactly the fixes it needs. For more on this, read the definitive guide I wrote. I also talk about how this might mean more frequent minor releases, but that might just mean that .1 might be less of an omnibus release four to six weeks later, and is instead only a week or two later with a few important bug fixes.

    • Marcus 1:07 pm on October 26, 2013 Permalink

      I was under the impression that these auto-updates are exclusive to wordpress itself, not themes or plugins, but point 5 in your great writeup makes me want to ask for clarification:

      will plugins and themes also update themselves automatically in any way?

      • Trifon 4:53 pm on October 26, 2013 Permalink

        By default; no, it only updates Core.
        But it is possible to update themes and plugins with these options.

    • EMG 1:15 am on October 27, 2013 Permalink

      When there’s a security vulnerability and something malicious can happen (I remember way back when there was the problem with spammers and scammers hacking into certain WP versions and injecting in links to malware sites if not outright corrupting site accessibility), I personally don’t see how an automatic security fix would be unappreciated.

      So yes, after years of using WP from its 2.X days and seeing a variety of problems sneak in through security issues, I can see this as a win-win scenario.

      However, as an advanced WordPress user, I would hesitate to support anything more than this in the future and especially not without a way to opt in and opt out.

      I really admire that the WP team looks out for their userbase – including those who would really ultimately benefit from a more streamlined and simplified process and even desire such a thing.

      The simplification and streamlining of processes could be really helpful (like in the case I first mentioned above)… until it genuinely starts to impinge on the user experience and user choice in a negative way.

      Personally, though, I’m not that sort of user.

      After so many years of using and supporting WP, I am in the habit of always checking WP for news and updates for information and if there’s a new release, I read the information before diving in and though seldom do minor updates come with compatibility issues, it has happened before (and no, I never alter core files) and for this reason, I have always weighed my choices before making a decision and I dislike my ‘choice’ of making a decision being taken away from me… even if it was a choice I myself would have made on my own terms.

      I run a self-install on my own site; not on .com’s network.

      I am responsible for my own website, not WordPress.

      If a bug gets in, that’s my fault and the onus is on me.

      If I make a choice to not break some functionality immediately and wait to do a maintainance or security fix so I can make a backup first just to be sure, then that is my choice and if I get some kind of malicious code injected into my site in the meanwhile, so be it.

      Reading a readme and clicking an extra button or two isn’t going to kill me (in other words, options are not necessarily bad).

      People being responsible for themselves and their choices isn’t a bad thing, either, and if someone ruins their install because they weren’t reading instructions or didn’t understand how things work (that’s why you get help!), it isn’t WordPress’ fault, either.

      I personally can and will take responsibility for my choices and nothing in life is ever perfect including web publishing platforms. It’s called being an adult and I’m not going to point my finger at WordPress.

      … Unfortunately, I am not the most PHP-savvy person and if, in the future, I decide that I do NOT want automatic updates (I like updates, don’t get me wrong; I just want to be able to educate myself first, make a backup JUST IN CASE, and make the choice myself, thank you!), I’m not sure if I would be able to disable the functionality without some kind of problem and this is something that concerns me.

      Ultimately, beyond just security and very minor necessary automatic updates, I want CHOICE, not decisions made for me.

      I chose WordPress as my web publishing platform out of choice because even though it isn’t perfect (and nothing in life is), it has what I need and that includes the variety of options and out-of-box customization features available. Please don’t take my choice to have my options away from me in the future.

      Thanks for reading!

      • Andrew Nacin 4:00 pm on October 27, 2013 Permalink

        Great comment! Ultimately, I think we are years away from even considering automatic updates to major releases. The update technology is here now, but we have so much more to do to get to the point where we can be confident in each and every major release. Things like dependency resolution, detecting possible incompatibilities (including between two plugins) before we update, detecting and fixing all kinds of failures after we update, etc.

        There are also a number of intermediate steps we could take on the way there. For example, we could suggest an automatic update across major versions — but only once the .1 is out.

        • EMG 11:34 pm on October 27, 2013 Permalink

          Thanks much for the additional thoughts. :) It is reassuring to get a glimpse into the thought process involved in such a thing.

          I read the articles you linked to for another poster and I can understand the thoughts (well, at least a good majority of them) that went into making the choices involved in this auto-update business.

          So here’s a question: Let’s suppose in looking to the future and WordPress reaches a point where auto-updates on major releases is a viable possibility. At this point in time, would it be unreasonable – given the fact that we are now talking about major updates and not just security patches or minor fixes – to request that auto-updates for such a thing be made absolutely optional?

          I’m thinking how you’re thinking in regards to what you said about testing for compatibility and making sure there are backups and what-ifs about potential upgrade failures, etc, and it seems like in that case, the potential troubles involved with auto-updating outweigh the benefits of auto-updating.

          As an advanced end user, I am therefore wondering if there is a reassurance to be had in regards to always having an option – even if it’s more advanced like in the examples you stated in this blog post – to be able to SAFELY disable such a thing without ‘hurting’ the core files.

          In particular, I am thinking maybe automatically including in a plugin that would safely turn such a feature on or off?

          After reading your other posts, I am thinking in particular about the post you wrote about Firefox removing the checkbox for the disabling JavaScript function and your own comment about how you used an Extension/Add-on (I can never get the two straight) to do the same job.

          I myself as a front-end web designer (X/HTML and CSS, less of the PHP) use extensions/add-ons in a similar fashion… including disabling JS, custom stylesheets, and other things when I am troubleshooting websites.

          It makes me wonder if this what end users of WordPress are being encouraged to do?

          Rather than keep all the various options and choices all within the core, in order to offer a potentially more stable and easier-to-QA/beta test, the options are disabled in the install … but are offered instead as ‘extensions/plugins/add-ons’?

          Would love to hear your thoughts on this; the conversation has given me more food for thought for sure.

    • Peetra 10:46 am on October 27, 2013 Permalink

      I am not happy with these options to disable the update mechanism, there should be a simple tick box in the back end for this!

      I want to make my updates when I am online myself because it gives me the safety of having fresh backups if something goes wrong.

      • Andrew Nacin 4:02 pm on October 27, 2013 Permalink

        You are clearly a developer or power user. You have the ability to disable the update mechanism by installing a plugin or changing your site’s configuration. Beyond that, it’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.

    • WPDogger 1:20 pm on October 27, 2013 Permalink

      This is a very naive and misguided change to WordPress. I understand the rationale, but one size does not fit all. Automatic updates have not worked on our VPS server since we were forced to lock it down due to thousands of attacks on our WP sites. If the automatic update is run, it fails every time and the site is shut down with the maintenance screen.

      I’ve seen the same thing happen randomly when some of our clients run the automatic updates on some GoDaddy servers.

      This needs to be a simple checkbox to turn it off or on.

      • Andrew Nacin 3:52 pm on October 27, 2013 Permalink

        No. It’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.

        Have you even tried automatic updates on your VPS server? If it can’t modify the files, it won’t try to go through with an update. You are welcome to email me and I will personally diagnose your problems with automatic updates and make any adjustments to WordPress core that are necessary to avoid problems in the future.

    • AITpro 3:59 pm on October 27, 2013 Permalink

      @ Andrew Nacin – Quick question:
      I would like to force a real world WP auto-update for testing. Specifically I am looking for the best approach to triggering the wp_maybe_auto_update cron to simulate a real world update check from WP. I can do this manually in testing, but I would actually like to simulate a “hands off” test, which I can do with my API Server, but was just wondering if you guys already have something in place for this type of test where I would actually be getting the response from WP. Auto-updating ROCKS!!! Total awesomeness!!!

      • Andrew Nacin 4:10 pm on October 27, 2013 Permalink

        All you need to do is call wp_maybe_auto_update() or do_action( 'wp_maybe_auto_update' ). The best simulation is to run it in logged-out context (so, a different browser, or private browsing mode); otherwise, that’s about it. I ran test updates a few hundred times in 3.8.

        If you’re running a development version (or are forcing the automatic_updates_send_debug_email filter to true), you’ll get an email at the conclusion of the update.

        If you’re more adventurous, check out https://gist.github.com/nacin/7047909.

        • AITpro 4:29 pm on October 27, 2013 Permalink

          Perfect! So my assumption is that by doing this, this will create/force the wp_maybe_auto_update cron DB entry to be entered instead of having the cron scheduled if there were some kind of failure on the first attempt correct? Just looking for a yes or no on that. Thanks man. Your ROCK!!!

        • AITpro 4:42 pm on October 27, 2013 Permalink

          Disregard. Just tested and confirmed my question. Thanks again!

          • AITpro 6:28 pm on October 27, 2013 Permalink

            DOH! I’m a dummy. wp_maybe_auto_update is a standard WP Cron @since 3.1.0. LOL

            • AITpro 6:42 pm on October 27, 2013 Permalink

              Ok maybe not a dummy. This cron was added as a standard cron in 3.7. ;)

    • Central Geek 4:41 pm on October 27, 2013 Permalink

      Running multiple WordPress sites myself, I am not happy with the short sightedness of WP core developers requiring users to go into each site files and make changes to “Opt-Out”. While you are getting better at releases not killing sites, there are too many variables that can have a negative effect on a site by allowing unattended updates.

      All this automatic Opt-In shows me is how little you believe users would check a box which might say “Enable minor and security automatic updates”. I think (and this is only my thoughts), WordPress just stepped into the babysitting arena. Most of us are adults and can handle out own sites. Give us the option in our settings to turn on or off these automatic updates. You have given us the options to do so many things in settings, why force us to “Opt-Out” of this change.

      Your statement, Andrew “Beyond that, it’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.” is erroneous, IMO. That statement reeks of a condescending attitude.

      Requiring users to go into files to turn something off is, in fact, placing the weight of technical choices on your end users, if they don’t want to run the risk of an update that doesn’t go right, thus shutting down their site.

      I don’t agree with your logic that you have made a smart decision to automatically do “minor and security” updates. Even our servers (those of us who have our own VPS or Dedicated Server), give us the option to do updates automatically or manually, the software running on it. There is good rationale for that. THINGS GET BROKEN.

      Doing updates without giving the end user the option to backup, before such updates is one of the worst decisions I have seen WordPress developers make. I don’t care how “confident” you are, if there is a need for a security update, there is something somebody missed. That, in and of itself, gives me pause when thinking about allowing you to automatically update my sites.

      Give us the option to turn on or off this stroke of genius spawned by the Google and Facebook automatic “Opt-In” practices.

      I personally see this change as a total lack of “confidence” in the end users ability to keep up with updates. You do not have the obligation to remove the option for us to make our own decisions.

      I see you are defending this choice WordPress has made, pretty aggressively. Just make the change and allow us to make the choice, ourselves.

      I love working with WordPress, make no mistake about that. But this decision is one of the worst WordPress core developers have made. There are just too many variables that could cause an issue.

      Your own warnings have always been, Backup, Backup, Backup before an update. Now, within one version, you have become so confident that you throw that important advice to the wind and want to automatically update? I think not.

      I hate to say it, but that rationale sounds more arrogant than smart. Forgive me if that is offensive, but this is no small matter.

      Telling us that it is your obligation not to put “technical” decisions on the end users, while explaining to us the technical process of disabling or modifying what you have done is almost laughable.

      • Andrew Nacin 5:15 pm on October 27, 2013 Permalink

        Well, I am not happy with the shortsightedness of your post.

        There will never be a checkbox in WordPress core to turn off security updates. Ever. I’m not happy with developers thinking we should just let sites be insecure because reasons. Under what circumstances should a user not want security updates? Offering that as an option would be an abomination. It would be the most stubborn, amazing example of open source catering to a vocal minority at the inconceivably large expense of its end users. Security issues do not cause hypothetical issues. They cause real, direct, serious harm. I’m not trying to be dismissive — you simply are not the target market for this decision.

        WordPress sites serving malware doesn’t just hurt that site, or even the brand of WordPress — it hurts every user on the internet. With WordPress powering 20 percent of the internet, a day rarely goes by where someone on the internet doesn’t visit a site running WordPress. We must not be ignorant about this.

        I’ve written extensively on this subject. For more, read Firefox makes a decision, removes an option, our own philosophies page, Checkboxes that kill your product, and numerous essays written by Havoc Pennington.

        It’s worth nothing that nothing short of the reputation of WordPress — not to mention my own reputation — is at stake here. If “THINGS GET BROKEN,” how do you think I’m going to sleep at night? Given my skin in the game here, I wouldn’t be so confident (call it arrogance if you’d like) if I didn’t have very good reasons to do so.

    • Central Geek 6:22 pm on October 27, 2013 Permalink

      I never said turn off security updates. I said give us the option to turn off “automatic” updates. There is a major difference.

      I am not hosting my sites with WordPress.com, I don’t want WordPress and it’s developers deciding for me what I have and what I don’t have automatically updated. Give us the option in our settings to turn on or off the automatic updates. I don’t care what you think is best. I am not asking for you to tell me how to run my sites.

      If I want to backup my sites prior to an update, I should have that option by my settings. Not me going through the technical process of accessing files and making changes to them.

      Your response is another indication of the attention to detail WordPress developers seem to be lacking at this time. You didn’t even clearly understand what I said. And you jumped on what you presumed I was saying, even though I was clear that I was suggesting the option to turn off the “automatic” updates, not updates altogether. You haven’t provided me with sufficient evidence that would support my being that confident in your ability to decide whether my sites should be updated automatically by you or the rest of the core developers without giving me the option to manually allow background updates after I backup my sites.

      • AITpro 6:57 pm on October 27, 2013 Permalink

        Take a look at the code in /wp-admin/includes/class-wp-upgrader.php and you will see FailSafes after FailSafes after FailSafes…….. If you do not want WP autoupdates to happen on your site then add the Constant in your wp-config.php file that is clearly posted above to turn off Core updates.

        • Central Geek 7:06 pm on October 27, 2013 Permalink

          The point is this. The statement was made, “Beyond that, it’s our duty as developers to make smart decisions and avoid putting the weight of technical choices on our end users.” and then there is the description of how to go about (through technical process) making changes to the wp-config.php file one by one, for each site, to disable automatic updates.

          I know how to do what was suggested. I don’t think it should be required for anyone to go through that process to opt out of WordPress imposing these automatic updates on users, because they either don’t like the fact that some people don’t do those updates on their own, or for some reason WordPress has adopted the notion that we aren’t capable of knowing what is best for our sites.

          I don’t care what failsafes are in place. There is opportunity for something to go wrong. Even possibly a flaw in the update itself, which without allowing for backups prior to such updates, could cost users valuable information. We have no way of knowing when these updates take place ahead of time. Allowing the simple option in the settings to turn those automatic updates off, without having to manually go into the wp-config.php file, would be a smart decision, not the other way around.

          • AITpro 7:14 pm on October 27, 2013 Permalink

            You do have a valid point in general, but what I think what is very important to focus on is these autoupdates are “minor” updates and not “major” updates. A major update might have the potential for a problem, but a minor update is basically just a patch of sorts. I guess if there was a coding mistake in a minor update then it could cause a problem, but obviously before WP releases anything it is tested, retested, tested again and then maybe tested 100 more times. ;)

            • Central Geek 7:25 pm on October 27, 2013 Permalink

              Yes, I am quite sure there is a lot of testing that goes into any update. And the best of efforts has proven in the past, to have adverse effects on sites. Minor or major updates, WordPress and it’s gurus have (until this point in time) made it very clear that backups should be done before “ANY” update.

              Now, they seem to have abandoned that suggestion and are now saying “As long as we do these “minor” updates for you, you have nothing to worry about”. I don’t buy it. I don’t care how careful they are, writing code for something that has so many plugins and themes (in the repository) that have code that does not conform to WordPress “suggested” practices, too much can go wrong.

              If WordPress enforced a standard, things might be quite different, but they don’t do such enforcement. There is where the weak link is in the logic of this “Automatic Updates” change.

              Even the biggest software manufacturers acknowledge that as long as other software (which they do not require to conform to their standards) is working in conjunction with their software, automatic updates should be an option that is in their settings. This is my argument.

            • AITpro 7:34 pm on October 27, 2013 Permalink

              Yep, it is a standard to provide an option to turn something on or off and WP is offering this with Constants in the wp-config.php file. I am very comfortable with adding or removing stuff to the wp-config.php file, but maybe a lot of folks are not comfortable with doing that. I’m sure a plugin or 2 will be created to add this as an option to do this from that plugin, but it won’t be me who does that. ha ha ha.

            • Central Geek 7:41 pm on October 27, 2013 Permalink

              Yes, AITpro there is already a plugin that does turn this automatic updates feature off. I shouldn’t need to turn to a plugin to do what WordPress should do already. As they themselves say, more plugins, slows down a site.

              If a person has a lot of sites, it is very time consuming to access the hosting account, via FTP or otherwise, and go into the wp-config.php file and make changes. Just put an option in the settings and let it be set by the user. That’s all that needs to happen.

            • AITpro 7:45 pm on October 27, 2013 Permalink

              I guess what I don’t get is this. When you first install WordPress you need to add your DB connection information: username, password, etc. so adding…

              1. Disables all core updates:

              define( ‘WP_AUTO_UPDATE_CORE’, false );

              …to the wp-config.php file is pretty much that same thing to me. ;)

            • Central Geek 7:52 pm on October 27, 2013 Permalink

              That’s well and good if you are creating a new, or fresh install. That might be reasonable. But when someone either has multiple sites or is managing multiple sites, it’s not that quick. Have you tried working with 100 sites or so? It’s more than enough to have to go to the settings and turn on or off, but that is a reasonable expectation. Requiring the accessing of wp-config.php to do all of those sites is not reasonable. This should be a setting.

              Do you have a few hours you don’t have something else you could be working on? It is unnecessary to require that of users.. :)

            • AITpro 7:59 pm on October 27, 2013 Permalink

              Ah yeah 100+ sites @ 1-5 minutes a piece would take some time. I see your point now. Ok I have some spare time today so I’ll create a disposable plugin that will allow you to do this with one click. This should only take about 30 minutes to complete. I’ll post the plugin zip file for download in my Forum when it is finished.

            • Central Geek 8:01 pm on October 27, 2013 Permalink

              Too bad WordPress won’t do it, but thanks. :)

            • Ipstenu (Mika Epstein) 8:22 pm on October 27, 2013 Permalink

              Re editing wp-config – A lot of people use one click installs from their hosts and never edit the config files.

            • AITpro 9:42 pm on October 27, 2013 Permalink

              heres the zip file: http://www.ait-pro.com/p3672/autoupdate.zip
              Keep in mind this is a very stripped down plugin – it only does one thing… Adds this WordPress Constant: define( ‘WP_AUTO_UPDATE_CORE’, false ); to your wp-config.php file directly below this text * That’s all, stop editing! Happy blogging. * in your wp-config.php file to turn Off WordPress Core Updates.
              Install the plugin zip file with the WordPress Upload Zip installer. Click the plugin’s Settings link, click the Add Constant to wp-config.php button. You will see a success message if the code was added successfully. You will see a “you have already done this message if you click the button again”. it is actually checking for the code in wp-config.php so it is a valid check.

            • AITpro 10:49 pm on October 27, 2013 Permalink

              I just add a Remove button as well. So this plugin now adds and removes the define( ‘WP_AUTO_UPDATE_CORE’, false ); Constant.

            • Central Geek 5:14 am on October 28, 2013 Permalink

              Thanks AITpro.

          • Andrew Nacin 5:28 am on October 28, 2013 Permalink

            While this post is called “the definitive guide to disabling auto updates” what it really is is a cookbook to tweak them to exactly what you want. It was a post written by a developer, for other developers, precisely to avoid the kind of confusion that has muddied this comment thread.

            If telling 100 sites to do the same thing requires a UI setting, you need to look at how you do deployment and management. From a pure maintainability standpoint, the last thing I’d want is a UI setting I’d have to consistently set, individually, across 100 sites. I’d want a constant I can deploy, or a plugin I can share, or something along those lines. If I’m managing 100 sites, it’s going to be easier for me to deploy code to all of them than it is to go into each dashboard. We are developers — we write code to solve problems! The belief that going into 100 dashboards to tick a manual checkbox is easy and preferred is strongly indicative of a very serious problem.

            • Central Geek 6:03 am on October 28, 2013 Permalink

              The belief that you are solving problems (which apparently are mainly in your logic) with an automatic update hard coded, which requires users to implement code to disable is flawed from the very beginning. It only takes one time for your rationale to fail to prove my point. You can get it right all the time, until that one failure and never prove my point wrong.

              Automatic Updates of any software, where “20%” of the internet is using that software, without allowing a setting to turn it off is inconsistent with most major active software on the market.

              When you write a post like what you have written, it is helpful to developers and non developers across the board. that is not disputed.

              The stubborn position taken that the decision to hard code something that requires “technical” processes to disable, while claiming that it is your responsibility to make “smart” decisions that take away the need for end users to make “technical” decisions is a VERY SERIOUS FLAW IN YOUR LOGIC,

              You can defend what has been done until hell freezes over. The decision not to allow users to disable it in their settings is wrong and a poor decision. Time will prove that out. You cannot (as a programmer) be right 100% of the time. It just doesn’t work that way, I don’t care how “confident” you are. In fact, that very confidence is an indication of a flaw in your logic. You will mess it up, WordPress history proves that out. Programming history in general proves that.

              Be as arrogant about it as you want, it won’t change the fact that only one time does a major site have to be taken down by a flaw in an update, and you have a VERY SERIOUS PROBLEM. People won’t have had the opportunity to put the update to any testing before updating their live sites. They won’t know where to look, except to WordPress, to get it fixed. WordPress does not have the support system to handle such a failure.

              Your argument fails on several, already discussed, points. Just put an option so that users can disable your automatic updates. While you may be an accomplished author, and have done a very good job on certain parts of WordPress code, the decision not to allow the average user to be able to disable automatic updates, without going through a technical process is wrong. Plain and simple.

              The whole argument is in stark contrast with the practice of allowing and urging users to back up their sites prior to them clicking on the button to update their website. Please explain the deviation from that logic, which has been promoted by WordPress all along?

              All it takes is for you to mess it up one time, the way you have decided is the best way. Yours and WordPress’ reputation doesn’t support the confidence you are requiring of users, in that area. Nor does the history of programming itself. This decision is not a wise one. Sure, it’s great for Google and Facebook who gather and sell their users’ information and make billions of dollars off of it, until they opt out.

              But, for a software that is being used by a large portion of sites across the internet, to remove the option for most of it’s users to easily turn off the automatic updates, it’s not the wisest of decisions. And again, time is on my side, to prove it out.

            • Central Geek 7:36 am on October 28, 2013 Permalink

              And Andrew, you are correct in your statement “The belief that going into 100 dashboards to tick a manual checkbox is easy and preferred is strongly indicative of a very serious problem.”

              The notion that Automatic Updates should be on by default is indicative of a serious problem. Making such decisions for users is not a practice that should be employed by any software, where there are thousands of plugins and themes that are not “required” to conform to the standards set by the platform being used.

              Automatic Updates should not be on by default. At the time of any update that would offer such a feature, the user should be given the option to turn that feature on. And explain to the user that the setting is available to turn it on or off in the settings, should the user change their mind. That is the way it should be done. So, we are in agreement with your statement there. But it doesn’t stop with that statement.

            • AITpro 2:44 pm on October 28, 2013 Permalink

              I agree with you 100% man that this topic has gone wild / off topic. Maybe split or move the posts starting from the point where this train jumped the tracks. ;)

            • AITpro 2:48 pm on October 28, 2013 Permalink

              Or just delete everything that is not relevant to the topic.

            • AITpro 3:15 pm on October 28, 2013 Permalink

              Just throwing an idea out there man to be helpful. What about creating a new topic for non-developer questions and concerns, move all non-developer questions to that topic. Get your Guide back where it is supposed to be and state this topic is for developer posts only and post the link to the non-developer topic. I’ve had to do this exact same thing several times on my Forum where my Guides get cluttered with personal questions, off-topic questions and other stuff that wrecks the purpose of the Guides. Just a thought man.

            • Helen Hou-Sandi 8:04 pm on October 28, 2013 Permalink

              I don’t know how to say this without sounding abrupt, so I’m just going for it: this is a developers’ blog. It’s about the development of WordPress core. It is not meant to be end-user or non-developer facing. An end user would be more interested in a plugin that gives UI for fine-grained management of automatic upgrade options, whether turning them off or enabling more of them, which as I understood either exists or will shortly in the original Automatic Updater plugin: http://wordpress.org/plugins/automatic-updater/.

            • Central Geek 6:09 pm on October 28, 2013 Permalink

              If I might be allowed to approach this from a different angle.

              With all due respect, Andrew (and I do mean respect), you and the other core developers have presented those of us who may not be coders, “developers” (in your sense of the word) or anything other than users to you, with an update that for all intents and purposes attempts to lock us into using your automatic updates without providing us a reasonable explanation for the change, or an explanation for the deviation from the backup, backup, backup rhetoric WordPress has been putting forth for quite a while.

              Because you offer us no simple solution to the automatic update default On, we begin to look for a solution. What we find is this post, which you say is “by a developer for developers”. Well, given that you (WordPress) don’t offer the normal, easy solution, we begin to comment.

              You may not want us here, but because of the change and the way you went about it, you now have us here. You (WordPress) created this situation by deciding for us what you believe we should have, because you don’t believe we should have the weight of such “technical” decisions on our shoulders.

              Like it or not, we are part of the same team. We are people who take your routines, and create from them something we want to present to the world, the same as you take someone Else’s language and create routines which we can use to accomplish our goals.

              We are all developers at some level, and we are (or should be) considered part of the same community. We are dedicated to the use of WordPress, we have a great deal of respect for those who have created the WordPress platform. At least give us the option to turn your automatic updates off in a simple way, so that we don’t have to bother you with our lack of knowledge and understanding of what you have knowledge and understanding of.

              If you want to know where the confusion came from, take a look at what you (WordPress) did and the way you (WordPress) did it. What else did you expect to happen, when you gave us no other options, except to wait for someone else to create a plugin to accomplish what you didn’t want to allow us to do via our settings?

    • sylvestercomputerguy 7:08 pm on October 27, 2013 Permalink

      We all know that doing the updates is generally a no-brainer.
      And we all know that there are basically two groups: Non-Coder Users and Coder Users of varying skill.

      For the non-coders, generally only responsible for their own website, I believe that having the autoupdate installed and active by default is a great idea, as it will make things better for everyone by patching up otherwise unsecure installations that may date back many many versions.

      However, for the coders who are likely in charge of other folks’ websites, I believe the problem is in the lack of choice on how those updates are accomplished, and the fact that some coders aren’t comfortable with anything beyond HTML and CSS, so the code switches may be a bit daunting.

      For coders who are more advanced, there’s just the hassle of going in the backend to see if it’s turned on or off on a particular site, then editing the file accordingly, when they are already in the admin interface where the change would be less steps. For both camps, a simple page with toggles for each of the code switches would give an easy visual way to know which way each site is configured, and an easy way for all to modify them.

      I don’t believe we are actually debating the merits of doing the updates, or the faith in WP that they won’t blow up stuff (although weird things happen when dealing with third party plugins/themes/hosts, and sometimes we like to be more safe than screwed), it’s more that coders responsible for other sites would rather feel more confident about how things are set, and a toggle quickly shows status while also providing a fool-proof way for changing the setting.

      I join in the request to add visual toggles that will effectuate the same switches that are currently required by code. If nothing else, if WP wants to keep the decisions out of lower level hands, perhaps a green/red indicator to let us know if it’s set to ‘auto’ or ‘manual’ update so it’s easy to tell without fishing in the backend.

    • sylvestercomputerguy 7:40 pm on October 27, 2013 Permalink

      This looks like it might be what we are looking for http://wordpress.org/plugins/automatic-updater/screenshots/

    • Gtantra 7:56 pm on October 27, 2013 Permalink

      Central Geek does have a valid point . I too was concerned about the site breaking . Now I do understand that the updates are minor , and minor updates are tested, tested and re-tested – But non of these testing is done with the third party theme’s we install on the site ( as well as the plugins installed ) . So where is the guarantee that it can’t break ?

    • subpopet 9:09 pm on October 27, 2013 Permalink

      Autoupdates broke my site (kept redirecting me to the home page), had to reinstall 3.7

      • Dion Hulse 12:00 am on October 28, 2013 Permalink

        WordPress 3.8-alpha nightlies had an issue yesterday where only the front page would load. The next nightly release would’ve corrected it, but when you’re using the bleeding edge (3.8 in this case) breakage is expected occasionally and shouldn’t be run on a production site (although many of us do, I had the same thing happen to me).
        So it wasn’t the autoupdate that broke, it was an untested nightly release with a bug.

    • linkomatic 2:39 pm on October 28, 2013 Permalink

      This is such a strange discussion, complete with entrenched positions and comments that border on personal attacks. I’ll try to avoid both. I owe my livelihood to WordPress, and am eternally grateful to the people who support it. So, I’m not out to rip anyone a new one — but EVERY process can be improved. I don’t have an axe to grind, but I do have opinions. These comments are offered in that spirit.

      First off: the communication about what changes this release brings, esp. WRT the auto-update process. I THINK I understand which releases will be auto-updated, but that is not specifically called out in either the blog posting or the release notes. And there is no mention of what happens when, for example, you have installed version 3.7 installed and the newest version is, say, 3.8.2. Would it be possible to explain this further so that someone who is not a WordPress “insider” could understand exactly how this process will work? That would be very helpful.

      That aside, I agree strongly with several of the commenters who are asking for a simple, non-intrusive way — a “checkbox” if you will, not requiring editing wp-config or adding plugins — to control whether WP updates automatically when “maintenance and security” updates are available. Here’s why…

      It has been beaten into me — time and again — by various WP security experts to ALWAYS take a backup before applying ANY kind of software update, including any type of update WP core update, lest you want to place your site at risk for an update breaking your site. And I beat this same message into my students, too. (I teach classes in WordPress.) Why should this change now? Because the core team tells you it’s “safe” to assume there will be no problems? Sorry, as much as I’d like to believe that, old habits (esp. regarding site security die hard). So, I’m not going to change this practice any time soon — at least until there is a clear track record of auto-updates resulting in ZERO failed sites. (Not sure how WP can track this — so, that probably means I’ll never deviate from the practice of taking backups before updates.)

      The question then becomes: is it too much to ask someone to install a plugin or edit wp-config to turn off the auto-updates? My vote: YES it is. Whether you manage one site or hundreds of site, the option to turn off auto-updates should be as simple and straightforward as possible. Looking at it again from the perspective of one who teaches WordPress, most of my students are very non-technical people. If there were a way to totally eliminate their need to edit wp-config, I would vote for that. (Hey, how about adding a script to assist the “Famous 5-minute installation process” that would prompt users for the values they need to provide??? Now THAT would be a real improvement!) So, I’m not going to direct them to an obscure blog post (like this one) to tell them what to do.

      And a plugin to do this? Really? Another thing I have been taught — and I teach my students — is: the less plugins the better. How exactly is a plugin somehow better than a checkbox — a checkbox that defaults to “YES, please apply maintenance/security updates automatically”, a box you have to UN-check to disable? You could even add a warning on the screen: “Don’t uncheck this box unless you really know what you are doing.” This solution seems to be totally in the spirit of what you want WordPress to be: simple solution that empowers users. And core developers are doing their job, and everyone can sleep at night.

      Thanks for listening.

      • Central Geek 4:35 pm on October 28, 2013 Permalink

        linkomatic,

        You said everything I was trying to say and did it much better. I am probably one of those who seemed to border on personal attacks, which was not my intent.

        I have a great deal of respect for all of the core developers of WordPress, as well as those who contribute. The last thing I want to intentionally do is attack them. But I am also one of those who is entrenched because of the very same reasons you state in your comment.

        Why change the logic of backups before updates? And if this is to change, why not give us a good explanation for why we should trust something that hasn’t had a good track record until the most recent update, prior to 3.7?

        I’m all for jumping on board, but make it make sense, and make it simple. The processes being explained are not simple. That is outside of the very foundation of WordPress, which is supposed to be simple.

        Much better presented than I, thanks.

    • wprick 3:01 pm on October 28, 2013 Permalink

      So let me ask this. If and when there is a minor security update or a minor bug update and it breaks the users site. Does the auto update then fix the break when it happens. Will it be fixed in a timely manner where sites that do and will eventually break because no one is perfect all the time. How will it be handled if this happens? I am for the updates but at the same time I want to feel secure about any updates that I have no control over to be fixed so the site is not down for any real length of time.

      Also, how will we be informed that there has been a flaw when it arises because it surely will at some point in time do to imperfection by even the most brilliant of coders. How will the end user know that the result of the break is from a minor security update or bug patch. Will we be sent emails or such notifying the end user of the flaws when they arise because they will eventually.

      How do we determine whether it is a beak in a plugin, a theme related problem or anything else for that matter. I would rather not live with a guessing game when it comes to a broken site and not know if it is a result of a backend update that is hidden. Again I am for the auto updates but with some kind of plan in place for when a site has faulted do to a hidden update.

  • Andrew Nacin 5:34 pm on October 18, 2013 Permalink
    Tags: , blamenacin, mkdir_failed_pclzip   

    Have you been receiving update failures with the error code mkdir_failed_pclzip? Then why haven’t you reported it? ;-)

    So, on October 14, I accidentally committed a change that deliberately raised this error when PclZip was used to extract downloaded ZIP files. If ZipArchive is present, it is used instead of PclZip, so this doesn’t affect most installs by default. But, there are a lot of installs that do use PclZip, and they are “stuck” on the October 14 nightly build, and are unable to update past that point.

    So, a few options to fix this:

    • You can download the latest nightly build (or WordPress 3.7 RC1 will be released soon) and manually install it. (You probably just need to copy over the file wp-admin/includes/file.php.)
    • Or, you can open up wp-admin/includes/file.php, head to about line 747 and remove the comment on the if statement, as was done in changeset 25799.
    • Or, you can install the Zip PHP extension. :-)

    Of course, it is absolutely critical that an install is always able to update, even in development versions. @dd32 and I take that very seriously. Sorry for the lapse.

     
    • Ipstenu (Mika Epstein) 5:51 pm on October 18, 2013 Permalink | Log in to Reply

      *cough* I didn’t report http://wordpress.org/support/topic/wordpress-failed-to-update-to-wordpress-37-beta2?replies=16 upstream because I saw that once people updated manually, it was fixed, which told me that it was already fixed in core, and people were just unlucky in getting it. Looked like a relatively small subset too.

      Mea culpa. Normally I’m better about that!

    • Fretless 6:14 pm on October 18, 2013 Permalink | Log in to Reply

      Haven’t had a problem with auto-updates so I’ve not noticed. Obviously using ZipArchive on my server…

    • programmin 9:36 pm on October 18, 2013 Permalink | Log in to Reply

      I was curious, is there a technical reason for not auto-updating when using ftp setup? AutoFTP for example.

      • Andrew Nacin 6:17 pm on October 21, 2013 Permalink | Log in to Reply

        When we can’t own files we create, we avoid direct filesystem methods and instead request FTP credentials from the administrator. But, we don’t store the FTP password anywhere.

        If you choose to add your FTP password to your wp-config.php file, then we’ll do an automatic background update via FTP. That said, it’d be faster and more reliable if you changed your setup so we could do direct filesystem methods.

  • Andrew Nacin 5:29 pm on October 16, 2013 Permalink
    Tags: ,   

    Agenda for today’s meeting in #wordpress-dev at 20:00 UTC.

    • Go over the last few days of progress, as well as what we’ve been learning via statistics for background updates. (Spoiler: excellent.)
    • Need a commit or revert on #20316 (garbage collect transients). It has a patch — the queries need testing and review.
    • Need a decision on #24963 (IIS stuff).
    • Finalize the about page. It’s going to be text-heavy as there’s nothing to show off UI-wise. What about a single giant three-column image across the top? I mean, it can be a picture of a sunrise for all I care. Or some screenshot of the WordPress admin. Or some photos from the crowds at WordCamp San Francisco and WordCamp Europe. Anyone have any ideas?
    • WordPress 3.7 Release Candidate 1 (by tonight).
    • Branch WordPress 3.7 (after RC1).

    @dd32 and I are working on #10787 this afternoon as well.

     
  • Andrew Nacin 7:38 pm on September 25, 2013 Permalink
    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.

     
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