I’m working on deploying my WordPress site to a live server using Phing for automation. I want to store my database configuration settings directly in my Phing build script instead of hardcoding them in wp-config.php.
What I need is a way to create a Phing task that will read these property values and automatically update my wp-config.php file with the correct database settings during deployment.
Can anyone show me the best approach to accomplish this? I’m looking for a clean solution that will make my deployment process more flexible.
i’ve been using the reflexive task for this and it works great. just set up your wp-config with placeholders like ${live.database_name} and phing replaces them automatically during build. way simpler than filterchains. make sure you backup your original config though - learned that one the hard way lol
The filterchain approach with ReplaceTokens works great for this. Set up placeholders in your wp-config.php file and use Phing’s copy task to replace them during deployment. Create a wp-config template with tokens like @DATABASE_NAME@, @DATABASE_USER@, etc. Then use a copy task with filterchain to swap these tokens with your build properties. I’ve used this on several WordPress projects - it’s pretty reliable. Watch out for token delimiters conflicting with existing WordPress syntax. I use @@ delimiters to avoid issues with PHP variables. Also consider using a separate config template directory so your original wp-config.php stays intact during development. The big advantage? You can have different property files for staging and production, making deployment way more manageable across multiple server setups.
Another solid option is the replaceregexp task - gives you way more control. You can target specific lines in wp-config.php with regex instead of relying on placeholders. For example, match the existing define('DB_NAME', 'database_name_here'); line and swap just the value with your build property. This way you’re working with a standard wp-config.php file without touching the template. I’ve found this super useful with existing WordPress installs where you can’t mess with the config structure. Regex also handles edge cases better - like when devs have weird formatting or comments around the database constants. Just test your regex patterns thoroughly since bad patterns will break your config during deployment.