Handling different database dump URLs in WordPress testing.
I’ve had back and forth feelings about the use of database dumps as starting points in WordPress acceptance tests. The main issue with them being WordPress hardcoding the site URL address in the options table.
The values stored in the
siteurl options will be looked up by WordPress any time it needs to generate a permalink and the
posts table will contain absolute URLs in the
That’s not the whole picture but one that gives a good idea about the complications involved in sharing a WordPress database dump as test fixtures.
A tool like the WP-CLI
search-replace command solves exactly that problem but that relies on a live database using a live WordPress installation.
To tackle this issue and others of a more complex nature I’ve developed the codeception-setup-local package but that might be an overkill to handle this glorified string replacement issue.
Latest version of WP Browser features an update to the
WPDb module that, when instructed to populate the test database from a dump file setting the
populate parameter to
true, will try to read the WordPress URL hardcoded in the dump file and replace it with the one specified in the
urlparameter of the
To make an example if the developer that set up the starting database dump had WordPress served on
http://localhost:8080when she exported the database dump and my WordPress local installation is served instead at
'http://wp.local then any recurrence of the former hardcoded URL will be replaced with the the latter without modifying the original dump file.
To prevent the module from attempting the replacement the
urlReplacement parameter must be explicitly set to