內容簡介
，WordPress Post Forking 是一款外掛，讓使用者可以創建一個替代版本的內容，以促進 WordPress 內容管理的協作方法。例如，可以允許外部用戶（例如訪問您網站的訪客）或內部用戶（例如其他作者）提交建議的修改，甚至可以在較小或單一作者的網站上使用，以使文章作者能夠編輯已發布的文章，而它們的變更不會立即顯示 。如果您熟悉 Git 或其他分散式版本控制系統，那麼您已經熟悉 WordPress Post Forking。
您可以如何使用它？
- 讓沒有編輯或發布文章能力的用戶編輯和提交對內容的變更（類似於 GitHub 的 pull request 系統）
- 協作編輯（通過解決兩個用戶之間的衝突）
- 將已發佈內容的保存草稿變更
- 編排已發佈內容的待審變更
它如何運作？
當沒有 edit_post 權限的用戶嘗試編輯某篇文章時，WordPress 將自動創建一個後退或另一個版本的文章，用戶可以自由編輯。編輯畫面將與其熟悉的標準文章編輯界面相同。完成後，他們只需點擊「提交查看」。此時，分叉進入標準 WordPress 審核隊列（就像任何沒有 publish_post 權限提交文章的作者一樣），編輯人員可以審核並可能批准更改以發布。如果更改可以自動合併，則原始文章將被更新，否則編輯人員將提供解決衝突變更的功能。所有這些都使用 WordPress 內置的自定義文章類型、修訂版本和差異功能完成，因此它應該對大多數 WordPress 用戶來說很熟悉。
概念
WordPress Post Forking 將 Git 的許多成熟慣例引入了 WordPress，因此使用獨特的詞彙來描述它的功能：
- 文章 - 使用 post_content 字段的任何 WordPress 文章，包括文章、頁面和自定義文章類型
- 分叉 - 克隆的文章，旨在進行編輯，而不干擾父文章
- 分支 - 同一父文章的並行版本，由文章作者擁有
- 合併 - 將分叉的更改推回其父文章
- 衝突 - 當文章被分叉時，如果對分叉進行了特定行的更改，並且在合併之前在父文章上編輯了相同行，則無法自動合併該文章，並將冲突呈現給合併者進行解決。
為什麼需要這個外掛？
這是一個初始版本，旨在展示外掛的核心功能，並希望隨著專案的發展進行進一步改進和精煉。請考慮捐助您的時間以幫助改善專案。
更多資訊。
外掛標籤
開發者團隊
原文外掛簡介
WordPress Post Forking allows users to “fork” or create an alternate version of content 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
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.
Concepts
WordPress Post Forking introduces many of Git’s well-established conventions to the WordPress world, and as a result, uses a unique vocabulary to describe what it does:
Post – Any WordPress post that uses the post_content field, including posts, pages, and custom post types
Fork – Clone of a post intended for editing without disturbing the parent post
Branch – Parallel versions of the same parent post, owned by the post author
Merge – To push a fork’s changes back into its parent post
Conflict – When a post is forked if a given line is changed on the fork, and that same line is subsequently edited on the parent post prior to the merge, the post cannot be automatically merged, and the conflict is presented to the merger to resolve
Why this plugin?
GitHub for Journalism — What WordPress Post Forking could do to Editorial Workflows
Project Status
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.
More Information
For more information, or to contribute to this documentation, please visit the Post Forking project wiki.
[Photo courtesy babomike]
How To Contribute
Post Forking is an open source project and is supported by the efforts of an entire community. We’d love for you to get involved. Whatever your level of skill or however much time you can give, your contribution is greatly appreciated.
Everyone – Help expand the project’s documentation wiki and answer questions in the support forums to make it easier for other users to get started, or join the discussion on the P2 (Blog) to help shape the project’s future.
Users – Download the latest development version of the plugin, and submit bug/feature requests.
Non-English Speakers – Contribute a translation using the GlotPress web interface – no technical knowledge required (how to).
Technical Folks – Fork the development version and submit a pull request, especially for any known issues. This tutorial may be helpful if you’re new to git.
Roadmap
Future Features (Maybe):
Front end editing (just click edit, make your change, hit submit)
Ability to fork more than just the post_content (e.g., taxonomies, post meta)
Appending parent revision history to fork
Spoofing post_type so metaboxes, etc. appear
Author pages for fork contributors
Open Enhancements
Under The Hood
** Warning: geek content! **
Forking a post creates a copy of the most recent version of the post as a “fork” custom post type. Certain fields (e.g., post_content, post_title) are copied over to the new fork. The plugin also stores the revision ID for the revision prior to when the fork was created (see includes/revisions.php for more information as to why we store the previous revision).
The fork post type has its own capabilities, allowing a user without the ability to edit or publish on the parent post to edit a fork. Once changes have been made, assuming the user does not have the publish_fork capability, the user would submit the fork for review (similar to submitting a Pull Request in GitHub parlance) using the normal WordPress moderation system.
Publishing a fork (either by the fork author, if they have the capability, or my an editor) triggers the merge itself. The post content of the fork undergoes a three way merge with the base revision and current version of the parent post.
A fork can have three post statuses:
Draft – The fork is being edited
Pending – The fork has been submitted for publication
Published – The fork has been merged
Note: No user should have the edit_published_fork capability. Once published, the fork post_type simply exists to provide a record of the change and allow the author page, to theoretically list contributions by author.
Where To Get Support Or Report An Issue
There are various resources available, depending on the type of help you’re looking for:
For getting started and general documentation, please browse, and feel free to contribute to the project wiki.
For support questions (“How do I”, “I can’t seem to”, etc.) please search and if not already answered, open a thread in the Support Forums.
For technical issues (e.g., to submit a bug or feature request) please search and if not already filed, open an issue on GitHub.
For implementation, and all general questions (“Is it possible to..”, “Has anyone…”), please search, and if not already answered, post a topic to the general discussion list serve
For general discussion about the project and planning, please see the P2
