WordPress.org

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

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

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

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

    • 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¢.

  • Jen Mylo 1:53 pm on April 23, 2013 Permalink
    Tags: , deadlines   

    Post Formats, Schedules, and Philosophy 

    Post Formats UI is looking like this right now:
    Screen shot 2013-04-23 at 9.05.04 AM

    This seems confusing, because it looks like they are icons to insert something (Image, Gallery, Link, Video, etc), but instead of launching a popup to insert a link or an image, the screen changes and the navigation that was just used to choose disappears completely. (Note: If Standard had some indication of being the default/current selection it wouldn’t be as confusing)

    Clicking on one — say Link — makes the UI change, the big icon row go away, and a format switcher link drops below the title rather than keeping its visual hierarchy above the post stuff, and it’s generally disorienting.

    Screen shot 2013-04-23 at 9.09.35 AM

    If the user thinks, “Whoa, what happened, I better change format again,” and they click on the “Change format’ link under the title field and next to the “Enter URL” instruction, the screens morphs again to this:

    Screen shot 2013-04-23 at 9.12.41 AM

    Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing. Does it still think it is a link bc they didn’t actively choose to return to standard, they just chose to see the options? If that’s so, why did the url field disappear?

    Looking at the release schedule:
    Screen shot 2013-04-23 at 9.40.18 AM
    We launched Beta 1 on April 4, and it’s been almost 3 weeks without a follow-up beta 2.
    …I am wondering if the post formats ui is really prime time ready, or if it should be one of the very first thing sto land in a 3.7 branch so we can get the things that are completely ready into the hands of users sooner rather than later?

    Since I’m outside the core dev group now, I’ve been on both sides of the deadline delay dance. I know how hard it is to let go of something that feels like it is thisclose to done. And I know that just about everyone on the core team will be thinking right about now that I should shut up (and I’m okay with that, because it used to be my first response to deadline questions to core, too). But we have this philosophy posted on wordpress.org:

    Deadlines Are Not Arbitrary

    Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because through trial and error we’ve found that to be a good balance between getting cool stuff in each release and not so much that we end up breaking more than we add.

    Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.

    The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.

    The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.

    I’m not trying to be a troublemaker or imply that anyone isn’t doing everything they can — I know for a fact that people are working themselves into the ground on this release. Nor am looking to incite a debate about deadlines or all the explanations of how we fell behind this time (I’ve been following along, everything is really pretty normal). But would it be better to not try to squeeze it all in, get out what we can ship now (including the awesome 2013 theme that regular people still don’t have access to), and take a quick breath to relax before diving back in on a new cycle? Shipping is a feature, too. ;)

     

    • mordauk 2:01 pm on April 23, 2013 Permalink | Log in to Reply

      I love where the new post formats UI is going, but I have to agree with Jen about the confusion a lot of users are going to see. When playing with them last week, I caught myself asking some of the exact same questions Jen mentioned above, and I’m a “power” user.

      If it is one or the other, I’d prefer to see 3.6 pushed back a bit so that it can still include the new post formats.

      • Jon Brown 5:47 pm on April 23, 2013 Permalink | Log in to Reply

        Ditto. Current UI is confusing for all the reasons Jen documented. I was actually starting to like the UI just before beta,, but beta 1′s change post format link is awful. Fix or punt, but don’t release it like this. Do keep API’s either way, I’d assume changing those might cascade into post revision changes?

        • lisafirke 10:38 pm on April 24, 2013 Permalink | Log in to Reply

          On the UI, yes, it’s confusing, even to an experienced user. The fix doesn’t seem that tough, though. Keep in mind that icons don’t have to carry all the weight. Words are useful, too! What would be wrong with adding a simple: “Choose a post format:” label?

          Also, standard icon shouldn’t be a pin. That to me signifies a *sticky* post.

      • Harish Chouhan 11:42 am on April 25, 2013 Permalink | Log in to Reply

        Yup pushing back 3.6 seems better path. So much work has been put into this already. The Tabs that were there very early in the development of 3.6 were annoying but more usable. Hiding and displaying the Post Format icons, involves extra click and confusion.

    • Caspar 2:05 pm on April 23, 2013 Permalink | Log in to Reply

      tbh, I have no idea why post formats made it into core. They have, so it’s useless to complain. But if Links got removed from core into a plugin, so should post formats.

      The UI itself looks very nice, though, if one likes the feature. Yet I think Jen is right: give it the time it deserves. I don’t think a majority of users would miss it if it had to wait until 3.7.

      • George Stephanis 2:06 pm on April 23, 2013 Permalink | Log in to Reply

        Post formats have been in core for some time now. It’s just the UI implementation that’s new, to make it easier for people to use, as well as implementing the custom fields for each.

        • Jen Mylo 2:17 pm on April 23, 2013 Permalink | Log in to Reply

          UI enhancements are, well, enhancements. This is what the schedule says about Beta 1:

          From this point on, no more commits for any new enhancements or feature requests in this release cycle, only bug fixes. Any enhancements/feature requests not completed and committed by this point will be punted to future. Please don’t get angry and complain when this happens; it’s necessary to get us to an on-time release. You can keep working on your pet ticket and have it ready for early 3.7.

          Saying that the UI was an overall bug is enough stretch to snap a tendon. :)

          • Aaron D. Campbell 2:20 pm on April 23, 2013 Permalink | Log in to Reply

            The new UI was in before beta but the tests revealed bugs. I think that saying we’re trying to stretch the definition of bug to include the original UI enhancement is an equally tendon-snapping stretch.

            • Jen Mylo 2:35 pm on April 23, 2013 Permalink

              Poor usability isn’t really a bug, it’s unfinished design.

      • Mike Schinkel 8:52 pm on April 23, 2013 Permalink | Log in to Reply

        I have no idea why post formats made it into core. They have, so it’s useless to complain. But if Links got removed from core into a plugin, so should post formats.

        In hindsight, compared to my opinion when they were first announced, I definitely have to agree. With everything you just said, except the first part; I do have an idea of why.

    • John Blackbourn (johnbillion) 2:07 pm on April 23, 2013 Permalink | Log in to Reply

      +1 on punting the post formats UI to 3.7, and releasing 3.6 with the other great features we have, including Twenty Thirteen. I think to bring this UI up to scratch we need to re-address it without the impending delay of 3.6 looming over our heads.

    • Aaron D. Campbell 2:09 pm on April 23, 2013 Permalink | Log in to Reply

      Where the icon strip is back, but the link field has disappeared and the icon next to Add New Post is still a link. This is super confusing.

      I agree that the icon should change back to standard. That’s a bug.

    • Chip Bennett 2:10 pm on April 23, 2013 Permalink | Log in to Reply

      +1 to releasing the Post Formats UI updates when they’re ready: either by delaying 3.6, or punting the implementation to 3.7.

      Can we keep the underlying functions, though? Standardizing on post-format related post custom meta data, and standard data fields for each post format type, is equally (if not more) important than the UI improvements.

      • Jen Mylo 2:13 pm on April 23, 2013 Permalink | Log in to Reply

        I would agree.

      • George Stephanis 2:30 pm on April 23, 2013 Permalink | Log in to Reply

        +1

      • Beau Lebens 2:50 pm on April 23, 2013 Permalink | Log in to Reply

        Can we keep the underlying functions, though? Standardizing on post-format related post custom meta data, and standard data fields for each post format type, is equally (if not more) important than the UI improvements.

        Definitely agree on this bit.

      • Konstantin Kovshenin 2:57 pm on April 23, 2013 Permalink | Log in to Reply

        What exactly is the benefit of keeping the APIs to access meta data, without keeping the UIs exposing that data?

        • Chip Bennett 3:20 pm on April 23, 2013 Permalink | Log in to Reply

          Because the back end isn’t the only place that those meta-data are exposed? Theme-rendering of the meta data is completely unaffected by back-end UI.

        • Drew Jaynes (DrewAPicture) 3:55 pm on April 23, 2013 Permalink | Log in to Reply

          I can see some benefit in keeping the APIs to access the metadata, which is to make it available and allow the wider WordPress community to innovate and iterate on that information. Of course, it doesn’t really solve the issue of Twenty Thirteen relying on that metadata and having no UI to handle it.

          • Chip Bennett 4:50 pm on April 23, 2013 Permalink | Log in to Reply

            The API handles migration of appropriate data to post meta data. Could that be confusing? (Where did my video go?) Sure. That can be addressed, though, with simple metaboxes for relevant data, even without the contextually changing icons/UI. And post format selection is already available via meta box.

        • Drew Jaynes (DrewAPicture) 4:05 pm on April 23, 2013 Permalink | Log in to Reply

          I’m with @chipbennett that we should either extend the release or punt the UI to 3.7 while at the same time keeping and exposing the underlying functionality.

          As I said in response to @koveshenin, I can see one major benefit of exposing the meta data APIs as allowing for community innovation and iteration. I’d like to see us expose the APIs and maybe package core’s version of the UI into a plugin. The ability is there, the implementation is not and I’d like to see us give it a better measure of caution before we roll it as a core UI.

        • krogsgard 4:10 pm on April 23, 2013 Permalink | Log in to Reply

          I already do custom UI interfaces for clients w/ post formats, and the new functions and standard meta data conventions are enormously helpful for future proofing a custom UI. If the UI gets bumped, keeping the new functions will still be a big win for theme developers.

      • Marcus 6:38 pm on April 23, 2013 Permalink | Log in to Reply

        +1

        the ui is too important to rush, since it’s used by everyone

    • Hassan 2:18 pm on April 23, 2013 Permalink | Log in to Reply

      I don’t really think that Post Formats UI are that important of an addition to make the release date pushed back again and again. I know some people might want it, but for me I’ll probably won’t use it all. Btw, if my theme doesn’t support it, I won’t see it, right?

      So, yeah… I don’t mind pushing it to v3.7 instead. I’d rather ship something fully tried, tested, and trued than half-bake it and rush the release.

    • mindctrl 2:24 pm on April 23, 2013 Permalink | Log in to Reply

      I’d like to see this come in 3.6, even if that means pushing back the date. If this version is all about “content”, and Twenty Thirteen is all about blogging, it makes sense that this UI makes it in and launches with 3.6 and the theme.

      I don’t think there are millions of people sitting around tapping their feet saying WordPress 3.6 better come on 4/29, or even know that’s the date. The devs and core team, sure. Users, not so much. It is about the users, right?

      The rabbit hole thing kinda doesn’t apply in my mind. It’s not adding one more feature here or there. It’s getting one of the centerpiece features of this release finished and included.

      If everyone agrees to push back the release date and that no work gets done in 3.6 that’s unrelated to Post Formats UI, there is no rabbit hole.

      • Daniel Dvorkin (MZAWeb) 2:31 pm on April 23, 2013 Permalink | Log in to Reply

        Personally, I don’t really like the new Post Formats because I don’t find it very useful for my use cases. Having said that, I must say this argument makes a whole lot of sense.

        • Nashwan Doaqan 4:15 pm on April 23, 2013 Permalink | Log in to Reply

          I agree with you, The post formats is not very useful to me, but maybe for others it may be very important … anyway after all work on The New Post Formats UI it will be hard thing to move it to 3.7 :(

        • nofearinc 9:31 pm on April 23, 2013 Permalink | Log in to Reply

          I do agree with you; don’t get their concept, not sure if I will. I’ve seen other systems using this approach though and it would be interesting to see what users would judge here if they get an access to the post format switcher. It’s still a common blogging platform even if we build CMS-based stuff out of it.

          Problem is we can’t easily deprecate anything that’s open to the public and it might be the new ‘Links’ thingy that lives and dies notoriously.

        • mattyrob 10:47 am on April 24, 2013 Permalink | Log in to Reply

          I can’t see a use for this section either so I’ve hidden it on my testing sites.

          That said, if this is supposed to be a new core feature of 3.6 then releasing a new version without it and bumping to 3.7 seems ill advised.

          I’d say get it fixed, delay the release to all this to happen (and if possible while fixing it, allow it to be hidden from the Screen Options).

      • kevinjohngallagher 11:02 pm on April 23, 2013 Permalink | Log in to Reply

        I don’t think there are millions of people sitting around tapping their feet saying WordPress 3.6 better come on 4/29, or even know that’s the date. The devs and core team, sure. Users, not so much. It is about the users, right?

        I disagree.

        It’s not about “millions” of people, it’s about the businesses and organisations that based themselves on top of WordPress. As we move out of the small shops, and small website builds into larger engagements (Government, Enterprise, Education, and Charity sectors) we start to hit more and more procedural issues and legislation.

        There is a huge challenge for many of us of balancing Open Source agility against Service Level Agreements. We’re navigating digital security engagements, code freezes and legal red tape (hello disability discrimination act versus our love of mouse-only hover menus and slight shading that colour blind people cant see) – and these things are planned well in advance.

        For example, the Release Date for WP3.6 is the same week as the big bank holiday weekend in the UK (most don’t happen in both Scotland and England), so we’ve had to make plans around it in February. We are so focussed on blogging end users that we forget about the business ecosystem thats built around WP beyond that of 5 or less people organisations.

        if we want WordPress to scale, in a non-technical sense, then we need to address some of the fundamentals of our product management.

        • mindctrl 12:49 pm on April 24, 2013 Permalink | Log in to Reply

          Major WP versions are mostly about features, and if your SLAs for large organizations require you to be on the cutting edge of Feature 1.0 at release time, you just might be insane. :)

    • Ryan Boren 2:35 pm on April 23, 2013 Permalink | Log in to Reply

      The four month deadline is so fanciful as to be arbitrary. It always has been. Historically, we just can’t do a major release with a marquee UI feature in that time, certainly not without heroic efforts of the 3.5 sort. So we end up facing decisions like this. Every single release we wonder if we have to punt the marquee feature. Punting often requires major surgery that can be as much work as finishing the feature. Punting is demoralizing. Four month releases are empty promises that bring us here.

      • Jen Mylo 3:09 pm on April 23, 2013 Permalink | Log in to Reply

        I used to argue that a 6-month schedule was more realistic with the kinds of features we choose, so I don’t disagree with you, but the people who made the 3.6 schedule and chose the scope for it are the core leads, no?

        At least change the schedule page if a decision was made to push back release by a month or whatever.

      • kevinjohngallagher 10:43 pm on April 23, 2013 Permalink | Log in to Reply

        I can’t disagree with you Ryan, but in an agile methodology – and again thats what the core team has embraced – it’s a completely moot point.

        Every completed work that is signed off in each sprint that matches “definition of done” makes it into a releasable candidate. Work that is not integrated into the “master branch” isn’t released.

        The issue is not a 4 month, or a 6 months or a 4 week or a 12 month release cycle, it’s the management of scope of what can be done in that time period. Can we release a new WordPress version every 4 months? yes. Can we release a new WordPress version every 4 weeks? yes. Can we do that regardless of the amount of scope we presume we can deliver? heck no!

        The developers that work on care are amazing. As a failed developer myself I’m always in awe of what gets done. But there are 4 factors in the engineering pyramid: Scope, Time, Quality and Resource.

        > When Scope is more than should fit into time, and resource stays the same, the only variable that moves is quality.

        In WP’s history, thats usually to the detriment of edge cases. Especially when we’re talking about UI changes.

        Historically, we just can’t do a major release with a marquee UI feature in that time

        That to me suggests that Marquee UI features should be done over 2 (or more) releases. We should release features when they are ready in accordance with our definition of done. Releasing a feature that isn’t up to our MVP isn’t going to do any good, and neither is changing our release date. We shouldn’t try to change our release date to fit in with our feature set, nor vice versa.

        I suggest the Project Manager reads: http://ma.tt/2010/11/one-point-oh/

        Punting often requires major surgery that can be as much work as finishing the feature

        Thats a very different issue. We should be managing integration in the most decoupled way possible. Tight coupling of features into the core so that they *have* to ship is a scary scary path that leads through “bloatville” to “dependancy-city”. If something can’t be built as a plug-in, then thats the issue that should be solved first.

    • Scott Taylor 2:36 pm on April 23, 2013 Permalink | Log in to Reply

      I would argue that the deadline is entirely arbitrary, and it was never realistically altered based on shifting resources. That being said, we had a previous UI iteration we were all proud of, and then user testing said otherwise. The new UI tested about 3 million times better (I’m a data scientist by trade). Since we are in beta (shipping late for sure), now is the perfect time for more testing and tweaks, not less.

      In the past few weeks, we have landed some huge and wildly complex commits, but there are not a litany (or really any) of those left. There are things here or there, but none (?) are blockers.

      I agree it’s crunch time, but I would rather we all pull together and use our noggins rather than criticize and shelf it. What’s *really* missing? *How much* needs to change? @lessbloat and I rejiggered the entire UI in 1-2 days. I doubt that kind of effort is needed again or a that complete reboot is necessary

    • Tom J Nowell 2:36 pm on April 23, 2013 Permalink | Log in to Reply

      I’d suggest:

      • The post format icons should never go away, they provide a second purpose as an indicator and feedback once clicked, hiding them removes that function and forces the user to either remember what they clicked, or figure out from scratch if they’re looking at an existing post.
      • Icons and labels at the moment look arbitrary as if they’re just floating in the middle
      • When opening a new page, how do you know that it’s a standard post, it’s not highlighted in any way or shown to be active. It’s not obvious that the icons are a toggle/selection
      • The icons look more like buttons, actions, that they do something rather than set a status/toggle/selection

      So I’d say that they would be better as tabs, always visible, or at least with a separating line so it’s clear that they are separate from the controls underneath and have a high level purpose, associating them with the Add New Post rather than the content box.

      • Jen Mylo 3:11 pm on April 23, 2013 Permalink | Log in to Reply

        I would agree that keeping the icons present would be less disorienting.

      • Andrew Ozz 8:46 pm on April 23, 2013 Permalink | Log in to Reply

        A post format is something that should be chosen once at starting a new post. It could be changed later but that would mean loosing/removing some of the data that the user has entered (well, we don’t “loose” the data but it becomes unreachable/useless).

        In that terms hiding the icons after a post format has been set makes sense. Perhaps the link can be more prominent and be above the title field (or whatever field is at the top for the current format).

        Keeping all post format icons visible at all times is not good imho. We still need to educate many users what post formats are and how they can be used. Part of this is that changing a post format comes at a cost.

      • Erlend Sogge Heggen 10:46 pm on April 23, 2013 Permalink | Log in to Reply

        +1 for icons never going away. If that was the case however, I think it should be possible to turn off post formats altogether. If you’re using a format-supporting theme but your client is only interested in making ordinary posts, you’d want those tabs out of there.
        +1 for making them look more like tabs.

    • Tom J Nowell 2:46 pm on April 23, 2013 Permalink | Log in to Reply

      Here’s a UI that fixes the issues, doesn’t have the pretty images, but that can be fixed ( look at your browser tabs for an example )

      http://alexking.org/wp-content/uploads/2011/10/format-standard-510×244.png

    • Justin Sainton 2:49 pm on April 23, 2013 Permalink | Log in to Reply

      I’d agree with Pippin, Scott and Ryan. Do what’s necessary (which most agree, is not much) to ship with this in 3.6. We’ve already lost one original content feature (to @danielbachhuber and @kovshenin’s great malaise), I don’t see the benefit in shipping without a Post Format UI.

      It also seems that the general opposition to the new UI is “It’s awkward…people won’t know what to do…it’s jarring” – all of that is also true of the Post Format concept in general, we heard the same arguments when the initial API was introduced. Give people time and give them credit to work it out.

      • Jen Mylo 3:01 pm on April 23, 2013 Permalink | Log in to Reply

        Millions of people have no trouble understanding the concept with Tumblr. Regular users don’t even think about “post formats,” they think about “posting a video” or whatever the format is.

        • kevinjohngallagher 9:57 pm on April 23, 2013 Permalink | Log in to Reply

          The difference with Tumblr is that it is not a post format change, it’s a post type.
          We have post types (with custom UIs to look like post formats), and post formats that have the same functionality as post types.

          Post formats are essentially standardised custom post types with a unified UI – but only accessible from a totally different place in the admin section.
          ( CPT called “quotes” is a main navigation link, while post formats is inside post, and then choose quote)

          Post Formats are a great idea, but in a rush to get them out the door in 3.1 we took a tactical decision rather than a strategic decision which has led us to where we are now.

          • Manny Fleurmond 2:50 pm on April 24, 2013 Permalink | Log in to Reply

            That’s actually a good point. I’ve been trying to figure this one out myself.

    • nphaskins 3:02 pm on April 23, 2013 Permalink | Log in to Reply

      I think it’s right on the money how it’s currently sitting. I wasn’t too keen on how it sat previously (small icons and boxes) so to the guys who re-jigged it, I think you did a stellar job. I’ve been using this (the new UI and functions) extensively over the past week or so as I’ve been rebuilding a few products against the current beta and the current UI. I find it quite nice and don’t consider it confusing at all. I asked my wife to look, and she knows nothing about web shit, and even she could figure it out.

      I’m typically a “hard to please” kind of person and I really do think that this is damn close to being kosher.

    • Nashwan Doaqan 3:03 pm on April 23, 2013 Permalink | Log in to Reply

      The new post format UI is a main feature in 3.6, I can’t imagine the 3.6 version without it… but if you think it is not ready yet you can move it to 3.7 and focus on other bugs tickets…

      My opinion is to do one idea perfectly is better than doing a lot :)

    • BobDunn-Trainer 3:10 pm on April 23, 2013 Permalink | Log in to Reply

      Yes, I do believe if it is released, we will all adapt, even though it is confusing for the average user. The big question is will they even attempt to use these, or totally ignore them. Putting them up front and center will force them to at least try to understand.

      At our last WordPress meetup we did an overview of 3.6. I asked all the casual users to raiser their hands. Then I asked them to keep their hand up if they had ever used post formats or even understood them. All hands when down.

      From the perspective of the people I work with, casual users, I am good either way ;)

    • Stuntbox 3:20 pm on April 23, 2013 Permalink | Log in to Reply

      I’m just one person, but I’d vote for keeping Post Formats in 3.6. Until now, the lack of any kind of admin UI has made Post Formats an incomplete feature. Most casual users aren’t using or discovering them because it’s completely invisible to them without a UI.

      Tweaking and refining the existing UI design seems like it would benefit from this shipping. While there’s been user testing on the Post Formats UI, it’s limited in scope compared to the total number of users who will be exposed to it and provide useful feedback once it goes live.

      It also seems like there are small tweaks that can be made to improve the current UI without punting on it altogether or causing huge delays. Things like simply updating the main heading in the admin UI as the user makes a selection. It won’t cure everything, but it would be a subtle reinforcement if it changed from “Add New Post” to “Add New Image Post”, etc, as a user made selections. (I know I’m getting off topic here, but you get the idea.)

    • Robert Dall 3:27 pm on April 23, 2013 Permalink | Log in to Reply

      On Schedules:

      To use an analogy… If the ferry is always late… I don’t say the ferry is broken… I say change the scheduled…

    • Grant Palin 4:46 pm on April 23, 2013 Permalink | Log in to Reply

      The post formats basic functionality has been in place for some time already. I’m surprised there hasn’t been an official UI for it sooner. It’s something I think is core to blogging, and could be worth pushing on it a little bit more to get it done now. And ship it when it is ready, rather than committing to a deadline. I thought the 3.6 cycle was surprisingly short anyway, so there’s room to extend it a bit.

    • Knut Sparhell 5:02 pm on April 23, 2013 Permalink | Log in to Reply

      My first impression after seeing this new post format UI was: How elegant! Sometimes something will feel confusing to someone. When introducing new features the questions should be if the UI at least is educating and guiding the road to understand the purpose.

      These post formats are a major leap forward. Removing (punting) this would reduce 3.6 to a release that just fixes some old bugs. Push the scheduled dates a few weeks more and get it released.

      Lesson to learn is to start working on major new features in the cycle preceding the cycle it’s going to be released. Use a plugin to iterate, like with the MP6 project.

      • Jen Mylo 5:29 pm on April 23, 2013 Permalink | Log in to Reply

        I do think the icons look elegant. Remember that in 3.7 that icon style will be replaced by the icon style in MP6, so it will likely have a pretty different feel.

        • kevinjohngallagher 10:01 pm on April 23, 2013 Permalink | Log in to Reply

          I think thats an issue right there.

          We’re considering releasing something that we KNOW we’re not happy with, and that is changing next release anyway.

          Why are we forcing multiple UI changes on our users?

          I personally like the UI, though the UX is lacking, but if we’re changing it anyway – what are the advantages of releasing it?

    • Arnan de Gans 6:05 pm on April 23, 2013 Permalink | Log in to Reply

      Sure let’s turn WP into the next Facebook :(
      Can these buttons be hidden in a jquery slide in/out kinda thing?

      Think of the 2nd screenshot, where you click the “change” format and a section slides out pushing all elements on the page down. You click the post format you want. It slides back up and the below form changes accordingly.

      That’s unobtrusive, non-confusing and is “trusted” since some other sites use a similar approach for posting items or hiding options.

    • Scott Taylor 6:51 pm on April 23, 2013 Permalink | Log in to Reply

      I have yet to hear specifics from anyone about what they want to change and how. No patches, no mockups, no explanation of what actually sucks and a plan to start attacking it. So, sounds like we’re still in beta and could use some Trac activity from those with an opinion.

      I’ve been actively working on this stuff for the past 3 months and most of the people on this thread have had light involvement, if any at all. I am trying to figure out what is constructive about pointing fingers right now.

      • Jen Mylo 7:01 pm on April 23, 2013 Permalink | Log in to Reply

        I’m not trying to point fingers, as I said. I’m trying to get us to take a look at what is ready to go and what still needs more work, and re-assess the scope/schedule as needed. I also didn’t say it sucked, I said it was confusing, and I posted a step by step outline of why along with screenshots. I have been on the receiving end of the “should it be cut so we can ship” with a WordPress release many times, so I get it that defensiveness is the first reaction. Everything you just said, I’ve said before.

        If the decision is to extend the cycle and try to deliver in May instead, that’s a valid outcome too, but it’s not reflected anywhere on the schedule, which still says there’ll be a beta every week. Being late isn’t the end of the world, but going 3 weeks without another beta makes it seem that there are bigger problems than just fixing bugs, and if the schedule needs to be adjusted/updated to allow for more design/dev time then it should be.

        *I’ve *also* been the pm in the past who extended the dev cycle without updating the schedule page, and got comments asking about it on this blog, so I understand the natural reaction to that is, “Hey, we’re spending all our time on the product, don’t hassle us about a blog page.” :)

    • Matt Mullenweg 7:32 pm on April 23, 2013 Permalink | Log in to Reply

      We shouldn’t take this personally. Features get adding and removed from releases all the time, even ones I’ve advocated for or worked on, and even at the eleventh hour.

      It’s also very normal to get tons of feedback after all the work on a feature has been done, or often after it’s been shipped.

      Even if it was pulled from core entirely, the work could be put into a plugin that we can see how it gets adopted and used in the WP ecosystem.

      • toscho 9:02 pm on April 23, 2013 Permalink | Log in to Reply

        I think this is a good idea. We could put it into a plugin and ask the users to allow us collecting usage data to see what elements should find a way into 3.7. Empirical data would surely help.

      • nofearinc 9:35 pm on April 23, 2013 Permalink | Log in to Reply

        Sounds like the best way to test something major and trendy without risking to think about deprecating and cleaning the codebase afterwards. +1

      • kevinjohngallagher 10:07 pm on April 23, 2013 Permalink | Log in to Reply

        I’m not against this thinking at all.

        My concern from a purely Project / Product management point of view is that the decision was made to tightly couple this specific change with an external dependancy in the 2013 theme.

        I’m a huge believer in MVP, or MMS depending on where you did your Agile training, and that we’ve fallen foul of the desire to push things into a core release when they weren’t ready before.

        I also believe that this is a prime example of the 80/20 rule causing issues with the decision making for core. As we move more towards CMS and away from purely blogging, WP.com is always going to enforce “purely blogging” concerns/issues/features into the 80 camp.

        [One] can’t imagine the fun conversations that we’ve already had with government agencies around the delay in the beta2 of their chosen CMS due to blogging UI concerns…

      • Erlend Sogge Heggen 11:05 pm on April 23, 2013 Permalink | Log in to Reply

        The plugin route for developing and testing flagship features across several cycles has proven to work very well for MP6. I hope the WP team will adopt this method for more core features in the future.

        In this instance though, I don’t see why it would be necessary. Even with its current quirks (make it always-on and tabbed-styled and it’s perfect imo) the new post format UI is a HUGE step forward for this very little known feature, all because of an incomplete UI.

        No one’s going to be worse off for this update. They’re either gonna continue making standard posts like they used to, or they’re gonna click those buttons and start learning about post formats.

        • Matt Mullenweg 3:00 am on April 24, 2013 Permalink | Log in to Reply

          FWIW, being freed from core was the best thing that ever happened to MP6.

          I do think people will be worse off with this update though. It’s really disheartening to see the confusion that people have when they face the dashboard and the post page, and the overwhelming majority of people who start WP give up without ever making a first post. I think for reasons like Jen pointed out and that came up in user testing.

          The downside of not putting it in is there will be 4-5 months until the next release. Since people think it’s worth waiting at least a month for that doesn’t seem that bad. The downside of putting it in would be the millions of new WP users that are exposed to it for the 4-5 months until the next release (assuming we even do another iteration on it immediately post-release, which we’re not historically great at).

      • mor10 1:21 am on April 26, 2013 Permalink | Log in to Reply

        Putting Post Formats in a plugin is definitely the right thing to do. The UI and implementation is confusing but more importantly most current themes don’t have much support for the feature and the output in these themes will be unreliable if not bizarre. Additionally Post Formats are only relevant for blogging. For those who primarily use WordPress as a CMS they are a distraction and end up being in the way. The key questions here are: Do new users understand how Post Formats work? And do WordPress users actually want and use Post Formats at all?

        • kbiglione 3:45 pm on April 26, 2013 Permalink | Log in to Reply

          This is exactly the problem. New users are baffled by post formats as it is, and the new UI doesn’t do much to solve that problem.

          Honestly, the new UI seems designed to promote a feature that hasn’t been embraced by theme designers. It’s almost as if we’re doubling down on a bad decision (adding Post Formats to core).

    • Mike 8:40 pm on April 23, 2013 Permalink | Log in to Reply

      Very dumb idea to pull it out! It is better – if necessary to delay the release. If the process works and it’s the GUI that is the problem [for some] just add a toggle to disable it in the Writing settings.

      The Post Formats concept – as presented is very clever, even radical. That’s what a WordPress release should be – moving the bar, innovating, taking blogging to where it’s never been before. It is very likely that this attempt – while far superior to the previous version – is not perfect. But an insular GUI testing audience is not the best group to really charter a path through future waters.

      WordPress is too big now to rollout helium releases. Too many people are putting in big efforts. Taking the Post Formats changes out at this point is disrespecting the great work that’s gone into developing it and disappointing large numbers of developers and users looking forward to innovating with yet another groundbreaking WP technology.

    • Chris M. 8:41 pm on April 23, 2013 Permalink | Log in to Reply

      Give it time. Here’s a thought from the UI perspective:

      http://screencast.com/t/7WMDyVgc1

    • Samuel Wood (Otto) 9:36 pm on April 23, 2013 Permalink | Log in to Reply

      I say delay the schedule, address the minor concerns that remain. and roll out up to a month late if needed.

      This is the big feature for 3.6. It’s the one that has gotten the most work. And at this point, I think the UI concerns remaining seem relatively minor and fixable, with proper suggestions and input. Nothing here looks like it’s drastically broken enough to go to the MAJOR task of ripping it all out of core just in order to do a release and hit the deadline.

      Deadlines Are Not Arbitrary, this is true. But that point is there specifically to address the issues of feature-creep and unmitigated-scope-expansion. This is neither of those things. Taking the time to make some relatively minor adjustments and polish to the UI seems minor by comparison to hitting that deadline at-all-costs.

      • Samuel Wood (Otto) 9:42 pm on April 23, 2013 Permalink | Log in to Reply

        Specific suggestions to address the UI concerns in the OP:

        • Make the “current” format have a highlight of some type. Slight background shading. Something.
        • Instead of putting the “change format” below the title, have a selection-action cause the bar to scroll upwards, hiding it or reducing its space-on-page. Not completely hiding it, maybe leave the text visible, and still shaded to show the current format.
        • On mouseover or some other form of indication of change, scroll the bar back down again, but without scrolling the whole page down. Make it overlay the existing area, then change the displayed UI when a new format is selected.

      • kevinjohngallagher 10:21 pm on April 23, 2013 Permalink | Log in to Reply

        Brother,

        I agree with your premise in an abstract sense, but not in the specific one.

        We should not stick to a release schedule (really a guideline) just because we posted it, but we should also be aware that companies and organisations do plan against the schedule as posted.

        Given that agile, and we’re using the modified Scrum methodology, states that every sprint has a releasable product as per our “definition of done”, one has to wonder how we’re so off track. I can’t be alone in having a meeting with a client tomorrow morning who will ask why there is no Beta2 at the date when RC2 was meant to be released.

        If we’ve bitten off more than we can chew, then we need to change something:

        • ship with what works (and meets our definition of done) and push the rest to the next release as per the management methodology that we prescribed to

        OR

        • delay the launch to squeeze in as much as possible, and accept that the amount of UAT testing is going to diminish.

        My concern is that every time we’ve made a UI change where we’ve shipped it ASAP, we’ve caused issues. I’m all for release early, release often; i’m all for an agile methodology; but that way of thinking requires a lean model where you release the Minimum Viable Product every time possible. This is not the MVP of 3.6.

        We need to get out of Developer mode and into release management mode. Thats incredibly hard for amazing developers to do. it’s so hard to say, damn it we’re close but it’s just not ready. But we’ve been here before, lets learn some lessons (Capital P Dangit… Inaccessible menus in 3.3… inability to log out without a mouse in 3.3 and 3.4 etc etc).

        • Samuel Wood (Otto) 9:43 pm on April 24, 2013 Permalink | Log in to Reply

          Sorry, you lost me when you started talking “agile” and “scrum” and all that other nonsensical project management stuff that I kinda don’t care anything about.

          I’m talking about this specific case. Not a methodology. Not some buzzword-heavy stuff that is, IMO, completely meaningless to real-world software development. I don’t subscribe to any of that jazz, and am totally uninterested in arguments based on it.

          For this specific case, at this specific time, the UI seems quite good and only needs some minor improvements to be polished enough to be usable. That’s what I’m saying. Is it worth delaying a bit to finish it? I say “yes, it is”.

          If you have arguments relating to that particular, I’d be happy to listen to them. I’m a coder, I speak as a coder. I don’t do project management, nor have any opinions based on it.

          • Konstantin Kovshenin 9:15 am on April 25, 2013 Permalink | Log in to Reply

            +1 billion.

          • kevinjohngallagher 6:59 pm on April 27, 2013 Permalink | Log in to Reply

            I’m a coder, I speak as a coder. I don’t do project management, nor have any opinions based on it.

            Totally here you. So can I ask then, WHO IS THE PROJECT MANAGER?

            Is it worth delaying a bit to finish it? I say “yes, it is”.

            Cool. When you say “delaying a bit”, how much is “a bit” ?
            10 minutes? 1 day? 1 year? 1 month? 1 week?

      • Mel Choyce 2:11 am on April 24, 2013 Permalink | Log in to Reply

        +1. We’ve already made good strides improving the usability of the post formats UI, and I think with some further tweaking and testing we can get it done for 3.6.

    • nathanrice 2:24 am on April 24, 2013 Permalink | Log in to Reply

      Not that anyone is taking a vote, but as was mentioned earlier, I really don’t see why Links was removed, but post formats needs to be a core feature.

      Or if it MUST be core feature, why the UI needs to be exposed to users with themes that don’t DO ANYTHING in particular with the data, or to users who don’t need, or don’t want, post formats or the associated UI to be part of their publishing experience.

      Or if it MUST be forced on users regardless of whether their theme supports it or they want it (ugh), then why does it HAVE to be part of 3.6? I’m not even sure it’s conceptually sound, much less functionally sound.

      So I’m with Matt, there’s good reason to make this into a plugin, test and iterate, get feedback, and maybe one day it makes it into core.

    • Mark Jaquith 7:16 am on April 24, 2013 Permalink | Log in to Reply

      The concerns here seem relatively minor, and can be addressed with a few small tweaks. The treatment we have now tested very well (whereas the one in beta 1 did not).

      I was going to make this point, but I’ll just quote Ryan:

      Punting often requires major surgery that can be as much work as finishing the feature.

      This is absolutely the case here. It it were a matter of removing a file and shipping an RC, that might be a different conversation. If people are willing to help out, we can get these tweaks done tomorrow and ship another beta.

      • Knut Sparhell 8:57 am on April 24, 2013 Permalink | Log in to Reply

        How much work is it to remove the new post formats UI from trunk? This has to be compared with the work that remains to make the feature and the UI great.

        Do another iteration on the UI presented here, before making a decision. You guys in the post formats team have done so much great work. It’s already 90% perfect.

    • bobbingwide 1:12 pm on April 24, 2013 Permalink | Log in to Reply

      Simple question. Is there an approved design for the post formats UI? Failing that, documentation on what each post format is supposed to do and how it does it.

    • Tom Auger 4:02 pm on April 24, 2013 Permalink | Log in to Reply

      Hi Jen, thanks for this post. I also agree the the current UI is confusing, but I also really like it, AND I also agree with others who point out that changing a post format once the post has been started can be a Bad Idea. Our UI should allow, but not facilitate any workflow that involves changing the post format after the fact.

      So:
      1. When you create a new Post, the input fields are all greyed out until you select one of the post formats.
      2. Once you have selected a post format, the currently selected post format icon remains lit up, and aligned to the left, just above the title. The remaining post format icons collapse under (and behind) this icon – in other words, they disappear.
      3. Where the strip used to be, we now have the text that says “Change post format”.
      4. Clicking this link invokes some kind of confirmation that essentially says “data could be lost”.
      5. Clicking the confirmation brings back the Post Formats ribbon, while greying out the other input fields again.

      The only thing I don’t like is if you want to just get in and write a Post post, you still have to click on the “Post” format icon before you can get started. One solution would be to enable a third-level flyout on the “New Post” menu item that lists miniature versions of the post format icons, so you can jump right into creating the type of post format you want.

      • Mark Jaquith 7:05 pm on April 24, 2013 Permalink | Log in to Reply

        Clicking this link invokes some kind of confirmation that essentially says “data could be lost”.

        It isn’t lost, actually. I don’t know if that changes your thoughts on anything. Whether or not the choosing UI should be always visibile is pretty much the last big decision to be made.

        • mindctrl 9:55 pm on April 24, 2013 Permalink | Log in to Reply

          The old UI was always visible. That’s not to say the new one has to follow suit, but the current sliding out of view is awkward. I’d prefer it stay visible, highlight the current selection (color icon for active?), and ditch the “change format” text link (which BTW is disconnected from the previous format choosing location).

          To repeat an earlier statement about image post format, the “Link URL” box is confusing at best. Nothing there that suggests “this is the place your image will link to”. Also, I’d guess that most people will be interacting with the media library “Select/Upload Image” far more than the “Image HTML or URL” box. Something should be changed there. The latter is far too prominent, imo.

          The “Image HTML or URL” box is very large, almost suggesting more than one URL can be pasted. However it doesn’t work if you try it. But more importantly, if you paste a long URL and decide to erase it and replace it with another, the box totally disappears. (I should add this to Trac).

      • Brent Logan 8:29 pm on April 24, 2013 Permalink | Log in to Reply

        I disagree that changing post formats is a bad idea. I use post formats and change formats *all the time.* Here are some examples:

        1. An image in the post becomes the point of the post so it changes from standard to image.
        2. An aside becomes a status and maybe back again. (I have changing definitions, for what is what.)
        3. A gallery gets culled to a single image.
        4. A standard becomes a quote.

        It’s really no big deal to change formats. At least, it shouldn’t be. The tabbed interface used by FavePersonal is easy to use, shows the current format, and makes it easy to switch between formats. http://crowdfavorite.com/wordpress/themes/favepersonal/

        Sure, not everyone is going to want or use post formats. Give them an option to hide the UI. But for those of us who are waiting for this, make it easy to switch, please.

    • Franz Josef Kaiser 4:31 pm on April 24, 2013 Permalink | Log in to Reply

      After reading that MP6 will be integrated/finalized for WP 3.7, I can’t understand why the post formats UI was ever proposed for 3.6. When we already got a new UI in the line, why not introduce new features right when we got it? Would lower the needed UI work, would integrate better, would be more consistent.

      For now just pulling the UI (or post formats completely) out of core and delivering it as plugin that “does phone home” to provide feedback sounds like the only right decision. +1 for that idea.

    • mor10 6:26 pm on April 26, 2013 Permalink | Log in to Reply

      I just demoed the current iteration of the Post Formats UI to someone unfamiliar with WordPress but familiar with online publishing applications in general. This is what he said:

      “Based on the UI, my assumption would be that I could write an article and when I wanted to insert an image, a quote, a gallery, a video, or whatever, I just hit the appropriate button above and the fields that show up allow me to do that. What actually happens is not at all what I anticipated.”

      I think there are several issues with the way Post Formats have been implemented in general and how they are presented here, but the most important thing right now is that there is an assumption new users will automatically know what post formats are. The way they are presented doesn’t give any indication of what they are or how they work, and the interpretation of my friend is far more intuitive than the one being assumed by proponents of the current UI.

      • Matt Mullenweg 12:17 am on April 27, 2013 Permalink | Log in to Reply

        I was thinking about this a lot yesterday, and it could actually be an interesting approach to a next-gen editor if you think of a post as a series of blocks some of which are full-width and some of which are pulled to the left or right with the text flowing around them. These blocks could be a quote, image/caption, video, gallery of several images, slideshow… with the first two covering 95% of what frustrates people when trying to “lay out” posts. Imagine it a bit like the Storify creator, or a TGD story, or post on Joen’s blog, though there’s probably a better example of what I’m talking about out there somewhere.

        • Mike 8:26 am on April 27, 2013 Permalink | Log in to Reply

          There are quite a few “block” CPT plugins (or one could roll his/her own CPT) and with the Display Posts Shortcode plugin (for example) it is easy to insert these into posts.
          Another option is to go back one step to the Media CPT features and re-design the approach to inserting media elements into posts. This would extend existing core technologies that already offer quite a bit and preserve workflow traditions.
          It comes down to what is desired out of the box. I like Beta 1 with a settings option to disable the new GUI (similar to turning off the Tool Bar).
          While it’s not perfect (what is?) it would be great to take an holistic approach to an overhaul of the edit post page that re-examines what’s there and reconsiders how to approach extensibility going forward.

        • mor10 6:06 am on April 28, 2013 Permalink | Log in to Reply

          I recently worked on a site where we did something very similar: instead of displaying images, video, and audio mixed in with the content, these elements were pulled out and placed in the area usually used for the sidebar. It worked especially well with image galleries because it allowed us to display the images in larger sizes with full captions. There is something there for sure.

    • Matt Mullenweg 9:16 pm on April 26, 2013 Permalink | Log in to Reply

      I know it’s not fashionable at the moment, but we should include the Press This posting screen in our support for formats if we’re going to do it right in a core release.

    • KirkM 4:59 pm on April 27, 2013 Permalink | Log in to Reply

      As a veteran user of WordPress and chronic (albeit quiet) WordPress beta tester, the only real thing I find confusing about the new post format layout is that there’s nothing there to tell the user what exactly those icons are for. Okay, so it may seem obvious to some but in real use, it ain’t so obvious. But this has already been said.

      From my point of view, some added text, above the post format icons, that simply stated something like “Choose your Post Format” or “Change you Post Format” or simply “Post Formats”. Anything that will tell the user exactly what those buttons are for. You could even add a “Learn More” link after the post format “title” that opens a page in another browser window/tab that briefly explains what each post format does and what it’s used for. But for the now adding description “title” above the post format icons would be enough?

    • paaljoachim 8:40 pm on April 27, 2013 Permalink | Log in to Reply

      I just do not get it. Why of why have multiple post types, when all one needs is one post type.
      There is a toolbar above the content area that the group could have spent time on improving. For adding media there is the Add Media button. Everything else there is the existing toolbar and the toolbar needs improving to make creating and adding content easier and better looking.

      I did see the http://wpusertesting.com/videos/DC7-7.mp4 and totally agreed with how she did things. I do believe that most new users will also create posts in a similar way.

      The more options available the more confusion the result can be. One Page type and one Post type seems like a good option to me, and then make the toolbar for adding/editing content amazing easy to use.

    • ezhil 4:00 am on April 29, 2013 Permalink | Log in to Reply

      The current post format reminds me of tumblr interface. wordpress is mostly used as cms and for regular websites. This post format would typecast wordpress as a personal blogging s/w. i hope we can add a settings option to enable/disable this so that it would be usefull for people who wants it.

    • Jeff Cohan 2:07 pm on April 29, 2013 Permalink | Log in to Reply

      I know I’m late to the party. And all of you probably have more WordPress knowledge in the tips of your pinky fingers than I do in my old brain.

      But here’s my $0.02 on the issue of POST FORMAT CHOOSING/SWITCHING:

      Forget icons. Forget tabs. Put the Post Format options in the “Publish” meta box, after the “Published on” section. Make it work like the “Status” and “Visibility” options: a select menu with an “Ok” submit, which causes the UI to display the pieces appropriate for the selected format. Default (obviously) would be standard.

      For users who don’t know/care about Post Formats (yet), the choosing/switching function would be out of the way. For those who do, they know where to get it.

      There. I said it.

  • Scott Taylor 9:57 pm on April 8, 2013 Permalink
    Tags: Audio, , MediaElement, , ,   

    Audio / Video support in Core 

    Post Formats are a big feature in WordPress 3.6. What you may not know is: there is now native support for Audio and Video in core! There has been great support for embeds by way of WP_Embed and oEmbed providers for a while, but, if you wanted to play an MP3 from your Media Library, you had to install a plugin. Supporting audio and video in core gives bands, podcasters, vloggers, et al the ability to easily and beautifully expresses themselves through sounds and moving pictures without using an external service.

    How does this work?

    At the core of the experience is the fantastic library, MediaElement.js. MediaElement is the facade layer that gives us maximum file support and cross-browser compatibility. While some libraries require a Flash-only solution to make your media work cross-environment, MediaElement lets you use HTML5 audio / video tags in every browser, and, only when necessary, will use a Flash or Silverlight plugin in the background to make incompatible media work. Translation, things like this: <audio> tag works in old IE, Windows Media files work in Chrome.

    MediaElement uses the same HTML markup, regardless of playback implementation, and you can use CSS to skin the players.

    Shortcodes

    MediaElement’s great, but we don’t want to be locked in to one external library forever. Instead of using MediaElement-specific markup everywhere, we expose audio and video markup through shortcodes: [audio] and [video].

    For the following scenarios:

    • I have an old post that has a video in the Media Library attached to it, and I want to use the new shortcode: [video]
    • I have the URL for a video, from the Media Library or external, that I want to play:
      [video src="video-source.mp4"]
    • I have a source URL and fallbacks for other HTML5-supported filetypes:
      [video width="600" height="480" mp4="source.mp4" ogv="source.ogv" webm="source.webm"]

    Same goes for audio:

    • I have an old post that has an audio file in the Media Library attached to it, and I want to use the new shortcode: [audio]
    • I have the URL for an MP3, from the Media Library or external, that I want to play: [audio src="audio-source.mp3"]
    • I have a source URL and fallbacks for other HTML5-supported filetypes:
      [audio mp3="source.mp3" ogg="source.ogg" wav="source.wav"]

    Shortcodes focus on the “what” and abstract the “how.” If you want to use a library that is not MediaElement, you can! Just look at what to filter: here

    Embeds

    There are also new embed handlers for audio and video. Using them is easy as dropping a media link on a line by itself in the editor:

    http://my.mp3s.com/cool/songs/coolest.mp3

I like this song because it is really cool!

    Works for both audio and video with URLs matching the allowed (and filterable) list of extensions (see: here and here)

    Admin

    Using the new post formats UI, it is even easier to get directly at the audio and video in your Media Library. When selecting, the media modal opens to your library, filtered by media type.

    Metadata

    In previous versions of WP, you could upload audio and video, but we were not generating metadata like we do for images. In 3.6, using the getID3 library, we are able to extract data from audio and video like cover art, song length, artist, album, song title, genre, codec, etc. It’s pretty great. We will soon be exposing more of this data in the admin as well, along with inline previews on the Edit Media page:

    Themers

    Themers can get in on the action, too, using structured-post-formats in their theme (Twenty Thirteen is a great place to look). The admin gives users flexibility when associating media with a post. the_post_format_audio() and the_post_format_video() will automagically retrieve and output your media in the front end.

     

    • sourceforge 10:09 pm on April 8, 2013 Permalink | Log in to Reply

      thank you, is this the html5 vid player? looks good, newer java based audio player is also needed, flash is always prone to attacks

    • Manny Fleurmond 10:11 pm on April 8, 2013 Permalink | Log in to Reply

      How does this handle m4a files?

    • Konstantin Obenland 10:59 pm on April 8, 2013 Permalink | Log in to Reply

      The attentive reader might have noticed how the buffer- and play-time-bars in the first and second screenshot have different colors.

      Themes can style these elements of the players. The first example is a screenshot from Twenty Thirteen, with a white buffer bar, an orange play time bar and no border-radius.

    • John Saddington 11:11 pm on April 8, 2013 Permalink | Log in to Reply

      this is fantastic. john dyer’s MEJS is amazing.

    • AK Ted 11:32 pm on April 8, 2013 Permalink | Log in to Reply

      This is great news! Can’t wait for stable to play with, no time atm for beta. :(

      Small grammar correction: “ability to easily and beautifully expresses themselves” (in first paragraph), should be “express”.

    • Michael Beckwith 11:51 pm on April 8, 2013 Permalink | Log in to Reply

      That’s pretty hot

    • Ipstenu (Mika Epstein) 1:07 am on April 9, 2013 Permalink | Log in to Reply

      What’s the fallback? Like if I use and they don’t allow for HTML5 (yes, I have people who don’t), what shows? Right now I made an html5video shortcode that has, at the bottom ‘Can’t see a video? Click here…’ and it defaults to the MP4.

      • Scott Taylor 2:47 am on April 9, 2013 Permalink | Log in to Reply

        I am pretty sure MP4 will win and play via Flash. If no flash and no HTML5, there will be a link that goes straight to the file.

    • Jon Brown 1:09 am on April 9, 2013 Permalink | Log in to Reply

      Not sure how I missed this on trac, but “YAY!!! & Oh No!!!!”.

      I just spent a month (not continuously) trying to figure out why MediaElements.js conflicted with Soliloquy (Flex based Slider) when both appeared on the same page on mobile. Only on mobile, everything worked fine everywhere else. I finally gave up, ditched ME.js for Video.js.

      I’m now about to test that site on 3.6 just out of curiosity as to what happens.

      I too really dislike this using shortcodes and my bigger concern is what this does to other plugins that use the shortcode already.

      Always seemed to me WP ought to follow best naming practices and use [wp_gallery], [wp_video], etc…

      • Jon Brown 1:26 am on April 9, 2013 Permalink | Log in to Reply

        That was easy to test… still conflicting somehow. I’ve let Thomas know with urls to dev/staging/live servers showing it all. It’s really bizzare that it only happens on mobile browsers (iOS chrome and safari) anbd throws no errors. Either works fine on it’s own, and we’ve recreated it on vanila WP running 2010.

    • Beau Lebens 1:42 am on April 9, 2013 Permalink | Log in to Reply

      <3

    • Tomas 4:01 am on April 9, 2013 Permalink | Log in to Reply

      WoW! This is good news!

    • Robert Chapin (miqrogroove) 1:48 pm on April 9, 2013 Permalink | Log in to Reply

      That’s hot! :D

    • redwallhp 10:35 pm on April 9, 2013 Permalink | Log in to Reply

      Awesome! The assimilation of the Crowd Favorite post format UI and MediaElement.js support in one version.

    • Frank 10:46 am on April 10, 2013 Permalink | Log in to Reply

      Yeah, this is cool. And I miss some important points to have this as a useable feature for real blogger’s life: mejs is out of the box not resonsible and this allone makes the joy half at the first glance. Yes, there is a dev’s tip for videos out there, that, if you set the width to “100%” it will work. And it does, indeed! Maybe this width issue of mejs videos should go into core?

      Responsive mejs audio seems to be more complicated. A simple width attribute setting does not work. At this time the width of the audio bar overlaps the standard width of 480 even in modern smartphones.

      Regarding video: the poster attribute of the shortcode is rather important, since it leeds to a screenshot like above, showing this nice preview picture for the video – but it’s not as easy to implement as it looks like. If you take an image from the media library with its predefinded sizes, it is to small or you’ll have an overlapping picture. For me setting the CSS class “mejs-container” to “overflow: hidden;” seems to resolve the issue as a quick hack.

      I think, the feature of having core supported video and audio is great, and it should be delivered in a way, that avoids frustration of users. The poster feature for videos is essential I think, the contra responsive issues should disappear as well.

      Keep up the good work!

    • Eric Andrew Lewis 11:18 am on April 10, 2013 Permalink | Log in to Reply

      Totally wow.

    • hearvox 12:22 am on April 11, 2013 Permalink | Log in to Reply

      any hooks yet for skinning the default MEjs player?

    • rilwis 2:22 pm on April 11, 2013 Permalink | Log in to Reply

      This feature is really great and useful for all people. I’ve been using MEjs and it’s really great. Nice UI, great support.

    • johndyer 10:48 pm on April 11, 2013 Permalink | Log in to Reply

      So glad to hear it! Glad to have “contributed” :)

    • Maor Chasen 6:15 pm on April 12, 2013 Permalink | Log in to Reply

      Love!

    • Anderton 9:06 am on April 15, 2013 Permalink | Log in to Reply

      Have been playing around with it while developing a couple of themes for 3.6. It’s lovely, and easy to style. Have been using MediaElements,js before, and when i found out that it would be included in the Core, i was thrilled. Good move!

    • Bjarni Wark 10:25 pm on April 16, 2013 Permalink | Log in to Reply

      Really good news, thanks for the efforts of making this happen.

    • Maeve Lander 4:58 am on April 17, 2013 Permalink | Log in to Reply

      Just wondering how will this affect existing audio/video plugins? Any potential problems, conflicts, things plugin developers could do better to integrate with this etc?

    • esmi 7:49 pm on April 17, 2013 Permalink | Log in to Reply

      I have to say, I’m really disappointed that there’s no mechanism for people to add captions for videos or provide text transcripts with audio files. come on, people! We need to be encouraging people to do this kind of stuff but unless WordPress provides the methods, it just won’t happen.

      • Scott Taylor 7:57 pm on April 17, 2013 Permalink | Log in to Reply

        #patcheswelcome

      • Ipstenu (Mika Epstein) 8:18 pm on April 17, 2013 Permalink | Log in to Reply

        Speaking as someone totally ignorant of this, how DO you add captions to videos? Can I include a transcript.txt file like I do for different video versions?

        • Joe Dolson 11:26 pm on April 17, 2013 Permalink | Log in to Reply

          There are various formats for captions, but yes, essentially it amounts to referencing a text file with captions. Mediaelement.js supports .srt and .vtt caption formats, and they’re referenced as

          In this context, you should treat the terms ‘subtitles’ and ‘captions’ synonymously, although technically they are different.

          All the WP system needs to do for captions is provide a mechanism to upload them and auto-generate the relevant track elements, basically.

    • esmi 8:11 pm on April 17, 2013 Permalink | Log in to Reply

      We’ve only just picked this up in the make.wordpress.accessible group but, yes, we will be trying to come up with some patches if we can :)

    • FranciscoAMK 8:19 pm on April 21, 2013 Permalink | Log in to Reply

      Is the featured image set as the “poster” for the video post format?

  • Lance Willett 6:37 pm on April 8, 2013 Permalink
    Tags: , ,   

    We love testers

    We’d love more people to install Twenty Thirteen, with special emphasis on trying out all the new Post Format features.

    Also, if you have access to Windows with various versions of Internet Explorer we especially need help testing out some IE8 and IE10 issues (see Trac list link below).

    Priorities

    • Address open tickets in Trac, fix bugs and make improvements
    • More browser, device, RTL, and i18n testing
    • Post formats testing. For example, looking at the output from post_formats_compat(), making suggestions like Image should use wp_get_attachment_image() there for filters and correct core class attribute values in the resulting HTML.
    • Review and possibly refactor the js/functions.js JavaScript file, going to all procedural/functional or moving to a new architecture—the key is to be consistent with it within the file. We can also look at namespacing the events.
    • Ask Joen to do another design audit, checking versus his design vision for things like spacing, colors, and post formats.

    Office hours

    We’ll get back to office hours in #wordpress-dev IRC over the next few weeks, Tue and Thu at 17 UTC.

     

    • celloexpressions 1:40 am on April 9, 2013 Permalink | Log in to Reply

      Can’t make it to the office hours, but want to point out a couple more IE 8 issues that may or may not be ticket-worthy. The headings are displaying in Georgia font, but Bitter should work for IE 8. It’s fine on 9 and 10.

      Also, the header image is zoomed in in IE 8. See both issues in these screenshots (emulating 8/9 with 10): http://celloexpressions.com/nh/twenty-thirteen-fonts-ie8.png, http://celloexpressions.com/nh/twenty-thirteen-fonts-ie9.png.

      By the way, is IE 7 supposed to be supported/should it be tested?

    • ziegenberg 3:00 pm on April 9, 2013 Permalink | Log in to Reply

      Here’s a WP 3.6 with (slightly altered – just colors) Twenty Thirteen. Working great so far!

      http://zubau.at

      • Lance Willett 9:53 pm on April 10, 2013 Permalink | Log in to Reply

        Thanks for the link—cool color scheme! I’m seeing a few bugs in the comment form layout, though. Will need to debug and fix soon.

    • lisafirke 2:20 pm on April 15, 2013 Permalink | Log in to Reply

      Love the brave new look of TwentyThirteen– I’m working on a child theme for my personal blog… (It’s live but on the QT so I’m not too worried about glitches at this point).

      A few issues I’ve seen… with the fixed navbar, the header image I hacked/inserted into the masthead overlays and hangs below the bar. I know I can turn this behavior off by commenting out the JS but it may be an example of a use case that your more dive-into-the-code users will encounter. (I wanted that image to scale, which is why I inserted it as I have…)

      Other notes: I couldn’t get the JetPack carousel to work with the gallery post format as it does on the demo. Not sure if I just missed a step or if it’s not hooked into the theme correctly.

      The Status post format looks odd with an image floated left on the post… I nixed the background dotted line, but the Genericon (or whatever is producing the horizontal bar glyph in place of the title) is kind of distracting, too.

      Here’s the link: http://lisafirke.com/blog

      Looking forward to rolling out the finished version with much fanfare…

      • Lance Willett 5:38 pm on April 15, 2013 Permalink | Log in to Reply

        Hi there, and thanks for your notes. The fixed navbar + inserted HTML image isn’t a bug we’ll fix in the core theme—that’s a great example of child themes adjusting and changing how the core theme works.

        We’ll investigate Jetpack Carousel and the Status post format left-aligned image a bit more.

        • Lance Willett 5:29 pm on April 16, 2013 Permalink | Log in to Reply

          Lisa: can you give more info on the Jetpack Carousel issues you had? I couldn’t repeat—seems to be working normally with all the various “types” of galleries in Jetpack.

          • lisafirke 9:12 pm on April 16, 2013 Permalink | Log in to Reply

            See my notes below. I think it’s a jquery/Jetpack glitch of some kind, because others are reporting similar issues with Jetpack.

            The main thing is, with Jetpack enabled, I’m still not seeing any formatting options for the carousel–I only have the ability to toggle from slideshow to grid on a gallery post.

            • Jeremy Herve 10:29 am on April 17, 2013 Permalink

              You’re probably right. We know of some conflicts between jQuery 1.9.1 and Jetpack Carousel, and we”ll get this fixed before 3.6 ships.

              See this ticket for more details about the conflict.

      • Lance Willett 4:40 pm on April 16, 2013 Permalink | Log in to Reply

        Hi again Lisa, to get rid of the horizontal bar glyph for Status posts, look for:

        .format-status .entry-content p:first-child:before

        And either change or comment it out in your child theme.

      • jrbeilke 5:28 pm on April 16, 2013 Permalink | Log in to Reply

        lisa was there a specific browser that you were having trouble with the JetPack carousel?

        I’ve got 3.6 beta on my blog and loaded up a carousel post with JetPack slideshow ok.

    • lisafirke 7:25 pm on April 16, 2013 Permalink | Log in to Reply

      I’m using Safari and the latest beta build. I fixed a javascript error that was preventing the slideshow from running, but I don’t see any way to enable a full-screen slideshow. Here’s my test post: http://lisafirke.com/blog/2013/carousel-test/

      • lisafirke 7:29 pm on April 16, 2013 Permalink | Log in to Reply

        I’m thinking the problem lies with Jetpack and not with TwentyThirteen?

        • lisafirke 8:18 pm on April 16, 2013 Permalink | Log in to Reply

          I disabled my test, so don’t bother clicking through. Only the background color and exif field data items are getting displayed as configuration options–and in the media ui no choice of carousels or any other configurables beyond “slideshow” versus “grid”.

    • Ipstenu (Mika Epstein) 8:02 pm on April 16, 2013 Permalink | Log in to Reply

      There are posts in Alpha/Beta about 2013 – http://wordpress.org/support/forum/alphabeta

      (look for the ones that aren’t resolved)

      • Lance Willett 8:55 pm on April 16, 2013 Permalink | Log in to Reply

        Thanks, triaged 3 of the unresolved ones (1 was not related to Thirteen specifically).

        • Ipstenu (Mika Epstein) 9:58 pm on April 16, 2013 Permalink | Log in to Reply

          Shirley :) Is there a good way to report them or flag them for you? I don’t know enough about what is and isn’t a theme decision (seriously, I hate debugging themes!) to feel comfortable raising tickets.

          Also if you’re not a forum mod, I’ll make you one so you can resolve those posts too ;)

    • Jeremy Herve 10:37 am on April 17, 2013 Permalink | Log in to Reply

      As discussed yesterday during office hours, I tested 2013 against Jetpack Trunk, and found 2 issues, that we will have to fix in Jetpack before 2013 is released.

      Infinite Scroll seems to work fine, whether you use footer widgets or not. All widgets seem to be displayed properly, although I haven’t tested in IE.

      No problems with post formats either. There were some conflicts between Jetpack Shortcodes and the new Audio shortcode, but it was fixed in r696694-plugins.

  • Lance Willett 9:09 pm on March 26, 2013 Permalink
    Tags: , ,   

    Twenty Thirteen project update, March 26, 2013 

    Our focus right now is on post formats integration, both structured (formats with post meta) and “normal” output for the other formats.

    Priorities

    1. Work with Post Formats team to get the_video(), the_audio(), and the_image() functions into core, so we can avoid a ton of extra logic in Twenty Thirteen’s functions.php file to grab the first asset for a format. Making it easier for *any* theme to get the same data back and keep their template files simpler. Themes should not have to parse shortcodes or try to make something run through oEmded before display.
    2. Work with Post Formats team on post_formats_compat() functionality, improving Quote markup and filling in the gaps for other formats. Obenland is going to work on a patch for this.
    3. Image: we need clarification from 3.6 leads and Post Formats team on whether it is going to be structured or not (post meta) and it needs more work for the post-media functions (see 1 and 2 priorities above)
    4. Finalize each post format in Twenty Thirteen: what template HTML or PHP it needs, what it needs from core functionality to work correctly

    By post format

    Here’s a breakdown per format, per today’s discussion (IRC log).

    • Standard: good to go
    • Aside: we remove the title from the PHP template, added styling; non-structured
    • Chat: IHNIWIGOWTPF (see IRC log, hehe); non-structured
    • Gallery: we use a bit of PHP to remove default gallery styles, and we use a filter to change the image size to large on index view, then add a bit of CSS fanciness to change the first image to “bigger” size, 300×300 (single view is not changed other than to align the columns); non-structured
    • Link: structured, we use get_the_url() wrapped in our own fallback to output permalink if no URL is found
    • Image: right now it works OK without any changes, but the design calls for the image to be above the title, which means we need a way to pull out the first image, and have the_content() be output without that image; also filter content_width to 724 for this format (small issue with that reported in #23863). Seems like the best approach here is to use a custom image size to grab an exact 724 px wide image (unless it’s smaller that 724, in which case we grab the largest available). Ideal: a user uploads an image, adds it to the post content at exactly 724 from the Media editor, then the_image() outputs the exact HTML img tag + attributes.
    • Quote: structured; currently we rely on people using blockquote correctly in the editor, and style it with CSS; after Obenland’s patch to Quote markup (noted above in priority 2) we’ll add CSS support for the structured HTML markup, and leave in the basic styles in case someone uses post content anyway
    • Status: similar to Aside
    • Video: structured; we filter content_width to 724 to allow the video to be wider than the rest of the content area; needs the_video() to return the HTML output of first video and remove the same from the post content
    • Audio: structured, we’re leaning towards using the post format compat output instead of a custom structure in the theme; needs more testing but seems to be working OK as-is right now
     

  • Lance Willett 7:32 pm on March 19, 2013 Permalink
    Tags: , ,   

    Twenty Thirteen project update, March 19, 2013 

    We’re in great shape to get to beta. Here is what we’re working on right now.

    Blocking older installs

    Tracked in #23819 — since Twenty Thirteen is 3.6+ only, older installs could see errors. We’d like to come up with a graceful way to not allow older versions of WordPress to install and run Twenty Thirteen.

    Maybe a nag function in the theme that puts up a warning? Forcing a change the previously activated theme upon activation? What are your thoughts?

    Relates to #13780 also.

    Post formats integration

    See #23619, #23620, and #23621 — we are waiting on the core functionality to be committed before we can change the theme code (images, videos, galleries, links).

    Recently completed

    • HTML5 improvements to comment list, comment form, and search form (yay!) #22005, #23702, and #23701
    • Solidify footer positioning when no JavaScript or no Masonry script available: #23771
    • More gallery visual fixes: #23773 and #23769

    Open issues

    Here is a link to open tickets.

     

    • Rami Yushuvaev 8:22 pm on March 19, 2013 Permalink | Log in to Reply

      Great work lance.

      But regarding to search forms, seems like you didn’t addressed the old discussions on tickets #14581, #19321, and #19579.

    • chp2009 10:49 pm on March 19, 2013 Permalink | Log in to Reply

      I think putting up a nag function that can only be seen by a user with admin permissions is a great idea. As a matter of fact only a user with admin permissions should be able to see errors related to the administration of the website. It creates a better user experience.

    • chacha102 5:04 am on March 23, 2013 Permalink | Log in to Reply

      Plugins can deactivated themselves if they know their requirements aren’t met. There needs to be a precedent set for how theme’s who requirements haven’t been met can ‘deactivate’ themselves.

      I think that the result of a theme ‘deactivating’ itself should cause the same result as if the theme suddenly was removed. I believe right now it defaults to the default theme in WordPress. I would argue doing anything different then that creates an inconsistent error scheme.

      • Myatu 11:19 am on March 23, 2013 Permalink | Log in to Reply

        If there was a way to track which theme it switched from (active before trying to activate this theme), then one could simply revert the action. That would be the safest method, as it does not alter the website in any way (ie., theme specific customizations, etc).

        • Myatu 11:25 am on March 23, 2013 Permalink | Log in to Reply

          Having that said… Why not include this sanity check within the WP core itself, for both plugins and themes. Just give add two extra meta headers to the plugins/themes for the minimum WP and PHP versions, and add a little extra code that checks against these prior to activation. That would be a useful feature that could benefit many. #thinkingoutloud

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

          See #13780 for the WordPress version requirement support.

  • Helen Hou-Sandi 7:49 am on March 15, 2013 Permalink
    Tags: ,   

    Post Formats UI Update, 3/14 

    As noted in The Road to 3.6 Beta 1, we’ve got quite a bit going on for post formats. Many of the tickets are in need of testing (including unit tests) and then a commit. As always, there are a few different fronts: UI/administration, data, and parsing. Here’s where we are with each, and what needs to get done. There’s a large variety of tasks here, and we are seeking contributors to help :)

    (More …)

     

    • Luke Gedeon 3:32 pm on March 15, 2013 Permalink | Log in to Reply

      “Add New Post: Status” in the refreshed layout wireframes shows permalink above status field (Hey User, what’s up?) and has no title. As a user, having the status field above permalink feels more natural.

      As a dev, I wonder if we could use the Title field to capture the status instead of a custom field. This would allow normal processing to generate the permalink and put the order of fields into something closer to what a user might expect.

      When generating output for a status it “might” be preferable to hide the title even in themes that don’t recognize post formats. If that is case, core could return an empty title and the status stored in title as content. My preference would be to receive the status as a title anyway, since that would look best in most themes I have looked at.

      • Helen Hou-Sandi 7:13 pm on March 18, 2013 Permalink | Log in to Reply

        Status is not a custom field – it’s post_content. I don’t think we’re going to be able to get so adventurous with the status format edit screen layout – it’s quite likely that it’s going to just look the same as aside – title optional (toggle or otherwise), regular editor area. I also don’t think core should just turn titles off in a theme – that’s completely up to the theme to decide. A theme may very well use the_content in a way that looks like a title – 100% presentation layer, not data.

    • Dravel 5:27 pm on March 15, 2013 Permalink | Log in to Reply

      As a regular “John Doe” user of WordPress I must say that the plan of ditching the tabs in favor for the drop down thingy from @lessbloat is a major disappointment. The tabs were a new fresh style (needed one to) to a stale design part of post area itself.

      Reverting to a style that best described as 1995-ish when we are in fact roaming in the year 2013 is a huge step back, not to speak of the user unfriendliness the current iteration presents (http://make.wordpress.org/core/2013/02/22/post-formats-ui-update-221/#comment-8182), that little blob before the “Enter title here” does in no way even hint that there’s option’s lurking there. As a blogger I want it easy and straight forward, not guessing around before I can actually start to write my things.

      The tabs were ok and had a fresh thing to it, shoot even a vertical row of the icon’s made by @melchoyce with a sub title “Post Format” as a <h2> heading right under the “Enter title here” is way better than a obscure drop down thing, especially from a user friendly point of view.

      Just 0.2 cent from a regular John Doe user

      • Helen Hou-Sandi 7:18 pm on March 18, 2013 Permalink | Log in to Reply

        There are a lot of problems with the tabs interaction-wise. They are not adaptive to screen widths, especially smaller ones, incorrectly represent selecting a format as a primary action when in reality it is one that is performed once and then left alone, and they cause confusion among users, both “regular” and ones we tend to think of as knowing better (like the very people writing patches). Some users interpret the tabs as needing to fill out all of them rather than making a generally-one-time choice that sticks, and yet others saw ones like “Audio” and “Video” as being points for inserting media into their content. We have a lot of exploration to do, but tabs are definitely not it. Again, I regret having put them in even as temporary UI – the distraction caused has been a bit time-consuming to respond to.

      • jltallon 1:00 pm on March 20, 2013 Permalink | Log in to Reply

        From another “John Doe” user (+developer +project manager):
        @lessbloat‘s proposal at the URL below is right on: discoverable, intuitive, unintrusive, practical… good.

        Though I’m a bit wary of content parsing, I trust you to get it right, and the “teeny” mode will be of much help in guiding the users along the right way (input the “correct” content). Less meta is good for performance, too.

        0.02€ from me :)

    • Hugh 9:25 pm on March 15, 2013 Permalink | Log in to Reply

      I’m a lurker, but can someone point me to a post or discussion on the history of post formats? I am curious to know why the post formats for audio and video are not separate content types. – I’m sure there is some good thought behind this but being newish I’d just like to read why it is the way it is.

      • Helen Hou-Sandi 7:22 pm on March 18, 2013 Permalink | Log in to Reply

        I suppose the Codex has some information about what post formats are: http://codex.wordpress.org/Post_Formats, notably “A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post.”. Separate content types (post types) would not show up in a blog archive by default and are not posts, whereas these are supposed to be posts that just happen to contain audio or video (or quote, image, gallery, chat transcript, or link). Think of post formats as a way for users to structure/think about the content of their blog posts and as a way for theme devs to be able to customize the presentation layer of a given format.

    • WraithKenny 8:38 pm on March 18, 2013 Permalink | Log in to Reply

      “…what it means to re-initialize TinyMCE…” Is there a ticket or comment on which scenario would require TinyMCE to be reset?

    • Scott Taylor 10:22 pm on March 18, 2013 Permalink | Log in to Reply

      I am on a plane home from my Mexication – I am going to refresh my patches tonight, based on the fact that #23282 finally landed (editors note: woo hoo!). The patch on #23282 had some new functions (`has_shortcode()`, `shortcode_exists()`, `get_tag_regex()`, et al) that were present in ~5 different patches. Will also streamline any dupe’d code elsewhere among the patches that haven’t been committed. That being said , #23673 should be the next one to go in.

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

  • Lance Willett 10:12 pm on March 12, 2013 Permalink
    Tags: , ,   

    Twenty Thirteen project update, March 12 2013 

    This week we are closing as many open issues as possible to prepare for code freeze.

    Blockers

    Here are the current blockers to getting to a code freeze tomorrow, as scheduled:

    • Post formats: #23619 #23620 #23621 — waiting on the core functionality to be committed before we can change the theme code (images, videos, galleries, links)
    • #15080: Comment form HTML5 input types — just needs a commit
    • #20088: Improve wp_list_comments() markup — needs a code review from core team dev, then commit

    Recently finished

    Open issues

    Here is a link to all remaining open tickets.

     

    • RDall 10:22 pm on March 12, 2013 Permalink | Log in to Reply

      Oh my… I don’t think I have ever seen the default gallery so uber cool as I have in Twenty Thirteen…

  • Lance Willett 11:57 pm on March 4, 2013 Permalink
    Tags: , ,   

    Twenty Thirteen project update, March 4 2013 

    What we worked on last week

    Lots of fixes and improvements went in — thanks to everyone who reported and patched and tested.

    Bigger items discussed:

    1. Fixing the sidebar (including discussion of dropping it completely). We decided to just swap primary and secondary sidebars for now. See #23644.
    2. Remove fixed navbar for mobile — yes, let’s remove it. See #23647.
    3. Keep fixed navbar for desktop for now, but next step is to switch site title to menu there, try that out.

    IRC logs: Tue Feb 26 2013 | Thu Feb 28 2013

    What we’re doing this week

    More work on open tickets.

    Big items to tackle next:

    • Post format support: #23619 #23620 #23621
    • Sidebar / footer clearing, still no perfect CSS-only solution. JS techniques are next. See #23557.
    • Gallery styles: portrait sized images, #23649 — and caption styles, #23584.

    Non-theme tickets that affect Twenty Thirteen’s progress:

    • #15080: Comment Form Should use HTML5 input types for better accessibility
    • #15081: Search Form should use type=’search’
    • #20088: Improve wp_list_comments() comment markup

    Want to get involved?

    View open tickets.

    Join us in IRC during office hours and we can get you started on a ticket or task.

     

    • Monika 12:06 am on March 5, 2013 Permalink | Log in to Reply

      if a comment author is the post author his authorlink has “rel external and nofollow”,
      but his link is to the author page of the site, why rel external and why nofollow, no internal links should be nofollow,
      I ask this myself all the years ;)

    • RDall 5:05 am on March 5, 2013 Permalink | Log in to Reply

      I will try to get to the IRC during office hours… I just downloaded Twenty Thirteen Yesterday to my dev build. I am not a fan of the fixed nav bar… I understand I could make a child them to alter this… But it just looks odd… Take for example a 17in monitor without widgets. http://cl.ly/image/3K303B150131 I know I am late to the game… I know this has been previously discussed… Not asking to rehash something again… but just to give my “2cents” even if abet a bit late…

    • Maor Chasen 7:44 pm on March 7, 2013 Permalink | Log in to Reply

      Ha! The GIF on #23647 is a killer!

← Older posts

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