The weekly IRC meeting has been moved back one hour to 20:00 UTC. Still on Wednesdays. As always, check the sidebar for that info.
Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts
We’re so close to beta, I can taste it. For today’s meeting, think of anything outstanding that is still a beta blocker and then let’s talk about how we can get it sorted today. We’re going to keep at it until it’s ready. When? When it’s ready. But I’m hoping in the next 24 hours.
our original schedule had us hitting beta 1 today, March 13th. We’re not quite there. Beta should mean that we’re feature complete, and we’re not. We could do what we’ve done in the past, and declare a beta, while continuing to do feature work, but that just devalues the meaning of “beta”. I want people in the WordPress ecosystem to trust that when we say “beta”, that means we’re feature complete and that they should start seriously testing their themes and plugins against trunk for issues. If we continue with feature development during the beta period, that will just shove back everyone’s testing to the RC period, which will translate to more issues going unnoticed and tarnishing the release.
Consequently, I’m pushing the beta date back two weeks, to March 27th, and the release back one week to April 29th. If our beta period is actually a beta period (to work on bugs, not features), three weeks should be plenty of time. Ditto for the two-week RC period, for major bugs. We’ve needed longer periods in the past because we’ve been doing major feature development through the beta period and into the RC period, which, as mentioned above, I don’t want to do again.
Here is the major new-feature or new-feature-related stuff that needs to be settled and land in core (if they are going in at all) in the next two weeks (front-loaded as much as possible). Let’s redouble our efforts and get this sorted so we can get a beta out the door.
Post Format UI
I’ve decided to drop the Editorial Flow feature from the 3.6 roster. A few things happened. We looked into what the main feature (“forking” a published post and allowing it to be edited then reintegrated) would involve, and found that there were some really fundamental hurdles that were unlikely to be resolved in the time given. A lot of time was spent on the planning stage, and we just kept surfacing more questions. Moreover, because the hurdles were so low-level, they would have required a significant amount of time from a core lead like me, @nacin, or @ryan — time that we just didn’t have to give this cycle due to other responsibilities. What that left was #12706 — a somewhat related ticket with a long-running monster patch. This similarly needed (and still needs) a core lead to dedicate a lot of time to planning, reviewing, and committing it. That might happen, or might not. It didn’t seem fair to keep @danielbachhuber and @kovshenin responsible for something that might or might not make it, subject to other people’s availability.
Though disappointing, this effort wasn’t wasted. We learned a lot about the challenges involved, and we’re better positioned to tackle it in the future with more advance planning and a better understanding of the core team resources that need time dedicated to it.
A first draft of the Twenty Thirteen theme is now in core, for your inspection and iteration. See: r23452
A demo site is available for you to browse.
@matt set the goals for this theme: a focus on blogging, and great support for post formats (which are getting attention on the backend in 3.6 as well). Under Matt’s guidance, @joen explored the artistic possibilities and was joined by @obenland and @lancewillett in bringing it to fruition.
What you’ll notice first is the colors. Way more use of color than a bundled WordPress theme has had before. Each post format has its own color, so each is distinct, yet they are all complimentary. The bold colors encourage authors to try out all the different formats. This color extends the full width of the window, which breaks your blog up into a lush, segmented timeline. This effect is even more pronounced on mobile browsers, where the screen can be dominated by one or two posts at a time, in all of their chromatic fullness.
On closer inspection, you’ll notice details, like the font-based icons (“Genericons”, by @joen) that scale up to any resolution or zoom level and can be easily recolored using CSS.
You may notice some playful details, like the size-offset pagination arrows:
Or the 404 page (which I’ll leave to you to find).
One of the goals of having a new theme every year was to give ourself room to experiment. That hasn’t really happened. We’ve been far too conservative, trying to make themes that work reasonably well for everyone, but don’t push boundaries too much. That changes with Twenty Thirteen. It’s hard not to have a strong feeling about the theme, one way or another. It defies you to give it a shrug or a kurt nod. Some of you will hate it. And that’s okay. We’ll still be shipping Twenty Twelve, which is an excellent base theme and a canvas on which you can build anything from a blog to a static content site. But with Twenty Thirteen we’re taking a bold stance: this theme was meant for blogging, and it’s not a blank canvas. It comes pre-marinated with playfulness and warmth and opinions.
Twenty Thirteen really prefers a single column layout. Widgets live best in the footer, where jQuery Masonry bricks them together (but it supports a sidebar, if you really insist). Header images have a fixed width and height, and will be cropped at smaller resolutions, so the best choice is an artistic header where not 100% needs to be shown all the time (it ships with three).
Now that we have a first draft of Twenty Thirteen in core, it’s time to start iterating and sanding off some of the rough edges. Accessibility is still important, even when making bold artistic statements, and I’d be surprised if we didn’t have work to do there. We’ll need testing on lots of different browsers and platforms, and with lots of different plugins. @helen‘s Post Format UI team will need to give feedback on upgrading Twenty Thirteen to use the new post format API functions that are available.
@lancewillett and @obenland will be holding Twenty Thirteen office hours on Tuesdays and Thursdays at 1700 UTC. Interested parties should make an effort to attend and help us get this beauty ready for beta!
The WordPress 3.6 feature teams should be updating here on make/core twice a week, on the following schedule. List any major developments, summarize any notable IRC conversations that happened, call for help where coding, testing, discussion is needed, etc. They don’t need to be long, unless a lot of stuff happened. The idea is that people who aren’t in IRC and Trac every day can still stay up to date on features and jump in when they can. And it will keep the teams aware of their progress (or lack thereof) on a more regular basis.
Monday and Thursday
- Autosave/Post Locking
- Nav Menus
- Post Format UI
Tuesday and Friday
- Editorial Flow
- Core Maintenance and Architecture
Next, while many features are still being actively planned, the feature teams should hold IRC office hours where more realtime discussion can take place to get the features scoped and planned a little better. Feature teams should announce these hours here on make/core (can be part of their twice-weekly updates).
Agenda for the weekly dev chat:
1. Feature team updates
2. Set up schedule for more frequent feature team updates
3. Unstick anyone who is stuck
4. Rallying call for Ryan’s code maint ticket list
Like with any release, much more is going on during the 3.6 cycle than just the user-facing items on our agenda. We’d like to hit the following code maintenance and architecture items as well. If your interested or have thoughts, speak up or jump on the tickets! Some of these really should happen early, and they’re pretty much all going to need unit tests.
Use PDO for MySQL queries
#21663 — The
mysql_*functions in PHP are deprecated, so to get ready for future versions of PHP, we need to start routing queries alternatively for installs that support it.
Caching and Misc DB Tasks
No ticket for this? — Use magic methods to cleanup blogid and siteid in wpdb. These should fetch the canonical versions elsewhere. Also, support blog_id and site_id for consistency.
#21760 — get_term_by() calls are not cached.
#21401 — Load packaged object cache when advanced-cache.php and object-cache.php don’t implement wp_cache_init().
#22661 — Allow object caches to degrade gracefully.
#21767 — Remove stripslashes from API functions.
#18322 — The Road to Magic Quotes Sanity.
#22023 — Remove UNIQUE for slug in wp_terms. Prep for future taxonomy architecture changes.
#22301 — Performance problem with Recent Comments widget.
IRC Logs from discussion of some of these items.
A few years ago, I started publishing a mirror of WordPress on GitHub. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate
authors.txtfile, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to Git in the future, we would probably want our official mirror to have the best possible data.
That we re-run the
git-svnimport with a proper
We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migration to Git. Commits will be properly attributed in GitHub.
This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branch off of
origin(or even better, blow the whole thing away and re-clone).
So: thoughts? Would this ruin your day?
Distraction-Free Writing (DFW) made its debut in WordPress 3.2. It’s good, but it has some problems:
- It’s hard to discover. A tiny button that doesn’t stand out from other buttons.
- The transition is a bit jarring. Your content goes away, you land on another screen, and your content reappears. It feels like there is a cost to switching.
- It isn’t as fully-featured as it should be. If it isn’t capable of easily (and by that I, I mean without keyboard shortcuts) doing the majority of the formatting people need to do while writing, people are going to be disinclined to use it.
- It could use some polish. Some of the interactions are janky, and it’s not very responsive to large screens. There are strange issues that happen when you get to the end of a line or do a line break near the bottom of the editor. The Esc key doesn’t work when in TinyMCE. Lots of little stuff like that.
What I need is someone with CSS skills and JS competency to take on a bunch of little improvement projects for DFW. If you have those skills and care about making a beautiful and functional distraction-free writing experience for WordPress, speak up!