Описание
Content Version for Git backs up WordPress content versions to a GitHub repository. It creates a GitHub revision history for posts, pages, categories, tags, and optionally media metadata and original media files, so editors and site owners can audit changes, compare versions, restore earlier content, and recover deleted resources from wp-admin.
This is designed for site owners, agencies, and developers who want a GitHub-backed content audit trail without running Git on the WordPress server. The plugin writes and reads Git objects through the GitHub API. It does not keep a local Git repository and does not call the git CLI.
Features include:
- GitHub backup and revision history for WordPress posts, pages, categories, tags, and optional media resources.
- Automatic Git versions for normal post and page saves.
- Batched Git versions for direct category and tag relationship changes.
- Side-by-side content diffs and field diffs.
- Full restore and content-only restore modes.
- Deleted Resources view for posts, pages, and tracked media.
- Restore deleted posts/pages as new drafts and deleted media as new attachments.
- Optional media metadata and file tracking.
- Manual import of existing posts, pages, and media.
- Version store dashboard with branch, latest commit, tracked file count, size, and GitHub version store status.
- Direct GitHub API commits without a local Git worktree.
Safety boundaries:
- Import Existing Content only writes versions to GitHub. It does not change WordPress posts, pages, media, categories, or tags.
- No content is sent to GitHub until an administrator enables and configures the GitHub version store.
- Use a private GitHub repository because versions may include unpublished content, metadata, and media files.
- The GitHub token is not displayed after saving.
- Normal version writes preserve unrelated files on the selected branch.
- Reset GitHub Version Store rewrites the configured GitHub branch history, but it does not delete WordPress content.
External Services
This plugin connects to GitHub when the „Enable GitHub version store“ setting is enabled and a repository URL, branch, and personal access token are configured.
When enabled, the plugin writes Git commits directly to the configured GitHub repository using the GitHub API. Commit data may include post/page content, metadata, term references, media metadata, and media files if media tracking is enabled.
Create the GitHub repository before configuring the plugin. The repository may be empty, and the plugin can initialize an empty repository on the first write, but it does not create GitHub repositories. Use a dedicated repository or a dedicated branch for this plugin’s version store. Normal version writes preserve unrelated files on the branch, but Reset GitHub Version Store rewrites the configured branch history.
For fine-grained personal access tokens, select only the version-store repository and grant Contents read and write access. Organization repositories may require organization approval for the token before the plugin can use it.
The GitHub version store is disabled by default. No data is sent to GitHub unless a site administrator enables and configures it. Without the GitHub version store, this plugin does not keep durable local Git versions. GitHub’s terms and privacy policy apply:
- https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
- https://docs.github.com/en/site-policy/privacy-policies/github-privacy-statement
Снимки на разширението
Инсталиране
- Upload the plugin files to the
/wp-content/plugins/content-version-for-git/directory, or install the plugin through the WordPress plugins screen. - Activate the plugin through the Plugins screen in WordPress.
- Create a dedicated GitHub repository, or choose a dedicated branch in an existing repository.
- Create a GitHub personal access token that can read and write repository contents for that repository.
- Open Content Versions > Dashboard.
- Configure the GitHub version store and media tracking.
- Review any GitHub settings notice. Empty repositories can be initialized by the plugin; non-empty repositories should use an existing writable branch.
- Use Import Existing Content if you want to add existing posts, pages, and media to GitHub.
ЧЗВ
-
Where are Git versions stored?
-
GitHub is the version store. The plugin reads and writes versions through the GitHub API without a local Git repository.
-
Does this replace WordPress revisions?
-
No. It adds a Git-backed version history for selected WordPress resources.
-
Is this a WordPress backup plugin?
-
It backs up content versions to GitHub, including posts, pages, terms, and optional media resources. It is not a full site backup plugin and does not back up the WordPress database, themes, plugins, users, or server files.
-
Can I restore WordPress posts and pages from GitHub?
-
Yes. You can preview, compare, and restore tracked post and page versions from the WordPress admin. Deleted posts and pages can be restored as new drafts.
-
Can I use this for content audit history?
-
Yes. GitHub commits provide an external audit trail for tracked WordPress content changes, including post/page saves and category/tag relationship changes.
-
Does the GitHub version store run by default?
-
No. The GitHub version store is disabled until an administrator enables it and provides a repository URL, branch, and token. Without GitHub configured, versions are not durably stored and the plugin does not keep a local Git repository.
-
Will importing existing content change my WordPress site?
-
No. Import Existing Content scans selected resources and writes missing versions to GitHub. It does not modify WordPress content.
-
What GitHub repository do I need?
-
Create the repository in GitHub before configuring the plugin. The repository can be private or public, but private is strongly recommended because content versions can include unpublished content, metadata, and media files. The repository may be empty. If it is empty, the plugin can initialize the configured branch on the first write.
-
Can I use a branch that already has commits?
-
Yes, but a dedicated repository or dedicated branch is strongly recommended. Normal version writes use the current branch head as the parent commit and preserve unrelated files. If the branch already contains Content Version for Git files under
posts/,pages/, ormedia/, use Rebuild GitHub Index after connecting it to a site that has not indexed it yet. -
Why should I avoid sharing the branch with other work?
-
Reset GitHub Version Store rewrites the configured branch to a new empty history. WordPress content is not deleted, but unrelated files and commits on that branch will no longer be part of the branch history after reset.
-
What token permissions are required?
-
Use a token that can read and write contents in the selected repository. For fine-grained personal access tokens, select the version-store repository and grant Contents read and write access.
-
What happens if GitHub API writes fail?
-
The version is not stored. Configure GitHub before relying on the plugin for durable version history.
-
Are media files stored in Git?
-
Only when media tracking is enabled. In that mode, referenced media metadata and files are committed directly to GitHub.
Отзиви
There are no reviews for this plugin.
Сътрудници и разработчици
“Content Version for Git” е софтуер с отворен код. Към разширението са допринесли следните хора:
Сътрудници
Превеждане на “Content Version for Git” на вашия език.
Имате интерес към разработване?
Преглеждане на кода, разглеждане на SVN хранилище, или абонамент към програмната история (log) чрез RSS.
Списък с промени
0.1.8
- Fixed missing post versions when categories or tags are changed directly or in bulk without a post save.
- Batched taxonomy-only relationship changes into a single Git commit per request.
- Added automatic versions for category/tag metadata and registered term-meta changes.
0.1.7
- Improved large import reliability with smaller batches, import batch locking, and longer GitHub API request timeouts.
- Added automatic retry handling for interrupted import progress requests and gateway timeout responses.
- Added clearer import progress messages that point to Nginx, PHP-FPM, or load balancer timeout settings when relevant.
0.1.6
- Moved dashboard action feedback next to the relevant GitHub settings, import, rebuild, and reset controls.
- Replaced the GitHub repository API size display with a version-store content size calculated from tracked GitHub tree blobs.
- Added status API fields for version-store size while keeping existing size fields backward compatible.
0.1.5
- Fixed first import into an empty GitHub repository when media files require Git blob creation.
- Added GitHub settings checks and notices for missing repositories, empty repositories, missing branches, existing version-store branches, and branches that appear to contain unrelated content.
- Documented GitHub repository, branch, token, and reset-history requirements.
0.1.4
- Clarified that GitHub is the required durable version store.
- Renamed GitHub-related UI wording to GitHub version store.
0.1.3
- Tightened restore permissions for full Git version restores.
- Replaced trusted output wrappers with late escaping for generated admin HTML.
- Removed runtime shell diff generation from the diff view.
0.1.2
- Renamed the plugin and package slug for WordPress.org resubmission.
0.1.1
- Addressed WordPress.org review feedback for asset enqueuing, filesystem locations, and plugin metadata.
0.1.0
- Initial public release candidate.
- Added Git-backed versions for posts, pages, terms, and optional media resources.
- Added preview, diff, full restore, and content-only restore.
- Added Deleted Resources and restore-as-new flows.
- Added import existing content controls.
- Added GitHub version store settings.