Conversation
Instead of modifying wp-config.php to insert a define() call for DB_NAME, use static token-based parsing to check whether the constant is already defined, and if not, define it via the PHP auto-prepend script. This ensures the user's wp-config.php value always takes priority and the file is never modified for this purpose. Extracts the logic into a reusable defineWpConfigConstantFallbacks() function that can handle any number of constants.
There was a problem hiding this comment.
Pull request overview
This PR changes how Playground ensures required WordPress constants (notably DB_NAME) are available by avoiding direct rewrites to wp-config.php and instead defining missing constants via PHP auto-prepend.
Changes:
- Stop rewriting
wp-config.phpto injectDB_NAME; detect missing constants usingWP_Config_Transformerand define fallbacks viaphp.defineConstant. - Add
defineWpConfigConstantFallbacks()to encapsulate the “check + define via auto-prepend” flow. - Update tests to assert auto-prepend constants behavior rather than asserting rewritten
wp-config.phpcontent.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| packages/playground/wordpress/src/wp-config.ts | Switches from rewriting wp-config.php to defining missing constants via auto-prepend after token-based detection. |
| packages/playground/wordpress/src/test/wp-config.spec.ts | Updates tests to validate DB_NAME fallback behavior without relying on rewritten config output. |
| packages/playground/wordpress/src/boot.ts | Adjusts comment to reflect the new behavior (no wp-config.php rewrite). |
| packages/playground/blueprints/src/lib/steps/import-wordpress-files.ts | Adjusts comment to reflect the new behavior (no wp-config.php rewrite). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| it('should define DB_NAME via defineConstant when wp-config.php does not define it', async () => { | ||
| php.writeFile(wpConfigPath, `<?php`); | ||
| await ensureWpConfig(php, documentRoot); | ||
|
|
||
| // wp-config.php should not be modified. | ||
| expect(php.readFileAsText(wpConfigPath)).toBe(`<?php`); | ||
|
|
||
| // DB_NAME should be defined via the auto-prepend mechanism. | ||
| expect(getDefinedConstants(php)).toHaveProperty('DB_NAME', 'wordpress'); | ||
| }); |
There was a problem hiding this comment.
This assertion verifies that defineConstant was invoked (via consts.json), but it doesn’t prove DB_NAME is actually available to WordPress execution (i.e., visible at runtime when WordPress loads). Add an assertion that runs PHP (via php.run) after ensureWpConfig and checks defined('DB_NAME') and DB_NAME value, to cover the end-to-end behavior this PR relies on.
adamziel
added
[Type] Enhancement
adamziel
left a comment
adamziel
left a comment
There was a problem hiding this comment.
LGTM! I'd just address the last unresolved node from copilot
Verify that DB_NAME is not only written to consts.json but is actually available at PHP runtime via the auto-prepend script.
Summary
wp-config.phpto insertdefine('DB_NAME', 'wordpress'). Instead, use static token-based parsing to check if the constant is already defined, and define it via the PHP auto-prepend script if missing.wp-config.phpvalue always takes priority — if they defineDB_NAME, Playground respects it.defineWpConfigConstantFallbacks()function.Test plan
wp-config.spec.ts)DB_NAMEdefaults todatabase-name-herefromwp-config-sample.php)DB_NAMEinwp-config.phpuses the custom valueDB_NAMEinwp-config.phpstill works (DB_NAMEiswordpress)Closes #2530.
🤖 Generated with Claude Code