Tag Archives: 3.8

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.

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 WP.com 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.

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 WordPress.org usernames.]

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

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.

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: https://wordpress.org/plugins/widget-area-chooser/

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.

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

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:

Documenting Tips (language, tools for finding the version for @since, code refactoring)

A change to the way duplicate hooks should be documented (//duplicate_hook to /** This action|filter is documented in path/to/file.php */)

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!

Contributors

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

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.

@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. 🙂

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

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.

Since its inception, MP6 has gone through multiple stylistic iterations before landing on our “final” MP6 styles.

Results

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