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?
Updates from Ben Balter Toggle Comment Threads | Keyboard Shortcuts
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, how do people save so much with coupons, Ann, and 5 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.
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.
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?
FYI, requested a repo on .org so we can get it in the plugin directory when we’re ready