Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 4:20 am on January 10, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Git Mirror History Breakage 

    A few years ago, I started publishing a mirror of WordPress on GitHub. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate authors.txt file, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to Git in the future, we would probably want our official mirror to have the best possible data.

    Proposed

    That we re-run the git-svn import with a proper authors.txt file.

    Upsides

    We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migration to Git. Commits will be properly attributed in GitHub.

    Downsides

    This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branch off of origin (or even better, blow the whole thing away and re-clone).

    So: thoughts? Would this ruin your day?

     

    • Gustavo Bordoni 4:25 am on January 10, 2013 Permalink | Log in to Reply

      If this means that WordPress is taking any sort of steps towards using Git as a solution for code versioning I’m all for it!

    • Scott Taylor 4:25 am on January 10, 2013 Permalink | Log in to Reply

      DO IT! And document the ideal way to mirror with authors.txt after, please. I mirrored a bunch of repos and forget to do the authors part and I haven’t collected the energy to start over yet.

      • Bryan Petty 5:18 am on January 10, 2013 Permalink | Log in to Reply

        Authors file is simple: one author per line: “loginname = Joe User “.

        Run this to generate your initial authors file (from the root of your SVN checkout):
        $ svn log -q | awk -F ‘|’ ‘/^r/ {sub(“^ “, “”, $2); sub(” $”, “”, $2); print $2″ = “$2″ “}’ | sort -u > authors.txt

        Fill in the file with real names and email addresses.

        I use a modified version of Mark’s script to mirror a ton of repos myself:
        https://gist.github.com/3061041

        It’s mostly self-explanatory, see forked gist for Mark’s version.

        • Mark Jaquith 6:02 am on January 10, 2013 Permalink | Log in to Reply

          Another thing I’d do is contact everyone in that file and get them to doublecheck that we have an e-mail address that they’re likely to control for life. Probably best to use e-mail at a personal domain, if they have one, instead of Gmail or a company e-mail address that they might lose in the future.

    • Daryl Koopersmith 4:25 am on January 10, 2013 Permalink | Log in to Reply

      I think an accurate repository is worth the temporary breakage.

    • Ryan McCue 4:27 am on January 10, 2013 Permalink | Log in to Reply

      +1, I’d say we do it.

      What’d be really cool is if we can get the props parsed so that git lists the commit author as whoever was prop’d, and the committer as the person who actually committed it. AFAIK, that’s not possible without a complicated script though.

      • Bryan Petty 4:56 am on January 10, 2013 Permalink | Log in to Reply

        That would be cool, but I really can’t even think of any way to do something like this with the current repo as is without amending commits after the initial clone, which would be extremely resource intensive and could take weeks to do. Given that and the work involved with integrating the same process into the mirror updates for future commits as well, I would just say forget it.

        • Bryan Petty 5:04 am on January 10, 2013 Permalink | Log in to Reply

          Actually, come to think about it, git-filter-branch might be able to handle this efficiently.

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

        Interesting idea. But wouldn’t be able to handle issues with multiple props recipients. But we could give it to the first person or just in this case give it to the committer.

        • Ryan McCue 7:39 am on January 10, 2013 Permalink | Log in to Reply

          Multiple props authors mean that it’s ambiguous who actually created the patch, so the committer should be assigned credit lest we accidentally attribute it to the wrong person.

          (Also, we’d probably want to make sure that we fix up typos. `rmmcue` for example. ;)

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

        While parsing props like this would be cool I don’t think it would accurately reflect the way our process has worked and I would much rather put effort into collecting the props to commit data into a format we can integrate into the WP.org profiles more easily.

        I started on this a while back but haven’t finished yet, what I’m mostly missing is an 100% accurate props extraction method.

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

          At the moment, there’s basically two forms of commits with props: 1) the committer is merely committing a patch that was on a ticket (this is where we’d want to split author/committer); and 2) the committer is writing the patch with inspiration from someone (we’d want author = committer in this case).

          As far as I’ve seen, 1 seems to be the much more common case, but 2 is fairly common too. It could be a problem. (Regarding effort, it’s relatively simple using git filter-branch, so that shouldn’t be much of an issue.)

    • Michael Beckwith 4:27 am on January 10, 2013 Permalink | Log in to Reply

      I do all my pulling of WP from the svn repo anyway, but I keep an eye on some development via github. No harm for my stuff

    • topdown 4:31 am on January 10, 2013 Permalink | Log in to Reply

      I think that authors/contributors should be recognized when ever possible…
      +1 I say fix it.

    • Mike Schinkel 4:48 am on January 10, 2013 Permalink | Log in to Reply

      Got for it!

    • Bryan Petty 4:59 am on January 10, 2013 Permalink | Log in to Reply

      I think you’re already aware that I actually use my own clone of the WP repo partly for this reason, but also because it’s nice having branch and tag names that are exactly the same as the branch and tag names in SVN. It would be nice if those were fixed up as well if you do this.

      • Mark Jaquith 5:56 am on January 10, 2013 Permalink | Log in to Reply

        Yeah, if we’re doing this, we should take the time to iron out all other niggling issues. Would love to have your input on that. My issue with branch names is that it create ambiguous references. So if you go to checkout “3.5″ it will check out the 3.5 branch. In order to check out the 3.5 tag, you need to do git checkout tags/3.5. Not the end of the world. Might be worth it to get everything cleaned up.

        Hey, maybe we can just rebase me and retroactively teach me all this Git and Git-SVN subtleties! :-) Just don’t push me, man.

        • Ryan McCue 7:41 am on January 10, 2013 Permalink | Log in to Reply

          The way I do it for SimplePie is to name the branches spelled out (ala WP.org release notice slugs), such as one-dot-two. That avoids the ambiguity there. However, that’s probably a pain for WP.

          Another option I’ve seen which are popular: rename all tags (or all branches) to vX.X so that any one starting with v is the tag (or branch) and without is the opposite.

          • Boone Gorges 11:55 am on January 10, 2013 Permalink | Log in to Reply

            For my own stuff I do something like this. `3.5` is the tag, and `3.5.x` is the branch. I think Drupal does it this way.

            • Aaron D. Campbell 2:57 pm on January 10, 2013 Permalink

              Or enforce 3 digits for all tags and 2 for all branches, so 3.5 is a branch and 3.5.0 is the first 3.5.x tag

          • Bryan Petty 3:48 pm on January 10, 2013 Permalink | Log in to Reply

            Mark does already do this, which is why the branches are named #.#-branch.

            Anyway, git does assume you wanted the branch instead of the tag, but that’s almost always the case for me anyway. I almost never checkout the tags, and I don’t think anyone else does either (definitely not with SVN either). In the 5 months or so that I’ve had my mirror running, this has never gotten in my way once or annoyed me in any way.

        • Bryan Petty 3:58 pm on January 10, 2013 Permalink | Log in to Reply

          One other issue that’s really minor is that there’s still an iis branch in SVN that didn’t make it into your mirror that probably should.

    • sourceforge 5:12 am on January 10, 2013 Permalink | Log in to Reply

      it would be good, i have been asking /systems guys to install git as revision control, but it seemed only someone in some driver’s seat could ask for stuff there! git is fast, no problem if it breaks for a while! thanks for this! full ahead flank :)

    • Ozh 6:54 am on January 10, 2013 Permalink | Log in to Reply

      I think it’s possible to modify afterwards the author of each commit, so you don’t break the whole history
      https://gist.github.com/4032945

      • Ryan McCue 7:42 am on January 10, 2013 Permalink | Log in to Reply

        That will change the commit hashes, since the author/committer is stored as part of the commit object (which is used to create the hashes). There’s no way (by design) to change these after the fact without doing this.

      • Ryan McCue 7:44 am on January 10, 2013 Permalink | Log in to Reply

        (Also, forgot to note: even if this only changed one commit, this would cascade down through all subsequent commits, since the parent’s hash is also included in the commit object)

    • aristath 6:57 am on January 10, 2013 Permalink | Log in to Reply

      I think it would be a great step forward. Drupal also used to be in SVN and switched to Git a couple of years ago. It was entitled “the great git migration” and took almost a year to design, layout and implement the whole process but it was worth it. Using Git has many advantages! I believe that breaking the history is worth it in the long run.
      Sure it might be a bit inconvenient at first, but I believe that it could really give a new boost to WordPress development.

      • aristath 6:59 am on January 10, 2013 Permalink | Log in to Reply

        correction… Drupal used to be CVS, not SVN. But the principal is the same… :)

      • Ryan McCue 9:24 am on January 10, 2013 Permalink | Log in to Reply

        To clarify: this isn’t about moving WordPress to Git, this is about fixing up the Git mirror of the SVN repo. This is a step we’d need to take if it was decided to move WP to Git, but it’s not the main goal.

    • Remkus de Vries 7:28 am on January 10, 2013 Permalink | Log in to Reply

      Git ‘er done I say. Having to do a rebase / clone is no biggy at this stage.

    • Baki Goxhaj 8:59 am on January 10, 2013 Permalink | Log in to Reply

      Re-cloning WordPress is not a big deal and adding appropriate author information is the way to go toward the future, thus I think it should be done — the sooner the better.

    • Tareq Hasan 9:33 am on January 10, 2013 Permalink | Log in to Reply

      Surely go for it. A step towards SVN to Git.

    • Abhishek Ghosh 10:58 am on January 10, 2013 Permalink | Log in to Reply

      Git is always a better option but needs carefulness on individual basis. Many options for an user is to download. The developer is getting the option to create a better documentation or guide. Cloning is not really difficult.
      There are basic problems too, a good guide is needed for increasing awareness.
      As practically we are not shifting, there is time.

    • Mark Rowatt Anderson 12:06 pm on January 10, 2013 Permalink | Log in to Reply

      Two thumbs up – go for it!

    • Edward Caissie 1:26 pm on January 10, 2013 Permalink | Log in to Reply

      It reads like a lot of great points above … and I am all for them, too. Any rebase / clone issues would be far outweighed by the eventual benefits this will bring.

    • Amy Hendrix (sabreuse) 1:31 pm on January 10, 2013 Permalink | Log in to Reply

      +1 It’s really not a big deal to rebase now compared to not having a good history sometime later.

    • Tom Willmot 2:16 pm on January 10, 2013 Permalink | Log in to Reply

      +1 Do it. We run everything with WordPress as submodule, would not be hard to re-clone.

    • aaronholbrook 2:30 pm on January 10, 2013 Permalink | Log in to Reply

      +1, anything that would move us closer to using Git would be fantastic. Also not a big deal to re-clone if needed.

    • Chris Jean 3:00 pm on January 10, 2013 Permalink | Log in to Reply

      Sounds like a bandaid that needs to be ripped off. Better now than later when even more people use it.

    • mojowill 3:04 pm on January 10, 2013 Permalink | Log in to Reply

      I’d love to see a full move to GIT for everything on wporg!

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

      I’m all for the update in order to improve the history and prepare for a possible move to git. I’m wondering whether you plan to send a little message (could it be automated?) to all those who have forked the repo on github?

      https://github.com/WordPress/WordPress/network/members

      That would be hugely helpful in communicating the upcoming changes in case those people don’t read this blog (perish the thought).

      • Mark Jaquith 6:47 am on January 11, 2013 Permalink | Log in to Reply

        GitHub removed their private messaging feature, so I’d have no automated way of notifying everyone. This doesn’t concern me so much as we don’t accept pull requests on GitHub, so it’s not like their forks are functional in that way. I also think a lot of people fork repos and never update it from the upstream again. So they probably wouldn’t notice. And it’s easy enough to destroy it and refork it.

        What I was considering doing was putting a note on our project description on GitHub, for the next few months, providing a link to a post that explained what happened and how to resolve the divergent Git history.

    • Mark Jaquith 6:51 am on January 11, 2013 Permalink | Log in to Reply

      As the response was overwhelmingly positive (even from some of you who are traditionally serial devil’s advocates), I think we’re going to move forward with this. Thanks, all, for your feedback.

      What I’ll likely do it consult with various people (@bpetty, notably) about implementation, doublecheck the e-mail address in my authors.txt file (recommending that everyone use addresses at personal domains that they’re likely to control indefinitely), and then push out a WordPress-Fixup repo for people to audit, before pushing the new history to the WordPress repo.

      • Bryan Petty 7:02 pm on January 11, 2013 Permalink | Log in to Reply

        Confirming email addresses used would definitely be a good idea. I think a large portion of what you have now originally came from my list, which was meticulously put together from scouring plugin readmes, wp-hackers archives, and personal sites for publicly visible addresses since, at the time, I knew I wouldn’t be able to simply pull them from WP.org accounts used to make the commits (which would likely be the best source, aside from contacting everyone individually).

  • Mark Jaquith 9:04 pm on January 8, 2013 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.6: Distraction-Free Writing improvements 

    Distraction-Free Writing (DFW) made its debut in WordPress 3.2. It’s good, but it has some problems:

    • It’s hard to discover. A tiny button that doesn’t stand out from other buttons.
    • The transition is a bit jarring. Your content goes away, you land on another screen, and your content reappears. It feels like there is a cost to switching.
    • It isn’t as fully-featured as it should be. If it isn’t capable of easily (and by that I, I mean without keyboard shortcuts) doing the majority of the formatting people need to do while writing, people are going to be disinclined to use it.
    • It could use some polish. Some of the interactions are janky, and it’s not very responsive to large screens. There are strange issues that happen when you get to the end of a line or do a line break near the bottom of the editor. The Esc key doesn’t work when in TinyMCE. Lots of little stuff like that.

    What I need is someone with CSS skills and JS competency to take on a bunch of little improvement projects for DFW. If you have those skills and care about making a beautiful and functional distraction-free writing experience for WordPress, speak up!

     

    • Chris Wallace 9:08 pm on January 8, 2013 Permalink | Log in to Reply

      I’d like to help if you need me to.

    • Andy Stratton 9:08 pm on January 8, 2013 Permalink | Log in to Reply

      I’m interested and would like to get an idea of the list fo things to be done (CSS/JS). I’ll probably try to get @bmoredrew to help me too – anything we have competency and time to do I’m interested.

    • Jeff Bowen 9:11 pm on January 8, 2013 Permalink | Log in to Reply

      I don’t have the bandwidth to lead this, but I’d love to pitch in

    • ckhicks 9:11 pm on January 8, 2013 Permalink | Log in to Reply

      I’d be happy to help explore current/popular trends in DFW environments and provide research, if needed. This is one of my favorite WP 3+ features, and it is prime real estate for greatness!

    • Eric Mann 9:16 pm on January 8, 2013 Permalink | Log in to Reply

      I’d love to help, though it would be useful if we had a concise list of all of the “janky” interactions so we know what we’re committing to.

    • Zach "The Z Man" Abernathy 9:17 pm on January 8, 2013 Permalink | Log in to Reply

      I’m on board to help with this. And I agree with Eric Mann. A playbook on what we’re committing to would be great.

    • Mel Choyce 9:49 pm on January 8, 2013 Permalink | Log in to Reply

      Not a terrible amount of js competency, but I’ve got css skills and would like to help out with this.

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

        Similar skillset and would love to help with this one.

        There was probably talk about it already, but would moving full-screen button away from other buttons make sense? Perhaps next to Visual/Text tabs? Those two change the editor, so does full screen toggle.

    • theaccordance 10:01 pm on January 8, 2013 Permalink | Log in to Reply

      I completely agree with your assessment. The moment I found that the DFW toolbar lacked the ability to select headings I walked away from the Distraction-Free view; this is certainly something I’d like to see an improvement with.

      I just reviewed the full-screen views for a few apps on my Mac (which provide a similar experience to DF view), and with the exception of the top toolbar, the visual interactions remain fairly consistent. Would it be appropriate to approach the DF view in a similar fashion?

      Also, should consideration be given in DFW for additional functionality added to the normal TinyMCE via plugins?

      (Apologies if I should be bringing these questions up in a different location, I’m new and still getting acquainted with working on the core.)

    • adamsilverstein 10:18 pm on January 8, 2013 Permalink | Log in to Reply

      i’m in.

    • John Blackbourn (johnbillion) 3:37 am on January 9, 2013 Permalink | Log in to Reply

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

      As we have a lot of people willing to help, but none willing and confident to lead, and as this seems to be the least-well-defined of the features on the docket, it has been dropped as a scheduled feature and will instead be handled as the grab-bag of improvements that it is. I’ll work on getting it broken out into individual tasks and anyone interested should keep an eye out for “DFW” on Trac.

    • Robert Chapin (miqrogroove) 7:56 pm on January 14, 2013 Permalink | Log in to Reply

      Hi Mark, a less prominent yet important disadvantage of DFW is the lack of cross platform compatibility. iPad and other device support ahould be considered.

  • Aaron D. Campbell 1:07 am on January 8, 2013 Permalink | Log in to leave a Comment
    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.

  • Aaron D. Campbell 11:21 pm on January 7, 2013 Permalink | Log in to leave a Comment
    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.

    • 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 | Log in to leave a Comment
    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.

  • Mark Jaquith 7:42 pm on January 7, 2013 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.6: Autosave and Post Locking 

    I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

    Things this will likely involve:

    • Local storage of post data while editing, in-between autosaves and manual saves.
    • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
    • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
    • Probably some interaction with the team working on improving Post Revisions.
    • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

    @aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. :-)

     

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

      +1!

    • Jon Brown 7:46 pm on January 7, 2013 Permalink | Log in to Reply

      +1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.

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

        There’s at least one ticket that touches on that http://core.trac.wordpress.org/ticket/20299

        But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.

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

          Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).

    • Pippin (mordauk) 7:55 pm on January 7, 2013 Permalink | Log in to Reply

      Huge +1.

    • goldenapples 7:58 pm on January 7, 2013 Permalink | Log in to Reply

      +1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:

      • visualizing revision history as a tree rather than just a list (I look at vim’s :Gundo plugin as a rough UI example)
      • post meta as mentioned above, although that needs a LOT of thought (lots of postmeta is never shown in a meta box, or is not meant to be edited by authors…)
      • doing more to enable inter-user messaging along with the “heartbeat” autosave calls. Its possible to do something with websockets for the maybe 2% of sites that have that enabled, but for most people, the regular admin-ajax calls could be used to pass messages back and forth about what other users are viewing, if one user requests a release of the lock, etc.

  • adamsilverstein 9:07 pm on January 7, 2013 Permalink | Log in to Reply

    i’m interested in helping if i can

  • John Saddington 9:19 pm on January 7, 2013 Permalink | Log in to Reply

    omg. yes.

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

    And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.

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

      This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.

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

      Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.

      When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.

  • John Kleinschmidt 9:46 pm on January 7, 2013 Permalink | Log in to Reply

    I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.

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

    Excellent.

  • Grant Norwood 11:59 pm on January 7, 2013 Permalink | Log in to Reply

    Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.

    Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?

  • Gabriel Koen 9:18 pm on January 9, 2013 Permalink | Log in to Reply

    I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.

  • Mike Bijon 12:49 am on January 13, 2013 Permalink | Log in to Reply

    I’d like to help with this during this cycle too.

    Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.

  • Aaron D. Campbell 6:09 pm on January 7, 2013 Permalink | Log in to leave a Comment
    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.

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

  • Andrew Nacin 7:52 am on January 5, 2013 Permalink | Log in to leave a Comment  

    Call for testers. WordPress 3.5.1 is now in beta and we could use your help. (Use either the 3.5 branch in SVN, the WordPress Beta Tester plugin, or the nightly build (zip).)

    There’s about 30 tickets currently resolved, and another few we’re still working on. Here’s the full report of those. In particular, we could use help testing multisite rewrite rules. There’s a comment with testing instructions on the ticket, #23073.

     

  • Andrew Nacin 6:31 pm on January 2, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Impromptu 3.5.1 meeting in 30 minutes (19:00 UTC) in #wordpress-dev. Still upwards of 16 tickets to lock down. Would like to hit 3.5.1 beta by the end of the week.

     

  • Mark Jaquith 2:04 am on January 2, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    WordPress 3.6 Planning Session 

    I hope everyone enjoyed the holidays! We’re back to our regularly scheduled IRC meetings tomorrow, and are going to start by scoping and planning out the 3.6 cycle. Wednesday, Jan 2, 21:00 UTC. Please make every effort to attend! The theme I’m proposing for 3.6 is “Content Editing”, so especially start thinking about editing, editorial workflows, revisions, autosave, DFW, etc. Also be thinking about what you’d like to work on and how much time you can commit this cycle.

     

    • John Saddington 2:45 am on January 2, 2013 Permalink | Log in to Reply

      booya. this will be awesome. can’t wait to see what 3.6 brings in terms of content editing, especially for editors of blog and blog networks. bingo.

    • Japh 2:49 am on January 2, 2013 Permalink | Log in to Reply

      I plan to be there, Mark! Looking to be an excellent release. I like the proposed theme. Depending what it ends up looking like, I imagine features for this version will be very relevant for me.

    • nofearinc 8:49 am on January 2, 2013 Permalink | Log in to Reply

      this seems way more handy than the gallery functionality as it covers every single user and would lead to performance and UX improvement. Very exciting.

    • Sara Rosso 9:25 am on January 2, 2013 Permalink | Log in to Reply

      Exciting. I’m going to follow along closely on this one! :)

    • Ron Rennick 2:38 pm on January 2, 2013 Permalink | Log in to Reply

      I hope to attend but will miss the first of the meetup. After discussing the multisite roadmap at WPCS I went through most of the multisite tickets. For 3.6 I think it would be good if we went through and cleaned up some of the small enhancements and UX inconsistencies. I’ll have a few hours a week throughout most of the 3.6 cycle to work on those items.

    • David Tufts 3:53 pm on January 2, 2013 Permalink | Log in to Reply

      As far as the custom fields and custom meta boxes go, I would like to see extendable form elements in WordPress similar to the extendable widgets. There should be a base form element class that all other form elements can extend, allowing for all form elements in the custom meta boxes to be generated using built in WordPress elements like, date picker, color picker, editor, etc. This would include input validation and all the sql validation as well. I have added something similar to this in the KickPress plugin that is in the plugin repository. (http://plugins.svn.wordpress.org/kickpress/trunk/kickpress-form-elements.php)

    • mojowill 8:54 am on January 3, 2013 Permalink | Log in to Reply

      Interested to see where this goes!

    • ← Older posts

    c
    compose new post
    j
    next post/next comment
    k
    previous post/previous comment
    r
    reply
    e
    edit
    o
    show/hide comments
    t
    go to top
    l
    go to login
    h
    show/hide help
    shift + esc
    cancel