PageFerry exports a single Gutenberg page, post, or custom post type (content + manifest + media) to a ZIP file on staging, then imports it on production with correct block-level attachment remapping, slug + taxonomy preservation (categories, tags, and custom taxonomies), domain rewrite, hash-based media dedup, and update-in-place.<\/p>\n\n
Scope (Gutenberg-only): export\/import via ZIP for pages, posts, and block-editor custom post types; featured + inline images; slug + categories\/tags\/custom taxonomies; basic staging\u2192prod domain rewrite; existing-media reuse; create-new or update-selected; land-as-draft option; pre-import backup of overwritten content + plain-language log.<\/p>\n\n
Explicit v1 non-goals: builders (detect + refuse with a clear message), ACF\/SEO meta beyond pass-through (exception: ACF blocks that store their fields in post meta via Small ZIPs import in one upload. Larger bundles (over your host's per-upload limit) import file-by-file through an in-browser worker (bundled JavaScript, no extra service): the same dedupe\/remap\/create result either way. A single asset larger than the limit cannot import \u2014 the error names the file.<\/p>\n\n\n Requires: WordPress 6.5+, PHP 8.1+, PHP zip extension (for the export side).<\/p>\n\n\n PageFerry v1 imports Gutenberg pages only. The exporter detects page-builder meta (Elementor, Divi, Beaver Builder, Bricks, WPBakery) and records it in the bundle; the importer refuses the bundle with a message naming the builder instead of silently corrupting the layout. Export your content as Gutenberg blocks (or rebuild the page in the block editor) and ferry again. Builder support is planned after v1.<\/p><\/dd>\n Every media file is hashed (SHA-256) at export. On import, PageFerry looks the hash up in its reuse index and verifies the match by re-hashing the existing attachment \u2014 a stale index row never reuses a deleted file. Identical bytes reuse the existing attachment; same filename with different bytes uploads separately. The confirmation screen reports reused-vs-new counts, and the Logs tab records them per import.<\/p><\/dd>\n You choose on the import screen. Create-new (default) inserts the content as a draft with a unique slug (a clash gets a Tools \u2192 PageFerry Import \u2192 Backups. Each update-selected import stores the target's prior content and meta under a Your host caps each upload ( Blocks that keep their field data in the block comment (the ACF default) ferry like any other blocks: media IDs remap, everything else passes through. Blocks that store their fields in post meta ( No. v1 makes no outbound requests, loads no CDN scripts, and runs with no account or license key. All JavaScript (including the large-bundle worker dependency fflate 0.8.3, MIT, source at https:\/\/github.com\/101arrowz\/fflate) ships inside the plugin. Import\/export handlers require the usePostMeta<\/code> ferry their values with media-ID remap \u2014 see FAQ), bulk, direct push-without-ZIP, multisite.<\/p>\n\n\n
pageferry<\/code> to \/wp-content\/plugins\/<\/code>, activate.<\/li>\n\n
Why was my Elementor page refused?<\/h3><\/dt>\n
How does media dedup work?<\/h3><\/dt>\n
Update vs create \u2014 which is used?<\/h3><\/dt>\n
-2<\/code> suffix plus a notice). Update-selected overwrites the target's content, excerpt, terms, and featured image after snapshotting the prior content + meta into Backups and writing a log row. Terms (categories, tags, and custom taxonomies) match by name: existing terms are reused as-is (their current parents are kept, never restructured); only new terms are created with their exported hierarchy. The imported post type must be registered on the production site (activate the plugin or theme that provides the custom post type first). There is no one-click rollback in v1 \u2014 restore from the Backups tab by pasting the stored content back.<\/p><\/dd>\nWhere is my pre-import backup?<\/h3><\/dt>\n
pf-*<\/code> key before writing anything (kept: last 20). The Logs tab links each update row to its backup key.<\/p><\/dd>\nThe import says a file is too large. What now?<\/h3><\/dt>\n
upload_max_filesize<\/code>). Bundles over that cap import file-by-file automatically \u2014 but one single asset over the cap cannot. Raise the PHP upload limit, or drop that asset from the page and re-export. The error names the file.<\/p><\/dd>\nDoes PageFerry ferry ACF block data?<\/h3><\/dt>\n
usePostMeta<\/code>, ACF PRO 6.3+) ferry their field values too: image\/file\/gallery IDs remap to the new attachments, upload URLs rewrite, all other values restore verbatim through the ACF API. Two limits apply: reference fields (post\/relationship\/taxonomy\/user\/page-link IDs) point at source-site content and ferry verbatim \u2014 the export warns when they hold values \u2014 and on update-selected imports, fields unset on the source keep the target's existing values.<\/p><\/dd>\nDoes PageFerry phone home or load remote code?<\/h3><\/dt>\n
import<\/code> \/ edit_post<\/code> capabilities plus nonces.<\/p><\/dd>\n\n<\/dl>\n\n\n1.1.0<\/h4>\n\n
\n
usePostMeta<\/code> blocks: field values stored in post meta now ferry in the bundle (acf_post_meta<\/code>) and restore on import with media-ID remap and URL rewrite, written back through the ACF API. Skipped values are reported in the import log row (acf_skipped<\/code>); reference-type IDs ferry verbatim (export warns).<\/li>\n<\/ul>\n\n1.0.0<\/h4>\n\n
\n