Make WordPress Core

Tagged: 3.8.1 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 2:02 pm on January 27, 2014 Permalink
    Tags: 3.8.1, ,   

    Last week in WordPress core 

    And now, for the first in a series of synopsis posts outlining what’s going on in WordPress core. The idea behind these posts is to highlight technical changes in WordPress 3.9 as it progresses, with the hope of keeping the community informed. If you have suggestions for content you’d like to see, please comment below!

    Last week, we kicked off 3.9, and released 3.8.1 (yay!). There were a lot of changes that occurred in 3.8.1, and @nacin provided an overview. These were all added to trunk and will be in 3.9.

    Here are a few highlights from last week’s commits:

    @nacin also added a small enhancement to Trac to point users in the right direction when they end up on a ticket that was fixed in a released version of WordPress:
    This ticket was closed on a completed milestone. If you have a bug or enhancement to report, please open a new ticket.

    Other housekeeping items included new Trac “focuses”.

    For the complete list of 51 commits to trunk, here’s the changelog. Thirty contributors had a hand in last week’s efforts. Want to jump in this week? Write or test a patch for 3.9.

    Thanks for efforts from yurivictor, cojennin, iammattthomas, mdbitz, kraftbj, dd32, c3mdigital, jorbin, adamsilverstein, Otto42, JayCC, johnbillion, nacin, xknown, mattheu, nbachiyski, undergroundnetwork, morganestes, matveb, SergeyBiryukov, azaozz, joedolson, alex-ye, ciantic, MikeHansenMe, batmoo, Corphi, Marventus, ocean90, and DrewAPicture.

  • Andrew Nacin 12:39 am on January 24, 2014 Permalink
    Tags: 3.8.1,   

    3.8.1 auto update rollout 

    I’ll be using this thread to track the rollout of automatic background updates for 3.8.1, released earlier.

    The WP.org API is now sending update instructions to about 1 in every 128 sites. This is for all locales (not just English). 3.8.1 was released about four hours ago and I’d like to have the rollout complete in the next six hours or so. Sites check WP.org every 12 hours, but this timetable means all sites should be updating within one day of the initial release.

    So, why a slow rollout? Well, we’re monitoring a number of things that would cause us to put a pause on auto-updates, such as whether there were any critical issues in 3.8.1, whether update failure rates are higher than usual, how WP.org is handling the load, etc. The rollout is happening much faster this time than last time (3.7.1), and yes, the goal will be to eventually push out auto-update instructions immediately.

    So far, we’ve seen a 100% success rate for about a thousand auto-updates to 3.8.1, and north of 99% for one-click updates. (A reminder: a failure only means the site couldn’t update, not that it broke.) I’ll comment to this thread with more numbers as the rollout continues.

    • Andrew Nacin 12:45 am on January 24, 2014 Permalink

      In case you’re curious as to how this 1-in-128 is calculated, we take the first three characters of the md5 of the site’s URL and convert it to base 10. md5 is hexadecimal (base 16), so the three characters mean 4096 possibilities. It’s now serving sites where this base 10 number is 0 to 31.

      Just randomly serving an instruction every 128 requests wouldn’t work. We do it this way to ensure a site receives a consistent response with repeated API calls.

    • Jeff Rose 12:46 am on January 24, 2014 Permalink

      I’ll cop to being one of those one-button failures. My Digital Ocean test install had bad permissions. Not WordPress’s fault.

      • Andrew Nacin 12:50 am on January 24, 2014 Permalink

        What’s cool is we are actually able to break it down by error code. Bad permissions is what we’d consider a non-critical failure. The only time a “critical” failure occurs is if WordPress started to copy files over, but couldn’t verify we copied them all successfully. It’s still probable everything is fine with the site, and quite possible the update completed anyway.

        If an error occurs at any point before we start to copy files (such as a permissions error, which is a pre-flight check now), WordPress simply declines to continue. The vast majority of the less than 1% of errors we’re seeing from one-click updates are these kinds of errors.

    • Ipstenu (Mika Epstein) 12:47 am on January 24, 2014 Permalink

      Mine had a bad timing for an auto-update (yes, auto update WHILE I’m messing with files, that’s smart 😉 ). Stopped messing with files. It re-ran later and worked.

    • Andrew Nacin 12:59 am on January 24, 2014 Permalink

      Bumped to one out of every 64 sites.

    • Andrew Nacin 2:36 am on January 24, 2014 Permalink

      Now at one in every two sites. Will be holding steady here for possibly a few hours.

    • Andrew Nacin 4:11 am on January 24, 2014 Permalink

      Things are looking great, so all sites are now receiving auto-update instructions. The rollout is complete. We’ve seen about 100,000 successful updates in the last few hours.

    • Andrew Nacin 8:11 am on January 24, 2014 Permalink

      We briefly dialed it back to about 75% of sites after seeing hundreds of updates a second from installs set to UTC. We’ll bump it back up soon.

    • marvila 10:24 am on January 24, 2014 Permalink

      One quick doubt. I have a monitor on my system that alerts me whenever a file is changed on wordpress and, of course, it started to show me lots of file changes.

      Is there a place to see whether the auto-update is still happening? Just to be sure the alerts are really for the auto-update (although everything seems to indicate so).


      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        Once you get a success email, the update is complete.

    • Knut Sparhell 11:39 am on January 24, 2014 Permalink

      All but one of the 35 sites I manage are localized (nb_NO), and they all have the “Advanced Automatic Updates” plugin with at least minor updates turned ON (most have ALL options ON). Some sites now has been background updated to 3.8.1 (no available updates indicated), but some has been updated to 3.8.1, but still waits for 3.8.1-nb_NO (says such update is available in the admin).

      May I expect all sites to update to 3.8.1-nb_NO, or do I have to “update” from 3.8.1 to 3.8.1-nb_NO by clicking the Update button on each site? For 3.7 to 3.7.1 no localized sites was fully updated and I had to do the last part, to nb_NO, myself.

      BTW: Tomorrow is WordCamp Norway!

      • Andrew Nacin 10:10 pm on January 24, 2014 Permalink

        If the site is running the 3.8 English package, it’ll update to 3.8.1 in English, even if the locale is set to nb_NO. It requires A) for an nb_NO package to exist, and B) for your version.php file to have $wp_locale_package = ‘nb_NO’, for it to update to the Norwegian package. I hope to make this better in the future.

        Have fun at WordCamp Norway. 🙂

    • driveroll 12:53 pm on January 24, 2014 Permalink

      I’ve noticed these auto-updates on several of my sites, this is the first time it happens like that, automatically. I usually would prefer to update wordpress manually to take care of any possible conflicts with themes or plugins that aren’t ready for the update… I actually haven’t checked if any of these actually occurred on some of those sites. Is there a way for the auto-updates to notice if the site breaks for incompatibility reasons? Is there a way to choose not to run the auto-updates?


    • Gary Jones 2:50 pm on January 24, 2014 Permalink

      I had an interesting issue, which I can only put down to the 3.8.1 auto-update, as I’ve not edited code or content on my site for a few days.

      Others said that my site had lost its style. When I cleared my cache, yes, the style sheet link reference was broken:


      That’s the child theme name missing, and the version has reverted to the parent theme (Genesis Framework).

      I cleared the Varnish Static, Varnish Dynamic and Memcache caches in SiteGround User Area, and it’s all back up fine.

      My other sites on the same SG account, with different WP installs, all running child themes of Genesis 2.0.2, all look to have gone through perfectly fine. The affected site *only* has Genesis and the child theme installed (no Twenty* themes), but then that’s the same for the other installs as well.

      I can’t explain it.

      • Gary Jones 2:53 pm on January 24, 2014 Permalink

        The full link was:

        The ID there indicates that Genesis thought the child theme was still active (as it should have been), but somehow, the name and version number couldn’t be retrieved from it (file read issue?)

      • Ipstenu (Mika Epstein) 5:36 pm on January 24, 2014 Permalink

        Is the child theme still installed on the site?

        The upgrade should NOT delete any theme files. Actually … it can’t delete theme files, unless you named the child theme ‘twentyten’ or something.

        • Gary Jones 8:06 pm on January 24, 2014 Permalink

          The child theme was still installed, and apparently not touched (correct). A clearing of the host caches brought everything back up correctly.

      • Samuel Wood (Otto) 5:46 pm on January 24, 2014 Permalink

        Could be an issue with the files for the theme being temporarily unavailable. I’d check the filesystem on that particular server (or ask the host to do so). Also make sure you have an up-to-date backup of the site.

        There is a function called “validate_current_theme” that runs on the wp-admin/themes.php page. It checks that the relevant theme files exist. If they don’t, then it tries to switch the theme back to the default theme, which is currently twentyfourteen.

        In that switch process, if the default theme isn’t there either, then a quick read of the code seems to me that it could set the theme to a blank value, which would give the results you’re seeing.

        We’ve seen this in the past on some hosting setups where the filesystem was having intermittent failures. Users would say that it “randomly” switched back to the default theme. The theme validation check isn’t nearly as aggressive as it used to be, I think, but this is one possible way that it could happen.

        • Gary Jones 8:26 pm on January 24, 2014 Permalink

          That consequential explanation sounds viable.

          Lots of the files (in wp-includes, theme files, etc.) of the affected site are now 0755. As most files weren’t touched, that is likely from the initial install via Softaculous in cPanel, but it presumably rules out any file permissions issue.

          I’ve just checked the version.php of the other installs (the affected site was the root site, while others are add-on domains), and they still say 3.8, so they actually haven’t been touched.

          What’s more fun, is that version.php of the affected site says 3.8.1, yet I’m still getting an update notification in the WP admin.

          I’ve got one 3.8.0 install where the theme files are 0644 and folders are 0755, with twentyfourteen also present, another the same but without twentyfourteen present, and a third where the theme files are 0755. I’ll keep track and see if any break.

          I’ve commented out define( ‘WP_AUTO_UPDATE_CORE’, false ); which was added to wp-config.php by SiteGround Autoupdate, so that WordPress handles things itself.

          • Andrew Nacin 10:08 pm on January 24, 2014 Permalink

            validate_current_theme() won’t do anything unless you visit wp-admin/themes.php. This appears to be a hosting problem.

    • Gary Jones 2:54 pm on January 24, 2014 Permalink

      link rel=’stylesheet’ id=’child-theme-css’ href=’/wp-content/themes//style.css?ver=2.0.2′ type=’text/css’ media=’all’

    • KirkM 3:59 pm on January 24, 2014 Permalink

      I’m running 2 WordPress powered sites, the first being a rather ancient (going on 8 years on original install) but still viable personal blog and a newer (4 years) test site. The old personal blog updated automatically updated to 3.8.1 from 3.8 without a problem but I had to manually update the test site. The test site via the admin Update page. It did show that the 3.8.1 update was available though. Perhaps the auto-updates hadn’t gotten around to the test site yet or maybe the security plugin is keeping the auto-update from happening (see list of plugins for the test site). I have no way to be sure. No big deal though.

      Just for information purposes, the old personal blog site has the following plugins activated:

      All In One SEO Pack
      Artiss Transient Cleaner
      Better WP Security
      Clean Options
      Google Analytics for WordPress
      Lightbox Plus ColorBox
      P3 (Plugin Performance Profiler)
      Spam Free WordPress
      Subscribe to Comments Reloaded
      WP Revisions Control
      WP Robots Txt
      WP Super Cache

      And I’m running Weaver II Pro as a theme.

      The test site has the following plugins activated:

      Acunetix WP Security
      Clean Options
      Lightbox Plus ColorBox

      This site also runs the Weaver II Pro theme.

      So, no problems here really. No errors seen in any of the error logs for personal blog in regards to the auto-update. Considering how old the WordPress install is and what I’ve put the site through over the years, I’m glad to see the auto-update work so well. I do keep the site in good repair but still…great job to all!

    • Debbie Doglady 4:05 pm on January 24, 2014 Permalink

      I couldn’t do the one-click update. Got at “500 Internal Server Error”.

    • Xavier Borderie 4:41 pm on January 24, 2014 Permalink

      Automatic background updates is still not quite well-known among regular users: we (WPFR) received one e-mail from the owner of the (unknown to us) owner of a permanent makeup website running WP, about having received “quite a strange message”, with a copy of the “Congratulations on your auto update!” e-mail, and a question: “How come WordPress feels the right to update my site without my knowledge?”

      I told him everything about the feature, plugins to disable it and links to the Codex, and he answered with:

      Well let me thank you for showing to us that you can remotely control our site without our permission and without having been personally given access to the administration.

      Free software does not rhyme with abuse of rights.

      One final e-mail from me reassuring that no one ever touched his site, that it was all automatic and everything. No answer since then.

      But still. If one guy takes the time to complain about it, that means heaps of others are confused about it. It might be warranted to put more informational text in the e-mail sent on successful and failed updates.

      • Xavier Borderie 5:05 pm on January 24, 2014 Permalink

        Aside 1: his website is not even live yet, it’s apparently a test version for a forthcoming new version of their previously full-HTML site. I can understand the fury.

        Aside 2: a commenter on the FR announcement says he hopes his 3.6-using site (kept this way because it uses a 3.7+-incompatible plugin) will not be “brutally” updated to 3.8.1, and fears about update failures when the webmaster is unavailable for days (holidays).

        It’s all about education and good copy.

      • Ipstenu (Mika Epstein) 5:43 pm on January 24, 2014 Permalink

        Sadly this is an application of Zeno’s dichotomy paradox in action. We cannot ever alert 100% of the world.

        I would suggest you do a blast email (or a post on your site) explaining this to your customers. We did that at DreamHost and had a crazy small number of people who even blinked when they were upgraded. We told them it was coming beforehand, pointed out they COULD opt out, but we suggested they would not, and provided directions. The majority of people were fine with it (though I admit we already do upgrades for anyone who used our one-click upgrader), and the few who were not were glad to have the information on how to opt out.

        • Xavier Borderie 7:53 pm on January 24, 2014 Permalink

          Ah, but they’re not customers of ours 🙂 I’m the fr_FR translator, and WPFR is the non-profit entity for that hosts the FR support forum and organizes the Paris WordCamp, so there’s no way we can e-mail everyone. That being said, we could tweet and write a blogpost about this beforehand, true, true… Thanks for the tip!

    • rossagrant 4:44 pm on January 24, 2014 Permalink

      Hey Andrew!

      Just a quick question.

      I woke up to an email this morning from my staging site saying that it had been updated to 3.8.1 automatically.

      My production site which is on the same server and is basically a duplicate of staging didn’t auto-update.

      I was already logged into my dashboard, hit refresh and then saw the manual update flyout. I hit it and it updated no problem.

      Another WP install on a sub-directory of my production site DID update automatically, so 2 out of the 3 sites on the same server basically.

      Is there anything I should look out for as to why the main production site didn’t auto-update?

      What are the triggers for the update? Did it matter that I was logged in as admin at the time?

      Would love to understand what triggers this.

      Thanks 🙂

    • ElleJG 7:09 pm on January 24, 2014 Permalink

      Holy komoly. Call me a control freak but I don’t like arbitrary updates. An auto update from 3.8 to 3.8.1 came as a complete surprise!

      Can someone confirm that this can only happen within versions? As in I won’t someday find that all of my sites have jumped from 3.8 to 3.9 without me deciding it was safe to do so? And should I decide that I would like to update all by my little self when I know it won’t break anything – how do I do that?

      Until every WP plugin developer is forced to update along with WP core – which can’t and won’t happen – I personally think auto updates are a bad idea. But hey, that’s just my opinion. 🙂

      Thanks guys. Would appreciate the info. I’m already trying to figure out a site problem today, and having this happen at the same time did not make me happy.

    • stevenhong 8:28 pm on January 24, 2014 Permalink

      Ok. My website broke based on this automatic update. I was on my site before lunch, and came back and when I hit my site again, it was in maintenance mode. Looked at the timestamp of the file and it was 8 minutes ago. Deleted .maintenance, and the site is broken.

      Fatal error: Class ‘WP_Query’ not found in /home/steveho/public_html/wp-settings.php on line 251

      is all I get, both on the front end, and when I try to log in via wp-admin.

      I thought it might be a conflict in plugins, so I went and removed all active plugins (via phpmyadmin) and it still doesn’t work.

      What did work was for me to copy all the 3.8.1 files onto my server, and follow the install instructions. Entire site is back and running with all the data intact.

    • keeperbay 9:44 pm on January 24, 2014 Permalink

      UPDATE. Have installed the “Disable Auto Update Patch” on 45 WordPress blogs today.
      Have 120 more to go.
      More orders rolling in.
      THANK YOU WP CORE!!! Once again you have kept me gainfully employed. I’ve never received so many orders in one day.

    • Andrew Nacin 10:03 pm on January 24, 2014 Permalink

      IF YOU NEED ASSISTANCE, USE THE SUPPORT FORUMS. I’m closing comments on this thread.


    • keeperbay 10:20 pm on January 24, 2014 Permalink

      Here are the problems:
      Problem #1. WP Core thinks that posting a link to Codex will help, but Most Bloggers Know Nothing About Code!

      Problem #2. Auto Updating assumes that all plugins are going to automatically work with the new version of WP – When has that EVER Happened?

      Problem #3. When Problem #2 occurs, those bloggers who fall into the category of Problem #1 are stuck paying to have their sites restored, fixed or rebuilt.

      • Andrew Nacin 10:51 pm on January 24, 2014 Permalink

        1. Bloggers shouldn’t need to rush to update their site to keep it secure and stable. If WordPress can take care of that, we should take care of that. They shouldn’t need to even go to the Codex for this. It “Just works.”

        2. We don’t break plugins in minor versions. Auto updates are for minor versions. We take a lot of precautionary steps. All we’re doing is fixing a few bugs and any security issues.

        3. I’ve yet to see a site break due to an auto update.

    • rossagrant 10:55 pm on January 24, 2014 Permalink

      @nacin used the update tester on production and all is well – thanks! 🙂

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar