Make WordPress Core

Updates from Peter Westwood Toggle Comment Threads | Keyboard Shortcuts

  • Peter Westwood 11:16 am on February 4, 2013 Permalink
    Tags: ,   

    Revisions Update(s) for Last Week 

    These are combined and late (sorry).

    Last week we had two successful Office Hours discussions:

    We discussed the different mockups that both @adamsilverstein and @karmatosed have been working on with the discussions in the first meeting leading to some new mockups here: https://make.wordpress.org/core/2013/01/25/revision-update-125/#comment-7869

    And then @karmatosed created some further mockups after our second meeting bringing together our feedback and the different idea threads:

    Outside of the meetings our progress has been slow because most of us have been travelling for conferences / meetups

    Our next office hours are today at 16:00 UTC

    • John Saddington 2:09 pm on February 4, 2013 Permalink | Log in to Reply

      Just curious… are you guys using mockingbird mockup app for these? looks great!

    • Robert Chapin (miqrogroove) 7:42 pm on February 4, 2013 Permalink | Log in to Reply

      What’s the difference between Apply and Discard? Apply to what? Discard from where? What does it mean to discard a removal? I think this needs to be more verbose or more intuitive like Undo and Redo.

    • lessbloat 10:20 pm on February 4, 2013 Permalink | Log in to Reply

      I played around with an alternate concept this afternoon.

      My assumptions

      There are two major use cases:

      A) Undo a mistake I made

      B) Review changes & find mistakes other people have made

      With the major use cases in mind, here are the problems I see with the existing UI:

      1) With just a date/time stamp and author, there is no way to tell (at-a-glance) what revision you’re after from the post edit page, requiring you to click into revisions.

      2) Once you click a link from the post edit page, you are taken to a complete revision (without any comparison showing). This seems backwards to me. Seems like you should be taken to the comparison view by default. As you are oftentimes looking for mistakes, which are much harder to spot in the “complete revision” view.

      3) The “Revisions” table at the bottom is super confusing. 🙂

      4) It’s hard once on the revisions page to quickly move through additional revision sets.

      My rough proposal

      With those use cases and existing UI problems in mind, here’s what I came up with:

      Post edit page

      On the post edit page show more details related to each revision (base them off of comparisons with previous revisions):

      Or perhaps:

      Which adds:

      • gravatar (optional)
      • words removed
      • words added
      • total words (after add/removed)

      Revisions page

      Start off in comparison view:

      • Default to comparison view
      • Assume that the user wants to diff against the previous revision. We could add the advanced diff table selection option (with the radios) back in as either a screen option, or boot it to a plugin (it really is painful to use).
      • Allow them to quickly paginate through all revisions (“View Previous” button)
      • Give them a sense of which revision this is (out of all of them) with the black/gray dots at the top.
      • Change the paradigm from “older” “newer” to “removed” always on the left, and “added” always on the right.

      If you mouse over the black/gray icons, more info would show up in a tooltip:

      Then if you clicked the “View previous” button you’d see:

      Anyhoo… It’s still super rough, but I thought I’d through the concept out there.

    • adamsilverstein 5:03 pm on February 5, 2013 Permalink | Log in to Reply

      thanks for the new mockups!

      before reading your post, i created a ticket and posed patches that implement some of the mockup concepts we had talked about during office hours – #23396

      a few responses –

      i really like the idea of entering the revision screen already comparing to the previous revision, i never understood why we have the extra option of viewing a revision by itself.

      i still don’t understand the meta box on the post page, even if you can pinpoint the revision you want, which is doubtful, you still have to click into the revisions page to restore the revision. for this reason, and because of use case A, i think a link into the revisions interface belongs near the publish button, see #23352. i would just leave the meta box as is (hidden) and focus on the actual revisions page.

      i really like the next/back idea, especially if we can get the view refreshing without page reloads. this will make it easy to go back to find the exact revision a user needs.

      the little dot idea with popups, while nifty, is not really accessible. what do you think of the idea of a left column showing the list of revisions? ideally, i’d like to see these grouped when there are more than a certain number, either by user or by hour; otherwise the list becomes unwieldy on posts with many edits.

      i’m not sure i get the paradigm of removed on one side and added on the other, how will the user know what the post will look like when the restore the revision? willing to try, but i think i prefer the direction of a combined diff view with labels down the edge.

    • Midhun Devasia 7:37 pm on February 6, 2013 Permalink | Log in to Reply

      I had an idea about the revision change updates.

      What I’m thinking is that, when a user want to find what was changed
      1. Show the last changes in Revision meta box.
      2. And it should show the “Inline Diff” between last version and its previous version. (Comparing Side by Side or left right methods are more complex for normal users, I think they prefer Stoked text, wth color changes of what they deleted and what they added from the last change or revision )
      3. The revision meta should show the abbreviation of Big changes.
      4. If he is still can’t idenftify the changes he can link to the revision management page.
      5. Show atleast 10-20 revisions on the Revision Metabox, or else pagination/link to revision management page.

      The Above points are only for Revision Meta box as considered as Quick Reference of the revisions/changes what they made. can give restore link there too, if he find that was his revision.

      I had submitted a rough working patch for the above Inline diff method.

      Check my ticket.




    • esmi 7:50 pm on February 6, 2013 Permalink | Log in to Reply

      Still rather concerned about the colours being used here — both in the original screenshots & @lessbloats alternative concept screenshots. Can we look at using colours other than red & green? Red/green is the most common form of colour blindness, so this could potentially impact on 10% of all make users. See http://quirm.net/temp/revisions-cb2.jpg for an example of how the original screenshot would look to a user with red/green colour blindness.

      I’ve also analysed the foreground/background contrast on both the red & green test. Both fail the recommended 4.5:1 contrasts ratio. The red is 4.3:1 whilst the green only manages a really miserable 2.8:1. Anything below the recommended 4.5:1 ratio will hit visually impaired users (not all of whom use screen reading software) and about 50% of dyslexics.

      • Peter Westwood 9:12 am on February 7, 2013 Permalink | Log in to Reply

        Your concern is noted and not forgotten, our mockups have focused on the layout of the page and I want to try different colours once we have something implemented so as to address the accessibility issues.

  • Peter Westwood 9:42 am on January 23, 2013 Permalink
    Tags: ,   

    Revisions Update, Jan 22nd 

    This week the revisions team had our first in-person meeting and we started by setting out office hours for this cycle which are 4pm UTC on Mondays and Thursdays. We then went through and reviewed a large number of open trac tickets related to revisions to get a feel for the existing bugs and enhancement requests as well as to set down a line as to what we feel is and isn’t in scope.

    We ended our review with 8 “in-scope” existing tickets:


    • #16215 – Post Revision history displays the incorrect author
    • #20982 – Attribution of changes via edit_last after restore
    • #16847 – Capability check fails for custom post type revision edit (& map_meta_cap no good)
    • #9843 – Duplicate autosave/revisions clutter the database


    • #/22289 – Filter to override WP_POST_REVISIONS (or define it later)
    • #19932 – More context when display revision info for plugins
    • #18733 – Show revision number for post/pages in Revision list
    • #7237 – Multiple clean_post_cache() calls when saving a post due to post revisions

    We explicitly left the following out of scope:

    • #9681 – Add hooks to allow a plugin to support the deletion of unneeded revisions
    • #20564 – Post Meta Revisions
    • #20299 – Preview changes on a published post makes all post meta “live”
    • #11049 – Page Preview does not autosave page template

    After the trac ticket discussion we then talked about UI ideas and set ourselves some goals for this week:

    • More UI mockups – to come in the comment thread here
    • Start investigating and addressing some of the bugs

    Full logs of our IRC Chat are here

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

      I wonder how many people have had mega issues with post meta revisions and wanting that. Hmm.

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

        Plenty of people. Doesn’t make it in-scope, though.

        • Travis Northcutt 2:24 pm on January 23, 2013 Permalink | Log in to Reply

          Given that Alex King volunteered (albeit 9 months ago, so I don’t know if he has the time right now) to clean up what they built for inclusion in core, would it be feasible to get it in scope if the work is done by people other than Westi et al.? (Serious question – I’m not familiar with how much work a committer has to do once a good patch is presented for inclusion).

          • Bryan Petty 8:24 pm on January 23, 2013 Permalink | Log in to Reply

            Maybe, but it wouldn’t hurt to start patch reviews, testing, discussion and revising on the ticket either way. If it’s ready in time and there’s someone with the time to commit it, great, but otherwise, there will be that much less work involved with getting it included in 3.7.

          • Helen Hou-Sandi 9:09 pm on January 23, 2013 Permalink | Log in to Reply

            Indeed, there is nothing wrong with working on it, anyway.

    • Stephanie Leary 4:07 pm on January 25, 2013 Permalink | Log in to Reply

      For the diff UI: what if we had Visual and HTML options just like we do in the editor? The HTML view would show the markup, as we do now. The Visual would show only the content changes. Here’s a very old example using del and ins tags to emulate Word’s track changes feature (this was before Word switched to the bubble style it uses now).

    • adamsilverstein 5:30 pm on January 31, 2013 Permalink | Log in to Reply

      there was some discussion today that #20564 and #20299 are going to block progress on the workflow changes, we may need to reconsider those tickets if possible.

  • Peter Westwood 10:26 pm on January 20, 2013 Permalink
    Tags: ,   

    Revisions Update, for 18th Jan 2013 

    As Aaron posted before the revisions team has two clear focuses:

    • Fixing the Author Attribution issue – #16215
    • Improving the usability of the differences for the average user.

    So far most of our discussion has been in the comment thread of Aarons post and I want to catch up on the in-person discussion and start in earnest on fleshing out the direction.

    To that end I’m going to spend the majority of Monday the 21st working through the current ideas and also reviewing any revisions related trac tickets to pull together our direction and I invite all interested parties to join me for a discussion session starting at 1400 UTC on #wordpress-dev.

    It would be great if @karmatosed, @ethitter, @adamsilverstein could all be there and we can also arrange when our regular office hours will be.

  • Peter Westwood 9:44 am on February 11, 2012 Permalink

    Team Update: XML-RPC (Friday)

    We finished our first cycle last week and the implementation of the CRUD functions for Posts (and all Custom Post Types) has been committed to trunk see #18429 for more info.

    For our second cycle we decided to focus on CRUD for Taxonomies and Terms taking the patches from GSOC and iterating on them we are using #18438 as the tracker ticker for a single patch to cover all the different methods.

    We also decides to put more focus and effort into unit testing this cycle and have started creating some XML-RPC test case for existing/new functionality.

    Relevant Tickets: #18438, #18439, #18440, #18441, #18442, #18443, and #18444

    Office hours: 5pm-6pm UTC Mon-Fri

    • Ahmad Awais 1:31 pm on February 12, 2012 Permalink | Log in to Reply

      WordPress is taking part in GSoc 2012 ? If so , i am good in PHP , how can i join WordPress as a student for GSOC 2012.Guide me what can i do.I have 2 or 3 simple plugins written for WordPress by myself.
      Any help will be appreciated.

      • Aaron D. Campbell 4:26 pm on February 14, 2012 Permalink | Log in to Reply

        He’s talking about GSoC code from last year, but yes I think the plan is to participate again. There will be plenty more info on how to apply as the time gets closer (probably after WordPress is officially accepted to participate).
        If you’re looking for ways to increase your chances of getting chosen, I’d recommend trying to tackle some tickets on Trac (https://core.trac.wordpress.org/) so that you can point us to tickets that you’ve worked on. It’s a great way to show your coding chops and also get a feel for how the project/community works.

        • Ahmad Awais 4:45 pm on February 14, 2012 Permalink | Log in to Reply

          Thankx for your kind and informative reply , can tell me in tackling the tickets how cna i find help ? any tutorials available except codex and let me know how to adhere to the basic features of trac … how to use it , how to provide a patch how to test etc

  • Peter Westwood 7:49 pm on February 4, 2012 Permalink

    Team Update: XML-RPC (Friday)

    We made great progress this week continuing our focus on the major ticket for implementing wp.newPost (#18429) and working to keep the other bits of this API supporting the same formats. Our 2 week cycle ended on Friday and we are really close to having a patch ready for commit but didn’t quite make it in time. The team are continuing work on the patch and will re-group on Monday to review progress and plan the next cycle.

    Relevant Tickets: #18429, #18430, #18431, #18432, #18433
    Office hours: 5pm-6pm UTC Mon-Fri

  • Peter Westwood 10:49 am on January 28, 2012 Permalink
    Tags: ,   

    Team Update: XML-RPC (Friday)

    The XML-RPC team is working on the implementation of an wp namespaced api for XML-RPC to allow the Creation, Read, Update and Delete of Posts/Pages or any CPT. We are focusing on a tight integration in naming and behaviour with the core WordPress apis and avoiding strict one to one backwards compatibility with the older MetaWeblog/Blogger post creation apis so as to create a simpler more consistent api.

    Relevant Tickets: #18419, #18430, #18431, #18432, #18433

    Some of the tickets have existing patches we are happy with and some we are reworking, our primary focus for the first week has been implementing wp.newPost (#18429) and reviewing the other tickets. Once the implementation for wp.newPost is complete the other APIs should come together quickly.

    Office Hours: TBD – I will post these once we have them

    • Peter Westwood 2:53 pm on January 28, 2012 Permalink | Log in to Reply

      We are going to try “Office Hours” of 5PM-6PM UTC every weekday so as to keep in touch and be available for questions – at least one of us will be there with more than one of us most days.

    • Prasath Nadarajah 4:53 pm on January 29, 2012 Permalink | Log in to Reply

      I think #18443, #18444 should also be added to use these functions.

      Why we are not concentrating on custom taxonomy management in this release. Without that we will be limited to the terms already in the site.?

      • Peter Westwood 8:56 am on January 30, 2012 Permalink | Log in to Reply

        Those tickets are definitely ones we will consider for our next 2 week iteration but for the first iteration we are concentrating on the Create, Read, Updated, Delete for “Posts”. We are looking at simple term management as part of the Create/Update APIs to see if we can include a simple create on set mechanism there as well as looking at more fully featured APIs later.

  • Peter Westwood 3:43 pm on November 3, 2010 Permalink
    Tags: intertrac,   

    I have had InterTrac linking enabled from the Core trac to a few others and back the other way (previously the core trac had a minimal configuration).

    You can now refer to changesets and tickets in related tracs as follows:

  • Peter Westwood 9:18 am on November 2, 2010 Permalink

    I added a little to the file naming section of the WordPress Coding Standards to clarify the way in which we name our class files.

    In summary class files will be named using hypen separation and based on the class name they contain.

    I won’t be changing the name of old files but have updated the files we added in 3.1 before it’s too late.

    • Mike Schinkel 10:00 am on November 2, 2010 Permalink | Log in to Reply

      Glad you posted this. I’ve been meaning to ask and this seems like a great time. In core, some functions use a leading ‘wp_’ like wp_insert_post() whereas other functions don’t, i.e. update_post_meta(). Try as I might I’ve not been able to decipher a pattern but I’m sure one is in there I just haven’t been able to grok it.

      So when and why does a core function get a wp_ prefix and when not? Also, if there is legacy involved and some functions don’t follow the rationale, will they be cleaned up over time?

      This one has bugged me for a while… Thanks in advance.

      • Ozh 10:26 am on November 2, 2010 Permalink | Log in to Reply

        I think at the origin the wp_* functions were more private stuff used within APIs, but this has evolved without real guidelines

        • Mike Schinkel 10:45 am on November 2, 2010 Permalink | Log in to Reply

          Thanks for the reply. Would it make any sense to start some guidelines if none exist? If there are none it would seem like wp_ prefix might be consider reserved so a best practice would be to never name a function or variable starting with wp_ and then WordPress would be free to use that namespace for future enhancements?

        • Peter Westwood 10:47 am on November 2, 2010 Permalink | Log in to Reply

          @Mike: Actually best practise is for plugins/themes to prefix everything with something. That way they never clash with core or each other.

          I tend to prefix with my initials or the plugin slug.

    • Ozh 10:25 am on November 2, 2010 Permalink | Log in to Reply

      Any reason for the file naming scheme other than having something consistent and pretty to the eye?

      • Peter Westwood 10:28 am on November 2, 2010 Permalink | Log in to Reply

        I went with consistency to the existing rules which stated separate with hypens and just documented the current practises.
        Personally, I prefer the class. and functions. that BackPress uses but I also don’t see a need to change WordPress in that direction – what we have works fine.

        • Andy Skelton 7:36 pm on November 2, 2010 Permalink | Log in to Reply

          I value filenames that can be autocompleted with few keystrokes. My only material objection to a new filename is one that increases the number of keystrokes to access an old file.

    • scribu 4:05 pm on November 2, 2010 Permalink | Log in to Reply

      For context: #15280

    • Jacob Santos 6:12 pm on November 2, 2010 Permalink | Log in to Reply

      else if or elseif section:
      “Both notations are used in conjunction with curly brackets, there is no rule which to prefer. elseif can save you some hassles sometimes.”

      Problem 1: WTF?

      Problem 2: The point of a standard is to specify which is used for consistency. This is not a standard and therefore does not belong.

      Problem 3: elseif vs else if is only a problem when using if() : elseif() : else: endif;. Since this is rarely if ever used in WordPress, it makes more sense to use “else if” instead.

      “If you forget an equal sign it’ll throw a parse error instead of just evaluating true and executing the statement. It really takes no extra time to do, so if this saves one bug it’s worth it.”

      These bugs are certainly hard to find, however, if this is the case, then it also makes sense to never have any assignment in the if statements. This may go against the previous rule where variables aren’t created unless they are used more than once. It is worth it for consistency. It should be noted that assignment already exists in the if statements now confusing the standard.

      The “Self-Explanatory Flag Values for Function Arguments” Section.

      Most people solve this by simply using constants, it might be something to look into.

      • Andrew Nacin 7:21 pm on November 2, 2010 Permalink | Log in to Reply

        I’m working on a new coding standards document. In it, I’ve proposed s/else if/elseif/ and I plan to make that change across core.

        I don’t mind assignment in the if statement. We just need to be worried about left-hand comparisons.

        Re: function arguments: I’d rather a string any day.

        • Jacob Santos 8:19 pm on November 2, 2010 Permalink | Log in to Reply

          The mistaken assignment is most often a novice mistake and often corrected with simple peer review. When you have assignment in an evaluation statement, it confuses the reviewer as to whether you made a mistake or if it is intentional. It is considered best practice in that instance to always do assignment outside of evaluations for clarity and to let those reviewing the code know that you’re not making a mistake.

          Coding standards aren’t always preference, when working with others they should be considered for ease of review, clarity, beauty, and preference last.

          It also appears that certain aspects are being drawn from compiled languages and applied to interpreted ones without discerning why certain standards are applied to compiled and why those similar instances do not apply to languages like PHP.

        • hakre 11:13 pm on November 3, 2010 Permalink | Log in to Reply

          @nacin – I asked multiple times when the coding standard gets actually applied it to the wordpress codebase. I even offered help for that multiple times but I can not see any traction for months. Shouldn’t this something be done prior to a new point release? Is this actually something to expect or is the coding standard just to fill up a codex page?

        • Peter Westwood 8:09 am on November 4, 2010 Permalink | Log in to Reply

          @hakre: Coding Standards are always a guide. It is a waste of everyones time and effort going back and applying them to legacy code.

          They are all about promoting consistency going forward.

          We do not need to create unnecessary churn in the codebase as this just increases the test burden.

        • hakre 1:59 pm on November 4, 2010 Permalink | Log in to Reply

          The argument of legacy code can be left aside. The coding standard is not applied to new code as well. This might be about promoting something but not about actually doing it.

          But I didn’t pose my question that some might think they need to defend themselves, I mean this package is the work of many and as peter stated, this is all about promoting consistency going forward.

          Instead I wanted to find out if we can see some traction for this in the near future or not?

          We last talked about the coding standards before the hiatus and it was said that it will become applied to the codebase (IIRC the statement was by you Nacin). At least it sounded like quite a plan. This was somehow related to the sourcecode documentation on the wordpress website, this probably helps you to remember what I mean.

  • Peter Westwood 12:09 pm on November 1, 2010 Permalink

    Suggest Agenda items for Nov 3rd 2010 dev chat 

    Suggest agenda items for this weeks developer chat.

    Please note the new day and time – Wednesdays at 16:00 UTC

  • Peter Westwood 7:54 am on September 30, 2010 Permalink

    Suggest Agenda Items for today’s meet-up
    Please keep them on-topic

    • demetris 2:48 pm on September 30, 2010 Permalink | Log in to Reply

      Before trying to get feedback from plugin/theme authors and translators about my idea for an approach that would make it easier to translate plugins/themes, I would like to know what core contributors think about it.

      Proposal: Pool of common strings for core, themes, and plugins


      As I explain in the ticket, what would this mean for core, as far as I have thought it out, is designating a few dozen commonly used strings as strings for common use and not liable to change, and copying them over to a new file.

      I don’t know if this needs to be discussed in a dev meetup or if we can just use the ticket. Whatever people think.

      • Jane Wells 6:40 pm on September 30, 2010 Permalink | Log in to Reply

        Let’s use the ticket, so that time zone/availability won’t be a barrier to participating in discussion.

    • scribu 6:09 pm on September 30, 2010 Permalink | Log in to Reply

      Admin menu API. #14666 which led to #12718

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar