wpress import fails with "Could not execute statement: INSERT INTO `wp_wfconfig`" for sites using Wordfence

Read apps/cli/lib/import-export/import/importers/importer.ts, especially WpressImporter.prepareSqlFile() and its existing SERVMASK regex, then check apps/studio/src/constants.ts and upstream issue WordPress/sqlite-database-integration#403. Verify the chosen fix against a Wordfence .wpress backup and confirm the import completes with the post-import options and plugins restored.

Quick summary

Importing an .wpress (All-in-One WP Migration) backup from any site that has Wordfence installed fails partway through. The bundled sqlite-database-integration AST translator does not recognize MariaDB's bare 0x empty-BLOB literal, which Wordfence's wp_wfconfig table emits for empty config values. The import aborts on the first one and leaves the SQLite DB partially populated.

Filed upstream with reproducer: WordPress/sqlite-database-integration#403.

Steps to reproduce

1. On a source WordPress site that uses Wordfence, generate an All-in-One WP Migration export (.wpress).
2. In Studio, create a new site (or use an existing one).
3. Run studio site import path/to/your-backup.wpress (or use the GUI's Import option).

What you expected to happen

The wpress is restored end-to-end: every table imported, theme/stylesheet set, plugins activated, site loads correctly at the local URL.

What actually happened

The CLI errors out partway through:

Database import failed: Error: Could not execute statement:
INSERT INTO `wp_wfconfig` VALUES ('bannedURLs', 0x, 'yes')

Inspecting the SQLite DB after the abort:

• Schema is fully created.
• Tables alphabetically up to and including wp_wfconfig got partial data (wp_posts, wp_postmeta, wp_options, wp_users are populated).
• Tables alphabetically after wp_wfconfig (Wordfence diagnostic tables, WooCommerce, WP Rocket, WP Mail SMTP) have no rows.
• ai1wm's post-import option pass never ran, so wp_options.template, stylesheet, and active_plugins are empty - the front-end loads with the default theme and zero plugins active.

Impact

Some (< 50%)

(Affects every user attempting .wpress import from a site with Wordfence installed - Wordfence is widely used, but only .wpress users hit this code path.)

Available workarounds?

Yes, difficult to implement

.wpress is uncompressed, so database.sql lives in plain bytes inside the archive. A same-byte-count binary patch fixes it without re-packing:

path = "/path/to/your-backup.wpress"
data = open(path, "rb").read().replace(b",0x,", b",'',")
open(path, "wb").write(data)

After patching, studio site import runs to completion. Requires Python and shell access; not something a typical Studio user would do unaided.

Platform

Mac Silicon

Logs or notes

Cause

The AST translator (wp sqlite import --enable-ast-driver, in the bundled sqlite-database-integration plugin pinned at v3.0.0-rc.3) doesn't model MariaDB's bare 0x token (a hex literal with zero hex digits, valid in MariaDB/MySQL as an empty binary string). Hex literals with content (e.g. 0xDEADBEEF) translate fine; only the empty form errors.

Suggested fix in Studio

Once WordPress/sqlite-database-integration#403 is resolved, bump SQLITE_DATABASE_INTEGRATION_VERSION in apps/studio/src/constants.ts. Same path that was used for Automattic/studio#2302 → v2.2.17 → #2512.

If a faster interim fix is wanted, WpressImporter.prepareSqlFile() already does one regex pass for the SERVMASK prefix (line 436). A second same-byte regex (/(?<=[,(])\s*0x\s*(?=[,)])/g → "''") added inside the same rl.on('line', ...) handler would unblock wpress imports for the affected user population without waiting on the upstream release.

Environment

• Studio 1.8.0
• sqlite-database-integration v3.0.0-rc.3 (current pin)
• Source DB: MariaDB 11.4.7
• All-in-One WP Migration 7.105