Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

A WordPress Database Import Fails Because the File Is Too Large

phpMyAdmin and browser upload limits are presentation constraints, not necessarily MySQL limits. Raising every timeout may still fail through a proxy or leave an unknown partial import. Large databases are safer through hosting restore tools or the MySQL client with logs and explicit checkpoints.

Preserve the source dump and checksum before transforming it.

Validate the source

Record filename, byte size, compression, checksum, export command/tool, database version, charset and creation time.

Check before import:
dump decompresses fully
SQL header/server version
CREATE/USE statements
table prefix
charset/collation
source row/table counts

Do not upload a dump containing secrets to a public file URL.

Back up the destination

Export or snapshot the current destination even if it appears empty. Confirm the target database and WordPress configuration.

Use a separate staging database for rehearsal. Never import over the only current production copy without rollback.

Check free disk: compressed input, uncompressed SQL, MySQL data and temporary files may coexist.

Understand browser limits

PHP upload_max_filesize, post_max_size, memory, execution time and web proxy timeouts can each stop phpMyAdmin. Increasing them affects the hosting attack/resource surface.

Use cPanel/Plesk’s backup/restore importer if it supports large files and reports progress. Do not expose phpMyAdmin with unusually high limits indefinitely.

A browser timeout does not prove the server import stopped.

Prefer command-line import

On authorised hosting, stream the dump to the MySQL client without placing the password in command history:

mysql --user=DB_USER --password --host=DB_HOST DB_NAME < backup.sql

Run in a protected terminal as the correct user. Capture stderr and exit code, and keep the SQL file outside the public web root.

For compressed dumps, use the host’s supported streaming/decompression method and verify pipeline failures are detected.

Handle partial imports

If an attempt failed, list imported tables and compare counts before retrying. Re-running a dump with plain INSERT statements can create duplicates or primary-key errors.

The safest recovery is often to recreate a dedicated empty destination and import from the beginning. Confirm no new production writes occurred there.

Do not drop the wrong database; resolve exact names and backups first.

Split only on SQL boundaries

When CLI is unavailable, use a trusted importer that parses SQL and resumes between statements. Do not split by raw byte/line count inside a multi-row INSERT, quoted string or procedure.

Track chunk order, checksum and completion. Disable public access to the importer immediately afterward.

Avoid third-party online “SQL splitting” services for private WordPress data.

Address version and collation errors

MySQL/MariaDB versions may reject collations or SQL modes from another server. Capture the exact error and choose a compatible target collation based on language/data needs.

Do not replace charset declarations blindly; emoji and multilingual content can be corrupted silently.

Test representative accented and supplementary characters after import.

Check application-level integrity

An import can exit successfully while containing an old or mismatched WordPress state. Compare administrator users, active theme/plugins, latest post dates and critical options against the source.

Inspect auto-increment values and orphaned metadata using application-aware tools. Do not fix gaps in IDs; gaps are normal. Confirm scheduled events and plugin migrations do not immediately rewrite imported tables when WordPress first loads. Keep outgoing email and external integrations disabled during this controlled validation.

Verify the restored WordPress site

Compare table and row counts, then update WordPress URLs using serialisation-aware tools where required. Test login, editor saves, media metadata, cron and search.

Keep source/destination dumps encrypted with retention. Recurring care should document an import route for the real database size and test it; a backup is not operationally useful if the only restore interface cannot accept it.