Build/Test Tools: Add types for all dynamic constants in PHPStan. - #14034

Every entry in dynamicConstantNames now declares its type, so the list uses one style. WP_DEBUG_LOG is narrowed to bool|non-falsy-string.

See #65817.

`preg_replace()` is typed as returning `string|null`, which the `'string'`
type now configured for these dynamic constants does not accept. The
`null` return only happens on a regex error, which cannot occur for this
fixed pattern, and since `[^/]+` stops at the first slash the appended
trailing `/` always survives. The cast reflects that without widening the
constants' type.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Core defines `UPLOADBLOGSDIR`, `WP_LANG_DIR`, and `WPMU_PLUGIN_DIR` as
non-empty paths and concatenates them into other paths, and documents
`NOBLOGREDIRECT` as a redirect URL (or the `%siteurl%` sentinel), so these
become `non-empty-string`. None of them is guarded against an empty value,
so the narrower type makes no existing check look redundant.

`WP_DEVELOPMENT_MODE` becomes the union of the values core documents, the
ones `wp_get_development_mode()` accepts: `'core'`, `'plugin'`, `'theme'`,
`'all'`, and `''`.

`WPLANG` and `WP_SITEURL` stay `string`, since core explicitly checks them
against `''`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Each type in `dynamicConstantNames` reflects what core expects. Survey
real wp-config.php files, hosting and Docker templates, and WordPress.org
plugins and themes, and note where they are known to define wider values,
along with how core handles them.

The most common source is a config that passes `getenv()` through without
converting it, which yields `false` when the variable is unset and
otherwise a string, where `'false'` is truthy. Other examples are `1` for
the request-context flags, numeric strings for the legacy header image
sizes and `WP_POST_REVISIONS`, and `''` or `'0'` for `WP_DEBUG_LOG`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The note on the salt and key constants is about configs that read
environment variables in general, so describe it that way.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Core defines it as `30` and treats `0` as disabling the trash. A negative
number of days is meaningless: the REST API reports items as not
trashable, while `wp_scheduled_delete()` computes a cutoff in the future
and purges all trash.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Core only ever writes non-empty values for these: setup and the network
setup screen generate 64-character values, and the sample config uses a
placeholder phrase. An empty salt is tolerated rather than expected, since
`wp_salt()` and `wpdb::placeholder_escape()` treat a falsy value as
missing. Note that some configs nonetheless define `''`.

`non-falsy-string` would go too far, as it would make those truthiness
checks look redundant.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`true` or `-1` keeps every revision, `false` or `0` keeps none, and a
positive integer keeps that many. Core converts `true` to `-1` in
`wp_revisions_to_keep()`, and `wp_save_post_revision()` treats any
negative count as unlimited, but `-1` is the documented value.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This reverts commit 4f64676.

Core never checks for `-1` specifically: `wp_save_post_revision()` treats
any negative count as unlimited, and `wp_revisions_enabled()` only checks
against `0`. A lower bound of `-1` encodes a documentation convention that
no read depends on, so keep `bool|int`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Both types were narrowed without a comment, though real configs define
values outside them. The WordPress MU sample config defined
`NOBLOGREDIRECT` as `''`, which `maybe_redirect_404()` treats as no
redirect but `ms_load_current_site_and_network()` passes through as an
empty `Location` header. Some sites define `WP_DEVELOPMENT_MODE` as `true`,
which `wp_get_development_mode()` treats as `''` while Site Health shows the
raw value.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Not every typed dynamic constant needs one: PHPStan discovers constants
that core defines at the top level of a file, such as `MULTISITE`, and a
read inside a defined() check is never reported as not found. Explain that
the defines are for constants core only defines inside a function.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Both vary by install, but PHPStan took their values from the bootstrap,
treating `FORCE_SSL_ADMIN` as always `false` and `COOKIE_DOMAIN` as always
`''`. Core defines `FORCE_SSL_ADMIN` from the scheme of the `siteurl`
option, and `COOKIE_DOMAIN` as `''`, or as the network's cookie domain on a
subdomain multisite network.

Configs still commonly define `COOKIE_DOMAIN` as `false`, which was core's
own default until r58011, and pass `FORCE_SSL_ADMIN` through from
`getenv()`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`wp_scheduled_delete()` is not the only place an empty
`EMPTY_TRASH_DAYS` fatals: `_wp_delete_orphaned_draft_menu_items()`
multiplies it by `DAY_IN_SECONDS` too. And the `WP_USE_THEMES` comment
read as if core treated `0` as true, when only the string `'false'` is.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Multiplying an int by an empty string throws a TypeError on PHP 8, but on
PHP 7.4 it only warns about a non-numeric value and evaluates to 0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The types describe what core expects, so a guard against a value outside
one is reported as impossible. Note that such a guard should widen the
type in the same change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The PHPStan bootstrap pinned every cookie name and path to `''`, though
each is derived per install by `wp_cookie_constants()` or
`ms_cookie_constants()`, and may be defined earlier by `wp-config.php`,
`sunrise.php`, or a must-use plugin.

The cookie names become `non-empty-string`: core builds each one as a
prefix plus `COOKIEHASH`, and `setcookie()` throws on an empty name.
`COOKIEHASH` stays `string`, since core defines it as `''` when there is
no `siteurl`. `ADMIN_COOKIE_PATH` and `PLUGINS_COOKIE_PATH` are `string`,
like `SITECOOKIEPATH`, from which multisite derives the former.

`PLUGINS_COOKIE_PATH` gets the same `(string)` cast on `preg_replace()`
as `COOKIEPATH`, which cannot fail for this fixed pattern, and the
bootstrap placeholders for the cookie names become core's own prefixes,
so they no longer contradict their types.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The PHPStan bootstrap pinned `ABSPATH`, the content, plugin, and
must-use plugin directories and URLs, and the theme paths to fictional
literals, though each depends on the install. Core always defines them
non-empty: the entry points define `ABSPATH` from `__DIR__`, and the
others are concatenations onto it or onto the `siteurl` option.

`TEMPLATEPATH` and `STYLESHEETPATH` stay `string`, as core defines them
from `get_template_directory()` and `get_stylesheet_directory()`, which
return a plain `string`.

With `WP_PLUGIN_DIR` no longer a literal, PHPStan cannot resolve the
Press This include to a missing file, so its `include.fileNotFound` ignore
no longer matches and is removed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The PHPStan bootstrap pinned these to core's defaults, though sites
routinely override them, and `WP_START_TIMESTAMP` and the memory limits
are computed at runtime.

The memory limits are `string`, as core defines them from `ini_get()` or
shorthand notation like `'64M'` and passes them to
`wp_convert_hr_to_bytes()` and `ini_set()`. The autosave interval, cron
lock timeout, and filesystem timeouts are `positive-int`, since a value
below 1 changes behavior: autosaves fire on every change or stop, cron
runs overlap, and on PHP 8 `ftp_connect()` and `ftp_set_option()` throw.
The filesystem modes are plain `int`, as core computes them with
`fileperms()`, and setgid modes exceed `0777`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The comments on `ABSPATH` and `WP_START_TIMESTAMP` explained why their
values were fixed rather than derived at runtime: so error messages, which
quoted the values, stayed the same across machines and runs. Both are now
typed dynamic constants, so PHPStan ignores the values and messages quote
the configured types instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The PHPUnit bootstrap defined `WP_MEMORY_LIMIT` and `WP_MAX_MEMORY_LIMIT`
as the int `-1`, outside their `string` type. Core reads both through
`wp_convert_hr_to_bytes()`, which trims its input to a string anyway, and
`ini_set()`, so `'-1'` behaves identically. With core's own code no longer
contradicting the type, the comments documenting the mismatch go away.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Core treats all eight salts and keys alike: `wp_salt()` reads each of them,
setup and the network setup screen generate them together, and the repair
screen checks them together. Only three were typed, though, so the
recovery mode cookie service compared `AUTH_KEY` as untyped right beside
a typed `AUTH_SALT`. Give `AUTH_KEY`, `SECURE_AUTH_KEY`,
`SECURE_AUTH_SALT`, `NONCE_KEY`, and `NONCE_SALT` the same type and note.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>