WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from February, 2013 Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 8:30 pm on May 6, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Summary of last week’s dev chat on 4/30 (IRC log):

    Announcements

    Features as plugins

    • Met on 4/29 (IRC log)
    • Current potential considerations seem to be WP API and media grid.
    • Press This is getting some attention from an early stages working group, which could also be a part of the 4.0 release.
    • Admin Help is poised to shift into more of a continuous testing and advisory group, which is awesome.
    • Front-end editor is making good progress, but has UX issues that are getting worked on, needs iteration and experimentation and probably won’t be ready by 4.0, but should continuously be worked on, as is the goal of features as plugins in the first place. Developers needed.

    Potential ideas and their suggesters:

    Summary: we have good things in mind about more media improvements, more editing experience improvements, more visual media grid and better plugin installer experience (following in the footsteps of themes), and behind the scenes wins in taxonomy, multisite, and post type and comment APIs.

    If you’re interested in any of the above or have other ideas, please sound off in the comments.

    Getting involved

    • We are always looking for more people to be involved with Trac gardening, patch review, patch writing, or some combination thereof.
    • Component pages are running well, and most could still use the caretaking of a component owner or somebody who’d like to become well-versed in a particular area of core. To get started, just sign up for component notifications at http://make.wordpress.org/core/notifications/. No need to be an expert now – learning and persistence is more important.To help with a specific plugin, join their weekly chats and/or follow along wherever they post. See the Features as Plugins page for more information.
    • A reminder from @matt to always be dogfooding the product – use WordPress every day.

    Bonus punnage, to the lead’s chagrin:

    > wonderboymusic will make a t-shirt for anyone who gets all 16 of those Cache tickets closed :)
    > sams: “Cache Master”?
    > wonderboymusic: Johnny Cache
    > jorbin: If you fix the Cache, you’ll get the Credit. That Checks out.
    > MarkJaquith: I’d put in a cache pun, but I don’t want to be sent to purgetory.
    > johnbillion: You would have to be a cache machine to fix all 16

     
  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink
    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.

     
  • Matt (Thomas) Miklic 7:33 pm on November 11, 2013 Permalink
    Tags: , fonts, open sans   

    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.

     
    • Matt Mullenweg 7:43 pm on November 11, 2013 Permalink | Log in to Reply

      It’s also worth noting if we can solve this in a standalone way (the script not loading any of the rest of WP) we avoid licensing issues and also solve a general problem many people across the web have.

      Also keep in mind if this takes longer than a few days the right answer for 3.8 might be linking in core and releasing a plugin for people that bundles for people that don’t like Google.

      • Piet 4:28 am on November 12, 2013 Permalink | Log in to Reply

        I think it doesn’t have so much to do with liking or not liking Google. There are certain countries where Google is blocked and that includes loading their fonts. For all sites I built (I live in China), I bundle fonts, because only then I can be sure that these fonts load.
        That might be another argument pro-bundling :)

        • krembo99 6:03 am on December 22, 2013 Permalink | Log in to Reply

          I am with Piet – Have the same problems in china ( and elsewhere – granted – all totalitarian regimes, but still .. ). Google services work only sporadically . Fonts , jQuery CDN , Maps etc. Linking those resources makes the page time-out .

    • Doug Wollison 8:41 pm on November 11, 2013 Permalink | Log in to Reply

      Regarding the missing characters, don’t just about all browsers fallback to the next font in the font-family list for those characters?

    • mindctrl 8:46 pm on November 11, 2013 Permalink | Log in to Reply

      Relying on a third party for fonts in core doesn’t make me want to do cartwheels. It’s a backdoor analytics of sorts, and a privacy concern. The increased file size is the lesser of two evils. Neither option is ideal.

      I love Open Sans, but given the two options, I’d rather see Arial. *runs for cover*. I just tested swapping out Open Sans for Arial in trunk, and it’s really not that bad. Theming the WP admin/MP6 via plugins would be a great way for people to opt into hosted font solutions.

      • Doug Wollison 9:21 pm on November 11, 2013 Permalink | Log in to Reply

        Or, the better compromise; Helvetica (Neue if possible), finally falling back to Arial if things get desperate.

        • mindctrl 9:26 pm on November 11, 2013 Permalink | Log in to Reply

          I thought the same thing originally. Helvetica Neue isn’t that bad, but it’s also not standard on a number of platforms. Neither is Helvetica. This was news to me. I don’t know of a definitive list online, but this one from MailChimp is helpful, and the reason I said and tried Arial. http://templates.mailchimp.com/design/typography

          • mindctrl 9:27 pm on November 11, 2013 Permalink | Log in to Reply

            Sorry, actually standard Helvetica is.

            • jwarren 11:09 am on November 13, 2013 Permalink

              If we’re going with system fonts, it should probably just be standard ‘san-serif’, which will be Helvetica on OSX, Arial on Windows, and whatever has been deemed appropriate on the Linux distro of choice. It also allows people and browsers to override that easily for their own purposes – perhaps a different language, perhaps extra visual clarity, perhaps an unusual display technologo… who knows?

    • Robert Dall 9:41 pm on November 11, 2013 Permalink | Log in to Reply

      I have never really like relying on a third party service to do what could be done internally.

      Also what if you are developing locally without access to the internet?

      Regardless of who provides the free service. One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Now it would be easy to swap it out but why rely on something like that anyways.

      • Matt Thomas 9:50 pm on November 11, 2013 Permalink | Log in to Reply

        To be clear, we’re talking about linking to Google Fonts for Open Sans just until we can solve this in a standalone way, as @matt mentioned above.

        If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

    • Ryan Hellyer 10:04 pm on November 11, 2013 Permalink | Log in to Reply

      I suspect that bundling scripts into WordPress core will create privacy concerns for many people. The ability to perform analytics via them will disturb a small segment of the user-base.

      It may even be illegal in some countries. Germany springs to mind in regards to that. They’re already super ticked off about being spied on at the moment, so I think it might be best if WordPress doesn’t join the party too.

      And yes, you can install a plugin to force them to be self-hosted, but many people will just unwittingly hit the “update” button without ever realising that they’re opening themselves up to privacy issues.

      • Doug Wollison 10:10 pm on November 11, 2013 Permalink | Log in to Reply

        What if we take a progressive enhancement approach? By default, we wouldn’t actually load Open Sans from anywhere, and instead just falls back to whatever font it can. Then we offer plugins (or packaged right in the core) options for self hosted or google hosted.

      • daveshine (David Decker) 11:49 pm on November 11, 2013 Permalink | Log in to Reply

        Almost any modern theme loads Google Fonts already, including some of the default themes, plugins not counted…

        I have absolutely nothing against loading Open Sans from Google, and find it a rather good option to do so.

        Yes, there are lot of issues with privacy that should be done better – in my opinion this topic here falls not amongst them…. just my personal view.

        Thanks, Dave from Germany :)

    • Dion Hulse 11:14 pm on November 11, 2013 Permalink | Log in to Reply

      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.

      If we actually want to use Open Sans for WordPress, this is unfortunately what we have to do.

      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic) weighs in at 576K uncompressed (92K WOFF, 484K SVG), 174K compressed.
      • Open Sans (WOFF+SVG for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 4.5MB uncompressed (345K WOFF, 4.2MB SVG), 826K compressed.

      The SVG’s will compress well as they’re just text, WOFF is already compressed. We could have a light-weight PHP script that served compressed documents intelligently depending upon the client (selectively adding Charsets based on WPLANG / browser UA), but this has caching issues amongst other things.

      If we actually look at what the fonts are for though…

      • WOFF is the primary font, it’s supported by most browsers.
      • SVG is included for iOS 3.2-4.3 support, and for Android Browser 4.0-4.3.

      Given the significant size of SVG fonts, it makes me question if we should be using them at all, it doesn’t add much extra browser support.

      An alternative is shipping with WOFF+TTF fonts – that would add support for iOS 4.2-4.3 (iOS 3.2 misses out), and Android 2.2-4.3 (SVG only works for 4.0-4.3).

      • Open Sans (WOFF+TTF for Italic, Regular, SemiBold, and SemIbold+Italic w/ full charset support ) weighs in at 1,000K uncompressed (345K WOFF, 661KB TTF), 689K compressed.

      or.. just drop Open Sans for those mobile clients.. since it really doesn’t seem worth it.. WOFF supports most desktop browsers and modern mobile devices, and we should have a GOOD font fallback list for unsupported browsers (which we don’t currently have with MP6, but we did previously have in WP 3.6).

      • Dion Hulse 11:22 pm on November 11, 2013 Permalink | Log in to Reply

        I also missed that SVG is also for Mac Safari 3.2-5.0, not just for iOS. TTF is supported in Safari 3.1-5.0 as well.
        TTF/SVG is also needed for older Opera versions (desktop and mobile, and some gaming systems), but WOFF is supported for v11+ so that doesn’t seem like a deal breaker at all (coming from an Opera user..)

      • Matt Thomas 11:48 pm on November 11, 2013 Permalink | Log in to Reply

        I don’t recommend using the un-subsetted font for any solution because of the extra page weight that every user would incur. Intelligently loading the correct subset for the specified language is the best possible user experience, whether it’s linked to from Google fonts or we implement our own solution that accomplishes the same result. Just for comparison, this is the size difference for a single weight and style of Open Sans (we need four: regular, italic, semibold, and semibold italic).

        • English subset, WOFF: 13 KB
        • Czech subset, WOFF: 17 KB
        • Full charset, WOFF: 85 KB
        • English subset, SVG: 32 KB
        • Czech subset, SVG: 70 KB
        • Full charset, SVG: 1.1 MB
        • Dion Hulse 12:01 am on November 12, 2013 Permalink | Log in to Reply

          So yes, I’d never suggest SVG for this.. ever..

          WOFF however, we can get away with including the full set, the extra page load isn’t significant once it’s in the cache.

          Most web services will get away with only loading one subset as they know what the characters on the page are, WordPress doesn’t really know the answer to this, French accented characters can appear in an English post, etc.. so relying upon WPLANG is a rather bad idea for this.

          One method would be to have Javascript detect the characters on the page and load the english by default, and optionally load the larger CSS if it spots any of those characters..

          Even Google Fonts requires you to specify which subsets you want to load, it can’t automatically guess what’s on the page.. so it’ll have the same page load issues (except that you gain benefit from their extra-special browser compression and CDN).

    • davelab6 5:30 am on November 12, 2013 Permalink | Log in to Reply

      Disclaimer: I consult for Google, Adobe and other companies on web fonts and libre fonts issues, but I represent only myself. This is my own personal opinion.

      One day Google (or Adobe who just started there own free font embedding service) “could” turn around and say. “Ya were not going to do that free font thing anymore”

      Anyone can see that Google uses the Fonts API for its own web apps and web pages. Since the fonts are libre licensed, if that day ever comes, switching is possible.

      If you’re working locally with no internet connection, the fonts will just fall back to the browser-defined “sans-serif” font (Helvetica on OS X, Arial on Windows by default).

      If you’re working locally, you can install the fonts, and if the CSS includes them with ‘local’ (as the Google Fonts API css does) then they’ll load :)

      For WordPress to self host the fonts, in a way that matches the fonts served by Google’s Fonts API, you’ll want to subset them by language, and also have versions with the hinting removed to serve to browsers on platforms that don’t use hints, and perhaps also CFF versions for platforms with good CFF rendering. Since WordPress doesn’t have a dynamic font subsetter, you’ll need a set of language subsets and a set of hint subsets.

      WOFF, SVG, TTF, EOT is needed for full browser support, in descending order of importance. If you leave out formats, you will leave out users. Maybe that matters, maybe it doesn’t.

      By using the Google Fonts API you support all users on all platforms. The API doesn’t carry a cookie, so there aren’t the same privacy implications.

      • Matt Thomas 4:15 pm on November 18, 2013 Permalink | Log in to Reply

        Thanks Dave, this is good information to have. Aside from the font format issue — I think we could get by with WOFF and SVG or TTF, based on the browsers we have chosen to support (others would just fall back to browser-standard sans-serif as in 3.7). But hinting and internationalization are big issues that will be thorny to solve with a bundled solution.

    • jwarren 11:14 am on November 13, 2013 Permalink | Log in to Reply

      I would suggest that bundling would be ideal – who know what strange systems WordPress could be running on if/when Google eventually deprecates their fonts service? It also keeps the experience consistent for any isolated environments. Local development away from a consistent internet connection is not an infrequent occurrence, and the fewer 404s, the better.

    • toscho 3:17 am on November 17, 2013 Permalink | Log in to Reply

      MIME types for fonts are not always set up properly on the web server. I just had such a case recently, where the browser showed garbage on first load because of that. The second load took the fonts from cache, and the browser applied the correct glyphs.

    • Louy Alakkad 2:25 pm on November 17, 2013 Permalink | Log in to Reply

      How about using the ‘open-sans’ fonts by default and giving the user three options in theme settings, first is open-sans, second is google fonts and third is downloading a plugin that contains all the fonts needed?

    • Anderton 1:08 am on November 18, 2013 Permalink | Log in to Reply

      Also, Google is blocked in some countries (i could for example not use Google Fonts in China now and then). Now this is no issue with the bundling open san. But for reference: http://www.google.com/transparencyreport/traffic/disruptions/#expand=Y2013

    • Milan Dinić 4:50 pm on November 18, 2013 Permalink | Log in to Reply

      I vote for ditching Open Sans for reasons already mentioned in this thread:

      • Why would we all of sudden rely on external service for essential part of WordPress that is admin area? Then why don’t we also load jQuery from Google, at least that way there would be real benefit since it would save billions of request?
      • Why would we decide which subset to use based just on WPLANG? What with those that use admin in English even though content is in other language? What for multilanguage? Some browsers don’t do proper fallback and we’ll end with squares and other garbage. If Open Sans gets in, all subsets should be included, that’s the price of using nonstandard font.
      • Possible server issues.
    • mor10 7:41 pm on November 19, 2013 Permalink | Log in to Reply

      For the default theme any custom font needs to be bundled for a simple reason: Not every WordPress installation runs on a computer connected to the web. There are many scenarios in which the site is not connected to the web: It could be a standalone application entirely severed from any network, it could be a site hosted on a secure intranet, the list goes on. As an external font library would result in a non-standard experience for these use scenarios I would encourage the inclusion of any custom font in the package itself. And for those same scenarios the inclusion of TTF and EOT might well be necessary since many of these users (European hospital intranets is one example) are stuck behind old system architecture that doesn’t support IE9 and above. Keep in mind that IE9 requires Windows 7, an update not yet undertaken by large parts of government and large industry landscapes.

    • Milan Dinić 5:11 pm on November 28, 2013 Permalink | Log in to Reply

      I have coded a simple plugin that disables loading of Open Sans from Google’s servers. If you have any comments about it (including its name), please share and I’ll submit it to repository in a few days.

    • mighty_mt 7:34 pm on December 10, 2013 Permalink | Log in to Reply

      So what’s the status here? I see in 3.8-RC2 (and also in MP6 2.2.1) that Open Sans is still loaded from Google. And to be honest, I don’t like that.
      I also think that WordPress shouldn’t use web fonts for the admin at all (especially not ones loaded from third party servers). Even though the new admin looks very pretty with Open Sans.

    • Alex Nguyen 1:48 am on December 15, 2013 Permalink | Log in to Reply

      Is there any way to disable Open Sans in the new 3.8 update? My blog is in Vietnamese and Open Sans does not display Vietnamese characters properly.

    • Paul 8:36 pm on December 19, 2013 Permalink | Log in to Reply

      Would love to dequeue open sans, it was a lovely idea but on a unstable african ISP its making editing on a clients site an unbearable experience – and I’m fairly privileged – honestly a standard stack would suit me fine, or just ‘sans-serif as someone suggested above.’. I really don’t thing open sans looks that great to boot.

    • ElectricFeet 12:44 pm on February 19, 2014 Permalink | Log in to Reply

      If it must be linked and not bundled (and I defer to your expertise on that decision), the best option would be to have a simple checkbox in “Edit my profile”: Use Google fonts for admin area?

      Apart from privacy concerns, linking on local dev environments really slows things down.

      (I’m using Milan’s plugin for now. Thatnks Milan!)

    • owcv 4:23 pm on February 24, 2014 Permalink | Log in to Reply

      I’m not happy with this kind of integration of Google on my WordPress Website. I don’t want big brother to watch my site. Open Sans should be included in WordPress but not linked to Google. At least there should be an option to deactivate for users in countries with certain information privacy policies. In the EU for example this could be a violation of actual law!

  • George Stephanis 10:35 pm on November 4, 2013 Permalink
    Tags:   

    Upcoming Global Admin Search (née Omnisearch) Meeting 

    After the feedback in the merge chat today, it looks like we’ve got a bit more work to do on the global search spine.

    Based on a quick survey, it looks like Monday, November 11, 20:00 UTC (3pm EST) is likely to be the best time for the most people.

    As we’ve done before, we’ll meet in #wordpress-core-plugins on Freenode, and I’ll give a shout in advance on #wordpress-dev for anyone that may be lurking in there.

    Putting up the bat-signal:

    Other folks who spoke up during the merge chat that I’d love to have join us:

     
  • Andrew Nacin 7:14 pm on November 1, 2013 Permalink
    Tags: ,   

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

     
  • Samuel Sidler 11:27 pm on October 22, 2013 Permalink
    Tags: ,   

    Preparing your feature for the 3.8 merge 

    Now that 3.7 RC has shipped – and the final release is coming soon – it’s time to talk a bit more about how merging to core will work for feature plugins. First, let’s talk about decisions.

    Decisions

    I’ve been asked a few times “who decides” what goes in core and variants of that question. There’s actually three decisions that need to get made. In order:

    1. Does the feature belong in core?
    2. Is the feature ready for core?
    3. Should the feature be in this release?

    Core contributors and members of the community are strongly encouraged to help inform and guide each of these decisions. You may even want to offer some of your feedback in the form of answers to these questions. Each question is ultimately answered by a different group.

    1. Project leaders determine if a feature belongs in core.
    2. Contributing developers determine if a feature is ready for core.
    3. The release lead – for 3.8, @matt – determines if a feature belongs in a particular release.

    We’re now at the point where these questions need to get answered. To do that, it’s time to present your feature plugins.

    Present Your Feature

    If you remember back when we first started the feature plugin process, each team had to present its feature idea and answer a few questions. We’re going to do that again, but with a bit more information. If your project thinks it’s ready for core – and specifically for 3.8 – your team lead should make a post to make/core with the following information:

    • A visual and written overview of your feature plugin, along with a link to your plugin.
    • What problem is your feature plugin trying to solve?
    • What brought you to this solution and what other potential solutions did you explore?
    • Have you done user testing of your feature plugin? If so, what were the results? What worked and what didn’t?

    In your post, be sure to include links to previous posts and even specific comments that have helped form your decisions.

    Be ready for feedback from across the WordPress community – especially UX and code quality  – and be ready to defend your decisions or change your mind if a better idea emerges. Everyone will be reviewing the make/core posts and feedback in their discussion threads to determine if the answers to the questions above are all “yes”. If so, the feature can land when the merge window opens.

     
  • Andrew Nacin 3:07 am on August 7, 2013 Permalink
    Tags: ,   

    WordPress 3.8 meeting Thursday, August 8 

    In his State of the Word keynote, @matt announced that WordPress 3.7 and 3.8 will be developed simultaneously. Trunk would represent 3.7, while for 3.8, potential new features would be developed first as plugins. (3.8 starts at 35:00 in the video.)

    This “features as plugins” method* will allow teams to conceptualize, design, and fully develop features before landing them in core. This removes a lot of the risk of a particular feature introducing uncertainty into a release (see also 3.6, 3.5, 3.4 …) and provides ample room for experimentation, testing, and failure. As we’ve seen with MP6, the autonomy given to a feature team can also allow for more rapid development. And in a way, 3.7 provides a bit of a buffer while we get this new process off the ground.

    As announced at WordCamp San Francisco, Matt is leading the 3.8 release. He identified MP6 as a likely candidate for 3.8, along with the Twenty Fourteen theme. WP 3.7 will be released in October, at which point we’ll begin short window (probably two to three weeks) for any features to be merged for 3.8. If a feature isn’t ready for release by this point in the development cycle, it doesn’t land in core and moves to the next release. The target for WordPress 3.8 is early December.

    On August 8 at 18:00 UTC, Matt will host a WordPress 3.8 meeting in #wordpress-dev on Freenode.

    Thursday’s meeting is a great time to propose features that you’re interested in working on, keeping in mind they may or may not make it into WordPress 3.8. But keep in mind an early December timeline sets up WordPress 3.9 to kick off no later than January. Bring your ideas and thoughts as 3.8 development begins!

    To recap this post and the previous 3.7 post:

    • Wednesday, August 7 at 20:00 UTC — WP 3.7 initial planning meeting, #wordpress-dev
    • Thursday, August 8 at 18:00 UTC — WP 3.8 initial planning meeting, #wordpress-dev

    * Yes, this is more or less “feature branches,” but our rich plugin architecture makes it an obvious choice to follow the plugin-based model set by MP6. We have built features in plugins before — distraction-free writing in 3.3, the customizer in 3.4, and media in 3.5 all started as plugins. But they were pegged to a specific development cycle and did not have full teams developed around them, two issues we are now trying to fix.

     
    • Andrew Nacin 3:16 am on August 7, 2013 Permalink | Log in to Reply

      Just a note: All future weekly development meetings (Wednesdays, 2000 UTC) will cover both 3.7 and 3.8 updates and discussion items. Individual 3.8 feature teams will likely schedule their own office hours and such, as well. I understand how 1800 UTC is a terrible time for our friends in Australia and we’ll try to keep them a little more sane without upsetting our friends in Eastern Europe. :-)

    • Gage Morgan 3:34 am on August 7, 2013 Permalink | Log in to Reply

      That’s a very inspirational AND smart idea – building plugins are like making a model piece by piece to demonstrate what the software should look like before actually making any promises that the software will make it into core – if it doesn’t look right, rebuild it or just take it out completely. This will make the design process faster. Indeed, very smart indeed.

      • Scott Kingsley Clark 5:14 am on August 7, 2013 Permalink | Log in to Reply

        Agreed, and building as a plugin should help keep things well abstracted so it can be coded well, or other developers can provide their own ‘take’ on it too.

    • Eric Andrew Lewis 4:04 am on August 8, 2013 Permalink | Log in to Reply

      So working on two versions simultaneously is a practice that won’t be continued, at least for 3.9?

  • Andrew Nacin 7:17 pm on August 6, 2013 Permalink
    Tags: ,   

    WordPress 3.7 meeting tomorrow, August 7 

    If you haven’t caught @matt‘s State of the Word keynote at WordCamp San Francisco last weekend, you should. It contains a lot of great insight into how WordPress is used (using data from the 2013 user survey) and what should be expected for WordPress 3.7 and 3.8. (Talk about 3.7 starts at around 33 minutes in.)

    Here’s what was announced: WordPress 3.7 will be released in two months — early October. (Wat.) Jon Cave (@duck_) and I will be leading the release. It will be a quick “platform-focused” release, with a focus on stability and security.

    There are three main things we’d like to get done — language packs, auto-updates for minor releases, and some enhancements to help strengthen user’s passwords. Beyond that, though, the major goal of 3.7 is to offer a bit of a “reset” — which includes a huge cleanup of Trac. We’re currently at 3,800 open tickets, and we’d like to whittle that down as well as make things more manageable for the future. That includes reorganizing our Trac components, making it easier to contribute to certain areas of core (rather than, say, drinking from a single Trac firehose), and trying to organize teams around these components.

    Outside of core, there will also be work on developer.wordpress.org, which will include a hosted code reference and developer handbooks. As part of this, there will be a lot of inline documentation cleanup in 3.7 — potentially including an inline documentation standard for actions and filters.

    Better development tools will also be a goal in 3.7 — see also the post on develop.svn.wordpress.org from earlier.

    This is just the beginning. Please join me on Wednesday, August 7, 20:00 UTC for our weekly developer meeting in #wordpress-dev on freenode.net. I expect 3.7 to be a bit crazy, with a high volume of commits (oh, the days of WordPress 3.0), but also with increasing organization that can help set the stage for future releases. Daily bug scrubs! Rapid development! High tempo! Yay! Who is with me? See you tomorrow.

     
  • Andrew Nacin 2:26 am on July 28, 2013 Permalink
    Tags: post types, ,   

    Potential roadmap for taxonomy meta and post relationships 

    In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

    (During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

    The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

    At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

    So when we talk about term meta, we’re actually talking about term taxonomy meta — meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

    (There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

    At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

    It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

    These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.

    Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

    How can we remove an entire table but still be backwards compatible? We came up with two solutions:

    1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
    2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

    In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a wp_terms table. Wow, right?

    So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

    Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

    Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

    The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

    A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

    That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

     
    • Scott Taylor 2:39 am on July 28, 2013 Permalink | Log in to Reply

      `WP_Term` should happen as soon as possible. Proper modeling, fix caching, etc

      • Andrew Nacin 6:26 am on July 29, 2013 Permalink | Log in to Reply

        Yes, but ideally we wait until we have a single ID to pass around. It really needs to be term_taxonomy_id, but we don’t pass it around anywhere else in the UI.

    • Jon Brown 2:44 am on July 28, 2013 Permalink | Log in to Reply

      Will this happen for 3.7? j/king… I read every beautiful word of this post including the disclaimer. This all sounds brilliant. TaxID/TermID confused the heck out of me for a LONG time as a new to WP developer.

    • Scott Kingsley Clark 4:06 am on July 28, 2013 Permalink | Log in to Reply

      Excited about all the above, will watch like a hawk at how things go and be available to test and implement changes in my own projects!

    • Manny Fleurmond 4:52 am on July 28, 2013 Permalink | Log in to Reply

      Keeping an eye out for developments. The things that could be possible with connecting posts, terms, users, etc in all types of relationships (one to one, one to many, many to many) is mind boggling. This would definitely help plugins like bbPress and cause an awesome boom of innovation in the WP plugin development community. I wait and watch with baited breath.

    • Grant Palin 5:14 am on July 28, 2013 Permalink | Log in to Reply

      The two terms tables have puzzled me for a while. Now I see it is due to the way core is set up. So it’s interesting that you are looking at correcting the core setup and simplifying things a bit. WP_Terms sounds good, and will help improve the image that WordPress has among some coders as being poorly coded. And not least, the possibility of having content type or term relationships in core would be excellent, and further the ability of WP to be a CMS out of the box.

    • Mike Schinkel 5:22 am on July 28, 2013 Permalink | Log in to Reply

      Finally.

    • Shane Pearlman 5:51 am on July 28, 2013 Permalink | Log in to Reply

      + yay

    • rfair404 7:01 am on July 28, 2013 Permalink | Log in to Reply

      Both are great ideas. I want to play.

    • Avryl 8:29 am on July 28, 2013 Permalink | Log in to Reply

      Awesome! :D

    • Hassan 9:42 am on July 28, 2013 Permalink | Log in to Reply

      For the past two weeks or so I was always thinking about taxonomy meta, whether WordPress will ever support it or should I just go with workarounds (e.g. wp_options). Then all of a sudden @nacin wrote this post! Yay!

      Even though it’s not here yet (hey come soon already!), I’m already planning for some projects! (Yeah, I read the disclaimer :))

    • Julien 10:13 am on July 28, 2013 Permalink | Log in to Reply

      Great news! The future is bright with WordPress. This will open up everything and Worpress will be seriously taken as à tool for web application! Can’t wait to see this released for Wp 3.9 (kidding;))

    • Mike Little 11:24 am on July 28, 2013 Permalink | Log in to Reply

      For those who need to work now with the idea of Term/Taxonomy metadata, there are some plugins already out there. I have successfully used “Taxonomy Metadata” (http://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (http://wordpress.org/plugins/meta-for-taxonomies/) looks interesting.

      A question: the current system (sort of) supports synonyms/aliases for terms, which can be very useful: are there plans to retain this functionality?

      • Rahe 8:03 am on July 29, 2013 Permalink | Log in to Reply

        Meta for taxonomies is perfect, it uses the WordPress meta API and is only an API ( like the WordPress post_meta ).
        I use it very often, the only problem is there is no easy way like the posts meta box to display/edit the meta in the admin.

      • Andrew Nacin 8:13 am on July 29, 2013 Permalink | Log in to Reply

        I’ve almost never seen it used, but no plans to remove that functionality. This should continue to work just fine. Worth pointing out that any shared terms will be split which could possibly break aliases. Something to keep in mind.

    • aristath 12:30 pm on July 28, 2013 Permalink | Log in to Reply

      This conversation brings in mind what happened on Drupal 6 when it became Drupal 7. I know Drupal and WordPress are 2 completely different things, but bare with me.

      On Drupal 6, there were taxonomies and nodes. Something similar to out terms and posts… And the database structure was also similar to what we have now.
      On Drupal 7 however, they decided to make some radical changes. There were no longer nodes and taxonomies, everything was an “entity”. The database structure was significantly simplified and allowed it to move forward as a CMS.
      Ideally this is the direction I would love to see on WordPress… and this sounds like a first step to that direction.

      The proposed solutions are both viable, though I find the 2nd one more compelling.

      • Andrew Nacin 8:15 am on July 29, 2013 Permalink | Log in to Reply

        Yeah, we’re aware of this. It’s certainly something to at least think about. But I don’t think a generic “entity” makes sense for us.

        I’ll share that, according to folklore, the current taxonomy schema was actually inspired by Drupal’s own schema. And we know how that went. :-)

    • Charles Frees-Melvin 2:25 pm on July 28, 2013 Permalink | Log in to Reply

      What if there was a single meta table and a meta_type filed that has “posts”, “comments”, “users” in it. It would make meta more versatile to extend to taxonomies once taxonomies are ready for it. Kind of like we did to categories and link categories when we came up with the terms/taxonomies system.

    • Mike 2:47 pm on July 28, 2013 Permalink | Log in to Reply

      Does this mean I won’t be able to use one taxonomy term with two different taxonomies?
      Because I thought that was the perfect bug –>>feature scenario.

      • Matt Van Andel 11:57 pm on July 28, 2013 Permalink | Log in to Reply

        This wouldn’t affect that at all. Currently, taxonomy terms are an overly-normalized nightmare. If you create a Category called “Foo” and a Tag called “Foo”, only one term is added to wp_terms and then it is associated with the taxonomy in wp_term_taxonomy. The weird thing about this is that there is only entry in wp_term_taxonomy for each term, even though the normalized terms are listed in wp_terms. It is, frankly, really stupid… but as @Nacin said, hindsight is 20/20.

        What is being proposed is that those two tables are merged. You could still have identical terms in multiple taxonomies – but how they are identified in the database and by the API would change to something a little more sane.

        • Mike Schinkel 5:39 pm on July 29, 2013 Permalink | Log in to Reply

          taxonomy terms are an overly-normalized nightmare.

          Actually, if it had been normalized it would likely be much less of a nightmare. As-is the current schema causes E. F. Codd to turn over in his grave.

    • Robert Chapin 4:29 pm on July 28, 2013 Permalink | Log in to Reply

      Excellent direction.

    • Stephanie Leary 8:09 pm on July 28, 2013 Permalink | Log in to Reply

      I will now find @nacin and give him a hug.

      (+1)

    • portfola 8:43 pm on July 28, 2013 Permalink | Log in to Reply

      This is a welcome development, thank you!

    • Matt Van Andel 11:33 pm on July 28, 2013 Permalink | Log in to Reply

      Finally! These are all things that have driven me crazy for as long as I’ve been developing for WordPress.

      But over at *least* 5 major versions? Ugh. Post 2 Post is a decent bandaid, but that’s functionality that we need in core as of yesterday. What is the reasoning for spacing out the rollout that much? Is it just to minimize potentially breaking changes? Are there ways we can accelerate the process?

      • Japh 11:36 pm on July 28, 2013 Permalink | Log in to Reply

        If you have a listen to Matt’s State of the Word talk, you’ll note that the plan is to speed up update and release cycles generally. So this could happen over a shorter period of time than you might think, despite being over a number of cycles.

        In fact, I imagine it’s this type of thing that’s part of the reasoning behind speeding up the cycles: bigger changes can happen faster.

      • Andrew Nacin 10:43 am on July 29, 2013 Permalink | Log in to Reply

        As the post tried to carefully outline, this requires a significant number of schema, API, and architecture changes. Database upgrades can be very painful, especially with the very real potential of significant amounts of data to modify and migrate here — we need to make sure that we don’t try to bite off too much each release.

        There’s nothing wrong with Posts 2 Posts being in a plugin. You’ll note this post doesn’t actually promise post relationships — it’s entirely possible we leave it out of core for the long term. I’m not saying it’s likely, but my point is that not only is there not a way to accelerate this process, but that there isn’t a need for it either.

        • Taras Mankovski 5:28 pm on July 29, 2013 Permalink | Log in to Reply

          > There’s nothing wrong with Posts 2 Posts being in a plugin.

          This reads like a Jedi mind trick: “You don’t need this… Go back to work.”

          “I don’t need this… I’ll go back to work”

    • sboisvert 4:14 am on July 29, 2013 Permalink | Log in to Reply

      I’ve thought about this. And I’m happy smarter people have also thought about it and now have a good plan to fix it :)

    • Frank Bültge 10:04 am on July 29, 2013 Permalink | Log in to Reply

      @Nacin Thanks for the status. This are very nice news.

    • Michael Dance 5:00 pm on July 29, 2013 Permalink | Log in to Reply

      This sounds like a really, really sharp approach. Great job so far.

      As a heavy Posts 2 Posts user, I just want to mention that post relationships have pretty much eliminated my need for term meta.

      As a simple example: say you have a Journal Article post type and a Journal Issue taxonomy. Each term is a different journal issue, but for each one you’d want an image, a masthead — more than a term can provide. So that’s where term meta could help.

      But: with post relationships, you can just make Journals a post type and relate each journal to a bunch of articles that way. Suddenly journals have access to post meta, featured images, the works.

      I’m not saying I don’t want term meta at all, but there is a danger that it could open the door to terms and taxonomies being used way beyond the scope of what they’re meant to do and muddy the lines between term and post. And while post relationships can cover most of the use cases of term meta (if I’m wrong on this, I’d love to see some examples), the opposite is definitely not true, so to me, post relationships are the bigger priority.

      (All that said, I know that this is a long way off, and in the meantime I’m just as excited about getting rid of the shared term abstraction and creating WP_Term.)

    • Ben Huson 7:11 pm on July 29, 2013 Permalink | Log in to Reply

      Nice to see this on the roadmap – even if we should “not expect this to happen at all” :)

    • Marcus 12:46 pm on July 30, 2013 Permalink | Log in to Reply

      this will be awesome!

    • Allstar 9:14 pm on July 30, 2013 Permalink | Log in to Reply

      I’m all for progress…

      What about internationalisation?

      I’ve wanted for ages for the term_taxonomy tables description field to be moved into the terms table. Therefore all the language would be in one place and the data in another.
      So, you would only use the term_taxonomy_id as a primary for getting stuff BUT you could have multiple terms (in different languages) associated with it. You would not go to the terms table first to find something unless it was by text lookup.

      A WP_Term object is a big *like* from me but I’d l’d also like WP to be easier on the international side of things and my above comment on how to do international user entered terms would be a good step.

      Of course I’m no Core Developer big wig so I might’ve overlooked something but it’s at least worth mentioning in case the idea had been overlooked or I overlooked a way of doing it.

    • shawfactor 7:18 am on July 31, 2013 Permalink | Log in to Reply

      @nacin the speed and modelling improvements would be nice but the can you elaborate further on how you would extend the current taxonomies which are doubles into triples without having a redundant field on the doubles?

      Also I think Posts 2 Posts plugin by @scribu is nice but as I’ve argued: http://shawfactor.com/b/gaA

      post relationships need to be in the core and they nheed to be semantic.

    • Chris Lema 2:53 pm on July 31, 2013 Permalink | Log in to Reply

      +1 for doing it over several releases (even if it’s slow). Quick DB changes have tons of unintended consequences. Great write up.

    • AzzX 12:10 am on August 2, 2013 Permalink | Log in to Reply

      I have used CPTonomies and Posts to Posts to achieve more functionality though they are hacks and susceptible to being discontinued and breaking. This is where Drupal excels. If I want to have ratings and comments on a specific Taxonomy I can – without hacking the core.

    • grindcode 12:10 pm on August 2, 2013 Permalink | Log in to Reply

      This is the last milestone WP needs to approach any needs. Good stuff!

    • Chuck Reynolds 10:43 am on August 3, 2013 Permalink | Log in to Reply

      needs to happen.. might as well start the move and roll it out slow.

  • Mark Jaquith 11:10 pm on February 18, 2013 Permalink
    Tags: , ,   

    Screen Shot 2013-02-18 at 5.15.50 PM

    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:

    Screen Shot 2013-02-18 at 4.52.23 PM

    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!

     
    • Amy Hendrix (sabreuse) 11:18 pm on February 18, 2013 Permalink | Log in to Reply

      First impression: WOW

    • Michael Beckwith 11:18 pm on February 18, 2013 Permalink | Log in to Reply

      Holy color!

    • Alison Foxall 11:24 pm on February 18, 2013 Permalink | Log in to Reply

      Nice Mark!

      First thing I notice is that although the search bar sticks to the top with the Twenty Thirteen branding while you scroll, the main navigation is not up there with it on both large desktop screens and small device screens. Was there a reason for this or can this be changed by the user? And of course I\’m wondering if the user will be able to change those colors for each post format. :)

      • Mark Jaquith 2:26 am on February 19, 2013 Permalink | Log in to Reply

        It’s a known issue, and something I’d like rectified. The dropdown menu that you get on small screens would be great up there. And colors could be overridden by a child theme — probably a lot of option overload if we exposed that.

    • Mel Choyce 11:30 pm on February 18, 2013 Permalink | Log in to Reply

      WOW, instant love! The colors are bold but harmonious, the type is GREAT, and it’s got such a fabulous funky retro futurist feel. Thumbs up!

    • Emil Uzelac 11:34 pm on February 18, 2013 Permalink | Log in to Reply

      Pretty good for the first draft!

    • Xavier Borderie 11:46 pm on February 18, 2013 Permalink | Log in to Reply

      Wow indeed! I too was getting a feeling that the “clear white” theme spirit could feel overplayed if 2013 had it. I for one am very glad that the team is making such a bold move in a creative direction. I trust there will be enough theme option and color schemes so that users can make it their own in a few clicks.

      Great work!

    • aradams 12:10 am on February 19, 2013 Permalink | Log in to Reply

      Love the colors, love the flow. Nice to see creativity unleashed on the default theme!

    • Ipstenu (Mika Epstein) 12:13 am on February 19, 2013 Permalink | Log in to Reply

      Nice! Just … Amazingly nice. I’m gonna have to find a site to use that on. Maybe my own!

    • Marcel van der Horst 12:14 am on February 19, 2013 Permalink | Log in to Reply

      Can’t wait to try it out..

    • BrentLeavitt 12:22 am on February 19, 2013 Permalink | Log in to Reply

      I find that to be just delightful!

    • Aaron D. Campbell 12:23 am on February 19, 2013 Permalink | Log in to Reply

      So excited to have this in. It really is great!

    • Tony Scott 12:27 am on February 19, 2013 Permalink | Log in to Reply

      http://genericons.com/ seems to be behind a WP.com password.

    • Chuck Reynolds 12:32 am on February 19, 2013 Permalink | Log in to Reply

      Looking forward to the post format specific layouts and metadata.
      Would be nice if the video, once ‘fetched’, would autopopulate the title.

    • @mercime 12:50 am on February 19, 2013 Permalink | Log in to Reply

      Very Nice! Shades of BuddyPress :-)

    • trishasalas 1:01 am on February 19, 2013 Permalink | Log in to Reply

      …beautiful, you’ve managed to stick with the mimimal yet spice it up with jazzy colors. Instant LOVE <3

    • Austin Passy 1:03 am on February 19, 2013 Permalink | Log in to Reply

      The theme demo looks great. Like the direction it heading in.

    • Jose Castaneda 1:09 am on February 19, 2013 Permalink | Log in to Reply

      Looking forward to testing the formats. Now to get home and uptade core.

    • Eduardo Zulian 1:36 am on February 19, 2013 Permalink | Log in to Reply

      Just finished testing Twenty Thirteen with the new post formats scheme. Sweet. : )

    • Lori Berkowitz 1:37 am on February 19, 2013 Permalink | Log in to Reply

      Looks great! Also nice to see some post formats love :)

    • Edward Caissie 1:39 am on February 19, 2013 Permalink | Log in to Reply

      Except for the header trick … sorry, it’s just not doing anything for me.

    • Anthony Hortin 2:00 am on February 19, 2013 Permalink | Log in to Reply

      It’s lookin’ great so far! Well done to all involved!

    • Matt Mullenweg 2:12 am on February 19, 2013 Permalink | Log in to Reply

      It’s counterintuitive because this is a visually much more aesthetically opinionated base than we’ve had probably since Kubrick, but I think we’ll see a lot more customization and variations on Twenty Thirteen than Eleven or Twelve. It’s a delightful canvas to play on.

    • Justin Sternberg 4:25 am on February 19, 2013 Permalink | Log in to Reply

      Nice work all around! I couldn’t help myself: http://jtsternberg.com/

    • Sovit - (Theme Horse) 5:37 am on February 19, 2013 Permalink | Log in to Reply

      This one will be the great example to show that without choosing white color can also make clean and beautiful theme. Love the way designer play the colors.
      Thanks to all contributors. Its really Fantastic ! Can’t wait to see it out in my themes directory.

    • Noel Tock 8:04 am on February 19, 2013 Permalink | Log in to Reply

      Love the new direction, looking versatile and fluid, +1

    • Ryan Hellyer 9:37 am on February 19, 2013 Permalink | Log in to Reply

      And here I was thinking that WordPress default themes need to be bland and white.

    • Petya Raykovska 9:50 am on February 19, 2013 Permalink | Log in to Reply

      Wow. Bold move, I love it.

      I’d make the main navigation sticky though, together with the search bar and the site name.

      And it would be great to have some color palettes to choose from as visually color is the first thing you experience with this theme.

    • emzo 10:06 am on February 19, 2013 Permalink | Log in to Reply

      Default WordPress themes have always been great, but they’ve needed to be versatile and cater to the majority, and in doing so have had to be more conservative. This puts the fun back into WordPress, and definitely brings a smile to my face. I do agree that the collapsed mobile menu should be placed in the fixed header when scrolling though.

    • Luc De Brouwer 10:55 am on February 19, 2013 Permalink | Log in to Reply

      This. Looks. Awesome.

    • lonchbox 12:14 pm on February 19, 2013 Permalink | Log in to Reply

      Excellent work! I love the post formats styles :)

    • sourceforge 12:59 pm on February 19, 2013 Permalink | Log in to Reply

      there was a theme in tumblr directory by peter vidani, which used the colors for post types!

    • Monika 2:01 pm on February 19, 2013 Permalink | Log in to Reply

      it looks like Windows8 :-) colorful and dizzying.

    • mindctrl 2:12 pm on February 19, 2013 Permalink | Log in to Reply

      Nice and different direction. With this new bold approach, I’d like to see the base font size increased a bit more. Chrome is telling me it’s 16px, and with Source Sans Pro 16px looks more like 14px. It looks good and is easier to read at 18 or even 20px.

    • Aaron Aiken 2:50 pm on February 19, 2013 Permalink | Log in to Reply

      Absolutely beautiful. Good work!

    • Arnan de Gans 3:15 pm on February 19, 2013 Permalink | Log in to Reply

      Sponsored by Ubuntu I see…

    • Nashwan Doaqan 8:08 pm on February 19, 2013 Permalink | Log in to Reply

      It’s really a beautiful theme , but I don’t think It’s good to be a default theme ,It’s too colourful … Yes it’s different direction but many of WP users like the default themes because they are simple and have a less colours , I was thinking if you can make the colours system is optional in the theme control panel ….

      As I am seeing now , Its seems to be hard to use it as a framework , the default theme should be simple , clean , easy to customize and express WordPress main features !

      • Aaron D. Campbell 8:24 pm on February 20, 2013 Permalink | Log in to Reply

        Twenty Twelve will still be packaged with WordPress too. I do however think this theme will actually be pretty easy to extend.

      • Emil Uzelac 12:40 am on February 21, 2013 Permalink | Log in to Reply

        This is actually going to be a perfect default Theme and honestly, very easy to customize as well.

        Colors are post formats and they can be changed or removed ;)

    • Daniel 10:15 pm on February 19, 2013 Permalink | Log in to Reply

      Is there a reason why the fixed navbar replaces the navigation menu with the site title? Doesn’t that pretty much defeat the purpose of the fixed navbar to provide better accessibility to the site’s navigation? Why would I need a static bar with just a link to the front page?

    • David Radovanovic 12:37 am on February 20, 2013 Permalink | Log in to Reply

      ooooooooo, ahhhhhh – very awesome indeed! The long scrolling homepage, ever-adaptive elements, and I’m sure much more will be realized with a test drive. Thanks!! BTW – why the persistent header with banner on all pages? Am I alone in wondering why is the banner needed on pages other the homepage?

    • Jean-Francois Arseneault 5:35 am on February 20, 2013 Permalink | Log in to Reply

      Surprised to still see ‘Links’ in there as a post type…

    • shazdeh 9:03 pm on February 20, 2013 Permalink | Log in to Reply

      Love at first sight. :)

    • Zulfikar Nore 10:47 pm on February 20, 2013 Permalink | Log in to Reply

      Bold And Beautiful! A total change in direction from previous “Default” themes – this will make an awesome parent theme for developers to tinker with.

      Would like to chime in on the menu though….the sticky menu “bar” minus the menu is not doing it for me – I would like to see the menus as I scroll the page instead of a blank “bar”.

      Further more, since its bold in terms of color scheme – I would like to see the options to adjust the various sections incorporated in the Customizer’s Color section and not having to rely on changing them via child themes. As it is the child theme option would work for developer but not for the novice end user.

      But all in all, I’m totally loving what I see so far – now its time to go break it apart and see what I can conjure up :)

    • bjornsennbrink 9:48 am on February 21, 2013 Permalink | Log in to Reply

      What is up with the breaking of words in titles and in text? It was there in Twenty Twelve and is still around. Any insight on the word-breaking thingy would be great :)

    • alvarogois 2:58 pm on February 21, 2013 Permalink | Log in to Reply

      Strange unanimity… I’m a guy who likes color and bold, though I’m more for minimal. I don’t understand this theme and can’t picture it as a default WordPress theme. Maybe the focus here is on blogs, I get it, and giving the author a panoplia of customization options. I get it too. Nevertheless, I fail to realise how one goes from twentytwelve to this twentythirteen. Sure, it’s a cut, but I don’t see it as a step forward, something new, more like something else.

      (I could be wrong, though… me and Nashwan Doaqan up there…)

    • Marco Raaphorst 3:55 pm on February 21, 2013 Permalink | Log in to Reply

      cool, love it!

    • rilwis 5:32 pm on February 21, 2013 Permalink | Log in to Reply

      Amazing theme. I like it and have a good feeling when I see it at first. It’s great when you can push the boundaries so far. It’s time to show people that WordPress is easy to customize.

    • Brad Dalton 9:16 pm on February 21, 2013 Permalink | Log in to Reply

      Its like it or not based on my readers feedback. Personally i love it but also know you guys could seriously blow the socks off any premium theme out there. Built in hooks and conditional tags is where its headed i think. WordPress theme users are smarter now and want more. They understand the basics of coding. Extend further.

    • tomjanski 9:44 pm on February 21, 2013 Permalink | Log in to Reply

      The bold colors and bold theme. Bravo. It’s going to be a good one.

    • Shea Bunge 4:39 am on February 22, 2013 Permalink | Log in to Reply

      Wow… really, really good. It”d be nice to get the default theme out early this year. (I;ve always thought that the annual themes should be released at the start of the year, not the end ;)

    • lisafirke 3:34 pm on February 22, 2013 Permalink | Log in to Reply

      Gorgeous and playful. Bravo!

    • Tatiane Pires 3:06 pm on February 24, 2013 Permalink | Log in to Reply

      Great!
      I can’t wait to make a new theme for my blog based on Twentythirteen.

    • suzybyrnes 12:54 pm on February 27, 2013 Permalink | Log in to Reply

      love the full width. Agree with comments about fixed nav bar. Look forward to seeing what people do with it. Thanks v much.

    • bru.scopelliti 4:50 pm on February 27, 2013 Permalink | Log in to Reply

      What I have seen is very promising. Can’t wait the release

    • ecksteing 10:01 pm on February 28, 2013 Permalink | Log in to Reply

      Twenty Thirteen is absolutely beautiful. Love the use of differing colours per Post Format.

    • Hassan 8:04 pm on March 2, 2013 Permalink | Log in to Reply

      My first impression was color-shock!

      It reminds me of the new refresh of Windows.com after the release of Windows 8. Oh, and those arrows for Newer and Older Posts, It’s hard not to see the “Metro effect” there ;)

      Also, I love the theme!

    • Misha 5:37 pm on March 3, 2013 Permalink | Log in to Reply

      Oh, this theme is really nice on the whole! It’s interesting how it will look with a sidebar… I really need it.

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