WordPress.org introduced Reprint on November 13. The free tool copies a WordPress site’s files and database, so a publisher can open a copy with the theme, plugins and settings that make the site work. That gives a small newsroom a way to rehearse a plugin update or a hosting move before readers encounter it. A rehearsal and a final move need different checks. The first copy can look right and still be missing the subscriptions and editorial changes that arrived while the old site kept running.
WordPress’s built-in content export still makes sense when you only need to move posts, pages and other content records into another WordPress installation. Reprint is for the job where the rest of the site matters, such as when a membership plugin controls who sees a story.
Jump to a section
Test what your readers rely on
Reprint’s setup guide describes a plugin on the original site and a command-line client on the receiving computer or server. The guide calls for administrator access to the source. It covers macOS, Linux and Windows Subsystem for Linux for the client. You can use that setup to open a private copy without sending visitors to a new address. WordPress also announced an experimental option in its browser-based Playground.
Reprint’s guide to moving hosts says to disconnect outgoing email, live payments and scheduled jobs before opening the copy. A copied newsletter or membership plugin may still point at the account used by the live site. Keep the destination private while you change those connections. Use a test account and test services for any action that would otherwise send mail or bill a reader. Then check an article with a photo, a signup form and a paid story from both a free and a paid account. Here is how to test both sides of a WordPress paywall.
Write down which fixes only exist on the copy. If you changed a plugin setting in the rehearsal database, keep a note of the old and new values so you can reapply and verify the change after a fresh import. A homepage screenshot cannot tell you whether the copied form still writes to the correct list.
Reconcile what changed while the old site was open
Consider a paid local newsletter that finishes a rehearsal copy at 10 a.m. At 11:30, an editor fixes an event date on the source. By 2 p.m., the old site has recorded 12 new signups, three of whom already have paid access. A developer also fixes a signup form setting on the rehearsal copy. Opening the homepage at 2 p.m. could easily miss every one of those changes. The table shows which records a publisher needs to carry forward.
The example assumes WordPress holds an account or access record and a separate service records payment. If the payment service shows three successful transactions, check which three accounts should be entitled to read on the destination. Do not add three more accounts to the signup total or run the original charges again. Compare stable account or transaction identifiers in your private records, rather than relying on equal totals that might hide a mismatched reader.
Here is one way the totals can fool you. Suppose both sites show three newly paid accounts, but the source lists A, B and C while the destination lists A, B and D. Two accounts match. C could be locked out and D could have access it should not have. Open the paid story using representative test roles, then reconcile the specific new records against the membership and payment systems. The account check and the test login catch different mistakes.
| Change after the first copy | Where it happened | What to verify before routing readers |
|---|---|---|
| Event date corrected | Original site | Open the article and confirm the correction is visible. |
| 12 new signups, including 3 paid readers | Original site and payment service | Match 12 accounts and reconcile the 3 paid access records. |
| Signup form setting fixed | Rehearsal copy | Record and reapply the setting after the final database import. |
Keep the final copy and the switch separate
Reprint’s documentation on repeated imports says a new database pull can replace destination data with source data. It does not reconcile changes made on both sides. For the final move, plan a brief pause on writes to the source, including editorial changes and any forms that create records there. Coordinate where your payment service sends callbacks during the switch and reconcile events that arrive while the site is paused. Keep the original available for recovery. If it starts receiving writes again after the new site has opened, you have two sets of records to reconcile.
Before sending readers to the new host, check one of each item in your change list and confirm your destination is the only site set to run live jobs. If an issue is queued to go out around the move, check when a scheduled WordPress post actually appeared and verify the newsletter delivery separately. This procedure follows the transfer behavior documented by WordPress. The records above are illustrative, and we did not migrate a live membership site.