Make WordPress Core

Updates from December, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 5:43 am on May 3, 2013 Permalink
    Tags:   

    Hello everyone! Applications for Google Summer of Code are due in just 13 hours! (1900 UTC)

    I’ve been reviewing a lot of proposals and ideas. But if you’re waiting until the last minute (like I’m doing with this post), here are some random nuggets:

    • Original ideas are encouraged! We have a great ideas page but we’re not going to complain if you submit something else.
    • You don’t need to be a computer science student! We’ve had liberal arts majors and things turned out just fine.
    • Please demonstrate your abilities by making an attempt to contribute to WordPress core or by writing a plugin. Even though this may happen after applications have closed, it could help.
    • You can submit more than one proposal. This is good because we won’t accept two students for the same proposal. And because you might have two great ideas but aren’t sure which one aligns better with our interests. That’s okay — submit them!

    Finally, here are four more ideas in case nothing else appeals to you. (I’ll make sure these make it onto the ideas page next year.) If you’re still hunting, see if any of these set off bells in your head: (yes, there are WordPress plugins for everything, but innovation and new approaches are good things)

    • Activity. Activity streams, action history, notifications. Imagine what a dashboard could look like for a busy, multi-author site, and how helpful it could be to see what’s truly going on “right now” — as well as what you missed.
    • Meetups. Local WordPress communities organize a lot of meetups. A set of tools for organizers and the local community could be really helpful. (These tools could include integration with meetup.com and wordpress.org profiles.)
    • Dependencies. Allow plugins and themes to be dependent of one another. A theme could require a plugin or example, and WordPress would handle installing that plugin when you install that theme. Similar idea: Compatibility metrics. (Or: Can we be sure it is safe to upgrade everything?)
    • Bug tracker. WordPress can be a great platform for developer tools. Why not a bug tracker? (Read the 2010 ideas page for more.)

    Of course, there’s a lot of other great ideas on the 2013 page. If you haven’t looked recently, I added a few at the start of the application period, including some JavaScript-heavy stuff (editor modes, HTML5 application cache, TinyMCE views). Good luck!

     

  • Lance Willett 4:25 pm on April 23, 2013 Permalink
    Tags: , ,   

    Twenty Thirteen project update, April 23, 2013 

    The focus for Twenty Thirteen right now test, test, and test. Polish, polish, and polish. The IEs, RTL, testing with lots of popular plugins. Getting things working smoothly with the new core post formats functionality.

    Priorities

     

  • Erick Hitter 9:45 pm on February 19, 2013 Permalink
    Tags: ,   

    Revisions Update, 2/19 

    Following two consecutive days of office hours, we’ve reached a consensus on what the UI should be for comparing a single revision to the current version of a post:

    comparing-one

    Based on the above mockup from @karmatosed, @adamsilverstein is continuing development of the new revisions interface on ticket #23497.

    Once we have an acceptable, working prototype, we’ll revisit how to present the interface for comparing two different revisions. @nacin suggested, and we generally agreed, that a single slider with two grabbers would likely be a workable approach, but we’ll discuss that further once the above interface is implemented.

    No progress to report on the other tickets scoped for 3.6 as we’ve been focused on UI lately.

    [IRC log]

     

    • Ben Tremblay 9:58 pm on February 19, 2013 Permalink | Log in to Reply

      1st thought: the chunks appear w/o context. (I imagine it with a snippet of before and after.) You okay with that?
      #JustSayin’

      • Grant Palin 10:50 pm on February 19, 2013 Permalink | Log in to Reply

        Agreed, context is important. Just where in the document the shown snippet is located can make a dig difference.

      • adamsilverstein 11:27 pm on February 19, 2013 Permalink | Log in to Reply

        yes, for sure.

        although the mockup doesn’t make it clear, you will actually see your full document content, showing what has been removed, added (and what stayed the same), so the context is shown.

      • Peter Westwood 3:23 pm on February 21, 2013 Permalink | Log in to Reply

        The chunks appear without context because the mockup happens to show a full post rewrite :)

    • aldo.roman 7:11 pm on February 20, 2013 Permalink | Log in to Reply

      I follow the GIT (or others) DIFF as the mockup shows a ‘ + ‘ and a ‘ – ‘ signs, but I don’t think the end user will need them. Maybe the colours is enough and we can have a cleaner screen.

  • Mark Jaquith 4:46 pm on February 19, 2013 Permalink
    Tags:   

    Dropping Editorial Flow 

    I’ve decided to drop the Editorial Flow feature from the 3.6 roster. A few things happened. We looked into what the main feature (“forking” a published post and allowing it to be edited then reintegrated) would involve, and found that there were some really fundamental hurdles that were unlikely to be resolved in the time given. A lot of time was spent on the planning stage, and we just kept surfacing more questions. Moreover, because the hurdles were so low-level, they would have required a significant amount of time from a core lead like me, @nacin, or @ryan — time that we just didn’t have to give this cycle due to other responsibilities. What that left was #12706 — a somewhat related ticket with a long-running monster patch. This similarly needed (and still needs) a core lead to dedicate a lot of time to planning, reviewing, and committing it. That might happen, or might not. It didn’t seem fair to keep @danielbachhuber and @kovshenin responsible for something that might or might not make it, subject to other people’s availability.

    Though disappointing, this effort wasn’t wasted. We learned a lot about the challenges involved, and we’re better positioned to tackle it in the future with more advance planning and a better understanding of the core team resources that need time dedicated to it.

     

    • Alison Foxall 4:49 pm on February 19, 2013 Permalink | Log in to Reply

      Understandable. I had been loosely following what was going on and it just seemed like a huge task to undertake. Looking forward to getting more involved in the future.

    • Marko Heijnen 4:58 pm on February 19, 2013 Permalink | Log in to Reply

      I guess for 12706 it makes sense to develop it on Github. Like what happend with WP_Image_Editor. You still get an monster patch in the end but the changes can be better maintained. If I would make a change on the code now literally no one would find out precisely what I changed.

    • scribu 5:18 pm on February 19, 2013 Permalink | Log in to Reply

      Is there some place where the lessons learned from the planning stage are summarized?

      At the very least, links to some IRC logs would be good.

    • Robert Lilly 8:45 pm on February 19, 2013 Permalink | Log in to Reply

      Sorry to hear this won’t make it into the next release, but glad to realize that the issues involved are being thought through and that this will be addressed in the near future. I think this is a feature that is really needed whenever there is more than one person involved in creating/editing/maintaining posts.

      In my fantasy I’m imagining something like the Review feature of Microsoft Word, specifically the Track Changes and Add Comments functions.

  • Mike Schroder 6:49 pm on February 13, 2013 Permalink
    Tags: ,   

    Autosave and Post Locking – 2/13 

    This is a rather late update, and will serve for the last two; apologies!

    Last week, we talked about the locks that went in, and @markjaquith suggested that we replace the “lock” with a Gravatar, which I like quite a bit. Will experiment with that to see if it can work.

    Today we chatted about the most recent update to #23220 posted by @azaozz, which integrates the work done by @asannad (AmitSannad on IRC), and adds a UI for selecting which you’d like to restore: localsaves_screenshot

    In addition, if it’s found that you have an autosave that has failed, and have a newer version locally, you’re warned (either on the Posts list or Post itself), and linked to the UI that allows you to restore the content (post content and title only) and save at will:
    posts_Warning

    It was brought up during the chat by @nacin that the UI included in the patch might be more than we need, and that we should decide what is best for the user regarding restores, and perform it for them. We continue to chat about this, and opinions are welcome!

    Lastly, there is a patch from @mintindeed on #23295 currently waiting for integration! That patch, and the one on #23220 could use some testing — let us know if you run into problems on trac.

    We’ll be meeting again this Friday at 2100 UTC (1pm PST).

     

    • Gabriel Koen 7:28 pm on February 13, 2013 Permalink | Log in to Reply

      Oops I missed today’s meeting.

      I am working on some revisions to my patch based on feedback from last week’s meeting, unfortunately work is killing me this week so it will probably be the coming weekend (Feb 16–17) before I get a revised patch up there.

  • Daniel Bachhuber 1:52 am on February 8, 2013 Permalink
    Tags: ,   

    Editorial Flow Update, 2/7 

    Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

    For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patch commit-ready.

    For the second, the biggest question was how we should handle revisions for post meta and taxonomy terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in core will receive this by default.

    Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

    Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

    Office hour log

     

    • Jon Brown 2:12 am on February 8, 2013 Permalink | Log in to Reply

      Initially I was disheartened that you guys were dropping metadata support, but read the irclogs and it makes sense and I’m glad their are still advocates for adding it back in later.

      All of which I share only to say, THANK YOU, for such an open and transparent process. Really all the teams are doing a fabulous job and all the communication is hugely appreciated, so thank you for that and all the great work.

    • Erick Hitter 2:21 am on February 8, 2013 Permalink | Log in to Reply

      Tuesday office hours conflict (for me) with the WordCamp Base Theme chat, so I’ll note here that meta revisions are not in scope for 3.6.

      While the relevant tickets (#20564 and #20299) marked as 3.6, we’ve spent a good deal of time on UI/UX, and that will likely continue to be the bulk of our focus for this iteration. @nacin marked both as 3.6 because they block #23314, but we (@westi, @adamsilverstein, @karmatosed, and I) don’t have the availability to address them at this time.

    • crushgear 4:16 pm on February 11, 2013 Permalink | Log in to Reply

      Hi Daniel — you previously requested for some workflow examples. Here’s an example workflow from a WordPress.com VIP publisher:

      1) Writer puts text in WordPress and saves as “pending review” so the editor knows its ready.
      2) An editor goes in and edits the text in WordPress and schedules the post to publish, or publishes immediately if breaking news.
      3) The post goes live. 
      4) A producer goes in and updates the appropriate fields, if they are not already filled out (category, social text, SEO headline etc). Also could fix any typos found post-launch. Probably wouldn’t need approval before going live.
      5) A photo editor goes in and adds a featured image (these changes could go live without approval) and updates the post.

      Revisions:

      • Occasionally they post corrections after a story is published and those changes would need approval.
      • Occasionally they do rolling posts where they update the text or photos as an event goes on. Those updates may or may not need to be reviewed before publish.
      • Often they have rolling photo galleries where they add a photo each day as more photos come from the wire. Those changes they’d want an editor to review before updating the post.

      Suggestions:

      • It would be nice to have the ability to delete a revision without deleting the live post.
      • It would be nice to have the ability to schedule a revision to go live, so that an update can push without a person waiting around.

  • Erick Hitter 11:21 pm on January 25, 2013 Permalink
    Tags: ,   

    Revisions Update, 1/25 

    Yesterday, the revisions team had its second scheduled office hours chat in #wordpress-dev at 1600 UTC. @karmatosed and I were both afk, and our first chat was earlier this week, so it was a short meeting [IRC log].

    @nacin popped in to mention that he’ll be working on the API for draft changes to published content. This will overlap with, but shouldn’t take away from, the revisions efforts our team is working on. For reference, the ticket’s we’ve scoped for 3.6 are listed here.

    Overall, progress this week has been tentative, mostly focused around #16215 and #16847; thanks to @adamsilverstein for his efforts on those tickets thus far. A big area of focus in the near-term will be the UI improvements—there’s been a fair bit of discussion on this front in the comments here and here.

    Our next meeting is Monday, January 28, at 1600 UTC. At the moment, our office hours on Thursdays conflict with the Post Formats team, so one of us will have to move. We’ll keep the hours listed in the sidebar updated as we move forward.

     

  • Mike Schroder 11:17 pm on January 25, 2013 Permalink
    Tags: ,   

    Autosave and Post Locking Update, 1/25 

    We had our scheduled meeting today in IRC to continue planning the feature for this cycle.

    @azaozz noted that he’s continuing work on the Heartbeat API #23216, on schedule for initial commit before next week.

    I am continuing work on an initial pass for the post/page tables to display locks, and properly display edit/bulk edit links when locked. Should have an initial pass ready for view on Monday.

    @mintindeed offered to help port his plugin to core for improved login expiration warnings, which is great! He’s created #23295 to track the efforts.

    @asannad (AmitSannad on IRC) offered to help with localstorage Autosaves, which is being tracked on #23220. Initially, we’ll use a simple schema for storage, but will probably need something more complex later on to avoid collisions where multiple databases are used within the same domain.

    As initial guidance for improved workflow for locks, we’re looking over the plugin mentioned in #18515. @nacin is checking with the authors to see if there’s a new version we can take a look at.

    Our next meeting is on Tuesday, January 29th at 2100 UTC (1pm PST).

     

  • Daniel Bachhuber 7:34 pm on January 24, 2013 Permalink
    Tags: ,   

    Editorial Flow Update, 1/24 

    Kovshenin, Nacin and I chatted today in IRC about scope for editorial flow in 3.6. To help narrow things down, we’re now focusing on two things:

    1) “Finishing” the existing API such that you can register new post statuses with expected results (no bugs, etc.).

    Last week, Nacin and I had a long conversation about how enhancing the post status API in various ways could lead to complex, fully-featured workflows. We discussed again yesterday after the core IRC chat, and decided these enhancements still need more conceptual development. Instead, we’ll be focusing on the extent of #12706′s description:

    A developer should be able to register a custom post status using register_post_status(). The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to ‘draft’ and ‘pending’ statuses in core that should properly use the post status API.

    All existing arguments to register_post_status() should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.

    I hope to have a working, testable implementation of this by next week, using existing patches and maybe some new code.

    2) Allowing already published posts to be revised without being updated immediately.

    We discussed a few possible implementations of this. Our conclusion is to go with the simplest possible implementation, as there are already a few plugins to handle more complex implementations.

    Right now, it’s looking like this: a ‘draft revision’ can be created of an already published post. If a ‘draft revision’ of a post exists, it will appear in the post editor (instead of the published content). Anyone with appropriate permissions can make edits to the ‘draft revision’ without having those changes go live. Then, at some future point, the ‘draft revision’ can be pushed live to take the place of the original published post.

    Kovshenin will be working on wireframes for this over the weekend.

    We want your help!

    • What use cases do you have for the second, user-facing feature? The more details you can provide, the better.
    • Have you come across software which does the second piece well? Notably, it would let users easily choose between pushing their update live immediately, or continuing to work on and save their changes as draft.

    The next office hours will be Tuesday, January 22nd at 10 am PT / 1 pm ET / 1800 UTC.

    https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-24&sort=asc#m539794

     

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

      2). This is something I have really wanted for a long time, excellent!

    • Cliff Seal 7:51 pm on January 24, 2013 Permalink | Log in to Reply

      “What use cases do you have for the second, user-facing feature?”

      One example would be updates to breaking news, especially inside a larger news organization where there’s a review process. As news becomes more real-time (for better or worse), the space between updating a single post and live blogging will become more populated.

      • Daniel Bachhuber 8:00 pm on January 24, 2013 Permalink | Log in to Reply

        @Cliff How does the review process work now, and how would it ideally work?

        • Cliff Seal 1:18 pm on January 29, 2013 Permalink | Log in to Reply

          Sorry I missed your question here. It’d seem the second feature would be the ideal way to handle it—instead of the post, as a whole, being set to ‘Pending Review’ (or whatnot) and staying private until a reviewer publishes, an already published post could stay that way while a revision itself could be set to ‘Pending Review’ and be updated at will.

    • Knut Sparhell 8:27 pm on January 24, 2013 Permalink | Log in to Reply

      This ‘draft revision’ will be available for pages, too. I presume. For sites that need to update their more or less static content, this will provide a clean way to update, instead of creating a new page with a new permalink.

    • hereswhatidid 8:42 pm on January 24, 2013 Permalink | Log in to Reply

      2) Use Case

      • I have had a few sites where the client needs updates for any content to be run through several groups of people before it can be safely deployed. Having a “Revised Draft” status that could be viewed by specific user groups when they’re logged in would be very helpful. Perhaps a status indicator in the ribbon bar would be a good way to show what version you’re currently looking at.

      • Daniel Bachhuber 9:29 pm on January 24, 2013 Permalink | Log in to Reply

        Just out of curiosity: how does each user sign off on the content?

        • hereswhatidid 9:35 pm on January 24, 2013 Permalink | Log in to Reply

          Currently the review approval is handled via email and the changes are posted to staging environment for review. Once they are approved, the site admin goes in and publishes the update. But, just having the ability to show a preview version on the live site would cut out the need for the staging site entirely which would be a big improvement.

          I’m not sure having a system that would actually be able to deploy content only after specific users/groups have approved the content would be worthwhile to implement in the core. That would most likely still fall into the realm of a plugin. Just having the ability to save a Revised Draft which can be previewed would be something useful across the board.

        • krogsgard 9:58 pm on January 24, 2013 Permalink | Log in to Reply

          Permissions for publish_revisions and edit_post/page_revisions vs publish_posts/pages and edit_posts/pages could take care of this. Let plugins / devs / members plugin take care of roles, other than defaults for editor / author, etc.

          Triggering an email for when a revision gets sent to a pending status to the published post author would be awesome too.

    • Konstantin Kovshenin 7:38 am on January 25, 2013 Permalink | Log in to Reply

      I worked with a few companies before where “bosses” were very sensitive about what information goes out there, so they had to sign off each piece. It was easy with posts and drafts, but published pages for sections like “our mission”, “about the company”, etc was a huge pain, because changes went in Microsoft Word first, signed off and then copy-pasted into WordPress.

      Also, contributors wanting to make changes to their published posts is another obvious one.

    • Simon Dickson 10:42 am on January 25, 2013 Permalink | Log in to Reply

      Use case for no2: we’ll still need to keep the option to edit the ‘live’ post, even if there is a revision in draft.

      You can imagine: you might be mid-way through a substantial edit of a published post, or maybe you’re awaiting approval from someone. You suddenly realise there’s a factual error in the already published version. You aren’t ready to publish the new version in its entirety, but you can’t leave the error on the live site.

      We’re almost talking about Git-style branching, in effect – a ‘master’ version (live), and a ‘development’ version (revision in draft). Maybe there’s a UI lesson there?

    • Ben Huson 10:57 am on January 25, 2013 Permalink | Log in to Reply

      “What use cases do you have for the second, user-facing feature?”

      Use cases I can think of or have experience of are:

      1. Updating page content to reflect a season change – ie new products etc
      2. Updating pages to reflect a company change on a specific date – ie acquisition, annual report etc

      I’ve used some bespoke CMS systems where a draft is created whenever you edit a published page and then you choose to save (as a draft), publish or schedule.

      Would you be able to Schedule a draft revision as that would be very useful?

      I feel that a content approval workflow would be best handled by a plugin.

    • Ryan McCue 11:19 am on January 25, 2013 Permalink | Log in to Reply

      One place where I’ve seen this sort of thing is with MediaWiki with extensions: http://www.mediawiki.org/wiki/Extension:Approved_Revs or http://www.mediawiki.org/wiki/Extension:FlaggedRevs

      It looks those have an “approve” button next to revisions newer than the current published one, which I think could work. Perhaps if we add a new side metabox that lists revisions newer than the last published revision with approval and diff links.

      (Ideally, the way this would work is that posts would be mere pointers to a revision, and publishing would bump the post pointer to the latest revision. This is similar to git branches, where “master” e.g. is just a pointer to a specific commit, and committing to that branch makes a new commit and then bumps the branch. For WordPress, we could do similar but basically make the approve button sync the post to the revision.)

      • Daniel Bachhuber 1:14 pm on January 25, 2013 Permalink | Log in to Reply

        We discussed this some in IRC, and I’d be willing to have the conversation again, but I think the Git style approach is a little too complex and still plugin territory.

        In particular, it seems like most of the named use cases don’t require this degree of complexity.

    • cvernon 3:43 pm on January 25, 2013 Permalink | Log in to Reply

      Use case for 2) involves what is currently [imho] a bug: when you edit images, featured or attachments, custom fields or any other changes that are made at the db level through ajax to the original post, they are reflected on the front end immediately, without even needing to hit Update.

      One thing we did in a custom CMS platform a few years ago to avoid this is that all editing is actually done to a copy of the post, and then when saving the copy is saved back to the original. I would strongly suggest we take advantage of this new feature to fix this current bug. Then, if you change images or custom fields, and then abandon the edit, we just throw away the duplicated ‘draft’ post + meta + attachments. This means a major rework because when deleting images from a post, the deleted images must be a copy so that they are not lost if we decide to stop editing or not go through with the changes.

      Hope this helps.

    • sourceforge 4:21 pm on January 25, 2013 Permalink | Log in to Reply

      thank you @daniel and @nacin, daniel @ vip and nacin @ wporg have been pulling things, thanks for the help!

    • Jeremy Felt 3:21 am on January 26, 2013 Permalink | Log in to Reply

      I haven’t seen this exactly expressed yet, so tossing it out there. More conceptual, but also related to dealing with the current status stuff in core.

      It seems that the current core post statuses (draft, pending, publish, future, private, trash) are pretty good indicators of a post’s current state in the system.

      Most (all?) of the use cases for custom post statuses appear to fit under the umbrella of one of these post states, though with nomenclature that describes different parts of a custom worlkflow.

      Would it be plausible to introduce the idea of attaching a post state to a post status when it is registered? This could allow current parts of core relying on these states to stay useful – though status/state naming is confusing – while also accounting for new workflows.

      It would also be nice to see the ability for multiple post statuses to be assigned at once, which a structure based around states should allow for.

      • Daniel Bachhuber 5:44 pm on January 27, 2013 Permalink | Log in to Reply

        Correct me if I’m wrong, but I believe what you’re talking about is actually something Nacin and I discussed on 1/18: abstraction of post status special capabilities. For instance, ‘future’ has a special capability of transitioning between two statuses at a specific point in the future.

        We made the determination that the idea needs fleshing out conceptually before we can dive into it practically, so that type of enhancement is now out of scope for 3.6

        It would also be nice to see the ability for multiple post statuses to be assigned at once, which a structure based around states should allow for.

        This is probably outside the scope of any enhancements at this point.

    • Patrick Daly 3:28 pm on January 28, 2013 Permalink | Log in to Reply

      While not my CMS of choice, Sitecore has a very robust workflow system. Rather than write all out here you might want to review everything they have: http://sdn.sitecore.net/upload/sitecore6/workflowreference-usletter.pdf

  • Jen Mylo 4:50 pm on December 24, 2012 Permalink
    Tags:   

    Team Reps 

    Heya. Now that we know Mark will be the release lead for 3.6, on with team rep voting results. :)
    Part of why I wanted to wait was because the people with the most votes were Nacin and Jaquith, and I suspected Jaquith would be leading 3.6 (so he shouldn’t be team rep also, per earlier discussions).

    Core team reps: @nacin and @scribu. Woohoo!

    Term begins with the new year and goes through June.

     

← 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