I’ve created a v0.2 milestone, as I’ll be doing some work on this in order to add it to our VIP shared plugins repo. Austin Smith (@netaustin) may also be using it for a project and incorporating some post meta forking functionality.
Recent Updates Toggle Comment Threads | Keyboard Shortcuts
I’ve created an IRC channel on freenode( #wp-postforking ). I’ll idle in it to keep it alive.
@benbalter should we use the Google Group you created as a public email list for the commit log? Github doesn’t yet support this natively, so we need to set up a mailing list somewhere.
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?
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_postcapability 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_postcapability 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.
Introducing Post Forking for WordPress | danielbachhuber, mikeschinkel, Chris K., and 2 others are discussing. Toggle Comments
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.
I added a simple build file to minify the CSS and JS. There are two dependencies that will get announced if you try and run the script without it. Right now, the script only works if run from inside the root folder of the project.
@benbalter – Can you update your release script to remove this build script from what is pushed to WordPress.org ?
It’s the final countdown.
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.
@benbalter can you add @mjangda to the Github repo so he can check out the code?
Did a big round of cleaning up, including a whole bunch of unit tests (and associated fixes as a result).
- permission tweaks (on it)
Possibly a bug on merge, but I thinkit’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?