Updates from Ben Balter Toggle Comment Threads | Keyboard Shortcuts

  • Ben Balter 11:05 am on October 1, 2012 Permalink
    Tags: github,   

    Any thoughts on branches in terms of development? All for proper feature branching/merging. In the past, I’ve kept master in sync with .org’s SVN to avoid confusion for folks that stumble across the project for google, etc., and did most of the work in a `develop` branch, but up for others’ expertise. Thoughts?

    • Daniel Bachhuber 11:13 am on October 1, 2012 Permalink

      I used to follow the master/develop approach but then decided it wasn’t offering much value, was a pain to maintain, and made things painful when users wanted to submit pull requests

  • Ben Balter 8:00 am on October 1, 2012 Permalink

    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.


    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

      A better wiki interface?

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

      Very good plugin idea!

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

      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

      Wow. Nice!

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

      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

      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

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


  • Ben Balter 10:51 pm on September 30, 2012 Permalink

    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
    Tags: final countdown,   

    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

    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

      Sounds great!

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

      Update: Documentation should be close to good to go.

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

      Want me to crank out the publish metabox this weekend?

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

        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

        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 1:11 pm on September 9, 2012 Permalink
    Tags: .org   

    FYI, requested a repo on .org so we can get it in the plugin directory when we’re ready

  • Ben Balter 3:04 pm on September 7, 2012 Permalink

    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

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

      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

        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?

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