PageFerry

FAQ

Where are temporary files stored?

Exports and both import paths stage files in a site-specific, owner-only directory outside WordPress and uploads. The default parent is PHP’s system temporary directory; PageFerry checks its location and permissions before using it. If private storage is unavailable, export and import stop. Your host can set PAGEFERRY_PRIVATE_DIR in wp-config.php to an existing private parent shared by all PHP workers. The host must keep this parent outside every public document root and web-server alias, secure PHP’s own upload temporary directory, and provide coherent filesystem locks and rename operations. Containers must share the same private storage mount when handling the same import sessions.

The single-upload ZIP is deleted after preparation, with shutdown cleanup where available. Abandoned files and hard-killed requests are reclaimed by later admin-triggered GC after the idle grace; active leases and live sessions remain protected. Existing confirmations prepared in the old uploads location must be prepared again. Legacy cleanup requires the original workspace guards and activity/lock records; ordinary uploaded ZIPs and ambiguous old folders are preserved.

Why was my Elementor page refused?

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.

How does media dedup work?

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 — 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 plus missing source IDs, export notes, and ACF skips before anything is written, and the Logs tab records them per import (a success with skipped values shows as success with warnings).

Update vs create — which is used?

Choose the destination post type first; it applies to both new drafts and updates. Create-new inserts a draft of that type. Update-selected replaces the selected post’s content and checked details after saving a recovery snapshot; its status stays the same and its current URL slug is the default. An explicit slug edit changes the URL after review. The selected post must already have the chosen type. You can import a bundle into a different supported type, with a warning to check its taxonomies and template.

Terms match by slug, then name and parent; legacy name-only terms match by name. Existing terms keep their current parents. Selected new terms bring along the parents needed to recreate their hierarchy. There is no one-click rollback in v1 — restore from the Backups tab by pasting the stored content back.

Can I choose which parts to import?

Yes. The review shows every media item, term and reference location inline, plus editable title, excerpt and URL slug, a visual featured-image picker and template choices. Reset restores an edited field to its ZIP value. For each taxonomy, unchecked Clear keeps existing assignments and adds selected ZIP terms; checked Clear replaces them with selected terms, or clears everything when none are selected. All and individual term selections do not change Clear. A featured image must remain included in media. Content, blocks and supported field values always import together.

Media marked “Check this item” was detected from a number in a block setting that might be unrelated to an image. Inspect its thumbnail and reference locations before choosing. Excluded media is not imported or remapped, so its references may need repair. Thumbnails are private previews of staged files; unsupported or oversized images use a fallback. Choices apply after the ZIP has been uploaded and prepared.

What if the result is partial or the connection is lost?

A partial result identifies the saved page, incomplete items and available recovery data. If the execution response is lost, PageFerry cannot confirm whether the server saved the page: check the destination and import log before trying again. It does not automatically repeat execution or provide one-click rollback.

Where is my pre-import backup?

Tools → PageFerry Import → Backups. Each update-selected import stores the target’s prior title, content, excerpt, URL slug, terms, featured image and meta under a pf-* key before overwriting the post. Successful updates retain the last 20; partial outcomes keep recovery data. Results link to an authorized read-only snapshot when available. Restore manually in the editor; opening the snapshot makes no changes. Logs are supplementary and best effort.

The import says a file is too large. What now?

Your host caps each upload (upload_max_filesize), and PageFerry caps each media file at 256 MiB. Bundles over the host cap import file-by-file automatically — but one asset over the effective file limit cannot. Raise a smaller PHP upload limit, or reduce that asset and re-export. The error names the file. Aggregate and archive limits also apply as described above.

Does PageFerry ferry ACF data?

ACF blocks: 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 (usePostMeta, 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.

Post fields: non-block field groups located on the exported post itself (Post Type, Post, template, status or taxonomy rules) ferry the post’s own values in the bundle (acf_post_fields). On import, every name is checked against the fields the destination actually exposes for that post type (create) or the selected post (update); matching values restore through the ACF API with media-ID remap and URL rewrite, and names with no destination definition are skipped and listed in the preview and log instead of being written. Field-group definitions are not shipped — register matching field groups on production first.

Three limits apply to both: reference fields (post/relationship/taxonomy/user/page-link IDs) point at source-site content and ferry verbatim — the export warns when they hold values; nested group/repeater/flexible-content values require synchronized field definitions — incompatible child keys, rows or layouts skip the whole field before any of its values change, with notes in preview and completion; and on update-selected imports, fields unset on the source keep the target’s existing values.

Exports check saved values rather than field defaults, including nested children. Explicitly saved empty and zero values still transfer. Re-export older bundles with 1.2.2 or later to apply this distinction.

For post fields and usePostMeta block fields, PageFerry skips fields with Save Terms or bidirectional updates, including any container with such a descendant. The preview and log explain each skip; its destination values and related objects stay unchanged. Reused or unmapped media is never reparented by these ACF writes. Only attachments created by the current import can connect to its destination post.

Does PageFerry phone home or load remote code?

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 import / edit_post capabilities plus nonces.