Make WordPress Core

Updates from Aaron D. Campbell Toggle Comment Threads | Keyboard Shortcuts

  • Aaron D. Campbell 1:07 am on January 8, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Menus 

    For menus we’re going to try to focus on some UI improvements. Menus work pretty well but users, especially the less-technical ones, are easily confused. We’ve seen them try to add menus without names because they see the “Create Menu” button before they see the menu name field, we’ve seen them add a bunch of menus instead of menu items because they’re unclear on the difference, etc, etc. The goal for the 3.6 cycle is to make menus a little more intuitive and user friendly.

    @markjaquith and I are excited to have @lessbloat leading this. Take a look at all the user testing that has already been happening over at #23119 and make sure you comment here if you’re interested in helping out!

     

    • Aaron D. Campbell 1:08 am on January 8, 2013 Permalink | Log in to Reply

      On a personal note, I’d love to see #16075 addressed if there’s time.

    • Joey Kudish 1:10 am on January 8, 2013 Permalink | Log in to Reply

      In last week’s meeting, we discussed some improvement to the nav menu saving code as well. If that’s still on the roadmap, I’d like to help there.

      • Aaron D. Campbell 1:13 am on January 8, 2013 Permalink | Log in to Reply

        I don’t specifically remember talking about saving. I know we discussed sluggishness with lots of items, and I know we discussed needing a complete back-end rewrite, but I think we decided both of those were outside the scope for 3.6.

    • F J Kaiser 1:45 am on January 8, 2013 Permalink | Log in to Reply

      For those who’re writing the patches and participating on the ticket, the [wp-nav-menu] tag archive over at WordPressStackExchange might be of interest. The views & votes are a good indicator for what devs & users are interested in and what they might need/how they see those tings.

      http://wordpress.stackexchange.com/questions/tagged/menus?sort=votes&pagesize=50

    • Gustavo Bordoni 1:55 am on January 8, 2013 Permalink | Log in to Reply

      Hey Aaron, I was thinking these days, developers should have I way to put fields, or even HTML on the Menu Configuration panel. I could not find a filter or a action to to it.

      If menus, is on the aim for 3.6, I would like to try to implement an API to do it, just like the Widgets one.

    • Drew Jaynes (DrewAPicture) 2:49 am on January 8, 2013 Permalink | Log in to Reply

      I’m very interested in contributing to this nav-menus refresh. We had great results user-testing the new color picker in 3.5 and I have high hopes for what we can come up with for nav-menus in 3.6.

    • MB Creation 8:24 am on January 8, 2013 Permalink | Log in to Reply

      Hi. I’m sorry if this is not relevant but recently an offline page was still available in a menu. Don’t you think it should disappear from it ? (at least in the front-end ?). I Agree with gustavo about the idea of an API !

    • keoshi 11:53 am on January 8, 2013 Permalink | Log in to Reply

      Would love to help with this, I think it’s one area where we could use major UX improvements.

    • GrahamArmfield 12:37 pm on January 8, 2013 Permalink | Log in to Reply

      I’m pleased to hear that the menu builder is likely to get a refresh. When that is being done, please can we make a menu builder that is keyboard accessible too – the current one is impossible or very difficult for anyone with disabilities/impairments to use. See http://core.trac.wordpress.org/ticket/21289

    • rfair404 1:15 pm on January 8, 2013 Permalink | Log in to Reply

      Aaron, this is good news. I’ll help out on #16075

    • hereswhatidid 3:03 pm on January 8, 2013 Permalink | Log in to Reply

      I’d love to see it move away from the tabbed-style navigation and just use the underlying drop down menu for choosing which menu to edit. I’ve had far too many clients name a menu something like “Drop Down Menu for Home Page” which then pushes every other tab off the visible area. Also, managing any more than 4-5 menus is very painful as you constantly have to click the right and left arrows just to be able to select which menu to edit. I would love to help out if needed as I’ve already modified it to use the existing drop down menu on several sites.

    • Rian Rietveld 8:15 am on January 9, 2013 Permalink | Log in to Reply

      +1 for GrahamArmfield :”please can we make a menu builder that is keyboard accessible too” and hereswhatidid “just use the underlying drop down menu for choosing which menu to edit”.

    • adamsilverstein 3:40 pm on January 10, 2013 Permalink | Log in to Reply

      i’d love to help out with testing/bug fixing. i have several clients managing huge & multiple menus, interested in improving reliability of interface and usability over slower connections; finally accessibility is an issue i’d love to see improved.

    • lOOis 9:55 am on January 16, 2013 Permalink | Log in to Reply

      When managing menus with lots of items and levels it would be great to be able to add new items directly to the right place, by drag&drop from the pages widgets to the menu (and not at the end of the list and then having to drag it one by one to the right place)

    • magol 9:35 pm on January 21, 2013 Permalink | Log in to Reply

      If I understood everything right, I have to choose if I want the main menu to show the structure of my pages, or if I want to completely free create my own menu. I want to be able to reflect the structure of my pages, and stil be able to making adjustments.
      Eg. like a .path file. I have the structure on the pages to start from, and do adds, modifications, and deletions in the custom menu.

  • Aaron D. Campbell 11:21 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Revisions 

    Revisions are an extremely powerful tool for content tracking, but there are a few parts that need a little TLC. Ever since they were first introduced, there’s been a problem with proper author attribution on revisions (see #16215), and we’re going to take a crack at fixing that in 3.6. Additionally, while the current diffs are pretty cool, and make a lot of sense to those of us that look at diffs everyday, there’s a lot of room for improvement for your average user. We’d like to see some UI improvements around the diffs as well as information that makes more sense to an average content creator (words changed, a visual representation of what was added/removed, prettier output, etc).

    @markjaquith and I chose @westi to lead this. I’m excited to see the improvements on this one! There’s a little of everything in this project, so please leave a comment if you’re interested in lending a hand.

     

    • Alex Mills (Viper007Bond) 11:25 pm on January 7, 2013 Permalink | Log in to Reply

      It’d be nice to have revisions also include post meta and taxonomy data so that when restoring to a previous revision, the whole post’s state could be restored.

    • adamsilverstein 11:28 pm on January 7, 2013 Permalink | Log in to Reply

      i’d love to help with this.

    • Rafael Ehlers 11:31 pm on January 7, 2013 Permalink | Log in to Reply

      And make define(‘WP_POST_REVISIONS’, false); works!

    • karmatosed 11:32 pm on January 7, 2013 Permalink | Log in to Reply

      I’d love to help from a UI angle on this.

    • Erick Hitter 11:58 pm on January 7, 2013 Permalink | Log in to Reply

      I’m very interested in helping with this.

    • zippykid 12:32 am on January 8, 2013 Permalink | Log in to Reply

      +1

    • janw.oostendorp 1:49 am on January 8, 2013 Permalink | Log in to Reply

      A suggestion. Can revisions be stored like only save one revision a day per post? Most of the time I would want to restore a revision I already overridden the nr I’ve set on that day. So I can’t go back to yesterday.

      Maybe save all revisions of this day and 1 for every day that is defined in `WP_POST_REVISIONS`.
      Just a suggestion.

      • Peter Westwood 9:38 am on January 8, 2013 Permalink | Log in to Reply

        This sounds like an interesting idea. I think our primary drive will be around the presentation and making it much more user friendly.

        It may be that we can alter the presentation to provide a less verbose history by default with only one revision per day highlighted while keeping the full history as well – the full history is really useful in the context of one of the key theme of 3.6 – never lose your content.

        • Curtiss Grymala 4:22 pm on January 8, 2013 Permalink | Log in to Reply

          While I think this is an interesting idea, I think it might be just as helpful (more helpful in my use-cases) if revisions were actually systematically compared at some point, and identical revisions were either dumped or not highlighted.

          For instance, let’s say I go in to look at a post (for instance, to copy a shortcode I used in it, etc.) and then, out of habit, click “Update”. Although I didn’t change anything in the post, WP stores a separate revision for that update, and shows that in the list of revisions. It would be nice if WP was able to compare that version to the previous version, recognize that nothing changed, and downgrade that revision somehow.

          I think, either way, we would need to look at somehow classifying revisions (possibly with a +1 or -1) to differentiate between revisions that should be highlighted (for reversion purposes) and those that are just stored for record-keeping (basically just to know when someone accessed the edit page for that post).

          • wedi 7:17 pm on January 9, 2013 Permalink | Log in to Reply

            That is really a big point. It’s quite annoying to click through several revisions to find the last real change.

    • esmi 2:53 pm on January 8, 2013 Permalink | Log in to Reply

      Can some of the accessibility issues associated with revisions also receive some attention? Specifically, the Compare Revisions table.

      1. As this is a form, each of the radio buttons needs an associated label. By all means, position the label offscreen if you must but without those labels, the form is virtually impossible to use in some situations.

      2. Can we have unique text for each of the Restore links? Again, position the unique fragment offscreen if necessary but handful of identical-sounding links creates major problems for some users.

      3. Ideally, get rid of the table markup. Forms + tables = accessibility problems for many users.

      • Peter Westwood 10:55 am on January 9, 2013 Permalink | Log in to Reply

        Can some of the accessibility issues associated with revisions also receive some attention?

        We will definitely look at the issues you have highlighted and see how we can best address them.

    • lessbloat 9:27 pm on January 8, 2013 Permalink | Log in to Reply

      Thought I’d play with some visual indicators showing whats changed between diffs, so at a glance you can see: “Oh ya, this is the one where I just removed on line”, or “this is the one where I removed 5 paragraphs”.

      Option 1

      Option 2

      Option 3

      Option 4

      Hat tip to MarkJaquith for the concept.

      • Aaron D. Campbell 9:33 pm on January 8, 2013 Permalink | Log in to Reply

        I really like it. Personally I think the bars are more user-friendly than the raw numbers, but I don’t have much preference between those three.

      • karmatosed 9:58 pm on January 8, 2013 Permalink | Log in to Reply

        I like the bar dots the most but my worry about any graphical indicator like that is a ‘what does it mean’. 3 red dots to me or a lump of a bar isn’t as instantly recognisable maybe to all users. I guess my question would be: “Is it important to know what of what”? If that’s the case then a number is far more indication. If a vague idea is all that’s needed then exacts aren’t as required.

        Worth exploring around other ways of representing I think aside from ones that require more maybe guess work as to what % of what?

      • GrahamArmfield 10:10 am on January 9, 2013 Permalink | Log in to Reply

        As a sighted person a visual representation can sum up a concept neatly. Unfortunately not everyone is sighted or has clear sight. Using colour as the only way to convey meaning can also be problematic – especially in your choice of red/green. Some 8% of men and 2% of women are colourblind – with red/green colourblindness being the most common.

        Any solution like this needs to also include plain visible text to indicate what the bars mean. I’d especially echo karmatosed’s point – will even all sighted users understand what’s being represented here. And how would the dots/lines represent removing some characters and adding some different ones?

      • Peter Westwood 10:57 am on January 9, 2013 Permalink | Log in to Reply

        These are neat and address a piece of the UI that I hadn’t even considered improving yet :)

        If we don’t focus on trying to condense the visualisation of the whole diff down into some coloured fragments are there ways in which we can highlight if the diff is a large or small change well?

      • wedi 7:18 pm on January 9, 2013 Permalink | Log in to Reply

        That is great! An indication if the content or just meta data was edited would be very useful, too.

      • ArielK 7:48 pm on January 9, 2013 Permalink | Log in to Reply

        I like “option 1″ it’s very clear & simple.

      • Sam Parsons 11:06 pm on January 10, 2013 Permalink | Log in to Reply

        Here’s an idea of a mockup that would show both visually and give some words to explain to those not accustomed to this type of image and to those who have visual impairments (either color-blindness or others).

        mockup of the revision interface.

        • Peter Westwood 1:30 pm on January 11, 2013 Permalink | Log in to Reply

          This is quite neat, I wonder if this is too specific though :)

          What people probably want to know is things like:

          • Is this the revisions where I fixed that typo
          • Is this the revision where the editor re-wrote my whole post

          It will be interesting if we can present something more like a graduated size of change metric which has more end-user meaning that something very technical like word count – especially when word counting is so hard to get write in some situations like some asian languages.

      • karmatosed 1:07 pm on January 18, 2013 Permalink | Log in to Reply

        I had a bit of an experiment around this area. One thing that struck me was how small the content is for that wide area. It perhaps means we can use that area to give more information – people seem to be saying different information is useful to different users so perhaps just saying the time, who and an indicator isn’t enough.

        I also thought a bit about how things like commit messages and ways and along with different representations came up with the following.

        I know it’s very different from what have now it’s more just an exploration of a few things and doesn’t have to all be used.

        • karmatosed 1:09 pm on January 18, 2013 Permalink | Log in to Reply

          I just realised that squashed it down a bit in the message so here is the original linked to see it a bit more clearly:

      • karmatosed 1:25 pm on January 18, 2013 Permalink | Log in to Reply

        I also did a different exploration using bars.

    • esmi 11:33 am on January 9, 2013 Permalink | Log in to Reply

      If you’re going with the red/green combination, please consider using numbers – not bars. http://quirm.net/temp/red-green.png shows the display as it would be seen by those who suffer from 2 out of 3 of the known forms of color blindness. Using numbers would also by-pass any issues for non-sighted users and give everyone a clear indication of the changes made.

      • Siobhan 3:07 pm on January 10, 2013 Permalink | Log in to Reply

        In terms of writing, numbers are much more useful as they provide context. Also, word count is more useful than character count.

    • talgalili 10:51 am on January 12, 2013 Permalink | Log in to Reply

      Hello all,

      I would like to ask for another feature:
      When comparing two revisions, allowing a reviewer to have an “accept/reject” for each section changed (in a similar way as offered by libre-office or MS-word), which at the end of it will create a new revision.

      Background story for the request: I recently had the need for such a feature, since I have three friends working on the same post, where one is more “senior”. The senior friend wanted to be able to accept/reject changes by the other contributors. Since this was not an option in WP, we decided to do the first draft of the post in word, and exchange it by e-mails.

      Thank you all for taking on work at this front :)
      Cheers,
      Tal

  • Aaron D. Campbell 9:00 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Editorial Flow 

    I’m really excited to see our editorial flow get some love in the 3.6 cycle! We always want to be as extensible as possible and post statuses are one of those places where we’re not near as good as we should be. The plan goes something like this:

    1. Fully support the existing register_post_status() API in core
      • Make sure things don’t break when you add your own custom statuses
      • Update the metabox UI to show any newly registered statuses in the drop down, etc.
      • Add a ‘moderation’ flag so that unpublished statuses can be explicitly identified
      • Support for non-standard public post statuses
    2. Enhance the existing API
      • Add support for registering post statuses to specific post types
      • Allow for caps checks on different post statuses
      • New remove_post_status() function for removing an already-registered post status
    3. Editing workflow for already published content

    Additionally, we hope to address some issues around post meta for revisions, which is tightly related to the workflow for already published content.

    @markjaquith and I have chosen Daniel Bachhuber to lead this. If you’re not sure why, just Google WordPress Edit Flow and it’ll all make sense. There’s a lot of heavy-duty under the hood work here, so please leave a comment if you’re interested in lending a hand.

     

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

      Been waiting for this for a while…

    • conservativeread 9:11 pm on January 7, 2013 Permalink | Log in to Reply

      i want post tags and related posts to be automatic, i would also like to see more support for posting outside of admin from desktop apps like wlw and the new blogjet.

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

        Automatic tagging and related posts will both continue to be in plugin territory for now. I know there are some good ones out there, but the usecase is still too small to justify having that functionality in core.

        As for the desktop apps, WordPress as an XMLRPC API that they can use to post to it (the same one the mobile apps use). I don’t personally use any of those tools, but the capability is definitely there.

    • Joey Kudish 9:17 pm on January 7, 2013 Permalink | Log in to Reply

      I’m interested in helping with this effort!

    • Md Mahmudur Rahman 10:47 pm on January 7, 2013 Permalink | Log in to Reply

      This is the ideal time to address some issues pointed out in the below article (WordPress And Government) by @StephenCronin, as we are talking about Editorial Flow for the next release.

      http://scratch99.com/wordpress/government/use-of-wordpress-in-government/

      To be specific (quoted from the article):

      “Enterprise Level Websites

      Everyone has a different definition of ‘enterprise level’. It’s probably not sensible to try to tie that definition down. Instead, I’ll describe the sort of website I’m talking about:

      Anywhere from 3,000 to 10,000 pages (and let’s not talk about PDFs!)
      Anywhere from 3 to 7 levels deep: the site I’m currently working on will be 7 levels deep minimum
      The majority of content not chronologically based
      Several hundred distributed authors, located around the state, spread throughout maybe 60 business areas, each with their own signoff processes.
      Centralised editorial quality assurance
      Complex workflows:
      One piece of content may need to go through 5 levels of approvals
      Another may only need to go through 2 levels
      There will be different approval steps and different users for different content types and different categories
      Example: Content author -> Manager -> Communications -> Web Editor -> Tech QA -> Publish.
      Note: It’s not about traffic. We all know WordPress can scale, for example as in the case of WordPress.com. Rather it is about complexity and the ability of WordPress to handle this sort of site out of the box.”

      Cheers.

      • Mark Jaquith 3:58 am on January 8, 2013 Permalink | Log in to Reply

        So, the workflow and QA things you mention are kind of where this is going. Not building that into core directly, but making it easier for a plugin like Edit Flow to implement custom post statuses and a more complex posting workflow.

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

        You could, however, use a multisite instalation to achieve what you need, separating some of the content and workflow.

    • Justin Sainton 11:12 pm on January 7, 2013 Permalink | Log in to Reply

      I know @ryancduff and I would definitely love to help out here.

    • Scott Kingsley Clark 11:21 pm on January 7, 2013 Permalink | Log in to Reply

      Oh very nice, I shall eat cake on this day.

    • Tom Lany 12:32 am on January 8, 2013 Permalink | Log in to Reply

      It would be nice if editors could receive an email when a post is saved in the moderation queue.

    • Stephen Cronin 12:39 am on January 8, 2013 Permalink | Log in to Reply

      Looking forward to watching how this pans out! This has been a pain point for larger organisations for a while.

      Happy to give the perspective of the requirements for a large site (up to 5 levels of approvals, different approval steps / user groups for different content, based on content types, categories, even individual pages, etc), if catering for that sort of site is within scope.

    • nuggetsol 6:16 am on January 8, 2013 Permalink | Log in to Reply

      This would be a really nice addition to the core. I have developed a plugin which aims towards supporting workflow management – http://wordpress.org/extend/plugins/oasis-workflow/

      I have got some good feedback from the users. I am planning to add some new features, but support for custom statuses out of the box would be really wonderful.

    • Konstantin Kovshenin 9:10 am on January 8, 2013 Permalink | Log in to Reply

      I’m willing to contribute as much as it takes to get this done. Can somebody please list the existing tickets? Ones I’m aware of are #12706 #15132 #21787 #7745

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

        I would like to contribute to it to. We should be carefull about we deal with post status transitions too.
        Related: #22241

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

      Fantastic idea! That is something I was expecting for some time ago. I will keep in touch with some of that tickets and help where I can.

    • William P. Davis 2:11 pm on January 9, 2013 Permalink | Log in to Reply

      I’d love to help on this.

    • F J Kaiser 6:02 pm on January 9, 2013 Permalink | Log in to Reply

      One thing where I’d really love to see a solution is about that freaky thing that happens when switching “visibility” from “public” to “private”. When doing so, the “Save as (draft/etc.)” button disappears. It doesn’t come back when switching to “public” anymore. Ticket incl. several patches that cover different scenarios is here http://core.trac.wordpress.org/ticket/21563

    • lucasstark 1:33 pm on January 12, 2013 Permalink | Log in to Reply

      Any way we can also figure out a way for published content to remain published when a user submits updates for review? One of the trickest things to work around is to allow users without publish rights to submit updates to content with out taking that content offline. Seems like we could serve up the last published revision, assuming we have all metadata and taxonomy selection attached to the revision, rather than taking the main page off line. Right now I’m using a customized version of Boston Universities Versions Plugin, which does an OK job, but would be nice if this was built into core.

      The way it works now is “ok” for posts and news style items, but really seems to break down when dealing with pages.

    • Dave Clements 8:59 pm on January 15, 2013 Permalink | Log in to Reply

      +1. Would love to be able to register new post statuses. Wish I was savvy enough to help out!

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

  • Aaron D. Campbell 4:14 pm on February 16, 2012 Permalink
    Tags: , ,   

    Team Update: Headerators 

    We’ve pretty much wrapped up flexible headers (#17242) for both width and height. We’re currently reviewing a patch on #19840 and hope to have that finished this cycle. Our next project will be to work with Team Gandalf to help integrate flexible headers into their theme preview.

     

  • Aaron D. Campbell 7:31 pm on February 1, 2012 Permalink
    Tags: ,   

    Team Update – Headerators 

    We focused on flexible headers this cycle (#17242). We have a patch that we think is ready for commit, which adds flexible height and width. We had Nacin and Mark Jaquith look at the patch, they made some recommendations that we integrated, and it seems ready to go into core for some testing.

    You can test with the latest version of the Essence Theme on Github or see comment 48 on the ticket for information on how to add support to your own theme.

     

  • Aaron D. Campbell 3:43 pm on March 22, 2010 Permalink
    Tags:   

    I was considering adding another idea to the GSoC ideas wiki, but wanted to run it by the devs here first. Basically, making the login, registration, and lost password pages fully themeable. I know some work on this was started in #11172 with the creation of wp_login_form(), but we still seem to be pretty far from letting theme authors include login.php, register.php, and/or lost-password.php theme files.

    If it’s something that everyone thinks is a valid idea and a project we would like to see, I’ll try to flesh it out and add it to the wiki.

     

    • Mark McWilliams 4:55 pm on March 22, 2010 Permalink | Log in to Reply

      +1 I’d be all for that! :)

    • Joël Mayer 6:54 pm on March 22, 2010 Permalink | Log in to Reply

      Nice idea! Always looked for a SIMPLE way to customize the login/register/lost password pages to fit my website’s current theme. Hope the idea makes its way to the wiki and the WP 3 core.

      Thanks. :)

    • scribu 7:24 pm on March 22, 2010 Permalink | Log in to Reply

      Since WPMU already has a dedicated registration page template and one for registering a new blog, I’d go for it.

    • JamieO 8:46 pm on March 22, 2010 Permalink | Log in to Reply

      +1 as well. Especially if the branding (or ability to customize) is also applied to any of the emails that get sent out along with user registration.

    • Peter Westwood 10:06 pm on March 22, 2010 Permalink | Log in to Reply

      This has been discussed in the past and the consensus then was that it was better for us to provide template tags for people to use the forms in template files and allow people to re-style what we have via the existing hooks than make them something that is themeable by the normal theme process.

      I don’t think the normal theme process scales well in this regard for multisite related templating of the register page either.

      I think it needs more discussion before suggesting as a GSOC project and I am not sure it is large enough either.

      • Eric Marden 7:50 am on March 25, 2010 Permalink | Log in to Reply

        Peter,

        Can you point out some of these tags? This is one of the pain points for full customization, and I was unaware of the approach we should be taking until seeing this post.

    • Josemi 11:21 pm on March 22, 2010 Permalink | Log in to Reply

      I dont know if this is a good place for the question, but….For when the 3.0 Beta? You said that you will release it today—

      Greetings

    • Amy 1:41 pm on March 23, 2010 Permalink | Log in to Reply

      I say go for it.

  • Aaron D. Campbell 5:31 pm on January 29, 2010 Permalink
    Tags:   

    Core Plugin Infrastructure Update 

    Just a quick update on where we stand with the infrastructure for core plugin development. The mailing lists are currently being used and it looks like they should be able to scale fine.

    We still need a patch or plugin for Trac (http://core.trac.wordpress.org/ticket/11898) to help it handle the sheer number of plugins currently in the repository (not to mention the expected future growth). If anyone is able to help with that, please post on that ticket.

    The next steps will be to rework the current layout of the plugin pages on wordpress.org. Currently there’s a link on the admin tab to that plugin’s Revision Log as well as the RSS feed for that log. That needs to be moved some place where regular users can see it. Additionally the plan is to add a way for plugin authors to request a mailing list for their plugin directly from the wordpress.org repository.

    I’m excited to see all this fall into place so that we can turn the corner and see how core plugins will really shape up!

     

  • Aaron D. Campbell 6:14 pm on January 11, 2010 Permalink
    Tags:   

    Core Plugin Infrastructure 

    As many of you know, last Thursday’s dev chat resulted in a core plugins research team team (for lack of a better term). Basically, our job is to try to come up with a list of tools that should be supplied for all core plugins, in order to allow teams of developers to be effective and efficient. It’s only been a few days so far, but we wanted to update everyone on our progress.

    First, we started a new IRC channel on freenode to discuss core plugins. If you’re interested in offering suggestions or ideas, share them in #wordpress-core-plugins. The channel is logged at https://irclogs.wordpress.org/ as well, so feel free to put your ideas there even if no one is presently chatting. I’m sure a few of us will look at the logs (I know I do).

    We also started discussing the infrastructure that is needed. It seems that plugins already have a good SVN system in place, which is great. Additionally we think core plugin teams need trac (which we already have, but it needs some work), and mailing lists. The way we see it, core plugins should have most of the tools available to WordPress core developers, since they’ll be doing the same basic thing on a smaller scale.

    There’s still a lot to do, including coming up with suggestions on how core plugins should be developed, how developers will be added to or removed from a core plugin team, figuring out if any of the tools or processes would benefit all plugins (not just core plugins), etc. We’d love to get more input on these areas, either here or in #wordpress-core-plugins. Please remember though that we aren’t discussing what core plugins should be called, whether or not they’re a good idea, how plugins will become core plugins, or whether my mom’s a core plugin. We’re just trying to come up with a set of tools that would help the developers, and some basic best-practices for plugin development and team building.

     

    • Dan Cole 10:45 pm on January 11, 2010 Permalink | Log in to Reply

      How about considering letting each core plugin have it’s own Trac or be in a core plugin Trac. Plugin Trac works, but it has a lot of noise from the other 7,000 plugins. I think it would be nice to filter content for people. The current plugin Trac seams overwhelming until you get use to it and filter data. I’d assume people are Trac novices. It would also give developers more features, e.g. they could add components or create roadmaps. I like the idea of a core plugin being like core development, but on a smaller scale.

      • aarondcampbell 11:27 pm on January 11, 2010 Permalink | Log in to Reply

        The goal will be to use the existing trac, so that all plugins can benefit from it. However, we do need to see what we can do as far as good filters to allow you to see only what you really want to see, so we’ll try to make that process a lot easier.

    • Andreas Nurbo 5:31 pm on January 13, 2010 Permalink | Log in to Reply

      You should look into how RubyOnRails handles things. And also study GitHub.
      Better docs is also required if you want to improve stuff.
      A core dev cant replace good “best practice” articles as seems to have been suggested in wp corepse chat session. If you want all plugins to benefit from this endeavor you need better articles etc. Looking at core code and design decisions overtime core devs are not some coding gods.

    • John James Jacoby 10:40 pm on January 13, 2010 Permalink | Log in to Reply

      There’s been talk about trying to make a collaborative plugin for BuddyPress, to help group users together and let people “buddy up” with mentors and protege’s to help deliver the best quality code possible. I’d love to help out on something like this.

    • Andreas Nurbo 11:31 pm on January 13, 2010 Permalink | Log in to Reply

      I would be interested to help out with that. Good learning opportunity. I’m in the process of learning BuddyPress inside out since I’m gonna convert a community based on a old c#/asp.net CMS I wrote. Looks like I need to write plugins for BP in the process also.

    • Dan 3:09 am on November 13, 2010 Permalink | Log in to Reply

      I agree with Andreas. Definitately take notes from the Rails community and Git! SVN way outdated when compared to Git.

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