wp-config.php template omits the standard WP-CLI placement anchor — wp config set fails on all installs
K
Kevin Nugent
The wp-config.php generated for WP Engine installs replaces the standard WordPress marker comment /
That's all, stop editing!
/ with custom wording (# That's It. pencils down). WP-CLI's wp config set matches the standard comment as a literal string for its default placement anchor, so the substitution causes the command to fail on every install with "Unable to locate placement anchor".Please restore the standard marker — or, if the custom wording is deliberate, emit it in addition to the standard comment. Either restores compatibility with wp config set and the wider tooling ecosystem built on wp-cli/wp-config-transformer, with no functional change to the file.
If amending the template isn't possible, please confirm the officially supported method for adding constants to wp-config.php at scale across an account's installs.
Austin Wendt
Hi Kevin Nugent - thank you for the feedback here. I've spoken to the team(s) internally that manage the default wp-config.php, and they're going to look into the two options you mentioned (either change it back, or emit both).
In the interim, their suggestion was using WP-CLI's
--anchor
flag - something like:wp config set MY_CUSTOM_CONSTANT 'my_value' --anchor="That's It. pencils down" --placement=before
Would this work for you in the short-term?
K
Kevin Nugent
Thanks for the update, Austin Wendt. I tried that but it doesn't work I'm afraid.
First, the anchor string in your example doesn't match what's in the file. On our installs the line is:
That's It. Pencils down
with a capital P in "Pencils". WP-CLI matches the anchor with a literal, case-sensitive str_replace, so --anchor="That's It. pencils down" fails with the same "Unable to locate placement anchor" error. Corrected for case it does work. I've confirmed the string is identical across five of our installs, so it does at least appear stable.
Second, and this is why it doesn't solve our case: the apostrophe. I was using Claude Code to set constants programmatically across roughly fifty installs over your SSH gateway, and the gateway applies an extra shell parse to the remote command, so anything quoted in argv loses a layer. An anchor containing an apostrophe and spaces doesn't survive that. It's fine typed into an interactive session, but not from a script, which is where we need it.
If your customised line didn't have the apostrophe then the --anchor arg would work. It's fine typed into an interactive session, but not from a script, which is where we need it.
Dropping the apostrophe would help, but on its own it wouldn't be enough. The same parse strips the spaces too, so any multi-word anchor arrives as separate arguments regardless. And a # comment is awkward to pass from a shell in its own right, since an unquoted # begins a comment.
Which points at a simpler fix. The only reason this is painful is that we have to pass the anchor explicitly at all. WP-CLI's built-in default never travels through argv, so none of these problems arise. If WP Engine's wp-config.php carried the standard line alongside your own, wp config set would work out of the box on every install and no --anchor would be needed:
/
That's all, stop editing! Happy publishing.
/That addition would make a standard WP-CLI command behave normally on your platform rather than failing with an error that gives no clue why.
One thing that would still be useful to know either way: is # That's It. Pencils down guaranteed to stay identical across installs and future WP or PHP versions? If it can vary, --anchor isn't something we could safely script against even interactively.