WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: 3.8 Toggle Comment Threads | Keyboard Shortcuts

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

     
    • Andrew Nacin 9:02 pm on December 18, 2013 Permalink | Log in to Reply

      Remember that a critical failure (what these numbers are calculating) only means “we started to copy files and failed to verify we copied all of them”. It doesn’t mean the site crashed and burned.

    • niklasbr 10:00 pm on December 18, 2013 Permalink | Log in to Reply

      Does 3.8.1 verify that no plugins or themes break and not just the WP update itself works as it ought to?

      • Ipstenu (Mika Epstein) 10:30 pm on December 18, 2013 Permalink | Log in to Reply

        There is no 3.8.1 at this time (we’ve not even started talking about it yet in today’s devchat ;) )

      • Andrew Nacin 11:11 pm on December 18, 2013 Permalink | Log in to Reply

        We’re not concerned about breaking plugins or themes in a minor release. These changes go through a very rigorous review process and are never designed to break or threaten compatibility.

        Major releases, on the other hand, could possibly cause problems on a minority of sites — and yeah, that’s where verifying that plugins and themes are good to go will come into play.

        The updating code is the same for both minor and major releases — shifting major releases to be auto-updated by default is all about avoiding breakage and shifting perceptions.

        • niklasbr 11:27 pm on December 18, 2013 Permalink | Log in to Reply

          Can I somehow convince you that it is a cause for concern or have you made up your mind on the topic?

          Plugins and themes do break all the time in minor releases, however, that is not a big concern when updating manually. However, it becomes a huge issue when they break automatically.

          • John Blackbourn 2:35 am on December 19, 2013 Permalink | Log in to Reply

            Plugins and themes do break all the time in minor releases

            Do you have a list of such plugins and themes (and which releases they broke in) to hand? Or a link to corresponding forum threads? Bear in mind we’re talking about minor releases here, which is a release number with a third level. For example, 3.7 is a major release, 3.7.1 is a minor release.

            • niklasbr 2:12 pm on December 22, 2013 Permalink

              I don’t have a list because I never thought such a list has been needed.

              WP Super Cache and JetPack are probably the most prominent I have experienced issues with in some minor releases (e.g. 3.6 to 3.6.1 and 3.5 to 3.5.1 and 3.3.1 to 3.3.2).

          • Jeff Chandler 3:23 am on December 19, 2013 Permalink | Log in to Reply

            The topic and concerns were discussed ad nauseum around the time the feature was added to WordPress http://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/ all of the angles have been discussed and no convincing is necessary. The only convincing that can happen at this point is from the data that is gathered from sites performing auto updates.

    • GJudy 4:50 pm on December 27, 2013 Permalink | Log in to Reply

      I am an intermediate user. I have about 30 sites, but only one seems to be doing this auto-update for the minor changes. It sent me 6 emails over three days that the update was in progress and done. http://gentwo.sensiblestrategy.com says 3.8.1 alpha is the version running. I don’t know what I did to get this one site into that update queue.

      None of my other sites have done anything. They were updated about the same time to version 3.8. Many were done using ftp because they were behind more than one version. Some were done with the update button even though they were behind more than one version. I turned all plugins off before updating exept on one site. That little test indicated deactivating may not have been necessary. One theme gave some trouble. Some appeared to have updated automatically (and silently) from 3.7 to 3.7 1, and I used the update now option successfully. There were some that get more regular attention and plugins, themes and WP were properly updated. There was one that had a glitch and I had to re-ftp the wp-admin. A couple were more balky about the cute dashboard choices.

      Nothing appears to be wrong with the site that had the auto-update to 3.7.1 and later to 3.8.1, except for the many notifications.. Not a profound issue or question, but I appreciate any input. Thank you.

      • John Blackbourn 4:54 pm on December 27, 2013 Permalink | Log in to Reply

        Best thing to do in this case is to install the Background Update Tester plugin on each of the affected sites and see what it reports. It should help you pinpoint any problems.

      • Ipstenu (Mika Epstein) 9:06 pm on December 27, 2013 Permalink | Log in to Reply

        3.8.1 alpha means you’re on the development version of WP (seeing as … 3.8.1 isn’t released yet). If you don’t want to be, manually reinstall the 3.8 files from a fresh copy and make sure you don’t have a beta tester plugin installed.

        More help needed? This would be time to post in the support forums :)

    • iburketh 1:25 am on January 7, 2014 Permalink | Log in to Reply

      Since this upgrade took place I can no No longer access my administrative screen in WordPress. I do have an error message that says word press update available. Update to three point eight – 26 now. However when I click update in my server I get another error message saying no update available. I have tried almost every solution available in the forums to no avail. Any help you could offer would be appreciated. I’m at a point where I am considering the reinstallation of Word press. However most of the posts that I’ve read say this is not necessary. Your thoughts would be appreciated. Thanks

      • Dion Hulse 1:43 am on January 7, 2014 Permalink | Log in to Reply

        If you’re using an external Object Cache (such as Memcache, APC, WinCache, etc) then try forcing that to reload, it may have become out of sync with your database.
        Failing that, on the Updates page (under Dashboard) try hitting Re-install and see if that helps.

    • webado 12:32 pm on January 24, 2014 Permalink | Log in to Reply

      I just got a first ever notification of an automatic update to 3.8.1. Kind of scared me, but as it happens things are OK.

      My concern is about WP sites which might have been hacked. None of mine have, but I deal with many such sites very often. Updating WP is always one of the things to do but first one must find and clean up the hack. What happens when there is an automatic update? Couldn’t this create more trouble potentially?

    • brasscrest 1:46 pm on January 24, 2014 Permalink | Log in to Reply

      Quote from the update page (when you don’t have automatic updates on):

      “Important: before updating, please back up your database and files. For help with updates, visit the Updating WordPress Codex page.”

      That’s why I don’t want automatic updates on. Because I actually back up my sites before implementing every core update. And also before updating most plugins. While I appreciate the hard work of the core team and alpha/beta testers, I have spent many thousands of hours developing content over 14 years. I’m not going to compromise that work by turning on background auto-updates that happen without giving me a chance to take a backup.

  • Matt Mullenweg 8:41 am on December 6, 2013 Permalink
    Tags: 3.8   

    State of 3.8, and thoughts on the next week 

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

    December 5th, our targeted but controversial freeze date, is drawing to a close. First the bad news: there are two blockers and we could not ship the package we have tonight, despite a lot of great effort. The good news is we are close, there are good priorities on the remaining issues, the new features appear resilient and are live on 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.

     
    • Gtantra 8:44 am on December 6, 2013 Permalink | Log in to Reply

      Give us a break already … we’re just getting used to 3.7 and already the next release !!!

      • Matt Mullenweg 8:51 am on December 6, 2013 Permalink | Log in to Reply

        Once you’ve used the new stuff, it’s hard to go back. :)

        We’re unapologetic about trying to get improvements in the hands of our community as soon as possible, but I do agree with you that upgrades can be a burden. How I’d like to solve that is not by avoiding upgrades, but by making them so seamless and effortless that people wouldn’t mind if we did them every day.

        • krembo99 9:07 am on December 6, 2013 Permalink | Log in to Reply

          I am not going to dispute the wordpress upgrades that are always great – but I agree that the frequency has become a bit high ( Not to say “Autodesky” ) – I believe no one will Dispute security, or bug related upgrades – but what is the reasoning behind too frequent feature upgrades ?

        • Jon Brown 9:20 am on December 6, 2013 Permalink | Log in to Reply

          +10

        • Hassan 12:30 pm on December 6, 2013 Permalink | Log in to Reply

          “We’re unapologetic…”

          Matt, you should work for Apple ;)

        • emzo 4:56 pm on December 6, 2013 Permalink | Log in to Reply

          Yes, like Chrome updates (and many other applications these days). I’ve absolutely no idea what version of Chrome I’m running, and I don’t really care, but I’m safe in the knowledge that it’s constantly kept up to date – and I don’t even know it’s happening.

      • Clorith 9:24 am on December 6, 2013 Permalink | Log in to Reply

        3.8 is so worth it, if only for the new Admin UI along, it’s so beautiful, really pulls everything together nicely

    • JohnRip89 3:56 pm on December 6, 2013 Permalink | Log in to Reply

      Matt the testing build you posted is not 3.8 RC1 is not working it is set to 3.7.1 (“Download WordPress 3.8 RC1 (zip) or use the WordPress Beta Tester plugin (you’ll want “bleeding edge nightlies”.) here is the link to that post: http://wordpress.org/news/2013/12/3-8-almost/

    • mor10 4:25 pm on December 6, 2013 Permalink | Log in to Reply

      Hats off to Matt and everyone else for setting a hard release date and sticking to it. This is the kind of decision and process that fosters trust in the market and shows everyone WordPress is a mature platform ready for the challenges ahead. The develop new features as plugins method also seems to have worked out quite well and I hope it continues moving forward.

      Impressive work from everyone involved.

    • Hassan 8:37 pm on December 6, 2013 Permalink | Log in to Reply

      The only thing that worries me is if/when plugin devs will jump aboard the MP6… err, NEW dashboard aesthetics. They have a couple of things to adjust for the new design, with menu icons being the first thing that pops in mind. I feel like I’m going to halt updating to 3.8 on my sites for while until most plugins adapt to the new look. Not a major thing, but it does worry me and I hope plugin devs do cooperate! Otherwise, I’m gonna nag them like a brat!

    • Brian Cruikshank 3:47 am on December 7, 2013 Permalink | Log in to Reply

      Thanks for the update, Matt. The pace of WordPress innovation is tremendously exciting.

      Is there any way #25838 can get some attention? All my author posts still 404s in WordPress 3.8-RC1 and it’s an update blocker to me.

    • Robert Chapin 7:38 pm on December 7, 2013 Permalink | Log in to Reply

      I’m hoping to offer a smooth upgrade experience to the Fix Admin Contrast plugin users. I see the major changes in the WordPress UI design, yet the same eye-strain-inducing invisible input fields throughout. Haven’t looked at any of the code yet. Is it very different? Just very little time to offer here.

    • bnovotny 10:09 pm on December 7, 2013 Permalink | Log in to Reply

      I would like to see a few actions added regarding the login & users-new pages. One for the password change screen so that we can add a security question. I was trying to do that on a new release for my plugin in and wound up wasting too much time trying to implement a more secure lost password recovery option. A couple other ones for the user-new.php file so that folks that have plugins that add extra fields can extend to that page. (http://www.youtube.com/watch?feature=player_embedded&v=BhjEk5dTa7E)

      Thanks, that is all for now.

    • David Angel 4:08 am on December 10, 2013 Permalink | Log in to Reply

      Looking forward to trying it out (right now!)

    • Brin 5:55 am on December 10, 2013 Permalink | Log in to Reply

      Just taken a look at the RC – serious amounts of awesome stuff – can’t wait!

    • PILOTUSA123 5:13 am on December 11, 2013 Permalink | Log in to Reply

      Good luck….I hope you guys keep up with the multisite installs. Multisite dashboard has been super slow…I see lot`s of people with the same problem on multisites…
      Please Matt help us out with this matter.

  • Lance Willett 9:34 pm on December 3, 2013 Permalink
    Tags: 3.8, ,   

    Twenty Fourteen Project Update 

    Home stretch. Let’s polish.

    Finished

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

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

    Next

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

    Discussion

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

     
    • Piet 12:46 am on December 4, 2013 Permalink | Log in to Reply

      Have a look at the Mobile Detect script (http://mobiledetect.net/). If I’m not mistaken it now also supports caching.

      • mbootsman 10:22 am on December 4, 2013 Permalink | Log in to Reply

        I use http://mobiledetect.net/ for some of my customers, seems to be doing the trick, and it is actively maintained.

        • serbanghita 4:35 pm on December 5, 2013 Permalink | Log in to Reply

          Thanks for recommending the class. Unfortunately it cannot use Mobile_Detect.class.php since that would require an extra plugin attached to the theme.
          It would have been nice to have a WordPress plugin that enhances wp_is_mobile() to use the Mobile_Detect logic.

    • George Stephanis 1:49 am on December 4, 2013 Permalink | Log in to Reply

      Possibly fire off a single ajax request that checks wp_is_mobile() and caches the result in localstorage?

    • Siobhan 11:39 am on December 4, 2013 Permalink | Log in to Reply

      First draft of Twenty Fourteen help for users: http://codex.wordpress.org/Twenty_Fourteen

      Feel free to edit or let me know if there’s anything you want me to add.

      • Lance Willett 4:24 pm on December 4, 2013 Permalink | Log in to Reply

        Thank you!

      • Nick 7:37 pm on December 11, 2013 Permalink | Log in to Reply

        Some quick specs would be great, like measurements in pixels:

        The standard content width for Posts and Pages is ????.
        Featured images should have a minimum / maximum width of ????

        Thanks!

    • Lorelle 10:43 pm on December 4, 2013 Permalink | Log in to Reply

      My college students decided on this Theme for their class magazine. They have a laundry list, one of which was reported immediately. We are going into finals this week, but I’ll have next quarter’s students rip this apart and hopefully contribute to the Codex doc as well.

      One immediate request from them is to fix the lack of author features. This is designed as a magazine site, so highlighting the authors is important. They would like to see the author description used on author pageviews, and the author description also at the bottom of the single post pageviews, something that is typical of most WordPress Themes designed for multiple contributors, and not.

      Thanks again to the entire team for such a great Theme. They had a blast digging into it – and have a lot of praises as well as whines. Love it!

    • Colleen 7:12 pm on January 30, 2014 Permalink | Log in to Reply

      What I really need is for the Full Width Page to really be full width. Just leaving off the widgets does not do anything to widen the page. I need to post a full month view of a calendar on our calendar page and it doesn’t fit. It seems we only have about 450 pixels to work with – even in Full Width View. Please expand it so we can use the full white part of the page.

  • Lance Willett 6:11 pm on November 12, 2013 Permalink
    Tags: 3.8, ,   

    Twenty Fourteen Project Update 

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

    Many improvements

    Author widget

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

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

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

    On our radar

    • Strategy for 3.7 and earlier non-MP6 handling #25906
    • Accessibility feedback on the slider
    • More work on contextual help and the user experience with Twenty Fourteen, maybe including user testing and research
    • Launching the theme on WordPress.com to get early feedback from real usage
    • Code review with core dev team
     
    • jeffr0 6:14 pm on November 12, 2013 Permalink | Log in to Reply

      Did you folks already have your meeting today?

      • Nick Halsey 6:18 pm on November 12, 2013 Permalink | Log in to Reply

        We’ve mostly just been looking at a few remaining things casually, you could definitely jump in with any questions/comments/feedback now (in #wordpress-themes).

      • VenturaVan 6:50 pm on November 12, 2013 Permalink | Log in to Reply

        Can anyone tell me if there is any work being done on colorizing the menu system? I am sooo tires of having to pay for custom plugins that sometimes break to make my menu’s colorful. Top level one color, second level another, third level another, etc. etc and being able to change those per category or per page.

        • Lance Willett 7:12 pm on November 12, 2013 Permalink | Log in to Reply

          Colorizing the menu isn’t part of the scope for this theme. The Accent Color option allows to change from the default green hue, though.

    • Lance Willett 5:51 pm on November 20, 2013 Permalink | Log in to Reply

      Launching the theme on WordPress.com to get early feedback from real usage

      Soft launched on WordPress.com today: http://en.blog.wordpress.com/2013/11/20/twenty-fourteen/. Soft meaning we’ll make a much bigger and louder hullabaloo with 3.8 release in core.

    • Mads Konradsen 9:13 pm on November 20, 2013 Permalink | Log in to Reply

      So Twentyfourteen will first be released on wordpress.org/themes along with 3.8?

    • Bharat Karavadra 6:45 pm on November 23, 2013 Permalink | Log in to Reply

      Hi Lance,
      I was playing around with customising twentyfourteen and I noticed a slight issue with the CSS media queries when looking at the theme at resolutions as defined in the CSS as (min-width: 594px) and (min-width: 673px).

      The issue arises when the site-main background is customised to have an image (and probably also when coloured), where the padding on the entry-header and entry-content varies at the above resolutions producing an odd looking T shape block for the combined entry-header and entry-content.

      You will hopefully better understand what I am describing at a page I created with some snapshots and notes at http://www.karavadra.net/blog/2014-entry-padding/

      Thank you,

      Bharat

    • Bharat Karavadra 1:21 pm on November 25, 2013 Permalink | Log in to Reply

      Also, when logged into WordPress and the Admin bar showing on the user side, the horizontal black header drops down below the admin bar by 4 pixels at resolution widths over about 790px which causes the site description at the top of the left bar to be slightly cropped and the white background appearing above the horizontal black site header.

    • Bharat Karavadra 1:27 pm on November 25, 2013 Permalink | Log in to Reply

      I just noticed that the drop on the site-header is not happening on http://twentyfourteendemo.wordpress.com/ when loggef into wordpress.com but only on self hosted wordpress.

    • Bharat Karavadra 7:01 pm on November 25, 2013 Permalink | Log in to Reply

      Hi,
      The issue with site-header dropping about four pixels is only happenng when using wordpress 3.7.1 or later nightly builds. I just upgraded to wordpress 3.8 beta 1 and the 4 pixel drop is not happening.

      However the padding of the entry-header and entry-content remains inconsistent in the browser widths mentioned above.

    • Lance Willett 12:39 am on November 26, 2013 Permalink | Log in to Reply

      Hi Bharat, please see our open ticket list, we have these already added there.

      • Bharat Karavadra 12:19 pm on December 10, 2013 Permalink | Log in to Reply

        Lance,
        I have just installed 3.8 RC2 and the padding issues with the entry-header and entry-content that I commented on above on Nov 23 still remain and on looking at the tickets – these issues are not the opens ticket list and I haven’t used the ticket system before so I’m not quite sure how to document this.

        • Lance Willett 2:31 pm on December 10, 2013 Permalink | Log in to Reply

          Hi Bharat, the background color/image and “T” shape isn’t something we’ll fix in the default theme, but could be addressed on an individual basis for a child theme as needed.

          • Bharat Karavadra 10:25 am on December 11, 2013 Permalink | Log in to Reply

            Thank you for the reply. I will try my hands at DIY on this and perhaps submit it as a ticket as an prospective enhancement,,

    • Bharat Karavadra 1:50 pm on November 26, 2013 Permalink | Log in to Reply

      Thank you Lance, I thought there would be a more appropriate place to submit such issues but I couldn’t find it. I’ll take a look at the ticket list now.

    • dejudicibus 12:28 am on December 26, 2013 Permalink | Log in to Reply

      Lance, I am using 24 Theme just now. I have a TOP MENU as primary and a SIDE MENU A as secondary. Now, in TOP MENU I have two items: A and B. When I click on B I would like to change the secondary menu to SIDE MENU B. But how? Currently which menu is assigned to which location is selected by admin panel, and there is no way to change it in a dynamic way. Any hint?

  • Matt (Thomas) Miklic 7:33 pm on November 11, 2013 Permalink
    Tags: 3.8, 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!

  • shaunandrews 7:25 pm on November 4, 2013 Permalink
    Tags: 3.8,   

    Widgets Area Chooser – 3.8 Proposal 

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

    The Widgets Area Chooser is available at: http://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.

    Demonstration
    Here’s what the chooser looks like:

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

    Please let us know what you think!

     
    • william.deangelis 7:37 pm on November 4, 2013 Permalink | Log in to Reply

      Not bad. I assume that on mobile each of those two panels would be its own screen? If that’s the case then I say wicked. Go for it!

    • Jeff Behnke 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      I like it. Solves the problems that need solving in the widget admin.

    • Bryan Petty 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      Just wanted to say that I’m excited that you’re working on this @shaunandrews, and it’s coming along nicely.

      I’m still curious how well this UI handles with 3-5 widget areas, and maybe 50+ available widgets, and what happens with the stored/saved widget settings, but this really is a great start.

      • shaunandrews 1:43 am on November 5, 2013 Permalink | Log in to Reply

        Hey Bryan, thanks for the kind words — I’m super excited to be working on this!

        I think you may be getting the Widgets Area Chooser (WAC) plugin confused with the general layout updates as part of MP6 and the separate widgets project. This post is focused solely on the WAC plugin, which lets you click-to-add a new widget.

    • and0r1995 8:25 pm on November 4, 2013 Permalink | Log in to Reply

      I don’t know, I like the idea and stuff, but I personally prefer the drag and drop, Although when there are a lot of widget areas it’s a bit annoying.

    • Marcus 8:36 pm on November 4, 2013 Permalink | Log in to Reply

      I like this, already an improvement, nicely done!

      Aside from @bpetty ‘s point, another (minor) idea/tweak also is for UX just clicking on the area to place a widget instead of click area > add widget will save a click for non-default widget areas. The cancel button should probably still remain.

      • shaunandrews 1:47 am on November 5, 2013 Permalink | Log in to Reply

        …just clicking on the area to place a widget…

        I thought about that initially, primarily because it was one less new UI element to show on the screen — the widget areas are already there, just let the user click on them to add the selected widget. This caused two problems:
        1) It wasn’t immediately obvious what to click.
        2) It didn’t really solve the problem of the widget area being off the screen.

        If you have an idea on how to make this all better, please don’t hesitate to sketch it out and/or attend our chat on Monday at 20:00 UTC. Your thoughts and feedback is greatly appreciated. Thanks!

        • Luke McDonald 6:25 pm on November 8, 2013 Permalink | Log in to Reply

          My initial thought when trying this out for the first time was I would click on the widget area I wanted and the widget would be added to that area. I was testing on a theme that had 7 or 8 widget locations, which is why I didn’t see the “Add Widget” button below the chooser list.

          That said, for me it was *obvious* what to click, and I think it would be for many others too. It seems this functionality should replicate that of a select menu or your typical drop-down menu. In both cases, once you select an item, an action takes place.

          If it’s not immediately obvious for users the first time, it will be the next time they do it. I think after someone knows how it works, it would be preferred not to have to make an extra click or even scroll down to the “Add widget” button in cases where there are many widget areas.

    • mbootsman 9:17 pm on November 4, 2013 Permalink | Log in to Reply

      Major UI improvement. Thanks for developing this!

      • shaunandrews 1:49 am on November 5, 2013 Permalink | Log in to Reply

        Thanks for trying it — hope you like it. Please let me know if you find any problems, or have any suggestions for improvements.

    • Dan Milward 2:59 am on November 5, 2013 Permalink | Log in to Reply

      Awesome work man. I don’t know why but on one of my test sites the list of available widgets is on the right hand side of the screen instead of the left hand side of the screen. Its pretty weird.

      Also I hope the menus screen gets a similar overhaul.

      • shaunandrews 3:16 am on November 5, 2013 Permalink | Log in to Reply

        Perhaps you’re using an older version of MP6? Can you provide version details for WordPress, MP6, and the Widgets Area Chooser plugin? Also, what browser and OS? A screenshot would go a long ways as well.

    • Grant Palin 5:17 am on November 5, 2013 Permalink | Log in to Reply

      I like it. I’ve found the drag and drop setup a bit finicky before, and the click, click, click seems a usability improvement, especially when multiple widget areas are involved. Plus the UI fits nicely with the MP6 theme.

    • HerrLlama 11:19 am on November 6, 2013 Permalink | Log in to Reply

      I don’t like it. The UI is nice tough, but the usability is … well how could I say it neat? … a piece of crap. Now I drag and drop the widget on the wanted position in the wanted widget area. With this “improvment” I have to click on the widget, then I have to choose the area and than click I have to click the add button. But after all that I have to drag and drop the widget on the right position. Seriously, that makes it more complicate than it could be.

      • shaunandrews 2:51 pm on November 6, 2013 Permalink | Log in to Reply

        You can still drag-and-drop widgets in to place. You don’t have to click.

        • HerrLlama 3:57 pm on November 6, 2013 Permalink | Log in to Reply

          Yes, I already read this, but your proposal is a way more to confuse the users. WordPress itself said that they wanted to implement decisions, not options. It would help if we don’t work on the frontend for the widgets and create an API (e.g. add_widget_to_sidebar( $widget_type, $sidebar ) or stuff like that) which actually works.

          I agree, that the UI needs some improvements, but there are plenty of different screens of editing things (tags, posts, menus, widgets, options, etc) which also confuses the users. I think we should focus on a consistent backend before we implement new things. If not, I think that is a major problem of WordPress. Have you ever been to a Typo3 backend? Everything looks like it is in one pour.

          And also: Sorry for beeing rude, but I’m german ;)

      • Helen Hou-Sandi 3:20 pm on November 6, 2013 Permalink | Log in to Reply

        As @shaunandrews noted, this does not replace drag and drop; it provides an alternate method for those who can’t or don’t want to drag and drop for whatever reason. Also, you are being rude, and that is unnecessary.

      • Matt Thomas 6:19 pm on November 7, 2013 Permalink | Log in to Reply

        I would recommend re-reading the original proposal. Managing widgets is currently not possible on a mobile device because drag-and-drop is the only supported method of adding or removing widgets.

      • PeterRKnight 4:17 am on November 8, 2013 Permalink | Log in to Reply

        drag and dropping a position vertically is easy (on desktop), the issue with the current widgets screen that this improvement solves is about making it much easier to add widgets to widget areas without having to do acrobatics. Try dragging and dropping a widget on a screen that requires scrolling because there’s so many widgets and so many widget areas. This however is a major usability improvement for desktop as well as mobile.

    • bfintal 2:08 pm on November 11, 2013 Permalink | Log in to Reply

      I like it. This would solve the drag and drop problem in mobile versions also.

      This is just me, but a method of duplicating a widget would be helpful.

      • shaunandrews 2:46 pm on November 11, 2013 Permalink | Log in to Reply

        Yup, part of the goal with this was to improve the experience of adding widgets on mobile.

        This is just me, but a method of duplicating a widget would be helpful.

        This isn’t the first time I’ve heard this request, so you are not alone. :)

      • Weston Ruter 6:20 pm on November 11, 2013 Permalink | Log in to Reply

        Regarding duplicating a widget, there is this Duplicate Widget plugin and there is the Clone Widgets plugin. The former does a shallow-copy/symlink/reference for the widget, and the latter seems to do a clone or deep copy of the widget. Which use case are you interested in? Do these plugins do what you want?

  • Kim Parsell 6:34 pm on November 4, 2013 Permalink
    Tags: 3.8,   

    The State of Inline Docs 

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

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

    PHP Documentation Standards

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

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

    WordCamp Contributor Days

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

    Contributors

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

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

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

    Progress To Date

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

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

    Weekly Office Hours

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

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

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

     
  • Lance Willett 2:17 pm on October 31, 2013 Permalink
    Tags: 3.8, ,   

    Twenty Fourteen Project Update 

    Status

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

    Finished

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

    Next

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

    On our radar

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

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

     
    • jeffr0 2:32 pm on October 31, 2013 Permalink | Log in to Reply

      When can I start asking questions about the final product? For example, is what I see on http://twentyfourteendemo.wordpress.com going to be the final layout of the theme? Or is the team still experimenting with different elements? All of that wasted space on the right bothers me as does not having the content area be wider.

      • Lance Willett 2:47 pm on October 31, 2013 Permalink | Log in to Reply

        Any time—why not join our office hours next Tuesday? The design is mostly final, won’t be changing much other than small tweaks for browser/device support and accessibility.

      • Lance Willett 12:35 pm on November 1, 2013 Permalink | Log in to Reply

        Hi again Jeffro,
        Here’s the relevant Trac ticket where Takashi (the theme’s designer) talks more about the decisions behind the content width: #25013.

    • LittleBigThing 3:45 pm on October 31, 2013 Permalink | Log in to Reply

      How can I download the theme to test it? Or is it too soon for that, do I have to wait till the beta release of WP 3.8?
      Sorry, I am obviously a rookie in contributing…

    • Nick Halsey 4:37 pm on October 31, 2013 Permalink | Log in to Reply

      I should have the featured-content-settings-in-customizer patch up on #25549 tonight. I’m running into a lot of the same issues there as with the accent color feature, so we should probably wait for the featured content stuff to get in to evaluate accent color further (ie, we may want to explore some core enhancements to simplify both).

    • jeffr0 7:58 pm on November 7, 2013 Permalink | Log in to Reply

      Can anyone explain how to actually use the Featured Content or get it to display? I can’t figure it out. Looks like it’s category based but when I created a Featured category and applied a post to it, nothing showed up.

    • jeffr0 5:19 am on November 8, 2013 Permalink | Log in to Reply

      I looked it up and 1700 UTC was 12 noon Eastern time so 3PM was already passed the meeting. Unless I’ve got UTC to EST all messed up?

  • Mel Choyce 7:43 pm on October 23, 2013 Permalink
    Tags: 3.8, , , mp6   

    MP6 — 3.8 Proposal 

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

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

    Screenshots

    What problems are we trying to solve?

    The current wp-admin has:

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

    We’ve solved these problems with the following:

    Modern aesthetics

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

    Improved contrast and readibility

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

    Future-forward

    Inherently HiDPI

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

    Responsive

    Why MP6?

    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.

     
    • lessbloat 7:56 pm on October 23, 2013 Permalink | Log in to Reply

      Let me be the first to say:

    • Nile Flores 8:12 pm on October 23, 2013 Permalink | Log in to Reply

      I like the idea of the color choice, but personally… I’d like the color choices to go further. I’m using my own version not too far off from this idea using my own brand’s signature colors.

    • Daniel Bachhuber 8:12 pm on October 23, 2013 Permalink | Log in to Reply

      Looking good! One programming note: Shouldn’t the screenshots be uploaded to WordPress to prevent link rot?

    • Daniel Bachhuber 9:14 pm on October 23, 2013 Permalink | Log in to Reply

      I’d like to pitch an idea I’ve been mulling over for the last week: MP6 as WordPress’ (Twitter) Bootstrap for the admin.

      For those not in the know, Bootstrap is a collection of UI / UX patterns, and their corresponding CSS / JS. The goal for Bootstrap is to make it much easier to get your web application up and running — many common UI / UX problems are solved for you. Want a login form? Boom. Want a modal? Bam.

      As a plugin developer, I poach from WordPress admin UI elements as often as I can. For instance, button primary is a godsend. Laziness is probably the primary reason, but consistency is probably more important. As you can find going through the Bootstrap website, there are many UI / UX patterns not defined in the WordPress admin that could be defined in MP6.

      It would, clearly, be additional work. I think taking on the work could provide these advantages:

      • Promote greater UI / UX consistency between core, plugins, and themes. A usable style guide seems like a reasonable, reachable outcome.
      • Clean up rough edges in existing styles. Making your code reusable, and having others use it, is guaranteed to improve the quality.
      • Make my life much easier.
      • Manny Fleurmond 9:16 pm on October 23, 2013 Permalink | Log in to Reply

        A reference for the dasicons would also be nice

        • Mel Choyce 10:20 pm on October 23, 2013 Permalink | Log in to Reply

          We have an unofficial guide here: http://melchoyce.github.io/dashicons/ (It’s missing a couple recent changes, I’ll be updating it soon)

          @helen mentioned the MP6 style guide below. @ryelle created an MP6 helper class page for hooking into color schemes within the MP6, and it could also be a good place to integrate a dashicons reference and instructions page.

      • Helen Hou-Sandi 9:19 pm on October 23, 2013 Permalink | Log in to Reply

        This is what I have been talking about for quite a while and have started to work on, but it’s a slow road when you’re alone.

        P.S. define(‘MP6_STYLE_GUIDE’, true);

      • Mel Choyce 10:20 pm on October 23, 2013 Permalink | Log in to Reply

        + 1,000,000

      • saas 5:09 am on October 24, 2013 Permalink | Log in to Reply

        I would be happy to see “(Twitter) Bootstrap” being a core of admin UI, it will surely make life of dev’s like me much easier (frankly I also find current UI based on .scss files quite easier to use, special thanks to @ryelle for providing .less version of for dev’s like me, keep up the good work @ryelle)

        But it would be good if we could and should or would use “Twitter Bootstrap” for core admin UI, it will bring a standard for not only admin UI but also will provide a guideline for building frontend UI, which will not be possible if we keep working on existing UI files (MP6), we will have to adapt it in a way, so we can bring more than just a rapid prototyping or ease of use.

        As we all know its been a dream for us to customize not only frontend / login screen but also admin UI to match the client website’s color scheme and brand. Which MP6 started to resolve but to seriously considering MP6 to be a part of core, we should bring all the tools (from gurus toolbox) on the wordpress table and pick the right tools for future of wordpress UI (admin, login screen, themes, plugins) and bring harmony between these so we can represent clients brands better.

        While we are on the UI topic, I would like to throw another suggestion out in the wild regarding which is regarding “UI Builder or Page Builder” it will be awesome if we could build such thing in core and using “Twitter Bootstrap” as a core UI framework with help build “Page Builder” a solid solution for our current UI building (generator) needs.

        I remember reading article regarding “Page Builder” being built for core but don’t remember it’s url, but I am sure you guys already know.

        So +!o,000,oo to Twitter Bootstrap :)

      • Scott Kingsley Clark 1:43 pm on October 28, 2013 Permalink | Log in to Reply

        Where do I send all of my +1′s? I’ve got a bag full just for you!

    • @ubernaut 12:51 am on October 24, 2013 Permalink | Log in to Reply

      hey everyone finally got a chance to put together my comments regarding the space efficiency issue i have been talking about in the office hours. While i do appreciate the concept of more white space i think that the removal of all of the separators does to some extent create a significant amount of whitespace in and of itself i believe it is possible to have the best of both world so to speak, anyway here is my post:

      http://ubernaut.wordpress.com/2013/10/21/mp6-the-other-side-of-the-coin/

    • Amy Hendrix (sabreuse) 3:20 am on October 24, 2013 Permalink | Log in to Reply

      I sometimes forget MP6 isn’t already the real admin. Totally in favor of getting it merged ASAP.

    • Gage Morgan 1:21 pm on October 25, 2013 Permalink | Log in to Reply

      You guys can’t ditch this idea like you did the Custom Post Formats UI. This NEEDS to be released in Core 3.8.

    • jeffr0 12:57 pm on October 28, 2013 Permalink | Log in to Reply

      Concerning MP6, color styles and custom menu icons. I’m using MP6 with the Midnight color scheme and although they don’t look terrible, the custom menu icons for some of the plugins I’m using don’t look very well. They look better or worse depending on the color scheme used.

      http://i2.wp.com/www.wptavern.com/wp-content/uploads/2013/10/CustomIcons.jpg?resize=146%2C243

      What can I do to inform plugin developers that they will now need to update their menu icons so that they look good with the different color schemes provided by MP6?

    • Central Geek 4:05 pm on October 28, 2013 Permalink | Log in to Reply

      WordPress is evolving, that’s for sure. I wasn’t too impressed with the MP6 plugin at first, but it is coming along very well. I think it would be great merge into WP core.

    • Helen Hou-Sandi 5:06 am on October 29, 2013 Permalink | Log in to Reply

      I moved development of the component + style guide thing to GitHub, as it’s more suited toward a developer-specific portal and isn’t meant for end user distribution: https://github.com/helenhousandi/wp-style-guide

    • mrwweb 4:08 pm on October 30, 2013 Permalink | Log in to Reply

      Can someone clarify whether this is nominating MP6 with or without the recently-added Widget admin changes? Until recently, that was its own project.

    • Ipstenu (Mika Epstein) 9:05 pm on October 30, 2013 Permalink | Log in to Reply

      Is there any way to have the toolbar reflect the css colors on the front end? It’s always black, and I kinda want to see sexy seaweed up front. :)

    • godhulii_1985 3:41 pm on November 1, 2013 Permalink | Log in to Reply

      User feedback:

      Is there any way that current leftmost column menu will retain its colour? (#21759B or #333333) All the left menu panel colours here were hurting my eyes. It would be better if current colours also exist in new colour schemes.

    • padelisspart 1:44 pm on November 2, 2013 Permalink | Log in to Reply

      OMG, So beautiful!!!

    • OriginalEXE 10:48 pm on November 5, 2013 Permalink | Log in to Reply

      First of all, I am all for this change, please add it to 3.8

      Next, I have one question. Will ‘mp6-highligh’ class change it’s name if this would be merged to core? I am asking because I am building interface now and would like to use ‘mp6-highlight’ class so that active item in the interface would adjust based on the color scheme chosen in the users profile.

      Thanks

    • LoweryAustin 7:03 pm on November 6, 2013 Permalink | Log in to Reply

      I am really enjoying MP6 so far but I found a bug in the css with Tinymce Split buttons. I wanted to share the fix so I wrote a post on it here:
      http://austinlowery.com/mp6-css-bug-with-tinymce-split-buttons/

      Is there a better place to file a bug report on this?

    • Ipstenu (Mika Epstein) 10:04 pm on November 6, 2013 Permalink | Log in to Reply

      Just ran into a layout ugly with Importers

      http://cl.ly/image/1n1i2d362A2I

      Does not happen on Plugin installs (the pop-in looks fine)

    • Rajesh Namase 12:07 pm on November 10, 2013 Permalink | Log in to Reply

      So nice, now users can choose different colors for dashboards. Font also looking nice,

    • keha76 8:03 am on November 13, 2013 Permalink | Log in to Reply

      I think that it’s an overall improvement that is really needed! But the admin menu feels unorganized without any menu dividers at all, a thin subtle gray 1px line would do it just fine.

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