Contentrain Bridge – Export to Markdown, JSON & Git

Contentrain Bridge turns your WordPress content into editable JSON and Markdown under Tools > Contentrain Bridge. You choose the content, review how it is modelled and which interface text travels, then download a ZIP or send the result to a branch in your own GitHub repository. Both are free.

• Advanced Custom Fields groups and repeaters become their own models with their own named fields, not one anonymous bag of values.
• Free software under GPL-2.0-or-later. No account, subscription or paid service is required for either delivery.
• Your WordPress site is not modified. The plugin reads content and source files; it never patches a theme or plugin. The one exception is opt-in: a switch, off by default, that adds a group for Contentrain Migrate to the robots.txt WordPress serves (see External services).
• Every export step is started by a logged-in administrator through a nonce-protected request, or, over the REST export API, by a program that administrator authorized with an application password or a connection key (see External services).
• Exports run in bounded steps and can be resumed, so large sites do not depend on one long request.
• Comment archiving is off by default. When enabled, email addresses, IP addresses and comment metadata are excluded.
• Metadata that looks like a password, token, key, credential or personal identifier is never exported, including inside selected fields.
• Exported site data remains the site owner's data and is not placed under the plugin's GPL license merely by being exported.

Media travels with the content: uploads are copied into media/ and the content is relinked to them, so the delivered repository does not depend on this site for images. A file over 8 MB, or one missing from the uploads directory, keeps its WordPress URL and is named in the coverage report. Dynamic WordPress and plugin output is not rendered during a source scan. These limits are written into the coverage report rather than implied to be complete. Want a working Astro website instead of files? Contentrain Migrate, a separate paid service, connects to this plugin with a key you create and builds a complete Astro site from your content: https://migrate.contentrain.io/?utm_source=wordpress-org&utm_medium=readme External services The plugin contacts no host other than this site unless you choose GitHub delivery. Two options read this site's own pages over HTTP, the way a visitor would, and send nothing elsewhere: "Also read the text your pages render" (the home page, a post, a page, search and not-found) and, with it, the connected-services check (the home page's script hosts). GitHub — used only when you enter a repository and a token in step 3 and start the delivery. The plugin then calls the GitHub REST API at api.github.com to read the target repository's default branch (or the base branch you name) and file list, upload the exported files, and create one new branch holding them. What is sent: the exported content files you reviewed, a commit message, and the token you supplied. Nothing is sent to Contentrain or to any other host, and no analytics or telemetry is collected. The token is used for those requests only and is never stored in the database or in the export. Delivery never writes to your default branch and never overwrites a file you edited in Git. GitHub's terms: https://docs.github.com/site-policy/github-terms/github-terms-of-service — privacy policy: https://docs.github.com/site-policy/privacy-policies/github-privacy-statement REST export API (inbound) — the plugin adds routes under /wp-json/contentrain-bridge/v1/ that let a program you authorize start an export and read its files. The plugin sends nothing by itself: the program asks, with an application password of an administrator who has the export and manage_options capabilities, or with a Contentrain Migrate connection key (below). Contentrain Migrate uses these routes when you give it such a password or key to migrate this site; what Migrate then does with the content is governed by Contentrain's terms (https://contentrain.io/terms-of-service) and privacy policy (https://contentrain.io/privacy-policy). The program that starts an export chooses its scope: Migrate asks for private content (drafts, pending, scheduled, private and password-protected posts, never the password) and for comments, and the exported files carry each post's own status. These routes only read: no remote call creates, edits or deletes posts, settings, files, users, plugins or themes; the plugin writes only its own temporary export files outside the web root and its own bookkeeping options. Revoke the application password in your profile (or the connection key on the Bridge screen) to end that access; exports expire after a day. robots.txt (only when you turn it on) — Tools > Contentrain Bridge has a switch, off by default, "Let Contentrain Migrate read my pages and media". It changes only the robots.txt WordPress itself serves, through WordPress's robots_txt filter, and contacts no host. When you turn it on, robots.txt gains one group for the ContentrainMigrate crawler: the rules your robots.txt gives every crawler (User-agent: *), without the lines that close the whole site (a Disallow matching /), followed by Allow lines for the REST API (/wp-json/), your uploaded media (/wp-content/uploads/) and /. By robots.txt's longest-match rule those Allow lines open only those paths: a rule such as Disallow: /wp- still keeps wp-admin closed. Paths you keep closed, such as wp-admin, stay closed to it, and every other crawler sees robots.txt exactly as before. Turning it off removes the group, and uninstalling the plugin removes the setting. If your site serves a robots.txt file from disk, WordPress cannot change it: the switch stays off and the screen shows the lines to add yourself.

1. In Plugins > Add New, search for "Contentrain Bridge" and install it. You can also download contentrain-bridge.zip from the latest GitHub release (https://github.com/Contentrain/wordpress-bridge/releases/latest), the same archive, and install it with Plugins > Add New > Upload Plugin.
2. Activate Contentrain Bridge in WordPress.
3. Open Tools > Contentrain Bridge.
4. Step 1: choose content types and options, then prepare the content.
5. Step 2: review the generated models and the interface-text candidates, then validate and finalize.
6. Step 3: download the ZIP, or deliver to a branch in your own GitHub repository.

Updates arrive through WordPress like any other plugin's, from the WordPress.org directory. A ZIP installed from a GitHub release is updated by uploading the newer release ZIP the same way; WordPress replaces the installed version. Export snapshots are temporary and are not affected.

0.8.5

• The plugin is named "Contentrain Bridge – Export to Markdown, JSON & Git" in the plugin list and the directory.
• The Migrate card states that Contentrain Migrate is a separate paid service that reads the site through a connection key, and its link is tagged utm_source=bridge so visits from the plugin can be counted. The link sends no site data.

0.8.4

• Widgets are read through WordPress's own widget registry: each registered widget reads only its own settings. The export no longer lists option names from the database to find widgets, so a widget whose plugin is inactive is not counted or scanned, as WordPress does not show it either.
• Connected services are found by setting names only. A setting whose name marks a credential (key, token, secret) counts as set when it is not empty; the database answers that, and the value is never read. Evidence names the setting ("mc4wp"), not the keys inside it. A form wired to a service (Contact Form 7, WPForms) counts as connected when its account entry exists; the keys inside it are not inspected.

0.8.3

• The content type list on the export screen shows each type's published count as a number ("Pages (7 published)", plus private ones when there are any). It used to join the per-status counts as text ("Pages (07010000000000)").
• Interface text only an administrator sees is no longer offered for review: an options panel (Redux, Kirki, a theme-options file), a bundled plugin installer (TGM), an admin directory, and minified scripts. JavaScript literals that are one lowercase word or a BEM class name ("fade", "collapsing", "pswp__img") are code. Each is still listed in bridge/hardcoded-text.json with its reason; the same words in a template a visitor sees stay a candidate.
• "Include all undecided" and "Exclude all undecided" decide every text candidate still waiting, on every page, in one step. Menu labels keep their default.
• A record with an empty title, or an empty ACF field marked required, no longer stops the export with "Required content value is empty." WordPress saves both: a title-less post, attachment or menu link, and a private or draft post that ACF never held to its required field. An empty title gets a label from the record's slug or id, counted per model in bridge/warnings.json; an empty required field is left out, becomes optional in that model, and is named in the warnings. No record is dropped. When a required value is still empty, the message names the model, the field and the language.

0.8.2

• Every REST route with an export id in its path checks, in its own permission callback, that the export is the caller's (the connection key's own, or the signed-in user's), and answers 404 otherwise. This replaces the id check that sat inside the connection key's authorization, which covered key requests only; the handlers still read the export through the same ownership check. Nothing a caller can do changes.
• The site title and tagline are the only options read untranslated for language strings, from a fixed list; any other name reads as empty. Same output as 0.8.1.

0.8.1

• A post or a term nobody has translated is no longer exported as a translation group of one: its language travels on the post or term itself, as before, and the translation groups are only the real ones.
• WordPress's own site-building types (navigation menus, template parts, reusable blocks, templates, global styles, fonts) carry their language but form no translation groups: they are not content Contentrain Migrate moves as entries.

0.8.0

• A multilingual site's languages now travel to Contentrain Migrate as Polylang or WPML declares them: each language's code, locale, tag, name, home address, direction and order, which one is the default, the language's own front page and posts page, and how the site's addresses carry the language (a directory, a subdomain, a domain, or a URL parameter, plus whether the default language is left out of them). Every value is the plugin's own, unchanged.
• Categories, tags and other translated terms now carry their language, and a term and its translations travel as one group, as posts and pages already did. A language a group lacks is named.
• Polylang's and WPML's own bookkeeping taxonomies (which post is in which language, which ones translate each other) are no longer exported as terms beside your real categories. What they record travels as each post's and term's language and as the translation groups.
• Menus carry their language, and with Polylang, the theme locations they are shown in for that language.
• Interface strings the plugin translates travel with their translations per language: the site title and tagline, and, with Polylang, the strings themes and plugins register in its Strings screen.
• With WPML + ACFML or ACF Options for Polylang, an ACF Options Page's other-language values now travel beside its default-language ones. The Contentrain store keeps its default-language values, as before.
• A post's language is now Polylang's or WPML's own code, the same one its translation group uses. With neither plugin nothing changes.
• WPML is supported through WPML's own documented filters. There is no WPML licence in this plugin's tests: the WPML path is tested against those filters' documented answers, not against a live WPML site.

0.7.1

• A request made with a Contentrain Migrate connection key no longer runs as the administrator who created the key. It runs with no WordPress user at all; the key stays valid only while that administrator still has the export and manage_options capabilities, and the exports it starts are recorded in the plugin's own settings, never in a user's profile. A key can no longer reuse or replace an export the administrator started with an application password. Revoking the key also removes the exports it prepared. Nothing changes for Contentrain Migrate: every route, answer and error code is as before.
• The Bridge screen, this readme and the privacy-policy text now say what the key lets Migrate read, that it cannot change the site, and how to revoke it.
• The export screen sends its requests as plain form fields, each checked on its own, instead of one JSON blob; the REST export routes declare and check every parameter; the note about a server that does not read .htaccess names the kind of server (nginx, IIS, other) instead of repeating the server header. A coding-standards check (PHP_CodeSniffer with the WordPress ruleset) now runs in the plugin's own tests.

0.7.0

• A new switch under Tools > Contentrain Bridge, "Let Contentrain Migrate read my pages and media", lets you open your site to Contentrain Migrate when your robots.txt closes it to crawlers. It is off by default. It changes only the robots.txt WordPress serves, adds one group for Contentrain Migrate, keeps closed what you close for every crawler (wp-admin, for one), and changes nothing for other crawlers. If your robots.txt is a file on disk, or a CDN serves it, the screen shows the lines to add yourself.
• Contentrain Migrate can ask the plugin how much a move would carry before you pay: the number of published entries per content type and the number of media files, as WordPress counts them. Only numbers are sent, never titles or addresses. The answer needs the same sign-in as an export (an administrator's application password or your connection key), so it is never public.
• The privacy text now says what an export already contained: authors' WordPress usernames as well as their display names, and, when comments are selected, comments of every status (approved, pending, spam and trash), each with its status.

0.6.5

• The "modified after" change list — the one a reader keeps when it has no earlier inventory to compare with — now covers every post type the export itself covers, including a custom post type the site keeps out of the REST API (a classic theme's portfolio or product type, which WordPress hides from REST unless the theme says otherwise). Before, an edit to such a record never appeared in that list, although the record itself was exported.

0.6.4

• The export screen (Tools > Contentrain Bridge) is laid out in WordPress's own cards and shows where the export is: the nine stages as a list with the current one marked, a progress bar with a percentage, the item being worked on, and the counts so far. A stage the chosen scope leaves out (media, comments) is shown as skipped.
• When the export stops, the screen says what happened and what to do: a stop the screen can retry (an interrupted or busy request, an archive or delivery that did not advance) offers Retry; an export the server gave up on offers deleting it and starting again with a smaller scope. Keyboard and screen-reader users land on the message, and progress is announced on a stage change and every quarter of the way rather than on every batch.
• A finished export opens with its totals and the two ways to take it, the ZIP download and GitHub delivery, with the coverage table folded away until wanted. Before an export the screen says what will happen.
• Each stage records its progress (items done, items in all, the latest item) in the export's state, so a screen opened later shows it too. An export started by an earlier version shows its stages without a count until its next stage begins.

0.6.3

• The export from the plugin's own screen no longer hangs on a host whose time or memory limit ends the request mid-step. Each request now does as many steps as fit in twelve seconds and saves as it goes; a request the host kills is counted, the next one works in smaller batches and saves after every step, an attachment that ends the request again and again is left out with a notice (its WordPress address is kept), and after six killed requests from the same point the export stops with a message saying what to do instead of retrying for ever. The screen retries a busy or interrupted request by itself, with a timeout, and shows the reason when it gives up.
• A host where the export's lock cannot be taken for a reason other than another request holding it no longer answers "busy" for ever: a marker that expires after two minutes stands in.
• The notice at the end of a repeatedly interrupted export names the stage and the step, so a report to the host or to Contentrain carries what is needed.

0.6.2

• Block themes whose footer is a block pattern (Twenty Twenty-Five's, for one) now export the footer's navigation menus. They sat inside the pattern, which the export did not open, so a migrated site printed the main menu in its footer instead of its footer links. They arrive as before, as menus of the footer.
• Advanced Custom Fields fields of a post now carry their type and label in the migration data, as the fields of an options page already did, so a migration no longer has to guess from the value what a field is (an image field holding a number is an image, not text).
• When a program such as Contentrain Migrate reads an export through the REST API, an export older than a day now answers "expired" and an unknown one "not found", instead of a generic bad request, and a request with no sign-in at all is told to use the connection key (some hosts strip the Authorization header). The download of an export you start yourself answers a missing or expired export the same way: "not found" or "expired", not a generic bad request.

0.6.1

• Advanced Custom Fields repeaters, groups and flexible content now reach the migration data under their field names (label, url), not ACF's internal keys (field_5f3a…), so they match what the REST API gives and the migrated fields are readable in Studio. Fields on posts and options pages are both affected. A key no field owns is kept as it is and reported.

0.6.0

• Advanced Custom Fields options pages ("Site settings", footer, contact details) are exported as site-wide fields in the migration data, typed like the fields of a post. They were already in the export as their own entry; a migration could not use them until now.
• Contentrain Migrate now asks for the "private content" scope when it reads an export through the REST API, so drafts, private and password-protected posts stay drafts, pending posts arrive in review, and a scheduled post keeps its publication date. A password-protected post keeps [protected]; the password itself never leaves WordPress. The plugin's behaviour is unchanged: the scope is chosen by whoever starts the export, and exports you start yourself are unaffected.

0.5.0

• Page builders: the Elementor layout tree and page settings, Divi's builder settings, the Elementor kit (global colours, fonts, layout), block-theme global styles and templates are exported without selecting them, so a migration can rebuild the design. Password-protected posts keep none of it.
• Page-builder data stays raw evidence and is never turned into content fields. A deeply nested Elementor page no longer stops the whole export as "too large"; a value nested past the limit is kept as JSON text with a warning.
• Advanced Custom Fields: groups, repeaters, flexible content, links, maps and multiple choices become values inside the entry (objects and lists) instead of separate one-row collections. A page link field no longer fails the export, a link inside a repeater row keeps its label, and fields are judged secret by their type rather than by a broad name rule.
• Menus: block themes (such as Twenty Twenty-Five) now export their navigation, including inline links, page lists and home links, and every menu says which theme location shows it. A link to a draft or private page is left out and reported; its child links move up instead of disappearing.
• Redirects: rules from .htaccess and Simple 301 Redirects are exported, 410 and 451 "gone" rules are kept, and Redirection's query, case and trailing-slash options are respected. A rule that depends on a cookie, header, IP or role is reported without its condition data.
• A ?p= link typed with or without www. is recognised as the same site.
• Tests: ACF, menu and redirect behaviour is checked against the same shared fixtures as Contentrain's WordPress importer, which is updated to 0.5.7.

0.4.0

• Contentrain Migrate connection key: Migrate can start and read exports on hosts that strip the Authorization header, without an application password. Shown once, HTTPS only, bound to one Migrate order: an hour to paste it, then valid for that order up to 14 days; revocable by you or closed by Migrate.
• A password-protected post (exported with private content) carries [protected] instead of an empty password, so a reader keeps it off the public site; the password itself still never leaves WordPress.
• REST: GET /about says which sign-in a reader can use; POST /exports/{id}/read reads a snapshot for a caller whose key travels in the request body; DELETE /key lets Migrate close its own key.

0.3.1

• Readme: contributors.

0.3.0

• REST export API for Migrate: start (POST /exports, reused per scope, max_age/fresh), list, and advance an export with an application password; read any snapshot file in 8 MiB chunks. Administrator permissions only.
• The snapshot of a REST export carries its RawIR v1 as bridge/rawir.json. GitHub delivery never includes it.
• media_files: false (REST, and a checkbox on the export screen): attachment records without their files; content keeps the WordPress upload URLs.
• SEO: Rank Math, AIOSEO, SEOPress and Yoast title and description templates are rendered to the text a page carries, with robots and canonical; SEOPress support; AIOSEO Pro term values. Checked against each plugin running live.
• Large sites: the export's memory no longer grows with the site. 5,000 posts, 20,000 media records and 20,000 comments export in about two minutes at a 64 MB memory limit.
• Shared hosts: an advance stops before PHP's max_execution_time and saves as it goes, and a request killed midway writes nothing twice.
• A snapshot being downloaded is not replaced by a fresh export for ten minutes.
• Updates are manual outside WordPress.org: install the new release ZIP over the old one.
• Readme: what the plugin requests from this site and from GitHub, and the REST export API, described for WordPress.org.

0.2.1

• Prevent partial ACF modelling, disambiguate same-name fields and normalize stored dates.
• Protect nested sensitive ACF values and private attachment scope.
• Fix nested-page media URLs, binary export reads and repeated GitHub delivery manifests.
• Clean up expired and uninstalled snapshots; serialize cancellation with active export work.
• Add a checksum-verified Bridge-to-Migrate intake adapter and reproducible package build.

0.2.0

• ACF field groups become Contentrain models: a repeater is a collection of records, a group is a related record, and sub-field types map onto Contentrain field types.
• Media transfer: uploads and their generated sizes are copied into media/ and content is relinked to them.
• Contentrain models: JSON collections, Markdown documents, a site singleton and an interface-text dictionary.
• Interface-text discovery in theme and plugin source, with a mandatory review step before anything is exported.
• Bounded, resumable export with validation before delivery.
• Free ZIP download and free delivery to a branch in your own GitHub repository.
• Metadata is opt-in, and secret-looking keys and values are excluded.

0.1.0

• Initial local RawIR v1 export.