Make WordPress Core

Updates from January, 2013 Toggle Comment Threads | Keyboard Shortcuts

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

  • Helen Hou-Sandi 8:56 pm on February 22, 2013 Permalink
    Tags: ,   

    Post Formats UI Update, 2/21 

    First run commit, mostly for soaking of functionality, went into trunk on Monday. This includes fallback output for theme compat and fields in the admin. The admin UI does not represent anything final – especially of note is the tabs, which are essentially the way they are in order to reuse CSS and avoid adding temporary code to core.

    (More …)

     
    • Beau Lebens 10:59 pm on February 22, 2013 Permalink | Log in to Reply

      Also of interest is #23282, which adds audio and video players to core to handle those post formats (and optionally be used anywhere else).

      • Helen Hou-Sandi 12:53 am on February 23, 2013 Permalink | Log in to Reply

        Good call, I keep forgetting to loop back to that.

      • Harish Chouhan 7:30 pm on February 23, 2013 Permalink | Log in to Reply

        Is it final that mediaelement would be used?

      • Anointed 2:50 am on March 7, 2013 Permalink | Log in to Reply

        I’m hoping that other systems other than medialementjs will be considered. Another ‘top” Option is definitely mwEmbed by Kaltura https://github.com/kaltura/mwEmbed

        • Helen Hou-Sandi 2:52 am on March 7, 2013 Permalink | Log in to Reply

          Licensing?

          • Anointed 3:02 am on March 7, 2013 Permalink | Log in to Reply

            All mwEmbed code is released under the AGPLv3 unless a different license for a particular library is specified in the applicable library path

            *I’m sure it could be adjusted if necessary

          • Anointed 3:05 am on March 7, 2013 Permalink | Log in to Reply

            Also, spend a few mins on the git site. Check the level of work put into this project over the years as one of the top active code sets on git. Then do a little digging into who kaltura is, (if you have watched a movie on an airplaine in the last few years, then odds are, it was built by kaltura). Bottom line, kaltura is one huge beast that would benefit both WP and Kaltura.

    • Harish Chouhan 6:54 pm on February 23, 2013 Permalink | Log in to Reply

      Just a question,
      For the meta field Image, will only attachment ID work, or if in a theme we are saving URL of the image in the “_wp_format_image” field, once WP 3.6 is released, will it work?

      • Helen Hou-Sandi 6:58 pm on February 23, 2013 Permalink | Log in to Reply

        A URL will work – the media modal just hasn’t had that panel added yet.

        • Harish Chouhan 2:07 pm on February 26, 2013 Permalink | Log in to Reply

          @helen,
          Currently the URL field for formats such as Link, Image & Quote is saved as _wp_format_url. Is this approach final? Or there is still chance of this being changed?

          • Helen Hou-Sandi 3:02 pm on February 26, 2013 Permalink | Log in to Reply

            It shouldn’t really matter to you if the meta key name changes or not – we’ve already introduced get_post_format_meta() as a helper retrieval function. It might be helpful if you could explain why you are asking these questions.

            • Harish Chouhan 6:16 pm on February 26, 2013 Permalink

              Hi Helen, since a year or more I have been using CF-Post-Format plugin which has different URL meta fields for Link & Quote format. I run a WordPress network and to avoid changes to my new themes in future, I am trying to follow the meta_key name based on WordPress 3.6. This will ensure I just have to remove the plugin when 3.6 is released.

              I also wanted to make a suggestion about Gallery meta box. Can you please let me know the best place to make that suggestion?

            • Helen Hou-Sandi 6:22 pm on February 26, 2013 Permalink

              We’re in active development – I would not change anything you are currently doing yet. You can make your suggestion here or on #19570.

    • rudwolf 3:41 am on February 25, 2013 Permalink | Log in to Reply

      Is there any planning to make filter and action hooks so we could be able to create our own new types of posts?

    • Lance Willett 6:00 am on February 26, 2013 Permalink | Log in to Reply

      I added a bunch of related tickets to for the default themes:

      Twenty Ten: gallery post format – #23617
      Twenty Eleven: gallery post format – #22907
      Twenty Eleven: link post format – #23618
      Twenty Thirteen: link post format – #23619
      Twenty Thirteen: video and image post formats – #23620
      Twenty Thirteen: gallery post format – #23621

      Seems like only Twenty Thirteen will need add_theme_support( 'structured-post-formats' ); at this time.

    • lessbloat 6:35 pm on March 4, 2013 Permalink | Log in to Reply

      Played with another design for the post formats selector this morning.

      Have a look:

      On load
      Active
      Formats without a title

      I figured it would be fairly discoverable, much less in your face than tabs, and work well for accessibility.

      Thoughts?

      • Seth Rubenstein 8:54 pm on March 6, 2013 Permalink | Log in to Reply

        I’m a fan. Agreed, much less in your face than tabs. Discoverable but out of the way.

      • mattyrob 8:57 pm on March 8, 2013 Permalink | Log in to Reply

        +1 from me for the cleaner interface. The tabs take way too much screen space and will surely just irritate bloggers who don’t use this aspect of WordPress.

    • Drew Jaynes (DrewAPicture) 6:49 pm on March 5, 2013 Permalink | Log in to Reply

      I really like this a lot. It fits with the existing UI much more seamlessly and it’s discoverable enough while not completely taking over the post editor like the tabs.

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

    Screen Shot 2013-02-18 at 5.15.50 PM

    A first draft of the Twenty Thirteen theme is now in core, for your inspection and iteration. See: r23452

    A demo site is available for you to browse.

    @matt set the goals for this theme: a focus on blogging, and great support for post formats (which are getting attention on the backend in 3.6 as well). Under Matt’s guidance,Β @joen explored the artistic possibilities and was joined by @obenland and @lancewillett in bringing it to fruition.

    What you’ll notice first is the colors. Way more use of color than a bundled WordPress theme has had before. Each post format has its own color, so each is distinct, yet they are all complimentary. The bold colors encourage authors to try out all the different formats. This color extends the full width of the window, which breaks your blog up into a lush, segmented timeline. This effect is even more pronounced on mobile browsers, where the screen can be dominated by one or two posts at a time, in all of their chromatic fullness.

    On closer inspection, you’ll notice details, like the font-based icons (“Genericons”, by @joen) that scale up to any resolution or zoom level and can be easily recolored using CSS.

    You may notice some playful details, like the size-offset pagination arrows:

    Screen Shot 2013-02-18 at 4.52.23 PM

    Or the 404 page (which I’ll leave to you to find).

    One of the goals of having a new theme every year was to give ourself room to experiment. That hasn’t really happened. We’ve been far too conservative, trying to make themes that work reasonably well for everyone, but don’t push boundaries too much. That changes with Twenty Thirteen. It’s hard not to have a strong feeling about the theme, one way or another. It defies you to give it a shrug or a kurt nod. Some of you will hate it. And that’s okay. We’ll still be shipping Twenty Twelve, which is an excellent base theme and a canvas on which you can build anything from a blog to a static content site. But with Twenty Thirteen we’re taking a bold stance: this theme was meant for blogging, and it’s not a blank canvas. It comes pre-marinated with playfulness and warmth and opinions.

    Twenty Thirteen really prefers a single column layout. Widgets live best in the footer, where jQuery Masonry bricks them together (but it supports a sidebar, if you really insist). Header images have a fixed width and height, and will be cropped at smaller resolutions, so the best choice is an artistic header where not 100% needs to be shown all the time (it ships with three).

    Now that we have a first draft of Twenty Thirteen in core, it’s time to start iterating and sanding off some of the rough edges. Accessibility is still important, even when making bold artistic statements, and I’d be surprised if we didn’t have work to do there. We’ll need testing on lots of different browsers and platforms, and with lots of different plugins. @helen‘s Post Format UI team will need to give feedback on upgrading Twenty Thirteen to use the new post format API functions that are available.

    @lancewillett and @obenland will be holding Twenty Thirteen office hours on Tuesdays and Thursdays at 1700 UTC. Interested parties should make an effort to attend and help us get this beauty ready for beta!

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

      First impression: WOW

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

      Holy color!

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

      Nice Mark!

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

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

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

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

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

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

      Pretty good for the first draft!

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

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

      Great work!

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

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

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

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

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

      Can’t wait to try it out..

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

      I find that to be just delightful!

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

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

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

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

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

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

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

      Very Nice! Shades of BuddyPress :-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Wow. Bold move, I love it.

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

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

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

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

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

      This. Looks. Awesome.

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

      Excellent work! I love the post formats styles :)

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

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

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

      it looks like Windows8 :-) colorful and dizzying.

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

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

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

      Absolutely beautiful. Good work!

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

      Sponsored by Ubuntu I see…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Love at first sight. :)

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

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

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

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

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

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

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

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

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

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

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

      cool, love it!

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

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

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

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

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

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

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

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

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

      Gorgeous and playful. Bravo!

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

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

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

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

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

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

  • Erick Hitter 4:39 pm on February 7, 2013 Permalink
    Tags: ,   

    Revisions Update, 2/7 

    We started today’s office hours by reviewing @karmatosed’s latest mockups for the revisions screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.

    @westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?

    Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in Core before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.

    For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.

    [IRC Log]

     
  • Aaron D. Campbell 6:09 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: the Post Formats UI feature 

    Post formats is going to be a major win for 3.6. It’s one of those features that has so much potential, but it really falls short in usability and honestly we haven’t really taken the time to truly show what it can do. We’re going to re-think the admin UI for post formats, similar to what Alex King did with his WordPress Post Formats Admin UI plugin. The goal is to make post formats much more user friendly and then show them off with the 2013 theme.

    We’ve chosen @helen as lead for this project. Helen has done some amazing stuff customizing the post screen for various projects, and we’re glad to be able to leverage that for core.

    Anyone interested in helping with this feature, please comment to let us know. The 3.6 schedule is considerably shorter than the 3.5 schedule was, so we really need to get moving on things as quickly as possible.

     
    • Paul 6:15 pm on January 7, 2013 Permalink | Log in to Reply

      take a look at what Hybrid does in its latest release
      http://themehybrid.com/docs/tutorials/post-format-tools

    • Chip Bennett 6:16 pm on January 7, 2013 Permalink | Log in to Reply

      I think standardizing on the Post Formats UI, the types of data/content used for each post format type, and the method of input of those data will be a HUGE win for Theme developers and end users alike.

      The Theme Review Team will support your efforts here. Please keep us in the loop, so that we can update Theme Review guidelines accordingly, and help educate Theme developers regarding any changes.

      I’ll pass the word over to the team, in case anyone wants to contribute specific UI ideas.

    • Jonathan Christopher 6:24 pm on January 7, 2013 Permalink | Log in to Reply

      Really loving the idea of this getting some love for 3.6! Like Alex King’s implementation, will the UI update include customization along the lines of Custom Field storage as well? Thinking specifically about a Link post, will there be a core-defined Custom Field correlated with that? I realize that’s a really specific question so I’ll generalize it by asking if those types of conversations (data storage) will be a part of the UI update?

      • Helen Hou-Sandi 1:46 pm on January 8, 2013 Permalink | Log in to Reply

        Going to stay away from implementation details here, – “just” gauging interest :) Don’t want to have discussion getting buried/lost.

    • nphaskins 6:25 pm on January 7, 2013 Permalink | Log in to Reply

      +1

      Pulling some ideas from Alex’s stuff would be pretty sweet.

      http://alexking.org/blog/2011/10/25/wordpress-post-formats-admin-ui

    • Mike Schinkel 6:28 pm on January 7, 2013 Permalink | Log in to Reply

      I’d love to see the ability in a plugin to move the TinyMCE editor to the bottom of the post screen rather than have it anchored where it has always been. Hopefully addressing post formats would make this a requirement?

      • Helen Hou-Sandi 6:30 pm on January 7, 2013 Permalink | Log in to Reply

        There’s a hook between title and editor as of 3.5. It’s purposefully not a sortables (metaboxes) area, but perhaps it’s at least helpful in that regard?

        • Mike Schinkel 7:14 pm on January 7, 2013 Permalink | Log in to Reply

          HI Helen,

          Thanks, yes I did notice that hook. In part it triggered me to want to be able to move the editor even more. :) Much of the custom post type work I do would prefer to have the body at the bottom vs. at the post. So it’s not really helpful because metaboxes still go below the editor. I can dream? :)

          • Helen Hou-Sandi 2:38 pm on January 8, 2013 Permalink | Log in to Reply

            I guess I find sortable metaboxes above a statically-placed TinyMCE instance disruptive in practice, especially since a user could presumably drag anything into any given sortable area. Since the title is similarly static in placement, it seems sensible that the hook between the two not be a sortable one. I put lots of things in edit_form_after_title, but haven’t (yet) wanted them to be in the metabox “look” or be draggable.

        • Justin de Vesine 9:22 pm on January 7, 2013 Permalink | Log in to Reply

          Speaking of sortables and TinyMCE, we recently needed to handle that gracefully, and we’re doing so by destroying the editor instances at the start of a sort and re-creating them afterwards, which seems to be both stable and reasonably speedy. (See https://github.com/Annotum/Annotum/commit/28f50e13ee00d63edd5563fa00dd45abcacf4e10 for the implementation in the Annotum project.)

          • Vitor Carvalho 4:13 pm on January 8, 2013 Permalink | Log in to Reply

            That is very interesting indeed! It would be nice to have it implemented in future WP. Thank you Justin ;)

        • Vitor Carvalho 4:11 pm on January 8, 2013 Permalink | Log in to Reply

          The problem about TinyMCE is that it cannot be sortable. Once instantiated it cannot be moved through the DOM.

      • Manny Fleurmond 12:13 pm on January 19, 2013 Permalink | Log in to Reply

        Just riffing for a bit: I hope people get what I’m trying to convey:

        So when I look at a post, I see the content data (the title and content), ie the meat and potatoes of a post and I see meta data/ taxonomies that add to the main data to categorize/tag/describe it. The content has is own area and meta data/ taxonomies/ etc are relegated to meta boxes. Looking at the different post format examples from other CMS’s, you are basically changing the type of content and therefore are changing the type of content fields you are using. Video posts may need a title and description, but they also need a video source url. An aside doesn’t even need a title. Post formats are just presets of custom content fields.

        In order to beef up post formats, I think we need to add hooks and an API that allows developers to change the content area of a post; to basically upgrade a few custom fields to content status. Not only should developers be able to add fields that are important enough to be content alongside the post title and post content fields, they should be able to replace those fields entirely, if they so wish. I have a side project where I disabled the title and content, to be replaced by a URL field and it always felt weird to me that I had to put that field in a meta box when it should have been considered the main content. A new post format UI would basically just be picking out a preset of fields that best fits the format of content. As Mike Schinkel suggested in the UI update post, flexibility is key as it would open some nice functionality for plugin developers as well as make WP a lot more robust.

    • Edward Caissie 6:28 pm on January 7, 2013 Permalink | Log in to Reply

      Something to keep in mind (perhaps more so for the Theme Review Team) is not to go forward with Post Formats pigeon-holed into a rigid display of their associated content. I can see strong recommendation being made for how one might use the Post Formats but I would like to see anything stronger than a recommendation.

      • Edward Caissie 6:30 pm on January 7, 2013 Permalink | Log in to Reply

        er, I meant: “… I would *not* like to see anything stronger …”

      • Chip Bennett 6:49 pm on January 7, 2013 Permalink | Log in to Reply

        I think the “big win” opportunity here is in establishing a standard convention regarding what *types of content* apply to each post format type, and what *type of data* each of those types of content are.

        For example, some post format types lend themselves well to *not* having a Post Title. That convention can be established, and Post Title hidden from the UI. (The associated Theme Review guideline would be “must not display Post Title for format types X, Y, Z”)

        For another example, some post format types have been implemented using post custom meta data. For all such instances, it is hugely important to standardize on hat post custom meta key/value.

        Implementation of Post Formats has been a bit of a “wild west”, with different Theme developers making different assumptions about appropriate content and appropriate data types for each post format type. I would love to see those assumptions standardized – and it is on that standardization that I think the WPTRT dovetails nicely into the effort by the UI team.

        • Mark Jaquith 7:19 pm on January 7, 2013 Permalink | Log in to Reply

          This. We don’t want to constrain theme design, but we do want theme designers to know what data they’re getting, in which format, and to know which assumptions have been made about the utility and availability of various pieces of that data.

          • Devin Reams 7:25 pm on January 7, 2013 Permalink | Log in to Reply

            Agreed. The frustrating part of formats so far has been the fact we standardized on the formats, but not other benefit/data to go with it. So we still have to “throw” everything into the_content. A consistent meta data format would be a big win here.

            But, you say, “what If someone switches to a theme without post formats, don’t they lose that meta data”? Sure, which is why we came up with some code to ‘fall back’ in those cases (attach the meta to the content display, basically): http://alexking.org/blog/2011/11/02/wordpress-post-format-fallbacks

            • Daniel Jalkut (Red Sweater) 7:45 pm on January 7, 2013 Permalink

              I want to strongly agree with this and also point out that from a 3rd-party client developer perspective, this has implications on the ability to present a meaningful editing UI as well. I develop a blog editing app for the Mac, that also supports Tumblr which has the closest comparable feature to this that I know of. With Tumblr, I present e.g. the quotation and the attribution of a “Quote” type post separately, in indepent fields. With the WordPress “everything in content” approach, it would be possible to structure the content of the post on first edit, but impossible to reliably pull it apart again when opening up to re-edit.

              I imagine the same problem is limiting the ability of theme and plugin developers to innovate in the wp-admin built-in editor.

        • Aaron D. Campbell 7:26 pm on January 7, 2013 Permalink | Log in to Reply

          This is huge. We want users to be able to change themes and know that all their posts (in any format) will continue to work as expected. We don’t want one theme using _link_url postmeta and another _url because that’s when content is lost (or at least appears lost to the user, and for all intents and purposes it might as well be)

        • grantpalin 12:01 am on January 9, 2013 Permalink | Log in to Reply

          I agree, a standard convention will be useful to guide themers in implementation – something that’s seemed lacking since formats appeared. Guidelines, not rules!

        • Jonas Bolinder (jond3r) 12:36 pm on January 9, 2013 Permalink | Log in to Reply

          A too strict position on which data is allowed or not for a theme too display for a certain post format is discouraging. In particular a theme might want to display a relevant Post Title, which can be beneficial for understanding the content for humans (and bots).

    • Zach "The Z Man" Abernathy 6:29 pm on January 7, 2013 Permalink | Log in to Reply

      Count me in! I’m on-board for whatever is needed in 3.6

    • Travis Northcutt 6:39 pm on January 7, 2013 Permalink | Log in to Reply

      @Helen, when/where will you be discussing what needs to be done? I’m not *sure* I can commit time to helping ,but I’d like to follow along in any case.

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

        Should be like anything else in development – likely IRC for much of the interaction to keep things moving quickly, along with the ticket #19570 on Trac (especially summaries). Right now we’re gauging interest in various proposed features/release items.

        • Travis Northcutt 8:04 pm on January 7, 2013 Permalink | Log in to Reply

          Thanks! I haven’t gotten involved in contributing to core really in the past (beyond chiming in on a ticket here and there), so I wasn’t sure what exactly to expect.

        • Slobodan Manic 7:23 pm on January 9, 2013 Permalink | Log in to Reply

          I’m sure I can commit time :)

          Really, would love to help with this one, agree with everyone else that post formats could use some standardization.

    • Justin Sternberg 6:55 pm on January 7, 2013 Permalink | Log in to Reply

      I’d be happy to help out with this.

    • prettyboymp 6:57 pm on January 7, 2013 Permalink | Log in to Reply

      A set of functions like the post_type_supports() functions of custom post types would be extremely useful.

      I use it frequently to create a handler (form controls/save callback) for certain types of post meta and can turn it on for any post type by just making that post type support it. Similar functionality for post formats would make it possible to carry some of these over instead always unnecessarily needing a custom post type.

    • Tammy Hart 6:59 pm on January 7, 2013 Permalink | Log in to Reply

      I’d like to help out with this as well. I’ve customized Alex King’s approach and used it a couple of times myself.

    • wycks 7:23 pm on January 7, 2013 Permalink | Log in to Reply

      This feature did meet with some pushback when it was first released because of lack of interest ( β‰  tumblr).

      Since then has there been any indication that people are using it? Can someone show me some good examples, besides ma.tt?

      Do you think it’s apparent lack of use is because of the UI?

      β„’ my opinion , I might be totally wrong.

      • Devin Reams 7:31 pm on January 7, 2013 Permalink | Log in to Reply

        See Alex’s blog or my blog using the FavePersonal theme which has the aforementioned “post format UI” (and associated meta data) which allows for a pretty nice user experience (both for publisher and visitor) a la tumblr. It allows a lot more to be done when creating responsive designs, too.

        I see a ton of other themes marked ‘post-formats’ in the theme browser on WP.org but the sample data doesn’t seem to take advantage of it (or the themes I saw don’t…).

      • Helen Hou-Sandi 8:03 pm on January 7, 2013 Permalink | Log in to Reply

        The various mobile apps also have post format support built in, with the image format being the one that probably sees the most use, as the “Quick Photo” feature in the apps automatically assigns that format. Of course, it’s up to the theme to do something special with it.

        The issues I see with adoption (or lack thereof) is with the lack of UI that makes an actual difference for the end user besides choosing from some radio buttons that don’t show you what’s different about the choices, and lack of data standardization for theme authors to take advantage of. It’s not something that’s going to be used by everybody in every application, and there are no illusions about that, but for those who do use it, it’s valuable and desirable, and we should always be making things better.

    • sara cannon 10:53 pm on January 7, 2013 Permalink | Log in to Reply

      count me in to help here as well.

    • Alex King 1:02 am on January 8, 2013 Permalink | Log in to Reply

      Obviously I’m a big fan of this getting into core. The trac ticket is here for anyone interested:

      http://core.trac.wordpress.org/ticket/19570

      The code in the GitHub repos should work fine with WordPres 3.5, but obviously we wouldn’t want the JS hacks that were needed to implement it as an add-on.

      Having thought it through and implemented this once already, I’m still pretty pleased with the overall approach we used and the naming conventions we established. I’d *really* love to see the post meta naming conventions maintained if at all possible.

      Helen, let me know if there are things I can do to help out!

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

      I’d like to help out with this, if there’s still room.

    • Amy Hendrix (sabreuse) 2:49 am on January 8, 2013 Permalink | Log in to Reply

      Sign me up.

    • grantpalin 12:04 am on January 9, 2013 Permalink | Log in to Reply

      I’d be happy to help with this in the form of suggestions and feedback. I’ve been puzzled by the lack of a real UI for using formats, and have used Alex King’s plugin to fill the hole. Something worthwhile could be to write a guide on migrating from a plugin-based solution to a core-based one, which I might be able o help with.

    • Jonas Bolinder (jond3r) 12:52 pm on January 9, 2013 Permalink | Log in to Reply

      I’m prepared to contribute (with code and opinions).

    • davebc 5:41 pm on January 9, 2013 Permalink | Log in to Reply

      I’m no coder, but I’ve been dying for post formats to get this attention since they debuted and have stuck with Tumblr solely for this reason ever since. There are few things I won’t do to help test, if you could use that.

      One request: please don’t overlook the bookmarklet when updating the UI for these features.

    • Japh 9:36 pm on January 9, 2013 Permalink | Log in to Reply

      I know I said it in IRC the other week, but just to be sure: I’m in for this one!

    • Lance Willett 4:50 pm on January 17, 2013 Permalink | Log in to Reply

      @aaroncampbell Can you tag this post “post formats”?

    • Lance Willett 4:52 pm on January 17, 2013 Permalink | Log in to Reply

      In case it’s helpful, here is some code that might be helpful even if for how *not* to implement. Heh.

      We have several themes on WP.com where post formats are crucial to the theme and where we needed to have “content parts” broken out, like in a Video post. We wanted just the video URL or markup and not the rest of the post content.

      From the Esquire theme, for example:
      https://wpcom-themes.svn.automattic.com/esquire/content-grabbers.php

      The regex there handles URL, video, and audio.

      Todo to make this much better:

      1. Use get_children() instead to replace the SQL in all thes grabber functions
      2. Cache the result in post meta, then refresh it only when the post changes

      We’d obviously love to replace all this code once core supports getting the better post format UI and being able to “grab” the content pieces out cleanly.

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