Brasth

Brasth Document Sync for Google Docs helps editorial teams use Google Docs as the source of truth while publishing clean WordPress content. Site owners provide their own Google OAuth web client, each WordPress user connects their own Google account, and authorized users can browse accessible Google Docs, link a document to a post or page, and sync content into WordPress.
The plugin exports Google Docs as HTML ZIP packages, imports embedded images into the WordPress Media Library, rewrites image URLs, sanitizes the resulting HTML, and converts common document structures to Gutenberg block markup. If Google blocks a large HTML ZIP export, Brasth Document Sync retries through the Google Docs API fallback before changing post content.
Features include:
<ul>
<li>Self-managed Google OAuth setup wizard.</li>
<li>Server-side Google Drive document browser for My Drive and shared drives.</li>
<li>Advanced Google Docs URL and raw file ID linking.</li>
<li>Background sync through WP-Cron with source status and diagnostic logs.</li>
<li>One-way Google Docs to WordPress sync for posts, pages, and enabled public custom post types.</li>
<li>Media import for images exported from Google Docs.</li>
<li>Gutenberg block markup for common headings, paragraphs, lists, tables, and images.</li>
<li>Uninstall cleanup for settings, encrypted user tokens, and scheduled events.</li>
</ul>
<h4>External Services</h4>
Brasth Document Sync connects to Google services only after a site administrator saves a self-managed Google OAuth client ID and client secret and a WordPress user connects their Google account.
This plugin sends requests to these Google services:
<ul>
<li>Google OAuth 2.0 endpoints, to authorize a user’s Google account and refresh access tokens.</li>
<li>Google Drive API, to list visible Google Docs, shared drives, folders, document metadata, and HTML ZIP exports.</li>
<li>Google Docs API, to read document structure when the large-document fallback is needed.</li>
</ul>
Data sent to Google can include OAuth client details supplied by the site owner, OAuth authorization codes, refresh-token requests, connected-user access tokens, Drive file IDs, folder IDs, shared-drive IDs, search text entered in the Drive browser, pagination tokens, and document export/read requests.
Data received from Google can include the connected Google account email address, OAuth tokens, Google Docs titles, metadata, modified time, version identifiers, document export content, and image content URLs needed to import media into WordPress.
Google’s terms and privacy documents apply to these services:
<ul>
<li>Google Privacy Policy: https://policies.google.com/privacy</li>
<li>Google API Services User Data Policy: https://developers.google.com/terms/api-services-user-data-policy</li>
<li>Google APIs Terms of Service: https://developers.google.com/terms</li>
</ul>
Brasth Document Sync does not send Google data to a Brasth Document Sync vendor-hosted service in this release.
<h3>Privacy</h3>
Brasth Document Sync stores site-level Google OAuth client settings, encrypted per-user Google tokens, connected Google account email addresses, linked Google document metadata, source sync status, diagnostic sync events, and imported attachment metadata in the WordPress database.
During document browsing and sync, Brasth Document Sync communicates with Google OAuth, Google Drive API, and Google Docs API as described in the External Services section. Imported Google Docs images are stored in the WordPress Media Library. Synced WordPress posts and imported media remain on the site until a user with sufficient permission changes or deletes them.
Uninstall removes plugin settings, encrypted user Google tokens, and scheduled cron events. Linked post metadata is retained by default; define <code>DOCSYNC_WP_FULL_UNINSTALL</code> or return true from the <code>docsync_wp_full_uninstall</code> filter to remove Brasth Document Sync post metadata. Synced posts and imported media are not deleted automatically.
<h3>Source And Build Instructions</h3>
Human-readable frontend source is included in <code>resources/</code>. Built assets are included in <code>build/</code>.
To rebuild the admin assets from source:
<ol>
<li>Install PHP dependencies with <code>composer install</code>.</li>
<li>Install frontend dependencies with <code>pnpm install --frozen-lockfile</code>.</li>
<li>Build assets with <code>pnpm build</code>.</li>
</ol>
The build uses Vite and writes <code>build/manifest.json</code>, <code>build/manifest.post-sync.json</code>, and hashed CSS/JS assets. Runtime React is provided by WordPress through <code>wp-element</code>.

Brasth Document Sync for Google Docs

Sync Google Docs into WordPress posts and pages with self-managed Google OAuth, a Drive browser, background sync, and Gutenberg output.

Jerome Steunenberg

PushPull stores selected WordPress content in a Git repository using a canonical JSON representation instead of raw database dumps.
This project is also documented through a DevOps-focused article series that explains how to efficiently manage a WordPress stack with Bedrock and PushPull, starting here: https://creativemoods.pt/devops-with-wordpress/
<h3>Beta notice</h3>
This is a beta plugin. It is still under active development, has limited functionality, and currently supports only a narrow subset of the intended PushPull feature set.
The current release supports these managed domains:
<ol>
<li>Primary domains: 
 generateblocks_global_styles 
 generateblocks_conditions 
 wordpress_block_patterns 
 wordpress_categories 
 wordpress_comments 
 wordpress_menus 
 wordpress_pages 
 wordpress_posts 
 wordpress_tags 
 wordpress_custom_css 
 generatepress_elements 
 wordpress_attachments (explicit opt-in only) 
generic discovered custom post types and taxonomies</li>
<li>Config domains: 
 wordpress_core_configuration 
 wpml_configuration</li>
<li>Overlay domains: 
 translation_management (WPML-backed) 
 media_organization (Real Media Library-backed)</li>
</ol>
PushPull keeps a local Git-like repository inside WordPress database tables and supports the following workflow directly from WordPress admin:
<ol>
<li>Test the remote GitHub or GitLab connection</li>
<li>Commit live managed content into the local repository</li>
<li>Initialize an empty remote repository</li>
<li>Fetch remote commits into a local tracking ref</li>
<li>Diff live, local, and remote states</li>
<li>Pull remote changes through fetch + merge</li>
<li>Merge remote changes into the local branch</li>
<li>Resolve conflicts when needed</li>
<li>Apply repository content back into WordPress</li>
<li>Push local commits to GitHub or GitLab</li>
</ol>
The plugin also includes:
<ol>
<li>An audit log screen</li>
<li>Local repository reset tooling</li>
<li>Remote branch reset tooling that creates one commit removing all tracked files from the branch</li>
<li>A dedicated Domains screen that separates WordPress core, installed plugin integrations, and discovered custom content</li>
<li>Global and per-domain managed-content views in the admin UI</li>
<li>A high-level PushPull status dropdown in the WordPress admin bar</li>
<li>Menu structure export and apply with hierarchy and theme location assignment</li>
<li>A scheduled lightweight remote-head check that highlights when <code>Fetch</code> likely has updates available</li>
<li>Bulk <code>Commit + Push All</code> and <code>Pull + Apply All</code> workflows for whole-site bootstrap and deploy flows</li>
<li>A <code>wp pushpull</code> WP-CLI command surface for status, configuration, domains, and sync operations</li>
</ol>
<h3>Current scope</h3>
This is an early, focused release. At the moment, PushPull is intentionally limited to:
<ol>
<li>GitHub and GitLab as implemented remote providers</li>
<li>Managed domains across three families: 
 generateblocks/global-styles/ 
 generateblocks/conditions/ 
 wordpress/block-patterns/ 
 wordpress/categories/ 
 wordpress/comments/ 
 wordpress/menus/ 
 wordpress/pages/ 
 wordpress/posts/ 
 wordpress/tags/ 
 wordpress/custom-css/ 
 wordpress/attachments/ 
 wordpress/configuration/ 
 wpml/configuration/ 
 wordpress/generatepress-elements/ 
 wordpress/custom-post-types// 
 wordpress/custom-taxonomies// 
 translations/management/ 
 media/organization/</li>
<li>Canonical JSON storage with one file per managed item for manifest-backed sets, plus directory-backed storage for attachments using <code>attachment.json</code> and the binary file</li>
<li>Explicit opt-in attachment sync through a media-library checkbox</li>
<li>Overlay domains that scope themselves to enabled compatible base domains rather than exporting every backend row blindly</li>
<li>A cached remote-head availability signal for <code>Fetch</code>, driven by a configurable recurring check instead of a live provider probe on every page load</li>
</ol>
It does not yet manage forms, users, arbitrary <code>wp_options</code>, or arbitrary plugin data.
<h3>How PushPull represents content</h3>
PushPull does not use WordPress post IDs as repository identity.
For the currently supported managed sets it stores:
<ol>
<li>One canonical JSON file per managed item</li>
<li>One separate <code>manifest.json</code> file for manifest-backed sets that preserves logical ordering</li>
<li>One directory per attachment for the attachments set, containing <code>attachment.json</code> and the binary file</li>
<li>Stable logical keys instead of environment-specific database IDs</li>
<li>Canonical logical-key references for cross-domain relationships such as reading settings, translation groups, media folders, GeneratePress condition targets, and menu object references</li>
<li>Recursive placeholder normalization for current-site absolute URLs in post-type-backed content</li>
</ol>
<h3>Configuration</h3>
PushPull currently supports GitHub and GitLab repositories.
For GitHub, grant:
<ol>
<li>Repository metadata read access</li>
<li>Repository contents read and write access</li>
</ol>
For GitLab fine-grained personal access tokens, grant:
<ol>
<li><code>Project: Read</code></li>
<li><code>Branch: Read</code></li>
<li><code>Commit: Read</code></li>
<li><code>Commit: Create</code></li>
<li><code>Repository: Read</code></li>
</ol>
In PushPull > Settings:
<ol>
<li>Select <code>GitHub</code> or <code>GitLab</code> as the provider</li>
<li>Enter the repository owner and repository name</li>
<li>Enter the target branch</li>
<li>Enter the API token</li>
<li>Optionally set the remote fetch check interval in minutes</li>
<li>Click <code>Test connection</code></li>
<li>Save the settings</li>
</ol>
<h4>Domain selection</h4>
In PushPull > Domains:
<ol>
<li>Enable one or more managed domains</li>
<li>Review WordPress core, installed plugin integrations, and discovered custom content separately</li>
<li>Opt into generic discovered custom post types and taxonomies when you want them managed</li>
</ol>
<h4>Workflow</h4>
The normal workflow is:
<ol>
<li><code>Commit</code> to snapshot the current live managed-set content into the local repository</li>
<li><code>Fetch</code> to import the current remote branch into <code>refs/remotes/origin/<branch></code></li>
<li>Inspect the live/local and local/remote diff views if needed</li>
<li><code>Pull</code> for the common fetch + merge flow, or <code>Merge</code> manually after fetch when you want review first</li>
<li><code>Apply repo to WordPress</code> when you want the local branch state written back into WordPress</li>
<li><code>Push</code> when you want local commits published to GitHub or GitLab</li>
</ol>
PushPull also performs a lightweight recurring remote-head check and visually highlights <code>Fetch</code> when the latest scheduled check suggests the remote branch has advanced since the last fetch.
For whole-site bootstrap flows, PushPull also supports:
<ol>
<li><code>Commit + Push All</code> to snapshot and publish all enabled domains</li>
<li><code>Pull + Apply All</code> to import and apply all enabled domains on a bare target site</li>
</ol>
If both local and remote changed, PushPull can persist conflicts, let you resolve them in the admin UI, and then finalize a merge commit.
When pushing to GitLab, PushPull currently linearizes local merge results into a normal commit on the remote branch instead of preserving merge topology. The merged tree content is preserved; only the remote Git history shape is flattened.
<h4>WP-CLI</h4>
PushPull also exposes a <code>wp pushpull</code> command.
Examples:
<ol>
<li><code>wp pushpull status</code></li>
<li><code>wp pushpull domains</code></li>
<li><code>wp pushpull config list</code></li>
<li><code>wp pushpull config set branch main</code></li>
<li><code>wp pushpull config enable-domain wordpress_pages</code></li>
<li><code>wp pushpull commit wordpress_pages</code></li>
<li><code>wp pushpull push</code></li>
<li><code>wp pushpull commit-push-all</code></li>
<li><code>wp pushpull pull-apply-all</code></li>
</ol>
<h4>Empty repositories</h4>
If the configured GitHub or GitLab repository exists but has no commits yet, <code>Test connection</code> will report that the repository is reachable but empty.
In that case, click <code>Initialize remote repository</code>. PushPull will:
<ol>
<li>create the first commit on the configured branch</li>
<li>fetch that initial commit into the local remote-tracking ref</li>
<li>make the repository ready for normal commit, fetch, merge, apply, and push workflows</li>
</ol>
You do not need to create the first commit manually on the provider before using PushPull.
<h3>TODO</h3>
<ol>
<li>Cache the admin-bar PushPull status summary so the high-level live/local and local/remote aggregation is not recomputed on every page view.</li>
<li>Move chunked async provider resumability fully into the provider layer so <code>BranchAsyncOperationCoordinator</code> no longer needs provider-specific GitLab staging rehydration logic.</li>
<li>Improve push progress and recap reporting to distinguish newly uploaded objects from objects reused from the remote history.</li>
<li>Surface unresolved logical-reference mapping issues, such as GeneratePress condition IDs that could not be converted to logical placeholders, instead of silently leaving mixed raw IDs and canonical refs.</li>
</ol>
<h3>External services</h3>
PushPull connects to the GitHub or GitLab API for the repository you configure in the plugin settings.
The plugin uses the provider REST API to:
<ol>
<li>Read repository metadata and the default branch</li>
<li>Read and update branch refs</li>
<li>Read and create Git objects or provider-equivalent commit actions</li>
<li>Test repository access before sync operations</li>
</ol>
PushPull sends the following information to the configured provider over HTTPS:
<ol>
<li>The repository owner, repository name, branch, and API base URL</li>
<li>Your configured API token in the provider-specific authentication header</li>
<li>Canonical JSON representations of the managed content you choose to commit and push</li>
<li>Commit metadata such as commit messages and, if configured, author name and email</li>
</ol>
In the current release, the managed content sent to the provider is limited to the enabled supported domains: GenerateBlocks Global Styles, GenerateBlocks Conditions, WordPress Block Patterns, WordPress Categories, WordPress Comments, WordPress Menus, WordPress Pages, WordPress Posts, WordPress Tags, WordPress Custom CSS, GeneratePress Elements, explicitly opted-in WordPress Attachments, WordPress core configuration, WPML configuration, generic discovered custom post types and taxonomies, WPML-backed translation management, and Real Media Library-backed media organization.
PushPull does not send your whole WordPress database to the provider. It only sends the managed content represented by the enabled adapters.
GitHub terms of service: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service 
GitHub privacy statement: https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement 
GitLab terms: https://about.gitlab.com/terms/ 
GitLab privacy statement: https://about.gitlab.com/privacy/

PushPull

Git-based content sync for WordPress. Project homepage: https://creativemoods.pt/pushpull/

Brasth Document Sync for Google Docs vs PushPull