Fixing WP‑CLI “eval()’d code” Parse Errors on PHP 8.4 During “wp db import”

If you’ve ever SSH’d into a server, confirmed WordPress is alive, and then hit this brick wall:

…you’re not alone.

This error is frustrating because it doesn’t point at your project files, and it looks like WP‑CLI itself is broken. In practice, it’s almost always WP‑CLI choking while it tries to bootstrap WordPress and read your configuration, usually wp-config.php.

Here’s how to diagnose it quickly and get your import working again.

Why this happens

Some WP‑CLI commands (including wp db import) must load WordPress configuration to find database credentials. During its bootstrap, WP‑CLI may extract/interpret config values and, in some cases, evaluate derived code.

That means:

• wp core version can work even if your config has issues.
• wp db import can fail if wp-config.php has a syntax/encoding problem, or contains constructs WP‑CLI doesn’t handle well.

The most common causes are:

1. A real syntax error in wp-config.php (often a missing ) before a semicolon).
2. A UTF‑8 BOM (byte order mark) or hidden characters at the top of wp-config.php.
3. Older WP‑CLI versions running on newer PHP (like PHP 8.4) exposing edge cases.

Step 1: Check your WP‑CLI version and update it

Start by checking what you’re running:

If you’re on an older release and you’ve upgraded to PHP 8.4, update WP‑CLI first:

If you still hit the same parse error, try the nightly build (useful when PHP releases outpace tooling):

Then retry:

Step 2: Lint wp-config.php with PHP

This is the fastest “is it actually broken?” test.

From your WordPress root (often httpdocs/):

If linting fails, you’ll get a real line number in wp-config.php. Fix that first.

What the syntax error typically looks like

The specific error pattern:

unexpected token “;”, expecting “)”

…often means a missing closing parenthesis before a semicolon. For example:

Step 3: Check for a UTF‑8 BOM at the start of wp-config.php

A UTF‑8 BOM is invisible in most editors, but it can break parsers in surprising places.

Check the first three bytes:

If you see:

…you’ve got a BOM.

Remove it safely

Make a backup, then strip the BOM:

Retry the import:

Step 4: Run the import with debug enabled

If the issue isn’t obvious, turn on WP‑CLI debugging:

This can reveal exactly how far WP‑CLI gets during bootstrap and which config values it’s tripping over.

Step 5: If lint passes but WP‑CLI still errors, simplify the config

Sometimes wp-config.php is valid PHP, but it contains patterns that don’t play well with WP‑CLI’s bootstrap.

Common culprits:

• heavy conditional logic around database settings
• dynamic construction of constants
• environment parsing with unexpected side effects
• complex includes that run early

The quick fix

Temporarily ensure your DB constants are plain and near the top:

Then move custom logic below those basics (or into a file that’s included later).

Retry:

A tight troubleshooting checklist

If you just want the “do this in order” version:

1. wp --version
2. wp cli update (and --nightly if needed)
3. php -l wp-config.php
4. head -c 3 wp-config.php | xxd (strip BOM if present)
5. wp --debug db import ../db.sql

Wrap‑up

When wp db import fails with an eval()’d code parse error, it’s rarely your SQL file. Most of the time it’s:

• a syntax issue in wp-config.php,
• a hidden BOM, or
• a WP‑CLI/PHP version mismatch.

With the steps above you can usually go from “mysterious eval error” to a clean import in a few minutes.