WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 5:20 pm on September 10, 2014 Permalink | Log in to leave a Comment
    Tags: , meeting   

    9/10 Agenda 

    WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

     
    • Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply

      Congratulations, everyone!

    • Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply

      4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
      Note: I have not discussed that with him, so it’ll catch him by surprise.
      My logic is as so:

      • in May, we had a big IRC convo during our weekly chat about committing to WP API.
      • From what I can tell, said API is quite ripe for 4.1, or could be with the proper effort.
      • Making Ryan a lead (if he can afford to) could be a good way to make WP API the big ticket item for 4.1
      • Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply

        That’s also obviously my vote for the focus in 4.1. :)

      • Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.

        Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.

        Just my two cents.

      • Andrew Nacin 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what. :)

      • Michael Beil 4:44 am on September 12, 2014 Permalink | Log in to Reply

        I concur with having @rmccue at the helm.

    • Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.

    • Andrew Nacin 6:57 pm on September 10, 2014 Permalink | Log in to Reply

      Some questions to ask:

      • What have we done in the last few releases that could benefit from a v2, even small things?
      • What have we added in the last few releases that needs to be propagated to other areas?
      • What have we not touched in a very long time and is long overdue for a revisit?
      • What brand new features should we consider working on?
      • What existing features need a complete rethink?
      • What are some bite-sized things that we could do to make a big impact? (3.9 and 4.0 were full of these.)
      • What are big things that are broken and that we feel like we could fix / make better?
      • What might Twenty Fifteen benefit from having in core?

      Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.

      • Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply

        For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?

      • Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply

        To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.

        I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.

      • John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply

        What have we not touched in a very long time and is long overdue for a revisit?

        I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.

        What are some bite-sized things that we could do to make a big impact?

        Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.

      • Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply

        Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.

        Here’s my idea in details: http://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185

        Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.

        Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…

        Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.

    • Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply

      I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.

    • John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply

      I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.

    • Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.

    • Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.

    • Aaron Jorbin 8:12 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).

    • Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply

      I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.

      • Xavier Borderie 8:17 pm on September 10, 2014 Permalink | Log in to Reply

        “in-editor image upload*”

      • Xavier Borderie 8:35 pm on September 10, 2014 Permalink | Log in to Reply

        Top notch foreign typography. It’s very hard, for instance, using French quotes or non-breaking spaces in the editor without resorting to copy-paste. The editor tries to hot-swap curly quotes but fails in many cases.

      • Xavier Borderie 8:39 pm on September 10, 2014 Permalink | Log in to Reply

        For translators: mark clearly strings that are used in JS, HTML labels/title tags or e-mail, because some translations use HTML entities to get some local things done, and that obviously does only work in HTML situations, not the others. I’m willing to work on that.

      • Xavier Borderie 8:29 am on September 11, 2014 Permalink | Log in to Reply

        Finally tackling that multilinguism issue — or at least build the foundations in 4.1, because it’d make for a great 4.2 announcement (‘cos, y’know, 42, Hitchhiker’s Guide, the Babel fish, all that :) ). Allegedly, the SPIP CMS does it very well (see here for their introductory post).

      • Xavier Borderie 12:44 pm on September 15, 2014 Permalink | Log in to Reply

        Oh, and since I just got another two requests for that non-ending issue: please do something about the “WordPress address (URL)” and “Site address (URL)” setting fields! People keep using it with no other thought, this bringing their site down, hoping for others to help them out! There must be a better way: hide it, add a warning, anything else than giving the impression that the use can enter URL in these fields and that WordPress will magically set everything in place :)

    • Stephen Edgar 9:50 pm on September 10, 2014 Permalink | Log in to Reply

      The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
      Export API improvements/overhaul #22435

    • Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply

      I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?

    • Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply

      The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.

      I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!

    • Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply

      For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.

    • Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply

      I’ll dump my rough notes.

      Mobile and media. Media and mobile.

      Context, Trust, Awareness, Flow

      Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.

      Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.

      Press This the UI should be a marquee user of WP API.

      Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.

      Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.

      Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?

      Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.

      Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.

      When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.

      Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.

      Multi-select upload everywhere.

      B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.

      Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.

      Fix the image editor on phones.

      Lose media-new.php?

      Oh wouldn’t it be nice…

      Settings that don’t suck.

      An index.php featuring Press This and a reader.

      Reader views for all list table screens.

      Theme switching from the customizer.

      Notifications, Stream.

    • Paal Joachim Romdahl 11:01 pm on September 11, 2014 Permalink | Log in to Reply

      Improving/renewing Settings was briefly touched upon but stopped up. Having a real useful Settings section would of course be really helpful. I bet a lot of people would have input about this and I bet there are also a few developers that really would like to come together and make this happen.

    • Stephen Edgar 5:54 am on September 12, 2014 Permalink | Log in to Reply

      Another suggestion, and with 99 stars at the time of writing:
      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

    • leemon 6:11 pm on September 12, 2014 Permalink | Log in to Reply

      Please, tackle the following taxonomy bugs once and for all:
      https://core.trac.wordpress.org/ticket/5809 – Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/5034 – Impossible to have duplicate category slugs with different parents

      Fixing this would be cool too:
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list

      Thanks

    • Paal Joachim Romdahl 9:12 pm on September 12, 2014 Permalink | Log in to Reply

      Certain features are directed toward a developer and would not really help a “regular” user as much. I am thinking that features also could be placed into categories of who would this be helpful for. Placing a feature into: Developer, Designer, Advanced Users, Basic Users. Most people who are associated with being here on this forum are very likely Developers. A few probably Designers and a very very would then place themself into the remaining two categories.

      As I work with education I identify myself have very strong empathy for a person who has just began with WordPress. And oftentimes see WordPress through their eyes. Core needs eyes on features from people with different backgrounds that can share thoughts and their perspectives into seeing a much larger view.

  • Mark Jaquith 6:25 am on July 23, 2013 Permalink
    Tags:   

    About page for 3.6 

    As we approach 3.6 final, we need to start thinking about the About page for the release. What should go on it? Shout out your ideas.

     
    • johnbierly 8:23 pm on July 23, 2013 Permalink | Log in to Reply

      At this point, as long as there’s a link to download 3.6, I don’t care if the entire page is collages of cartoon giraffes!

      Maybe style the page with the Twenty Thirteen fonts to give it some character. That could be a cool thing to do for every year’s major release — style that version’s page like the default theme for that year.

    • Chuck Reynolds 3:16 am on July 24, 2013 Permalink | Log in to Reply

      typography and html demonstration… li’s, ol’s, blockquote, h1-6, code blocks, etc etc

    • daveshine (David Decker) 11:36 am on July 24, 2013 Permalink | Log in to Reply

      The obvious things: Updated Revisions, updated Menus, etc. :-)

    • Siobhan 3:07 pm on July 24, 2013 Permalink | Log in to Reply

      Emphasis on how the writing experience in WordPress has been improved, particularly with Autosave which is an awesome new feature but may not be entirely obvious.

      Also worth talking about post locking which is great for multi-author blogs, & improvements to revisions.

    • Xavier Borderie 4:13 pm on July 24, 2013 Permalink | Log in to Reply

      Is there any way translations can use their own set of (translated) screen captures?

    • Eric Andrew Lewis 4:38 pm on July 24, 2013 Permalink | Log in to Reply

      How about including the “Introducing 3.6″ video?

    • adamsilverstein 6:11 pm on July 24, 2013 Permalink | Log in to Reply

      closed the wrong browser tab the other day while editing a post, came back to the post edit page and restored from the browser backup. BOOM! no lost work. wow! that’s amazing!

    • EricMesa 6:28 pm on July 24, 2013 Permalink | Log in to Reply

      What I’m most excited about for 3.6 and I would like to see in the about page would be some instructions on how to use the new, awesome built-in audio and video players.

      If it wouldn’t cause too much confusion, I’d also like a section on the page telling me where to get the Post UI Plugin.

    • Shea Bunge 9:03 pm on July 24, 2013 Permalink | Log in to Reply

      Updated menus, revisions, new theme.

    • delevega 5:24 am on July 31, 2013 Permalink | Log in to Reply

      Links to useful codex pages that have to do with the use of new or different functions / features. Maybe some information on twenty thirteen.

  • Mark Jaquith 6:29 am on July 10, 2013 Permalink
    Tags:   

    Hey! Remember that WordPress 3.6 release we were working on? Yeah… we’re still at it. But there’s hope! Post Formats UI has been extracted, and Revisions has gotten an intense refactoring that makes it scale up to hundreds of revisions without killing your server or your browser. A backlog of many hundreds of tickets has been whittled down. As of this writing, we’re below 40 tickets for 3.6, and they’re actively being committed and punted as appropriate.

    The plan is to keep on those tickets and get to RC by Friday. Help is appreciated! A bunch of people have been “pinged” regarding tickets on report/6, so please scan through those and log on to IRC to check for messages.

     
  • Mark Jaquith 8:25 pm on June 5, 2013 Permalink  

    We’re going to have some working IRC hours tomorrow, June 6th, between 1400 UTC and 1800 UTC. Show up if you can and we’ll hammer away at the remaining items from this post!

     
  • Mark Jaquith 8:16 pm on May 29, 2013 Permalink  

    Post Formats UI is exiting core, will live as a plugin 

    This is a hard decision. I’ve been talking to a lot of WordPress core developers and contributors, and the overwhelming consensus is that Post Formats UI is not ready for WordPress core, and that it would be a mistake to ship it as it currently exists. We’re going to pull it out, and let it continue development as a plugin, much like MP6.

    I fought hard for it, and a lot of people put a lot of effort into it. But the result just isn’t compelling, or obvious, or any of the things that it should be. It’s not just a matter of polish, it seems to be a fundamental issue with the concept. The release can’t be held up any longer for this. It needs to come out. I should have made this decision earlier. That’s on me. But letting it ride would be the worse mistake.

    Here is the proposed plan for extracting it, and for dealing with other tangentially related or other release-related items:

    Post Format Things to Move to the Plugin

    • The posts screen UI, including icons in H2 #24452 #24502
    • Enabling all formats by default #24452
    • The custom screen options (go back to what we had before) #24452
    • The content/excerpt/title necessity modifications in wp_insert_post() #24503
    • Content area size changes #24452
    • structured-post-formats support and post_formats_compat() #24453 #24454
    • Revisioning of the post format and post format metadata keys #24455

    Post Format Things to Keep in Core

    • Icons on edit.php (perhaps adding them to the radio format chooser to sync that context) #24519
    • post-new.php?format= shortcut
    • aside/status auto title generation (when blank)
    • URL extraction function (renamed from get_content_url() to get_url_from_post_content())
    • Post Format previewing #24483

    Upgrade Path for Beta Dogfooders

    • Consider rolling upgrade that pieces together post_content based on existing meta keys
    • Alternatively, include this as a tool in the post formats plugin
    • Perhaps a WP-CLI component to the post formats plugin, so those upgrades can be done on the command line, once

    Strategy for Media

    • Leave most of wp-includes/media.php — keep audio/video support
    • Call functions directly rather than calling do_shortcode() #24505
    • Have wp_get_(audio|video)_extensions() wrap wp_get_mime_types( $type = null ) if feasible #24504 (NOPE)
    • Remove or make sane attachment_url_to_postid() #24458
    • For A/V shortcodes, include the attachment ID, instead of just the URL (makes attachment_url_to_postid() unnecessary) #24458
    • Transition those IDs on import #24458
    • Consistency: embed shortcode takes URL as its content, but a/v ones take an attribute — make both for both? #24456

    Shortcodes

    • Keep shortcode_exists() and has_shortcode()

    What Else?

    Did I miss anything? Is there something that doesn’t seem like the right path forward to you? Let’s hash this out so we can move on it.

     
    • nphaskins 8:21 pm on May 29, 2013 Permalink | Log in to Reply

      It seemed mostly O.K to me kinda sad to hear it was pulled out. So with it going to a plugin does this mean core will never have UI for post formats?

    • Frankie Jarrett 8:28 pm on May 29, 2013 Permalink | Log in to Reply

      Agreed. It’s the right decision at this point to safely move forward. Thanks, Mark.

    • Mel Choyce 8:29 pm on May 29, 2013 Permalink | Log in to Reply

      If we want to keep the new icons, here are two rough ideas for placing them in the post formats metabox:


    • Travis Northcutt 8:30 pm on May 29, 2013 Permalink | Log in to Reply

      Mark, thanks for making the tough call to keep things moving forward.

    • Grant Palin 8:36 pm on May 29, 2013 Permalink | Log in to Reply

      That’s unfortunate, as the built-in UI is something I’ve been watching for a while. Good to know that it may eventually be reintegrated into core after it stabilizes and matures some more. Would the plugin solution be set up to minimize difficulties in transitioning it back to core? That is, forward compatibility?

      • Grant Palin 8:39 pm on May 29, 2013 Permalink | Log in to Reply

        Though I do see the rationale in separating the two, similar to that of the admin UI plugin. Don’t hold up the core release unnecessarily, but keep the door open for future integration.

    • mor10 8:47 pm on May 29, 2013 Permalink | Log in to Reply

      A hard decision to be sure, but the right one nonetheless. I believe Post Formats have a place in WordPress, but not in the core. I see great things ahead for Post Formats as a plugin. And mad props to the developers. Good code is good code whether it is in the core or in a plugin.

    • Hassan 8:52 pm on May 29, 2013 Permalink | Log in to Reply

      Oh, didn’t see this coming.

      Don’t know, mixed feelings.

    • Amy Hendrix (sabreuse) 8:52 pm on May 29, 2013 Permalink | Log in to Reply

      Thanks for making the tough call. I still think it’s a terrific feature, but I’d much rather give it time to evolve as it should rather than being shoehorned in to the (way cluttered, but that’s a different discussion) edit screen to make a deadline.

      And I’m super-happy we get to keep the stuff that came with.

    • Chuck Reynolds 8:52 pm on May 29, 2013 Permalink | Log in to Reply

      wow this is huge… mid dev w/ post formats… with the way they’re going it does seem like the best decision to pull them and make a killer plugin for it.

    • taupecat 8:55 pm on May 29, 2013 Permalink | Log in to Reply

      I’m sad to see the post formats UI go. I was really looking forward to it, but happy that we’ll be able to use it via the plugin.

    • extravaganzasd 8:55 pm on May 29, 2013 Permalink | Log in to Reply

      Thanks for this Mark – hopefully Post Formats will have a rejuvenating “vacation” from core and come back better than ever.

    • Eric Andrew Lewis 9:02 pm on May 29, 2013 Permalink | Log in to Reply

      If something is pushed into a plugin, it’s no less awesome for it. Cheers to all the awesome work that’s been done on it, looking forward to the plugin version. :D

      • Chuck Reynolds 9:10 pm on May 29, 2013 Permalink | Log in to Reply

        biggest concern right now is timing.. when. mid dev with something and i’m fully engulfed in post formats and cpts…. sigh.

    • Siobhan 9:08 pm on May 29, 2013 Permalink | Log in to Reply

      Really sorry to see this go – I’ve been having lots of fun using Post Formats recently. I don’t think I’d have ever used them if it hadn’t been a core thing with me running trunk.

      However, it sounds like the right decision, and a tough one to make. I’ll be installing the plugin and, as a recent post format convert, am happy to help with any feedback and improvements to it.

    • mt_Suzette 9:13 pm on May 29, 2013 Permalink | Log in to Reply

      I agree with Siobhan, sad to see this feature go as I was really digging the Post Formats, but I can understand the need to keep core as lean and mean as possible, and add it as a plugin if desired. Very hard decision to make, and I fully support it and look forward to using the plugin for those clients it will benefit.

    • Syed Balkhi 9:13 pm on May 29, 2013 Permalink | Log in to Reply

      Good call there :) I think it was getting a bit crowded in the Post UI for a whole lot of us who won’t be using the post formats.

    • Devin Reams 9:14 pm on May 29, 2013 Permalink | Log in to Reply

      Mark, I can’t remember if Alex brought the “Post Formats Fallback” to your attention early on. This is probably easy to incorporate or at least give a head start if desired:

      http://alexking.org/blog/2011/11/02/wordpress-post-format-fallbacks
      https://github.com/crowdfavorite/wp-post-formats-fallback

      • Andrew Nacin 8:22 pm on June 3, 2013 Permalink | Log in to Reply

        Devin, yeah, the feature was heavily influenced by Alex’s work.

        • Devin Reams 11:28 pm on June 4, 2013 Permalink | Log in to Reply

          Right. I was referring to reminding of the “Fallback” tool in reference to the need for:

          • Consider rolling upgrade that pieces together post_content based on existing meta keys
          • Alternatively, include this as a tool in the post formats plugin
    • John James Jacoby 9:14 pm on May 29, 2013 Permalink | Log in to Reply

      This really is a shame. Any opinions worth sharing on what could have been done to avoid the retraction? We had all hands on deck with this at the beginning, then it got broken up into minutia, followed by a few weeks of tuning.

      What did we learn from this experience, and how do we avoid it for future releases? Maybe a post-mortem-post after 3.6 is out?

      • toscho 10:17 pm on May 29, 2013 Permalink | Log in to Reply

        Maybe each new feature (remember favicons?) should live in a separate branch until it is ready to be merged without blocking the release. Or it should start as a plugin until the interface and the code work good enough.

      • Mark Jaquith 11:07 pm on May 29, 2013 Permalink | Log in to Reply

        I will do a postmortem on the release.

    • BobDunn-Trainer 9:18 pm on May 29, 2013 Permalink | Log in to Reply

      I agree, I think it was a good decision. For many who love and use WordPress all the time, I can relate to the loss. But for the average user, I’m still on the fence there. Even with their introduction, it could have only added more confusion or a matter of just ignoring them. I like seeing the direction of a plugin… great job and I know it wasn’t a decision that was made lightly.

    • Devin Walker 9:19 pm on May 29, 2013 Permalink | Log in to Reply

      I believe post formats was the big new feature in 3.6 that everyone was looking for but if it isn’t ready then I don’t think it should be rushed. It makes sense to put it in a plugin. In my opinion, good decision.

    • mor10 9:19 pm on May 29, 2013 Permalink | Log in to Reply

      How will this impact Twenty Thirteen? It seems to me the core feature of the new theme was the heavy integration of post formats.

      • Amy Hendrix (sabreuse) 9:55 pm on May 29, 2013 Permalink | Log in to Reply

        Very little, actually — the great majority of what Twenty Thirteen does is based on styling the Post Formats that have always existed (well, existed for several years, anyway!), and the team is already working on the remaining changes that need to be made.

        • mor10 10:22 pm on May 29, 2013 Permalink | Log in to Reply

          I’m curious to see how videos will be pulled out of the content for index pages and above-the-title display. That said I think the proposed method of putting image and video links in a separate field was questionable because of the fallback for themes that don’t support Post Formats and how the content risked getting excluded from feeds. Looking forward to seeing solutions to these issues and best practice examples on how to dislodge embedded videos for display elsewhere.

      • Nick Halsey 1:43 am on May 30, 2013 Permalink | Log in to Reply

        Well it’s straightforward from a technical standpoint but I think it’s awful from a user perspective, especially for new users. The primary feature of the theme is to do cool things with post formats, but the majority of users will not know that about Twenty Thirteen, and likely won’t know about post formats at all.

        You can’t really do much in an obvious way with the existing “UI” (if you can call it that), so that leaves Twenty Thirteen in an awkward position for non-power-users. We need to include a tooltip or some sort of obvious help text at a minimum, to ensure that users discover the concept of post formats, point out the metabox, etc. Without post formats, for new users, Twenty Thirteen is just a bold, but mostly white theme with orange accents that discourages a sidebar… and we all know how much more amazing it is than that.

    • zekeweeks 9:22 pm on May 29, 2013 Permalink | Log in to Reply

      Bummed – this was the thing I was looking forward to most in 3.6, and really enjoying in the nightly builds. That said, the decision to hold off until the fundamental issues can be resolved is the right one.

      What I’m more curious about – for future additions that are similarly wide ranging in scope, and critical in terms of getting the UX just right, how do we minimize risk for release cycles? Beta 1 was released with the claim that “we shouldn’t release a beta if we were still working on completing the main features” – I don’t bring this up due to any naïve belief that everything is worked out before a beta release; rather, I wonder if such conceptual and UX-critical issues should be solidified earlier in the process. (Or can they even be? Definitely interested in what everyone else thinks.)

      • Erlend Sogge Heggen 10:20 am on May 30, 2013 Permalink | Log in to Reply

        This is easy. All major features should always start their incubation period as a plugin. The MP6 project has proven this approach to be very effective.

        (Matt Mullenweg and others seemed to be in favor of this approach, but the notifications bar isn’t responding so I can’t find the comment)

    • bryananthonylewis 9:22 pm on May 29, 2013 Permalink | Log in to Reply

      Great question!

    • Andrés Villarreal 9:24 pm on May 29, 2013 Permalink | Log in to Reply

      Like many people commented before, I have mixed feelings too. Personally, I would have love to see this feature in the core, but on the other hand, I think WordPress has evolved a lot from the simple blogging platform that it used to be years ago, and the post formats UI could have meant an unjustified rollback towards that way, even being a burden for non-bloggers that won’t use it.

    • wptotaltraining 9:37 pm on May 29, 2013 Permalink | Log in to Reply

      I think that is a really good call. I was worried about training my clients on that, because most of them struggle with just the basics. Also I am looking forward to the new dashboard in the new release so glad to get it moving. Making it a plugin is great way for those who understand it to use it.

    • amdirect 9:53 pm on May 29, 2013 Permalink | Log in to Reply

      Big decision……also a tough one I bet. Don’t know if it is bad or not, just digesting it now. Knee jerk reaction is not good, but will think about it more.

      Thank y ou,.

    • blondishnet 10:23 pm on May 29, 2013 Permalink | Log in to Reply

      Nice mockups.

      The decision for making this a plugin is logical. I don’t use a lot of the post formats currently.

    • Shapeshifter 3 10:42 pm on May 29, 2013 Permalink | Log in to Reply

      I know I’m not a Core Developer, but I find this irritating. Trying to get developers to continually agree on a focused destination must but be like trying to herd cats. As an end user, I thought everybody here was creating a great new feature for WordPress. This is similar to moving the Link Manager to a Plugin (which I immediately installed). The Link Manager was removed from Core because supposedly not enough people used it. A similar sentiment here is that the additional options of post formatting will confuse new users. Too bad…let them read and learn a little. This dumb dog thought you were doing a great endeavor. To placate someone such as myself, can you Please immediately make available the new plugin so I can install what your are now removing from Core…..Sorry if I sound rude.

    • StyledThemes 11:48 pm on May 29, 2013 Permalink | Log in to Reply

      Yikes! I was just working on my next WordPress theme that has a lot of custom styling for each of the post formats. Hopefully this won’t be affected. I’m really not a fan of 80% of the post format options but a couple there are worthy. However, I can understand not wanting to put something in that isn’t ready for prime-time yet and to take on some rethinking of how to implement them is important.

    • Brent Logan 12:34 am on May 30, 2013 Permalink | Log in to Reply

      Core or official plugin, makes no difference to me.

      The main benefit of an “officially blessed” post formats structured data format is preventing “lock in” to a specific theme. Now, themes can support this data format and we can choose any theme that supports it.

      For that matter, the ability to extract the structured data from older posts that don’t use it is a huge step forward.

      Kudos to everyone who had a hand in making this happen. I look forward to continued improvements with post formats.

    • Mike Zielonka 12:53 am on May 30, 2013 Permalink | Log in to Reply

      I am a little bummed because folks that don’t follow the details of WordPress dev may miss out on these new features unless they hear about the plugin.

      Could you include the Post Formats plugin in the WP 3.6 updates so folks could at least see what it looks like and give them an admin notice to remove it if they don’t like it?

      • Andrew Nacin 8:24 pm on June 3, 2013 Permalink | Log in to Reply

        By removing it, we’re recognizing that this is not ready for “prime time”. So no, it will not be shipping with 3.6.

    • Nick Halsey 1:50 am on May 30, 2013 Permalink | Log in to Reply

      Is this plugin going to be usable for production environments and non-power-users, or is the idea to do something strictly development-oriented?

      I think that releasing a plugin for users that contains the current core behavior and a separate plugin to rethink the UI and iterate, a la MP6, would be in everyone’s best interests. That way all of the theme, etc. developers who have been preparing for a greater core emphasis on post formats can make their plans work for end users with a constant UI until the re-thought UI is potentially re-introduced into core and released. After all, 3 betas were released with the PFUI in some form. Such a plugin would probably use exactly what we have now, and allow people to actually use it without worrying about stability. That sort of a plugin and an MP6-style plugin have entirely different objectives and should be treated accordingly.

    • Jon Brown 8:57 am on May 30, 2013 Permalink | Log in to Reply

      I want to make sure I’m not filling in the gaps with too many assumptions.

      Post Formats have been in core for a long time now and will continue to be in core, correct.

      What is getting moved out of beta core and into a plugin is just the recently proposed enhancements to post formats to surface them more even in themes that don’t explicitly support them.

      The reason is because that work ended up with what some of us think is a pretty bad UI and it’s better to continue to iterate it in a plugin than it is to release it with core. The new plugin is really intended just a temporary bridge for those that have already started working with the structured post formats and those who wish to continue work on the structured post formats. That plugin is not intended to be core plugin or a long term solution for the masses to consume, right? I’m inferring that from likening it to MP6, whereas some of the comments here seem to think of it as a “core plugin” that people should feel confident adopting as “blessed”.

      • Aaron D. Campbell 2:30 pm on May 30, 2013 Permalink | Log in to Reply

        Post Formats have been in core for a long time now and will continue to be in core, correct.

        Correct

        What is getting moved out of beta core and into a plugin is just the recently proposed enhancements to post formats to surface them more even in themes that don’t explicitly support them.

        Correct

        And the plugin will be very much like MP6 in that it will be a staging ground.

        • Jon Brown 7:36 pm on May 30, 2013 Permalink | Log in to Reply

          Thanks for confirming Aaron. Some of the comments here seemed to conflict with what I understood.

          Personally I’d like to see MORE major features get developed and iterated as plugins over the course of a couple point releases. Instead of trying to go start to finish on major features in a single point release.

          I’d think that approach would reduce the occurrence of things like custom menus, structured post formats, etc. causing major delays to releases like this. Instead of building the functionality from scratch in core, the plugin code iterated over a few releases would get move into core at the begin of a point release dev cycle and then it’d just be a matter of validating the migrated code and minor cleanup.

          Maybe it’d even garner more participation because it’d give people a place to really focus their development efforts. I can see non-core contributors getting involved with a core feature development plugin more easily than wading into core trac…

    • Sami Keijonen 11:43 am on May 30, 2013 Permalink | Log in to Reply

      I’ll have to disagree on the decision. But in the same time now I have huge respect to Mark. These kind of decisions are always hard when it impacts so many people one way or another. And there are not so many people out there who can build WP as a better platform and in the same time make big decisions and stand behind them.

      I guess most of us might have selfish reasons do we agree or disagree on this one: Now I have to re-think my upcoming theme, update my old theme, now I have to teach my clients new stuff, I don’t like how it looks/works, I like how it looks/works, these should always be in the core / plugin, I don’t eve use post formats, I use them all the time.

      WP Core theme, thanks for hard work.

    • Brad Touesnard 12:51 pm on May 30, 2013 Permalink | Log in to Reply

      Tough decision Mark, but I think it’s the right one. I’ve heard from a few developers (client services and product) very concerned about the confusion over these new UI elements and the boom of support it was sure to cause.

      I love the idea of MP6 and this new plugin. Cautiously rolling things like this into a plugin, getting it stable, and then letting developers get their toes wet, test it on a few clients and see what happens. Making sweeping changes and having to deal with the consequences all at once is a lot tougher on developers.

    • memuller 1:18 pm on May 30, 2013 Permalink | Log in to Reply

      A sad decision, but the right one nonetheless (but yeah, we could have made it a lot earlier).
      I think MP6 has show us that developing new features as a plugin is very, very awesome and effective for a lot of reasons; so I’m thrilled to see this approach being used with more new features.

    • johnbierly 1:32 pm on May 30, 2013 Permalink | Log in to Reply

      Back when the F-117 stealth fighter was still top secret, its pilots weren’t even allowed to tell their families they were flying at night, much less WHAT they were flying. They had to maintain normal schedules with their families (up all day, sleep at night), but for missions they had to flip that around to sleep all day, fly all night. The need for secrecy even in their daily schedules was very hard on their bodies and brains, and two pilots/planes were lost in accidents due to disorientation and fatigue.

      So when other pilots stepped up and said, “We’re too tired to fly safely,” it was not seen as a sign of weakness.

      It was seen as a sign of STRENGTH.

      So double bravo to you and your team, Mark. Bravo for thinking outside the box and trying to add something radical and fresh to WordPress, and bravo again for knowing when to admit it’s not quite ready in its current form. This is why WordPress is king.

    • contempoinc 3:05 pm on May 30, 2013 Permalink | Log in to Reply

      So when can we expect the plugin?

    • Chris Blackwell 3:52 pm on May 30, 2013 Permalink | Log in to Reply

      This is not the right decision! Everyone has been talking about Post Formats UI in WordPress 3.6 and is touted as “the feature” for the next version of WordPress. To pull this out now after 3 betas is ridiculous. If you need more time, then take it, delay the release.

      I can just see the boring headlines now, “WordPress 3.6 released with new Theme and some audio/video support”

    • Sallie Goetsch 5:09 pm on May 30, 2013 Permalink | Log in to Reply

      I begin to understand why we were talking about free will and determinism yesterday. :-\ Seriously, though, I’d been using the post formats UI for weeks, because my current WordPress class for MediaBistro started May 8th, and in an attempt to provide my students with instruction they’d need for an imminent upgrade, I recorded 2 sets of video lectures about post formats: one with 3.5 and Twenty Twelve, one with 3.6 beta and Twenty Thirteen.

      Everything about the new post formats UI appeared to be working, AND it seemed a lot clearer how you were supposed to go about using them than when they were first introduced. The link post format always puzzled me before; I’d have to look it up, then test it, before I could record an example for the students. (And clearly I never made a habit of using it myself.) My likelihood of using Aside or Chat outside the classroom is approximately nil, but at least the new UI made it clear enough what to do. (I have a client who is using Aside, in a Twenty Twelve child theme, for her workshop announcements, because it’s blue and stands out. Semantically all wrong, stylistically appealing to her.)

      What I’d like to be able to take back to my students and to my meetup (which also got a demo of the new post formats UI, on the 19th), is an explanation of what wasn’t working, since they’ve all seen it apparently perfectly functional. You folks are building it, and I trust that you can see far more than I can why it’s not ready for prime time, or at least not ready for core. (I haven’t had time to look at the code, or to test it in any environment but a clean new install with Twenty Thirteen.) But I’d like to be able to take something back to people who thought “This looks easier and more fun than the way it was before.” (It was WAY more fun. Made the page edit screen look sad and neglected by comparison.)

      Once the plugin actually exists, I can tell them to install the plugin–which I presume will require 3.6. Are you going to call the plugin something obvious like Post Formats UI, so I can tell them what to look for, even if it’s not available until the class is over? I’m about to record a set of videos on the topic of plugins everyone needs (e.g. backups, security, spam prevention) and then one on plugins for writers (most of these people come from a journalism background), so now would be a good time to be able to include something.

      Thanks,
      Sallie

    • Nashwan Doaqan 5:14 pm on May 30, 2013 Permalink | Log in to Reply

      +1, It’s the right decision :)
      “Do One Thing & Do It Better Than Anyone Else”

      We love WordPress to be clean,smart,easy … I think that the current features are enough for 3.6, we should focus on bugs and making the API better.

    • Johannes Fosseus 5:41 pm on May 30, 2013 Permalink | Log in to Reply

      This is great news, backend ui need to be cleand up. I realy would like to se more stuff hidden or moved to plugins. So, from me, good news.

    • Veuse 7:58 pm on May 30, 2013 Permalink | Log in to Reply

      Will 3.6 still be shipped with the audio/video player? I suppose I will need to create custom meta-panels for video? Would love to see a “featured video” panel included, much like “featured image”

    • Anointed 9:49 pm on May 30, 2013 Permalink | Log in to Reply

      -1
      I was so excited about ths one feature that I literally spent weeks sending email notifications out to theme and plugin developers to notify them about the new post-formats ui in order to get them to finally fully support post-formats as it was such a prevalent part of the core. In the past, getting theme and plugin authors to add proper support for post-formats was virtually impossible. This time I was having great luck in getting acceptance and now you’ve pulled the rug out from underneath us.

      I read the entire post and replies but at no point did I see WHY ARE THEY BEING REMOVED?

      Like most others, I’ve played around with them for weeks now, built my own theme extensions for them and a few cool plugin concepts and really I have never had a problem. They seemed to work great, so why remove them now?

      What is even left to look forward to in 3.6 now?

      • Frankie Jarrett 10:09 pm on May 30, 2013 Permalink | Log in to Reply

        “…a fundamental issue with the concept.” Go look at the open tickets in Trac and they speak for themselves.

        WordPress is awesome because things that aren’t ready don’t ship. I think we’re all a little frustrated but we should be mostly thankful and move forward.

        Jane Wells gave warning this could happen over a month ago, so it’s not like it’s a huge surprise.

        http://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/

      • Aaron D. Campbell 10:28 pm on May 30, 2013 Permalink | Log in to Reply

        It’s not that they didn’t work or that they were unusable. However, in the end they’re no as great as we really want our post format support to be. Usually that’s fine because we can simply iterate and improve with each release, but in this case we’re worried that the direction we took will prevent us from achieving our ultimate goal. We don’t want to paint ourselves into a corner. We’re worried that if we continue as we are now, when we ultimately do something else, we’ll just have a lot of legacy code to support and a lot of extra code to write and maintain for all the backwards compatibility that will be required to make the new stuff work with what we were putting in 3.6.

        Without them, there’s still plenty to look forward to in 3.6. Post revisions have gotten a serious facelift and are going to be much easier to use, which is awesome. The new menus changes have tested far better than our old menus. There’s been a lot of work around autosaves, so that data is never lost even if your connection to your server is. The new Twenty Thirteen theme is still being released with this version too! Additionally, not all the work surrounding post formats is being pulled. For example, we’re going to be keeping the new audio and video embeds, which give native support for audio/video embeds directly in WordPress.

    • Jonas Lundman 1:05 am on May 31, 2013 Permalink | Log in to Reply

      Bad idea to remove formats from the core. At least make it as add theme support and dont make a fancy layout cluttered button in the top of edit pages. Leave the metabox as it is.

      I just started building themes based on the formats. It filles the gap between categories and theme templates. The latter is to present the structure of the page view and the format to grain the content part in the tamplate, without adding new themes.

      For example, in setups as CMS, internal projects with cistom post types and diffrent layers of front end access, a small status format can be adjusted for the contents purpose in layout and script funstions. List formats in categories and make all image format posts open in modal etc etc.

      The format UI make it possible to adjust the responsive desgin and views for diffrent roles.

      This is a huge step back to remove the UI and the future of using WP as a cloud service and much more.

      I agree formats is an overkill for users with default Twenty themes, but the few of us who extend the wordpress world, please respect the small voices in this matter

      / Jonas Lundman, coordinator and project manager.

    • manuelmasia 1:07 pm on May 31, 2013 Permalink | Log in to Reply

      As Anointed I spent a lot of hours to make my themes compatible with the new feature. I think it would be very kind if WP 3.6 had the ability to activate the new UI with a function like add_theme_support(), so the work of many developers won’t be lost.

      I think many developers won’t trust anymore the announcements of the beta versions, and this would be a shame.

    • Jeff Mackey 7:21 pm on May 31, 2013 Permalink | Log in to Reply

      I understand the decision. While unfortunate, it does makes sense.

      Question —

      If I was running the nightly build (recent, that supported the Post Format UI) in a test environment, and had several posts saved using the various formats, and then upgraded to the latest nightly build (that no longer has the Post Format UI), how do I modify those posts now?

      For instance, I no longer see the special image, video, or link fields in the Edit Post screen.

    • Daniel_Iceman 8:29 pm on May 31, 2013 Permalink | Log in to Reply

      I’ve been playing with 3.6-beta3 and it looks great, post formats ui don’t seems to be confusing in any way to me. The issue discussed by Jane Wells http://make.wordpress.org/core/2013/04/23/post-formats-schedules-and-philosophy/ don’t occur anymore.

      All important modification brings new tools and challenges, recently we saw this with Windows 8 and the Start Menu issue. It was partially solved giving user the oportunity to bring button back by themselves, so if something similar can be used here, would be good if the post formats ui could be activated in a simple way, no plugin, like any other configuration. Let’s say, in Settings > Writing page.

      I’m not a pro developer. Sure would not be so hard for beginners to do it as well. Thanks.

    • porter1985 2:03 pm on June 1, 2013 Permalink | Log in to Reply

      i think giving user the option to have this as a plugin is a great step.

    • Emory 3:31 pm on June 2, 2013 Permalink | Log in to Reply

      Post formats were great, and I was really happy with the way they were being implemented. I’m pretty disappoint.

    • Chandra M 12:30 pm on June 3, 2013 Permalink | Log in to Reply

      I am glad this is going out from the next version. I felt it was too confusing as there are just loads of fields and options. It never made sense to me to use 2 image fields for Image post formats and no fields in Gallery post format. It was just turning into a cumbersome CMS. Hope it matures enough at a later time.

    • Matt Van Andel 5:55 pm on June 4, 2013 Permalink | Log in to Reply

      Although the styling coincidentally falls in line with the MP6 direction (which is why I posted this there first), I threw together an alternate design that goes a little further with the end-user education, without the major underlying changes that Post Format UI introduced. It’s available as a plugin as of yesterday… http://wordpress.org/plugins/better-formats/

      And here’s what it looks like in use:
      http://www.mattvanandel.com/wp-content/uploads/2013/05/betterformats-screencap.jpg

      Two things…
      1. I think education and UX are important here… much more important than the underlying technology. In my openly-biased opinion, Post Formats are, and should remain, an aesthetics feature… not a functional one. I think that was the biggest mistake in Post Formats UI. This approach adds descriptions inline, which should help spur usage and adoption by end-users.

      2. We can improve usability and user experience substantially with a little bit of a UI refresh… but there are power users who don’t need the training wheels, and we can gradually take them off. In this early prototype, I’ve included an option for hiding the descriptions, which makes the Formats box a lot more compact. A “mini mode” with smaller icons (like Mel proposed) is also an idea worth seriously considering, since the less-verbose box still takes up a lot of space.

      My personal bias is to hide the radio buttons as much as possible. They’re an artifact from another time, and they look out of place. They also don’t help explain to users what they are used for. The “Better Formats” prototype may not be the best option for WordPress in the end, but I think it’s a step in the right direction… that is, emphasizing education over interface (in a manner of speaking).

    • VegasKev 6:46 pm on June 4, 2013 Permalink | Log in to Reply

      ugh…what a tough call that must’ve been. But I agree with you Mark. If it isn’t 100% ready, push it to future release. And with Murphy’s Law….everything will fall into place right after 3.6 or 3.6.1 drops and you’ll be adding them “early” into 3.6.2 or ..3 instead of 3.7 …cuz that’s how the universe works…lol

    • Abhishek Ghosh 10:08 pm on June 4, 2013 Permalink | Log in to Reply

      It is a very very good decision. #2 with colored icon on hover looks great.

    • perryb 1:46 pm on June 5, 2013 Permalink | Log in to Reply

      I wonder if there is another way of approaching Post Formats.

      The issue is that by implementing the UI you are instantly overloading users with all sorts of options, many of which they will not need and may not understand.

      How about making it so the post editor can intelligently detect what type of post is being created?

      Sub 200+ characters = aside PF
      Single image = image PF
      Gallery = gallery PF
      Link = link PF
      etc

      The publish button would change according to context ( perhaps with a choice ) “Publish as image etc” or “Publish as regular post”

      This way the feature could be easily switched on in the background by developers who can choose to support as many post formats as they like (perhaps even control the rules that determine format detection).

      The user only gets presented with the option at the point they hit publish ( reduced set of options ) and this would greatly reduce the demands on the interface.

      I also wonder if Post Formats would be better used if integrated more with the iOS and Android apps. If you take a photo on your phone and post it then it might instantly become an image format post and so on.

      I really like the concept and the purpose of Post Formats and I get the impression that they were introduced to facilitate more casual blogging styles (perhaps even reinvigorate blogging itself).

      Perhaps you need to think more about how people might realistically use them in practice which might give a clue as to how the UI might work.

      Look from the other end of the telescope :)

    • Mike 9:55 am on June 8, 2013 Permalink | Log in to Reply

      Just saw the latest build. I have to say it is a mighty shame that talented programmers are engaged in a monthly project to remove goodness from WP.

      I’m not buying the GUI confusion mumbo jumbo. Microsoft has made fortunes for many by aggressively promoting GUI confusion and they and we have survived.

      I think the confusing GUI aspects would have been quicker improved from release feedback. When evolution of technologies and GUIs is considered, it puts this controversy into perspective – Much a Do About Nothing.

      Perhaps there are times when consolidation and retrenchment are good, but there is no evidence that this was one of those times. IMHO there is every indication it was time to move boldly forward.

      I urge WordPress folks to keep the spirit and focus on making dreams happen rather than cutting them down to size.

    • ecabral 6:19 pm on June 8, 2013 Permalink | Log in to Reply

      @ Mark – RE: Did I miss anything?

      Yes :) When ca we expect the plugin to come out?

    • allancole 10:26 pm on June 11, 2013 Permalink | Log in to Reply

      I’m chiming in late, but I’m really disappointed about this. I’ve been developing themes for WordPress since 2006 and decided to subscribe to the nightly builds for the first time ever based on the new implementation of this Post Formats GUI alone.

      Post Formats have needed their own content fields and their own GUI since 3.1 and I never understood how they were useful without them.

      The problem with current Post Format GUI is that it doesn’t explicitly ask users to do anything specific with their content so while compatibility between themes may be better without Format fields, there’s no way for theme devs to deal with Post Format content in any consistent manner. In my opinion, ALL Post Formats should have their own separate content fields. That way all themes can take advantage of the additional content in the same way (or not). Without their content fields, Post Formats are really just standardized categories, which aren’t very intuitive for users to implement and it’s limiting to theme developers who may want to push the envelope.

      The design and of the GUI is a separate thing and if its buggy or confusing for users, it may not be worth squeezing it into 3.6 — I get that — then push it to 3.7. While the new GUI may not have been perfect, it was very close to what it needed to be and I found it to be very intuitive. The most confusing part was why each Format didn’t come with it’s own fields (ie: Galleries, Asides, etc). Seems like such an obvious next step for the GUI for the reasons I mentioned earlier. Most of my other smaller gripes have already been mentioned in other comments but Post Formats should also be theme dependent, just like Custom Headers/Backgrounds via add_support().

      All-in-all It’s just sad to finally get a taste of a much needed feature only to find out it’ll ultimately be removed from core and converted into a plugin making it more difficult for theme developers to do awesome stuff. I do however, like the idea of implementing it this way for testing purposes a la MP6.

      Just my 2¢.

  • Mark Jaquith 10:01 pm on April 17, 2013 Permalink
    Tags:   

    The weekly IRC meeting has been moved back one hour to 20:00 UTC. Still on Wednesdays. As always, check the sidebar for that info.

     
  • Mark Jaquith 8:07 pm on March 27, 2013 Permalink  

    We’re really close 

    We’re so close to beta, I can taste it. For today’s meeting, think of anything outstanding that is still a beta blocker and then let’s talk about how we can get it sorted today. We’re going to keep at it until it’s ready. When? When it’s ready. But I’m hoping in the next 24 hours.

     
  • Mark Jaquith 7:51 pm on March 13, 2013 Permalink
    Tags:   

    The Road to 3.6 Beta 1 

    our original schedule had us hitting beta 1 today, March 13th. We’re not quite there. Beta should mean that we’re feature complete, and we’re not. We could do what we’ve done in the past, and declare a beta, while continuing to do feature work, but that just devalues the meaning of “beta”. I want people in the WordPress ecosystem to trust that when we say “beta”, that means we’re feature complete and that they should start seriously testing their themes and plugins against trunk for issues. If we continue with feature development during the beta period, that will just shove back everyone’s testing to the RC period, which will translate to more issues going unnoticed and tarnishing the release.

    Consequently, I’m pushing the beta date back two weeks, to March 27th, and the release back one week to April 29th. If our beta period is actually a beta period (to work on bugs, not features), three weeks should be plenty of time. Ditto for the two-week RC period, for major bugs. We’ve needed longer periods in the past because we’ve been doing major feature development through the beta period and into the RC period, which, as mentioned above, I don’t want to do again.

    Here is the major new-feature or new-feature-related stuff that needs to be settled and land in core (if they are going in at all) in the next two weeks (front-loaded as much as possible). Let’s redouble our efforts and get this sorted so we can get a beta out the door.

    Revisions

    Post Format UI

    Twenty Thirteen

    Post locking

    Nav Menus

     
    • Peter Westwood 8:52 pm on March 13, 2013 Permalink | Log in to Reply

      The revisions UI Ticket is #23497

    • Myatu 12:06 pm on March 15, 2013 Permalink | Log in to Reply

      Sigh. I only have three requests for the devs: Comments, comments and comments. There’s a lack of proper developer documentation (read: the outdated Codex). But resorting to the actual source code/phpdoc is of no help either, as there’s a distinct lack of comments (particularly the additions added with 3.5 such as the new Media Library Javascript code). This is compounded by the fact there’s no rhyme or reason to some of the coding styles used – its getting uglier by the day, and I’m wondering if that has to do with missed deadlines (and thus devs feel pressured to make haste). Maybe it’s just me… But its starting to take the fun out of things.

      • Mark Jaquith 4:52 am on March 16, 2013 Permalink | Log in to Reply

        I agree. And yes, the media stuff (as wonderful as it is in execution) is too much of a black box. Just like we have people who update our help tabs and our PHPDocs, there should be people who work on improving code commenting, formatting, and readability. Would be a good task for someone who is new to core, as their confusion about unclear sections would be genuine and not simulated, as it might be for someone who already knows what the code does.

    • adamsilverstein 7:47 pm on March 17, 2013 Permalink | Log in to Reply

      also on revisions: #22289 (Filter to override WP_POST_REVISIONS)

    • Drew Jaynes (DrewAPicture) 9:05 pm on March 20, 2013 Permalink | Log in to Reply

      You want to change #23716 under Nav Menus to #23770 — Secondary tab for Locations?

    • Lance Willett 7:31 am on March 27, 2013 Permalink | Log in to Reply

      Under “Twenty Thirteen” you can now cross off #23619 and #23621.

  • Mark Jaquith 4:46 pm on February 19, 2013 Permalink
    Tags:   

    Dropping Editorial Flow 

    I’ve decided to drop the Editorial Flow feature from the 3.6 roster. A few things happened. We looked into what the main feature (“forking” a published post and allowing it to be edited then reintegrated) would involve, and found that there were some really fundamental hurdles that were unlikely to be resolved in the time given. A lot of time was spent on the planning stage, and we just kept surfacing more questions. Moreover, because the hurdles were so low-level, they would have required a significant amount of time from a core lead like me, @nacin, or @ryan — time that we just didn’t have to give this cycle due to other responsibilities. What that left was #12706 — a somewhat related ticket with a long-running monster patch. This similarly needed (and still needs) a core lead to dedicate a lot of time to planning, reviewing, and committing it. That might happen, or might not. It didn’t seem fair to keep @danielbachhuber and @kovshenin responsible for something that might or might not make it, subject to other people’s availability.

    Though disappointing, this effort wasn’t wasted. We learned a lot about the challenges involved, and we’re better positioned to tackle it in the future with more advance planning and a better understanding of the core team resources that need time dedicated to it.

     
    • Alison Foxall 4:49 pm on February 19, 2013 Permalink | Log in to Reply

      Understandable. I had been loosely following what was going on and it just seemed like a huge task to undertake. Looking forward to getting more involved in the future.

    • Marko Heijnen 4:58 pm on February 19, 2013 Permalink | Log in to Reply

      I guess for 12706 it makes sense to develop it on Github. Like what happend with WP_Image_Editor. You still get an monster patch in the end but the changes can be better maintained. If I would make a change on the code now literally no one would find out precisely what I changed.

    • scribu 5:18 pm on February 19, 2013 Permalink | Log in to Reply

      Is there some place where the lessons learned from the planning stage are summarized?

      At the very least, links to some IRC logs would be good.

    • Robert Lilly 8:45 pm on February 19, 2013 Permalink | Log in to Reply

      Sorry to hear this won’t make it into the next release, but glad to realize that the issues involved are being thought through and that this will be addressed in the near future. I think this is a feature that is really needed whenever there is more than one person involved in creating/editing/maintaining posts.

      In my fantasy I’m imagining something like the Review feature of Microsoft Word, specifically the Track Changes and Add Comments functions.

  • 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