Tagged: v0.1 Toggle Comment Threads | Keyboard Shortcuts

  • Ben Balter 8:00 am on October 1, 2012 Permalink | Reply
    Tags: v0.1   

    Introducing Post Forking for WordPress 

    WordPress sets out to democratize publishing, and today the CMS gains an important new feature to that end: Post Forking.

    WordPress Post Forking allows users to “fork” or create an alternate version of content and in doing so, sets out to foster a more collaborative approach to WordPress content curation. This can be used, for example, to allow external users (such as visitors to your site) or internal users (such as other authors) with the ability to submit proposed revisions. It can even be used on smaller or single-author sites to enable post authors to edit published posts without their changes appearing immediately. If you’re familiar with Git, or other decentralized version control systems, you’re already familiar with WordPress post forking.

    How might you use it?

    • Allowing users without edit or publish post capabilities to edit and submit changes to content (similar to GitHub’s pull request system)
    • Collaborative editing (by resolving two users’ conflicted saves – Wired’s example)
    • Saving draft changes of already-published content
    • Scheduling pending changes to already-published content

    Why this plugin?

    How does it work?

    When a user without the edit_post capability attempts to edit a given post, WordPress will automatically create a “fork” or alternate version of the post which they can freely edit. The edit screen will look just like the standard post editing interface that they are used to. When they’re done, they simply click “submit for review.” At this point, the fork goes into the standard WordPress moderation queue (just like any time an author without the publish_post capability submits a post), where an editor can review, and potentially approve the changes for publishing. If the changes can be automatically merged, the original post will be updated, otherwise, the editor will be presented with the ability to resolve the conflicting changes. All this is done using WordPress’s built-in custom post type, revision, and diff functionality, so it should look familiar to most WordPress users.

    Interested?

    Download the plugin from the WordPress plugin repository, or fork the project on GitHub, or for more information, visit the Post Forking project wiki.

    This version constitutes an initial release designed to showcase the plugin’s core functionality and is intended to be improved upon with additional features and refinements as the project evolves. Please consider contributing your time to help improve the project.

     
    • Deven Pitcher 1:30 pm on October 1, 2012 Permalink | Reply

      A better wiki interface?

    • Michael 1:33 pm on October 1, 2012 Permalink | Reply

      Very good plugin idea!

    • Chris K. 4:07 pm on October 1, 2012 Permalink | Reply

      This a really timely plugin. Thanks for making it available.

      In addition to Benjamin’s post on the subject, it’s worth looking at a project that came out of last summer’s Knight-Mozilla Learning Lab that has several similar aspects: http://polarjordan.blogspot.com/2011/08/moznewslab-proposal-infinite-story.html

    • mikeschinkel 5:15 pm on October 3, 2012 Permalink | Reply

      Wow. Nice!

    • cars 5:21 pm on May 30, 2013 Permalink | Reply

      It is hard to dispute the fact that car shopping is a stressful,
      anxiety-ridden task for many individuals. The sheer size of the expenditure involved and the
      myriad of choices on the market make the need for education and information quite
      critical. Fortunately, the tips below can make the process far simpler than you may have believed.

    • Ann 6:01 am on June 3, 2013 Permalink | Reply

      I am actually thankful to the owner of this site who has shared this fantastic paragraph at at this time.

    • how do people save so much with coupons 7:40 am on June 8, 2013 Permalink | Reply

      Good post. I am dealing with a few of these issues as well.

      .

  • Ben Balter 10:51 pm on September 30, 2012 Permalink | Reply
    Tags: v0.1   

    We’re all set with .org (get it? It’s a fork?), and both the GitHub repo and this P2 are now public. I’ve got a short post queued up for first thing tomorrow morning, and tagged v0.1 in both GIt and SVN.

     
  • Ben Balter 11:01 am on September 25, 2012 Permalink | Reply
    Tags: final countdown, v0.1   

    It’s the final countdown.

    two outstanding issues:

    Pending wrapping up the above, would love to see this get pushed public Thursday, if not, Monday at the latest.

    If you can take a few minutes to spin up and install and click around a bit, even opening issues would be helpful at this point.

     
  • Ben Balter 2:05 pm on September 15, 2012 Permalink | Reply
    Tags: v0.1   

    Did a big round of cleaning up, including a whole bunch of unit tests (and associated fixes as a result).

    Outstanding tickets:

    • permission tweaks (on it)
    • Possibly a bug on merge, but I think it’s resolved
    • Publish metabox refresh
    • Documentation final pass

    With the above knocked out, I think we’d have a solid 0.1 and would feel comfortably flipping the switch and making things public. Thoughts?

     
    • Daniel Bachhuber 2:43 pm on September 15, 2012 Permalink | Reply

      Sounds great!

    • Benjamin J. Balter 2:45 pm on September 15, 2012 Permalink | Reply

      Update: Documentation should be close to good to go.

    • Daniel Bachhuber 12:22 pm on September 21, 2012 Permalink | Reply

      Want me to crank out the publish metabox this weekend?

      • Benjamin J. Balter 9:24 am on September 22, 2012 Permalink | Reply

        That’d be awesome. Given your expertise with Edit Flow, I think you might know the code better (and seem to have a crisp vision for where it should be). Let me know how I can help.

        I was going to try to crank out the last few remaining permission issues this weekend, and and was hoping that we could shoot for at least a soft launch on GitHub early next week so we can get some more folks involved, or if the codes there, just go ahead and push to the .org repo.

      • Benjamin J. Balter 10:51 am on September 25, 2012 Permalink | Reply

        Any chance you had a chance to take a stab at metabox? (think I saw there was a wordcamp). If not, no worries, just trying to figure out how soon we can get this out the door.

  • Ben Balter 3:04 pm on September 7, 2012 Permalink | Reply
    Tags: v0.1   

    In terms of an MVP, it’s probably just documentation and clicking through / debugging. (re: documentation, if we do it in the WIki [ e.g., https://github.com/benbalter/wp-document-revisions/wiki ], I have a script to merge it down into readme.txt and readme.md )
     
    In terms of stuff on my list, I’d love to get at least a few unit tests in there, at least to get it set up with Travis CI (https://github.com/benbalter/wordpress-plugin-tests/), and was toying with the idea of integrating with Scribu’s front-end editing or similar. The APIs already there, and the permissions should work, it’s just a matter of building out the front end.
     
    Last, I think it should be a small lift, but the other feature on my list would be to either spoof or copy over the parent’s revision history on fork (so it’s like a true fork w/ the full history).
     
    Beyond that, I think you might know this space better than I do. You’ve seen the code… what sucks? What’s missing? What feature can we kill off?
     
    • Benjamin J. Balter 3:06 pm on September 7, 2012 Permalink | Reply

    • Daniel Bachhuber 4:34 pm on September 7, 2012 Permalink | Reply

      The killer feature is the button you can add on the frontend where users can “fork” a piece of content, make changes, and submit those changes for review. Ideally, users shouldn’t have to be logged in or need to access the backend for this to happen.

      If the backend workflow features are useful enough though, maybe the frontend stuff can come later and, after it, a big announcement.

      • Benjamin J. Balter 4:44 pm on September 7, 2012 Permalink | Reply

        That’s the vision. I’d love for it to be like P2 where most folks never even know the back end exists.

        I see two distinct use cases that we have to build for:

        1) Collaborative editing. I’m on the backend, i’m comfortable there, but the standard revision system isn’t enough for my organization’s needs.

        2) user-submitted edits. I’m a newspaper and I want people to be able to submit corrections, which I approve and go live.

        #1’s most of the way there. #2 is plumbed in. There should already be an API exposed to allow everything to happen from the front end. I played around with Scribu’s front-end-editing a bit, but nothing substantive.

        The one issue I’d love to figure out (as I imagine in #2 the publisher wouldn’t want the public in their users table), how to allow (pseudo)anonymous forks. We’d need some sort of persistence (this guy has submitted 3 things before) perhaps along the line of comment authors, but I think they’d need to be users (or at least *a* user) so the fork can have an author. Thoughts?

  • Daniel Bachhuber 1:44 pm on September 7, 2012 Permalink | Reply
    Tags: v0.1   

    After temporarily disabling custom capabilities, I’ve created my first fork! Doing so raises a few questions though:

    • What is the plugin supposed to be doing? What problem does it solve?
    • Do I publish a fork? If not, how do I merge it back into the original?
    • Should forks be a public post type if they aren’t intended to be published?

    Based on my prior opinions, forks shouldn’t be a public post type by default. The point of “creating” a fork is to be able to make edits to another post type, and then be able to “submit a pull request” to have your changes merged back into the original. This is what v0.1 should be.

    Thoughts?

     
    • Benjamin J. Balter 2:53 pm on September 7, 2012 Permalink | Reply

      I had two potentially conflicting design philosophies when I was sketching things out.

      1. Mirror GitHub as much as possible — it’s a well thought out workflow that most folks understand
      2. Use native WordPress functionality as much as possible — it’s a well thought out workflow that most folks understand

      Publicness: I remember going back and forth on whether forks should be public, and the only reason I fell on the public side was because if I fork a GH repo, my work on it, is by default, public. I don’t know how that would play out on the front end in a WordPress context, but that was the logic. Could go either way though. There’s something to be said for the possibility of a public revision history down the line, or ability to see pending “pull requests”, etc.

      Publishing: Theoretically, if I don’t have the `publish_post` cap, the publish button should be the standard submit for moderation. If I do have the `publish_post` cap, or am reviewing something from the moderation queue, I should have the normal publish button. The plugin should be intercepting the publish action and merging the fork into the parent post or presenting the conflict for resolution. I think this makes sense from a UX standpoint as you’re “publishing” the changes. Think of this less of a standalone CPT and more of fork of the parent post. Once published, nobody should have `edit_published_fork` caps, as they serve simply as a history, e.g., see this users forks (unless it makes sense to use the parent’s revision (the merge) and use metadata or some magic to query). The use case here was more for news-ish sites to allow readers to submit corrections, and have a running log of their contributions. If the forks are public, we just use author pages and don’t have to code anything. May make sense to back-burner this, or make it a filter for users that want the feature. Was in the original spec.

      Purpose: Originally, http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows/

      • Collaborative editing (by resolving two users’ conflicted saves – Wired’s example)
      • Saving draft changes of already-published content
      • Scheduling pending changes to already-published content
      • Allowing users without edit or publish capabilities to edit and submit changes to content (similar to GitHub’s pull request system)

      I’m not strongly opinionated on the public/private thing. If you think the contribution archive makes sense as a feature and that’s the way to do it (thinking author archive for a CPT), great, if not (or if there’s a better way to do it), let’s flip it.

    • Daniel Bachhuber 4:32 pm on September 7, 2012 Permalink | Reply

      I remember going back and forth on whether forks should be public, and the only reason I fell on the public side was because if I fork a GH repo, my work on it, is by default, public.

      If it’s a private repo though, the fork remains private. In the publishing world, most work remains private until it goes public. I think that should be the default option with the ability to enable public forks if you need.

      If I do have the `publish_post` cap, or am reviewing something from the moderation queue, I should have the normal publish button. The plugin should be intercepting the publish action and merging the fork into the parent post or presenting the conflict for resolution. I think this makes sense from a UX standpoint as you’re “publishing” the changes.

      This is not intuitive in my opinion. Instead, something like “Merge” would be more descriptive. Similarly, most of the other options in the post submit box could be removed.

      If you think the contribution archive makes sense as a feature and that’s the way to do it (thinking author archive for a CPT), great, if not (or if there’s a better way to do it), let’s flip it.

      Maybe this should be v0.2. It’s not terribly obvious as it is, but there certainly is great potential in allowing for public forks, showing version history and forking contributions, etc.

      • Benjamin J. Balter 4:38 pm on September 7, 2012 Permalink | Reply

        In the publishing world, most work remains private until it goes public.

        Totally agree. Just trying to think through the flow. That should be the case with public forks, no? If it’s not published (draft, private), it’s not public. If it’s published (meaning it’s already merged into live post), it’s public, no?

        Similarly, most of the other options in the post submit box could be removed.

        May make sense to (either now or down the line) remove the standard publish metabox and add our own simpler one? Was just trying to keep the UX as fluid as possible between forks and posts.

        Maybe this should be v0.2…. there certainly is great potential in allowing for public forks, showing version history and forking contributions, etc.

        #worksforme

        • Greg Linch 12:59 am on October 14, 2012 Permalink

          A potential bug with merging a forked draft back into a draft:

          I did: I forked a draft post and merged it back
          I saw: It published
          I expected: It to only merge — not publish

          Sorry if I missed this elsewhere (I’ve been following all the GitHub threads!), but will this be fixed going forward?

          I can imagine many use cases where this would be very problematic if not. If it stays as is, the admin language should be changed to “merge and publish” for drafts and “merge and republish” for previously published posts.

        • Daniel Bachhuber 1:07 am on October 14, 2012 Permalink

          That’s a bug. Merging into a draft shouldn’t cause it to publish. File a Github issue and I’ll take a look?

        • Greg Linch 10:27 am on October 14, 2012 Permalink

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