Automatic updates for 3.8 started to flow early…

Automatic updates for 3.8 started to flow early Monday. Since major releases are opt-in, future ones will get automatic update instructions immediately. It should have happened on release day this time as well (oversight on our part). Minor releases will continue to get a delayed roll-out. 3.7.1 happened over the course of about four days, while 3.8.1 will probably happen over a few hours or a day at most.

Success rate is around 99.78 percent of about 15,000 updates. That’s a bit lower than 3.7.1, which was 99.988 percent for about a million updates. This is to be expected; for example, far more files were changed. Definitely some great numbers but also lots of room for improvement! I’d love to be able to count the number of critical failures on two hands by the end of 2014.


State of 3.8, and thoughts on the next week

tl; dr: Still on track for release next Thursday. We’re extending the window for code changes by 3 days, through the 8th. RC2 package on the 9th will be what ships on the 12th.

December 5th, our targeted but controversial freeze date, is drawing to a close. First the bad news: there are two blockers and we could not ship the package we have tonight, despite a lot of great effort. The good news is we are close, there are good priorities on the remaining issues, the new features appear resilient and are live on which has generated a ton of testing, and we’re far enough out from our target (the 12th) that I’m confident we can ship that morning and still have had a 4-day freeze.

As a side-effect of the longer freeze and predictable date, I also think the best WP hosts will push it to their customers same-day and we’ll continue or improve our record of having localized versions ready to go.

What could break it? If an unknown unknown blocker pops up on Tuesday or Wednesday, we’re going to have to delay the release until the following week. Discovering that issue sooner, so it wouldn’t cause a delay, is a function of testing — the more we can test and cover now the better. We want to shake out big issues now, not next week. The more people that can run the RC or trunk at this point, the healthier the release will be.

What’s open right now? Our most substantial blocker, no-JS fallback for THX #25964, was raised a few weeks ago and we could have flagged its priority and developed a solution then, rather than the flurry of activity its had over the last two days. Our other blocker, the about.php page, is similar: I should have kicked off that page (#26387) when we nailed down exactly what headline features would be in the release, which was much earlier. Often user-focused non-code deliverables wind up as the last thing we do, but they’re so visible they deserve time to bake just like a complex backend change would. Of the the other 15-ish open issues there is nothing intractable, but there’s also nothing trivial, and for some issues we need to make a non-obvious decision to move it forward. We made the decision to punt or revert a number of things that weren’t fully ready yet, like the new author widget and RSSJS.

The things we missed are not a matter of having enough time, they’re a matter of priority. I think properly triaging issues as soon as they come in and being disciplined about working from highest to lowest will allow future release to avoid these problems. Even though that’s not hard to understand intellectually, sometimes you have to make the mistake to really grok it. I’m extremely proud of everyone who has been involved so far and in the amount of learning and growth I’ve observed even in our accelerated cycle.


Twenty Fourteen Project Update

Home stretch. Let’s polish.


  • Launched the theme on (announcement, Theme Showcase page)
  • Many, many fixes to get ready for code freeze (see all commits since our last update): including RTL, IE, contextual help, layout, etc
  • Improvements based on feedback from core dev team (simplification, code readability and commenting)
  • Lots of activity at the WordCamp London Contributor Day

A special thanks to everyone who participated in our “device testing and bug hunt” activity at WordCamp London, including but not limited to binarymoon, jartes, erichmond, janhenckens, sonjanyc, amistad18, iv.dimova, kdankov, robert olsen, iandstewart, chellycat, sixhours, cainm, blankthemes, thomasguillot, kwight, Frank Klein, siobhan, and defries. And all three of us on the Twenty Fourteen team were present: lancewillett, iamtakashi, obenland. [These are usernames.]


  • Wrap up final bug fixes: see open tickets
  • Make a Codex page for Twenty Fourteen help and tips—@siobhan to create the draft and kick it off


What’s a pragmatic solution for detecting mobile and table devices? We’d like to use wp_is_mobile() but that seems designed for only admin use since it assumes no page caching. See notes at #26221.

#3-8, #bundled-theme, #theme, #twentyfourteen

Twenty Fourteen Project Update

Crunch time! We’re working hard to make sure everything’s ready for 3.8 release. We’ve listened to all your feedback, thank you—including lots from last week’s dev chat. We’ve made significant improvements in the last week.

Many improvements

  • Many design changes to make the “first run” nicer and look better without featured images #25859 #25758
  • UI for Featured Content moved completely into Customizer (tag, display, count) #25549
  • Added contextual help and tips around the admin interface for setting up the Featured Content area #25837 #25869
  • Performance tweaks for faster loading #25876 #25922
  • IE, RTL, and i18n fixes #25036 #25625 #26071 #25144 #25625 #25888

Author widget

Too late to get it into 3.8 dev? It’s fairly light and can merge right away.

Last week at 3.8 features-plugin meeting we forgot to suggest this; we’d worked on it as a plugin first, see #24856: “Authors widget to highlight authors.”

This is a new widget for any theme to use, but we’d planned to show it off with Twenty Fourteen because as a magazine theme it’ll feature and show off multiple authors.

On our radar

  • Strategy for 3.7 and earlier non-MP6 handling #25906
  • Accessibility feedback on the slider
  • More work on contextual help and the user experience with Twenty Fourteen, maybe including user testing and research
  • Launching the theme on to get early feedback from real usage
  • Code review with core dev team

#3-8, #bundled-theme, #theme, #twentyfourteen

Open Sans, bundling vs. linking

In Wednesday’s 3.8 planning meeting we discussed hotlinking vs bundling Open Sans. MP6 followed Twenty Twelve’s example by linking to Google Webfonts, but the consensus from Wednesday’s chat was that bundling would be preferable.

I began experimenting with this last week; first determining which font formats were necessary to include. I settled on WOFF and SVG as the two formats that would cover every browser we’re aiming to support. I left out TTF and EOT as they add only marginal browser support (IE8), but would add significant weight to the WordPress download. We do include TTF and EOT versions of Dashicons, since loading those icons is essential to usability in a way that loading Open Sans is not.

The bundled Open Sans webfonts come from FontSquirrel. The Western Latin and Basic Latin subsets are small and include enough characters for English language support. Those subsets do not include a full set of glyphs for other languages, however (they’re available as separate downloads). There is a non-subsetted version of the font available which includes all necessary glyphs, but it’s 2x–2.5x the file size of the subsetted fonts, which add significant overhead to the pageload and can actually crash some mobile browsers. The Western Latin and Basic Latin subsets can cause missing characters (spaces or boxes) to appear in text using accented characters, which is a significant usability concern.

Google Webfonts solves both the character set and the font format problems by intelligently loading the font format and the character subset that’s needed for a particular browser and a particular website, and nothing more. For us to bundle Open Sans with WordPress, we need a way to accomplish that without adding significant heft to the core WP download. I’m starting this P2 thread to open up the discussion on how we might do that.

#3-8, #fonts, #open-sans

Widgets Area Chooser – 3.8 Proposal

Placing widgets with drag-and-drop can be tedious and annoying — especially if you have lots of sidebars on which to drop widgets. The Widgets team has been working on a few solutions (for this problem, and more), including redesigning the wp-admin widgets interface and adding the ability to manage widgets from within the customizer. These projects are still ongoing, and not ready for 3.8. However, along the way we’ve found a few incremental changes which improve the overall experience of working with widgets. Some of these improvements have made their way into MP6. Others involve more functional changes which don’t belong in MP6. This plugin is one of those improvements.

The Widgets Area Chooser is available at:

The Problem
Dragging widgets from the available widgets in the top-left, to a sidebar “below the fold” is hard. Almost impossible. Dragging widgets on a touch screen device is also difficult.

The Solution
Clicking (or tapping) on an available widget brings up a list of available sidebars that you can place the widget in to — its pretty simple, and works great on touch devices.

There’s also the accessibility problems that drag-and-drop introduces, which necessitates the need for the separate (and often neglected) Accessibility Mode. This plugin provides a much easier way for those with screen readers to add new widgets without having to drag-and-drop. In fact, this could be the first step towards removing the need for an Accessibility Mode for widgets.

Here’s what the chooser looks like:

Here’s a quick video of the plugin in action:

Please let us know what you think!

#3-8, #widgets

The State of Inline Docs

We haven’t posted an update in several weeks, so thought we’d bring everyone up to speed on the Inline Docs project.

This project started July at WordCamp San Francisco as a 3.7 release action item. Work continues into the 3.8 release cycle, and we would like to have the hook documentation completed by the time 3.8 is released in December.

PHP Documentation Standards

The PHP Documentation Standard has been amended several times since it was first published in early September. The latest amendments include:

If you are one of our contributors, please make sure you read the standards again to familiarize yourself with the changes.

WordCamp Contributor Days

We would like to thank WordCamp Toronto (10/6), WordCamp Europe (10/7), and WordCamp Sofia (10/27) for including Inline Docs as part of their respective Contributor Days. Approximately 35 files were documented, and several new contributors had their first patches committed to WordPress core as a result. Woot!


So far, 47 people have received props for submitting inline docs patches:

@admiralthrawn, @aeg0125, @a.hoereth, @andg, @aralbald, @bananastalktome, @ben.moody, @betzster, @bftrick, @dllh, @drewapicture, @dougwollison, @dustyf, @enej, @ericlewis, @Faison, @FrankKlein, @gayadesign, @gizburdt, @johnafish, @johnbillion, @jonlynch, @kpdesign, @l10n, @nacin, @naomicbush, @NikV, @ninio, @miyauchi, @morduak, @Nao, @natejacobs, @netweb, @nukaga, @nullvariable, @pauldewouters, @r3df, @rzen, @sboisvert, @SergeyBiryukov, @ShinichiN, @Siobhyb, @swissspidy, @tmtoy, @tomauger, @tw2113, @vinod dalvi

There are 10 other contributors with patches waiting to be reviewed and committed that will be added to this list. We want to thank everyone for their participation so far, and hope you continue contributing!

Progress To Date

According to the “master list“, there are 185 files containing hooks to be documented. The current status, as of today:

  • Completed: 92 files (49.72%)
  • In progress: 23 files
  • Available to claim: 70 files

Weekly Office Hours

We continue to hold weekly office hours meetings on Wednesdays at 19:00 UTC in #wordpress-sfd.

#3-8, #inline-docs

@matt will be running a WordPress 3.8 feature…

@matt will be running a WordPress 3.8 feature planning/decisions meeting on Monday, November 4, 21:00 UTC. Now that Daylight Saving Time has ended for both Europe and the U.S., note that the weekly Wednesday meeting is now moved from 20:00 UTC to 21:00 UTC (4 p.m. EST, 1 p.m. PST). (Americans, change your clocks on Sunday.)

I’d strongly encourage everyone to study, test, and weigh in on the four 3.8 proposals before the meeting. I believe the goal of the meeting will be to establish what exactly gets merged into 3.8.

API enhancements, bug fixes, etc. can/will continue as usual — it would be awesome if we had a surge not unlike 3.7. But for now, 3.7.1 is out, so stare at the download counter sip some tea, and relax this the weekend. 🙂

#3-8, #agenda

Twenty Fourteen Project Update


We’re right on target—making lots of progress on the main features in the theme. Finishing up within 1-2 weeks, then switching gears to verifying and testing (things like device testing, RTL, older browser support, accessibility, and more).


  • Implemented alternate slider view for featured content #25550
  • Implement featured content settings for authors to control which posts are displayed, and how many #25549
  • Used SVG images instead of CSS3 gradients for speed and responsiveness, more browser support, and vector-based scalability r25865
  • Allow any page to be set as front page #25685
  • Several passes at CSS code revamp to meet WP style standards and better organization and efficiency #25592
  • More accessibility fixes #25054


  • Accessibility feedback on the slider
  • Featured content options moved completely into Customizer (tag, display, count)
  • Accent colors: decide on keeping this feature in the theme #25563 #25580
  • Decide on pros and cons of creating an extra-large image size for full-width featured images #25758

On our radar

  • RTL and IE fixes
  • Mobile and tablet device testing
  • “Breaking” the theme in every way possible

Join us! Weekly office hours are Tuesdays and Thursdays at November 5th, 2013 17 UTC.

#3-8, #bundled-theme, #theme, #twentyfourteen

MP6 — 3.8 Proposal

The WordPress admin has not had a major visual overhaul since 2.7, and its age is starting to show. In a rapidly changing web environment where users are starting to expect good design, we need to make sure that our aesthetics match — better yet, exceed — their high expectations.

MP6 is a movement towards modernity. It is an exploration into the infinite possibilities that exist for improvement within our existing framework. It is a tenderly crafted visual update to the admin that we all know and love. MP6 is the future.


What problems are we trying to solve?

The current wp-admin has:

  • An outdated visual appearance.
  • Outdated technology.
  • Low contrast.
  • Suboptimal readability.

We’ve solved these problems with the following:

Modern aesthetics

  • Open Sans — a font as free as we are.
  • Cleaner styles — goodbye decoration, hello simplicity. Affordances still welcome.
  • Let it breathe — increased spacing between elements, which allow for better overall hierarchy and whitespace to guide the eye.

Improved contrast and readibility

  • Higher contrast dark default color scheme — great for eyes of all ages.
  • Lower contrast light default color scheme — helpful for those with dyslexia and sensitivity to light.
  • Refined typography — larger font sizes, crafted with better readability in mind.


Inherently HiDPI

  • Vector icons — beautiful and crisp at any resolution.
  • CSS effects instead of images — cleaner, faster, and more flexible.


Why MP6?


While we haven’t explicitly user tested this new skin, it’s been running on for months with minimal issues. The same old WordPress admin functionality is still there, just with a fresh coat of paint.

#3-8, #core-plugins, #feature-plugins, #mp6, #proposal