Title: WP Branches For Post Author: Hao Kexin Published: 5 mars 2020 Last modified: 12 oktober 2026 --- Sök tillägg ![](https://ps.w.org/wp-branches-for-post/assets/banner-772x250.png?rev=3703142) ![](https://ps.w.org/wp-branches-for-post/assets/icon-256x256.png?rev=3703142) # WP Branches For Post Av [Hao Kexin](https://profiles.wordpress.org/haokexin/) [Ladda ner](https://downloads.wordpress.org/plugin/wp-branches-for-post.2.3.3.zip) * [Detaljer](https://sv.wordpress.org/plugins/wp-branches-for-post/#description) * [Recensioner](https://sv.wordpress.org/plugins/wp-branches-for-post/#reviews) * [Installation](https://sv.wordpress.org/plugins/wp-branches-for-post/#installation) * [Utveckling](https://sv.wordpress.org/plugins/wp-branches-for-post/#developers) [Support](https://wordpress.org/support/plugin/wp-branches-for-post/) ## Beskrivning WP Branches For Post adds a Git-like editorial workflow to WordPress. When a published page or post needs a larger edit, you do not have to change the live content directly. Create a private working branch, edit it in the normal WordPress editor, review the differences, and merge only when you are ready. The public original keeps its post ID, URL and publication identity throughout the workflow. Version 2.3.3 also sets the branch language before copying translated categories and tags on Polylang sites. Version 2.3.2 stopped copying internal translation groups. Regular editorial taxonomies, including language and categories, remain supported. Version 2.3 adds selective, per-field conflict resolution inside Gutenberg; independent reviewers can approve the exact proposed Original/Branch decisions before a guarded merge. Version 2.2 introduced editorial approvals, scheduling and conservative block- aware merging. ### What’s new in 2.3.0 * Resolve eligible conflicting post fields individually in Gutenberg; choose current Original or Branch, review the three-way comparison and confirm before merging. * For sites requiring independent approval, submit exactly which conflicting values you want kept; a separate authorized reviewer approves those specific choices and the current content snapshot. * Refuse incomplete or modified choices, stale reviews, unsafe or unsupported fields, and attempts to substitute different choices after approval. * Keep original-only updates, original post ID, URL and history intact; never copy internal review proposals to published content. * Review, approve and schedule from the existing Post Branch editor sidebar; inspect proposed choices in Tools > Branch Workflow. * Improve responsive and keyboard-operated workflow controls. * Tested with real WordPress 7.1.3 / PHP 8.2, 8.3 and 8.4 installations, WordPress 6.6 baseline, Gutenberg browser automation, and popular editor/SEO plugin coexistence. Some newly introduced workflow interface messages fall back to English pending separately approved Japanese and Chinese translations; existing approved translation catalogs are preserved. ### What’s new in 2.2.0 * Merge independent Gutenberg top-level block edits while safely rejecting ambiguous or overlapping changes. * Request independent editorial approval; administrators may require approval for every branch merge. * Schedule safe merges for a future site-local time, with renewed permission, approval and conflict checks at execution. * Find pending editorial reviews under Tools > Branch Workflow; use the branch admin-bar and post-list shortcuts. * Safely synchronize independent Yoast SEO, Elementor and ACF metadata changes. Review and scheduled merge behavior use the same original-preserving merge service as manual actions. Scheduled merges depend on WP-Cron and may run later than the selected time on low-traffic sites. New workflow labels are available in English until their translations are separately reviewed; existing translations are unaffected. #### The workflow at a glance 1. Open a published, private or scheduled post, page, or supported custom post type. 2. Open the Post Branch panel and choose ”Create branch”. 3. WordPress opens an isolated draft branch. The public original is unchanged. 4. Edit the branch normally. Preview the branch whenever you need to. 5. Choose ”Review changes”. 6. Review branch changes, newer original changes, conflicts, and identity changes. 7. If the original has newer non-conflicting edits, choose ”Update branch from original” when you want the branch to include them before continuing. 8. When the review is clean, choose ”Save & merge into original”. 9. If both sides changed the same value differently, review the conflict and use force merge only when you intentionally want the branch value for the listed conflict. 10. After a successful merge, the original remains the public post and the working branch is moved to Trash. #### Feature guide with screenshots The screenshots on the plugin page follow the same workflow described below, so you can see what each control looks like before using it: * Screenshot 1 — Start safely: open the Post Branch panel on the original and choose” Create branch”. The live post is not edited. * Screenshot 2 — Work in isolation: the branch editor shows its relationship to the original, preview links, review state, and the actions available for that branch. * Screenshot 3 — Review before merging: ”Review changes” opens the three-way comparison so you can inspect the baseline, current original, and branch values together. * Screenshot 4 — Bring in safe upstream work: when the original has newer non-conflicting changes, ”Update branch from original” becomes available. * Screenshot 5 — Continue after updating: after the branch is refreshed from the original, the editor reloads with the rebased state and a fresh merge review. * Screenshot 6 — Stop on real conflicts: when both the original and branch changed the same mergeable value differently, normal merge is blocked and the conflicting paths are shown. * Screenshot 7 — Force only after review: force merge uses a separate destructive confirmation and prefers the branch value only for reviewed conflicts. * Screenshot 8 — Refuse stale reviews: if the branch or original changes after review, the merge is stopped and the current state must be reviewed again. * Screenshot 9 — Discard explicitly: abandoning a branch requires confirmation and moves only the branch to Trash; the public original is untouched. * Screenshot 10 — See active work from the original: the original post lists existing branches and their current review states. * Screenshot 11 — Keep normal WordPress navigation: branch state and quick actions remain available from the post list. * Screenshot 12 — Understand synced-pattern scope: branches that reference synced patterns display a warning because editing the synced pattern itself is global in WordPress. #### What the Post Branch panel tells you On an original post, the panel shows whether a branch can be created and lists active branches you can edit. On a branch, the panel shows: * A link back to the original. * Branch and original preview links. * The branch creator. * The current review state. * How many branch changes and conflicts were detected. * ”Review changes” to open the detailed merge review. * ”Update branch from original” when newer original changes can be brought into the branch safely. * ”Save & merge into original” when the branch can be merged normally. * An explicit force-merge path for reviewed conflicts. * ”Discard branch” when the working branch should be abandoned. #### Understanding the review states * Clean: no incompatible newer change prevents a normal merge. * Update available: the original contains newer non-conflicting work. The plugin can update the branch while keeping branch-only edits. * Informational: the original changed identity-related data that the branch is not allowed to overwrite, such as slug or publication identity. * Conflict: the original and the branch changed the same mergeable data differently. Normal merge is blocked until you review the situation. * Legacy/unknown: an older branch does not have the full 2.1 baseline needed for an exact three-way review. Review it manually before any force merge. * Missing: the original can no longer be safely resolved, so merge is unavailable. #### What the merge review contains The review separates changes into four groups: * Branch changes: mergeable values changed in the working branch. * Original changes since branch creation: newer changes made directly to the original. * Conflicts: paths changed differently on both sides. * Original identity changes preserved by merge: changes the plugin deliberately does not overwrite. For reviewable fields, the panel also shows the baseline, current original and branch values so you can understand why an item is listed. #### What is synchronized A successful merge can synchronize normal editorial content, supported post meta, and taxonomies. The plugin intentionally preserves the original post’s identity and publication state. In particular, the merge does not replace the original post ID, GUID, slug, author or publication dates. For hierarchical content, the branch cannot change the original parent relationship because that can change a public URL. Media IDs already referenced by content and featured-image metadata remain usable. Attachments are not re-parented. #### Editing while someone changes the original Version 2.1 uses the baseline captured at branch creation to distinguish three situations: * Only the branch changed a value: the branch value can be applied. * Only the original changed a value: the newer original value is preserved. * Both changed the same value differently: the value is a conflict and normal merge is blocked. This is why a branch can often merge safely even when the original changed after branch creation. #### Update branch from original When the original has newer non-conflicting changes, ”Update branch from original” rebases the working branch onto the newer original state. Branch-only work is preserved, original-only work is imported into the branch, and a fresh baseline is recorded. If the operation cannot complete safely, the plugin attempts to restore the branch to its previous state instead of leaving a partial update. #### Force merge Force merge is intentionally not the default path. It is offered only after a conflict is detected and reviewed. For listed merge conflicts, force merge prefers the branch value. Non-conflicting newer work on the original is still preserved. Extensions can further restrict who is allowed to force merge through the plugin’s capability/filter boundary. #### Synced patterns A WordPress synced pattern is global content. Editing the synced pattern itself changes that pattern everywhere it is used and is not isolated by a post branch. When a branch references synced patterns, WP Branches For Post warns you in the branch panel so that global pattern edits are not mistaken for isolated branch edits. #### Safety and failure handling * Branches stay non-public and normal WordPress publishing is forced back to draft. * Mutating operations repeat WordPress capability checks at the service layer. * Browser actions and REST routes use the appropriate nonce/permission protections. * Every 2.1 branch stores a full baseline snapshot for three-way review. * Normal merge refuses unresolved conflicts. * Merge and rebase operations verify synchronized state, reject stale reviewed data, and attempt rollback after write failures. * If a merge cannot finish its branch cleanup, the original is restored instead of reporting a partial success. * Successful merges and discarded branches go to Trash instead of being permanently deleted. * WordPress creates the normal revision history when the original is updated. * The plugin does not directly rewrite revisions or attachment parents with SQL. #### Block Editor, Classic Editor and list screens The complete review experience is available in the Block Editor document sidebar. Classic Editor, post-list row actions and the admin bar retain compatibility controls for creating/opening branches and performing supported branch actions. For the clearest conflict review, use the Block Editor panel. #### Troubleshooting the branch controls If an action is unavailable or the plugin stops a merge, that is normally a safety check rather than a hidden setting: * Create branch is disabled while the original has unsaved Block Editor changes. Save or discard those edits first so the branch baseline matches the saved original. * Create branch is available only for supported saved statuses such as published, private and scheduled content, and only when your WordPress capabilities allow the operation. * Update branch from original appears only when the original has newer changes that do not conflict with the branch. You do not have to run it before every merge. * Save & merge into original is not offered for an unresolved true conflict. Open Review changes and inspect the listed paths first. * If the branch or original changes after you reviewed it, the merge is stopped and the review is refreshed. Review the current state before trying again. * Force merge is shown only for a state that requires explicit conflict/legacy review and only when your account is allowed to force the merge. * If the original is missing or no longer matches the branch post type, merge is unavailable. * The Block Editor provides the complete three-way review. Classic Editor and list screens keep compatibility actions, but conflict-heavy work is clearest in the Block Editor. #### Compatibility with older branches Branches created by older plugin versions remain recognizable. A 2.0-style branch with a compatible stored baseline hash can still merge normally when the original has not changed. Older branches without a full 2.1 snapshot cannot show the detailed three-way comparison, so the plugin treats them conservatively and requires explicit review when the state is uncertain. ### For Developers Useful filters and actions include: * `wbfp_branchable_post_statuses` * `wbfp_create_branch_post_data` * `wbfp_excluded_meta_keys` * `wbfp_mergeable_post_fields` * `wbfp_can_force_merge` * `wbfp_branch_created` * `wbfp_before_merge` * `wbfp_after_merge` Security-critical invariants remain enforced after extension filters run. A branch remains a draft of the same post type, protected runtime metadata remains excluded, mergeable core fields stay inside the plugin’s allowlist, and force merge still passes through the plugin’s authorization boundary. See `ARCHITECTURE.md` for the data flow, `SECURITY.md` for authorization and synchronization boundaries, and `TESTING.md` for the reproducible full-validation environment used for 2.1. The Block Editor source is in `src/index.js` and is built with `@wordpress/scripts`. Human-readable source code and build tooling are maintained at https://github.com/ hsxk/WP-Branches-For-Post/. ## Skärmdumpar [⌊Original post: the Post Branch panel explains the isolated workflow and provides the Create branch action.⌉⌊Original post: the Post Branch panel explains the isolated workflow and provides the Create branch action.⌉[ Original post: the Post Branch panel explains the isolated workflow and provides the Create branch action. [⌊Working branch: branch status, original/branch preview links, Review changes and Discard branch controls.⌉⌊Working branch: branch status, original/branch preview links, Review changes and Discard branch controls.⌉[ Working branch: branch status, original/branch preview links, Review changes and Discard branch controls. [⌊Merge review: a three-way comparison of baseline, current original and branch values before merge.⌉⌊Merge review: a three-way comparison of baseline, current original and branch values before merge.⌉[ Merge review: a three-way comparison of baseline, current original and branch values before merge. [⌊Update available: newer non-conflicting original changes can be brought into the branch with Update branch from original.⌉⌊Update available: newer non-conflicting original changes can be brought into the branch with Update branch from original .⌉[ Update available: newer non-conflicting original changes can be brought into the branch with Update branch from original. [⌊Updated branch: the rebased branch reloads with the newest safe original changes and a fresh review state.⌉⌊Updated branch: the rebased branch reloads with the newest safe original changes and a fresh review state.⌉[ Updated branch: the rebased branch reloads with the newest safe original changes and a fresh review state. [⌊Conflict protection: normal merge is blocked when both sides changed the same value differently.⌉⌊Conflict protection: normal merge is blocked when both sides changed the same value differently.⌉[ Conflict protection: normal merge is blocked when both sides changed the same value differently. [⌊Force merge confirmation: an explicit destructive confirmation is required before reviewed conflicts can prefer branch values.⌉⌊Force merge confirmation: an explicit destructive confirmation is required before reviewed conflicts can prefer branch values.⌉[ Force merge confirmation: an explicit destructive confirmation is required before reviewed conflicts can prefer branch values. [⌊Stale review protection: a merge is stopped when the branch or original changed after the state was reviewed.⌉⌊Stale review protection: a merge is stopped when the branch or original changed after the state was reviewed.⌉[ Stale review protection: a merge is stopped when the branch or original changed after the state was reviewed. [⌊Discard confirmation: the branch can be moved to Trash without modifying the public original.⌉⌊Discard confirmation: the branch can be moved to Trash without modifying the public original.⌉[ Discard confirmation: the branch can be moved to Trash without modifying the public original. [⌊Existing branches on the original: active branches and their review states are visible before creating more work.⌉⌊Existing branches on the original: active branches and their review states are visible before creating more work.⌉[ Existing branches on the original: active branches and their review states are visible before creating more work. [⌊Post list integration: branch state and quick branch actions remain available from WordPress admin lists.⌉⌊Post list integration: branch state and quick branch actions remain available from WordPress admin lists.⌉[ Post list integration: branch state and quick branch actions remain available from WordPress admin lists. [⌊Synced pattern warning: the editor explains that editing a referenced synced pattern is global and not isolated by the branch.⌉⌊Synced pattern warning: the editor explains that editing a referenced synced pattern is global and not isolated by the branch .⌉[ Synced pattern warning: the editor explains that editing a referenced synced pattern is global and not isolated by the branch. ## Installation 1. Install WP Branches For Post from the WordPress Plugins screen, or upload it to`/ wp-content/plugins/wp-branches-for-post`. 2. Activate the plugin. 3. Open an existing published, private or scheduled post/page in the editor. 4. Open the Post Branch panel in the editor settings sidebar. 5. Choose ”Create branch” to begin a safe working copy. No separate settings page is required for the normal workflow. ## Vanliga frågor ### How do I request review and approval? Open a working branch and choose Branch review & schedule from the admin bar, or go to Tools > Branch Workflow. Request review after saving meaningful changes. Another authorized editor can inspect the Base / Original / Branch comparison and approve or request changes. The branch creator cannot approve their own proposal. ### Is independent approval mandatory for all sites? No. This policy is off by default to preserve existing workflows. Administrators may enable it under Tools > Branch Workflow; when enabled, even a direct or forced merge requires an approval matching the current branch state. Editing either the original or the branch invalidates that approval. ### Can I schedule a merge for later? Yes. Choose a future site-local time in Branch Workflow. At execution, the plugin rechecks the original and branch, permissions, approval and conflicts. It never force-merges on a schedule and will not overwrite a stale version. WP-Cron is traffic- dependent, so use a reliable server cron runner if timeliness matters. ### Can it combine changes made to different Gutenberg blocks? Yes, when both sides edited independent, unambiguous top-level blocks and the saved markup can be preserved without loss. Shared/synced patterns, HTML freeform content, ambiguous blocks and overlapping edits still require manual review; unsafe changes are not silently merged. ### Is a branch public? No. A branch is an isolated working draft. A normal WordPress publish attempt is forced back to draft. Use the plugin’s merge action when the work is ready. ### Does merging change the original URL or post ID? No. The existing original post remains the public resource. Its post ID and identity are preserved, and identity-related values such as slug, author and publication dates are not taken from the branch. ### What happens if someone edits the original while I am working? The plugin compares the original, the branch and the saved baseline. Original-only work can be preserved, non-conflicting work can be rebased, and overlapping divergent edits are reported as conflicts instead of being silently overwritten. ### Do I have to update the branch before every merge? No. If newer original changes do not conflict with the branch, the three-way merge can preserve them. Updating the branch first is useful when you want to continue editing on top of the newest original state. ### What does force merge overwrite? For conflicts you explicitly review, force merge prefers the branch value. Newer original work that does not conflict with the branch is still preserved. ### Can I preview the branch before merging? Yes. The branch panel provides a branch preview link and a link to the current original so you can compare them outside the editor. ### What happens when I discard a branch? The branch is moved to Trash. The original post is not changed. ### What happens after a successful merge? The original is updated through WordPress, keeping its identity, and the merged branch is moved to Trash. ### Are categories, tags and custom taxonomies included? Supported taxonomies are synchronized as part of the branch workflow, including clearing a taxonomy when that is the reviewed branch state. ### Is post metadata included? Supported post metadata is synchronized. Runtime/plugin bookkeeping keys are excluded, and extensions can add their own exclusions. ### What about featured images? Featured-image metadata is part of normal synchronized metadata. The referenced media item keeps its existing attachment identity. ### Are synced patterns isolated? No. Synced patterns are global WordPress entities. The plugin detects references and warns you, but editing a synced pattern itself affects every place that pattern is used. ### Does it support custom post types? Yes, when the post type uses the normal WordPress editing APIs and the current user has the required capabilities. ### Can I use branches created by older plugin versions? Yes. Compatibility paths remain, but older branches may not have the full 2.1 baseline required for detailed three-way review and are therefore handled more conservatively. ## Recensioner Detta tillägg har inga recensioner. ## Bidragsgivare och utvecklare ”WP Branches For Post” är programvara med öppen källkod. Följande personer har bidragit till detta tillägg. Bidragande personer * [ Hao Kexin ](https://profiles.wordpress.org/haokexin/) * [ Alkesh Miyani ](https://profiles.wordpress.org/alkesh7/) ”WP Branches For Post” har översatts till 10 språk. Tack till [översättarna](https://translate.wordpress.org/projects/wp-plugins/wp-branches-for-post/contributors) för deras bidrag. [Översätt ”WP Branches For Post” till ditt språk.](https://translate.wordpress.org/projects/wp-plugins/wp-branches-for-post) ### Intresserad av programutveckling? [Läs programkoden](https://plugins.trac.wordpress.org/browser/wp-branches-for-post/), kika på [SVN-filförvaret](https://plugins.svn.wordpress.org/wp-branches-for-post/) eller prenumerera på [utvecklarloggen](https://plugins.trac.wordpress.org/log/wp-branches-for-post/) via [RSS](https://plugins.trac.wordpress.org/log/wp-branches-for-post/?limit=100&mode=stop_on_copy&format=rss). ## Ändringslogg #### 2.3.3 * Fixed Polylang multilingual branch creation when the new draft initially uses the site default language: synchronize its intended language before category and tag terms. * Prevented translated categories from being automatically rewritten to the wrong language during branch creation; kept strict taxonomy verification, original translation relationships and normal editorial taxonomy behavior. * Added real WordPress regression coverage for default-language draft creation and language-sensitive category synchronization. No translation catalog updates. #### 2.3.2 * Fixed branch creation failures on Polylang sites by excluding the internal post_translations relationship from copied and merged taxonomy state. * Kept normal post language, categories, tags and editable custom taxonomy assignments synchronized; the original’s translation group remains unchanged. * Normalized older stored branch baselines in memory so internal translation-group data does not trigger false merge conflicts. * Added regression tests for multilingual branch creation, language preservation, legacy snapshots and translation-group safety. No translation catalog updates. #### 2.3.1 * Localized the 2.3 editorial review, scheduling, conflict choices and error messages in Japanese, Simplified Chinese and Traditional Chinese (54 new messages per locale). * Updated PHP gettext and Gutenberg editor translation bundles, preserving every previously approved translation. * Added real multilingual Gutenberg mobile and workflow-page browser regression tests on WordPress 7.1.3. #### 2.3.0 * Added safe, explicit, per-field Gutenberg conflict choices with current review- token enforcement and preservation of independent original edits. * Added independently reviewed conflict-choice proposals, approval bound to both content and choice hashes, and exact-choice checks at two merge gates. * Improved workflow visibility in the WordPress Tools screen, mobile layout and keyboard/accessibility browser coverage. * Expanded real integration and visual testing to WordPress 7.1.3 with PHP 8.2– 8.4, retaining WordPress 6.6 regression coverage. * Preserved all previously approved translation files unchanged. #### 2.2.0 * Added conservative, lossless Gutenberg top-level block-aware three-way merge and rebase for independent edits. * Added optional two-person editorial approval, pending review requests, reviewer capability enforcement, staleness invalidation and a review queue. * Added future scheduled safe merges using WP-Cron with unique job IDs, due-time checks, capability revalidation, no forced conflicts and cancellation. * Added workflow administration, REST endpoints, contextual errors, editor/admin- bar and post-list shortcuts. * Expanded compatibility testing for Yoast Duplicate Post, Yoast SEO, Advanced Custom Fields and Elementor. * Expanded real WordPress and Gutenberg browser regression checks, security validation, and 35-case visual evidence. * Preserved existing translation catalogs and changed CI to validate approved translations without regenerating catalogs on unrelated code changes. #### 2.1.1 * Improved merge review with readable Base / Original / Branch values for menu order, comment status, ping status and password state. * Added readable taxonomy term names and featured-image identity with thumbnail previews to the three-way review. * Kept post passwords masked and arbitrary custom-meta values private in the REST review payload. * Expanded Existing branches cards with branch ID, creator, modified time, state, change count and conflict count. * Added dedicated Existing branches views to the Posts and Pages list tables, including legacy branch relationships. * Kept branch-list counts and filtering aligned with WordPress author capabilities so users without edit_others_posts see only their own branches. * Prevented private original titles from being exposed in branch list states when the current user cannot read the original. * Localized readable Open / Closed review values through WordPress core translations. * Expanded real WordPress integration coverage to 130 checks and real Gutenberg browser coverage to 42 checks, while retaining the 35-case semantic UI/tutorial contract. * Tightened release-tree and ZIP hygiene so development hidden files remain outside the distributable plugin. #### 2.1.0 * Added a three-way branch/original/baseline review instead of treating every newer original edit as the same kind of conflict. * Added detailed branch changes, original changes, exact conflicts and preserved identity changes to the Block Editor merge review. * Added safe ”Update branch from original” behavior for newer non-conflicting original work. * Added selective three-way merge behavior that preserves original-only changes while applying branch-only changes. * Added explicit reviewed force-merge handling for true overlapping conflicts. * Added rollback and post-write verification for merge and branch-update failures. * Added reviewed-state tokens and service-layer freshness checks so a merge is rejected if the branch or original changes after review. * Reloaded Gutenberg after Update branch from original so the editor always reflects the rebased server state. * Added rollback when a successfully written merge cannot move its branch to Trash, preventing partial-success states. * Aligned Classic Editor and post-list actions with 2.1 review states so safe non- conflicting updates do not require force merge. * Added verified baseline-metadata writes and rollback when a branch refresh cannot persist its new baseline. * Added stale-state checks before and after branch refresh writes so concurrent original/branch saves require a fresh review. * Preserved hierarchical post parents during merge to avoid unexpected public URL changes. * Added branch/original preview links and synced-pattern warnings. * Added real WordPress 7.1 integration coverage and real Gutenberg browser end- to-end coverage for the 2.1 workflow. * Expanded the WordPress.org documentation and screenshots to explain the complete workflow. #### 2.0.1 * Raised the minimum supported WordPress version to 6.6 for the current block-editor JSX runtime. * Added missing translator comments and refreshed the shipped block-editor build. * Improved Plugin Check and PHPCS coverage and aligned the release build tree. * Moved WordPress.org artwork into the standard .wordpress-org directory and added tag-driven SVN deployment. * Added additional real-WordPress security verification coverage. * Special thanks to @miyanialkesh7 for the work contributed through PRs #2–#6: real-WordPress security verification, Plugin Check and PHPCS improvements, i18n fixes, and WordPress.org release tooling. #### 2.0.0 * Rebuilt the branch workflow for modern WordPress. * Added Block Editor document sidebar integration. * Added REST endpoints with capability-based permission callbacks. * Added baseline snapshot conflict detection. * Replaced publish-triggered merge with explicit merge actions. * Prevented branch posts from becoming public. * Reworked post meta synchronization to preserve multi-value keys and removals. * Reworked taxonomy synchronization so cleared taxonomies are also propagated. * Removed direct SQL revision and attachment-parent manipulation. * Preserved original post ID, URL, status, author, slug, and publication dates during merge. * Moved merged/discarded branches to Trash instead of permanently deleting them. * Added compatibility handling for branches created by version 1.x. * Added modern development tooling and CI syntax/build checks. #### 1.3.0 * Added developer filters and code cleanup. #### 1.2.0 * Added zh_CN, zh_TW, and ja translations. #### 1.1.0 * Added admin-bar/list actions and initial block-editor support. #### 1.0.0 * Initial release. ## Meta * Version **2.3.3** * Senast uppdaterat **5 timmar sedan** * Aktiva installationer **40+** * WordPress-version ** 6.6 eller senare ** * Testat upp till **7.1.3** * PHP-version ** 8.2 eller senare ** * Språk * [Chinese (China)](https://cn.wordpress.org/plugins/wp-branches-for-post/), [Chinese (Taiwan)](https://tw.wordpress.org/plugins/wp-branches-for-post/), [Dutch (Belgium)](https://nl-be.wordpress.org/plugins/wp-branches-for-post/), [English (US)](https://wordpress.org/plugins/wp-branches-for-post/), [Japanese](https://ja.wordpress.org/plugins/wp-branches-for-post/), [Romanian](https://ro.wordpress.org/plugins/wp-branches-for-post/), [Russian](https://ru.wordpress.org/plugins/wp-branches-for-post/), [Spanish (Chile)](https://cl.wordpress.org/plugins/wp-branches-for-post/), [Spanish (Mexico)](https://es-mx.wordpress.org/plugins/wp-branches-for-post/), [Spanish (Spain)](https://es.wordpress.org/plugins/wp-branches-for-post/) och [Spanish (Venezuela)](https://ve.wordpress.org/plugins/wp-branches-for-post/). * [Översätt till ditt språk](https://translate.wordpress.org/projects/wp-plugins/wp-branches-for-post) * Etiketter * [editorial workflow](https://sv.wordpress.org/plugins/tags/editorial-workflow/) [gutenberg](https://sv.wordpress.org/plugins/tags/gutenberg/)[revision](https://sv.wordpress.org/plugins/tags/revision/) [staging](https://sv.wordpress.org/plugins/tags/staging/) * [Avancerad vy](https://sv.wordpress.org/plugins/wp-branches-for-post/advanced/) ## Betyg Än så länge har inga recensioner skickats in. [Your review](https://wordpress.org/support/plugin/wp-branches-for-post/reviews/#new-post) [Visa alla recensioner](https://wordpress.org/support/plugin/wp-branches-for-post/reviews/) ## Bidragande personer * [ Hao Kexin ](https://profiles.wordpress.org/haokexin/) * [ Alkesh Miyani ](https://profiles.wordpress.org/alkesh7/) ## Support Har du något att säga? Behöver du hjälp? [Visa supportforum](https://wordpress.org/support/plugin/wp-branches-for-post/)