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?

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?

• GitHub for Journalism — What WordPress Post Forking could do to Editorial Workflows

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.

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.

It’s the final countdown.

two outstanding issues:

• permissions (Balter)
• Post metabox (Bachhuber)

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.

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?

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

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?