Giters

wp-cli / wp-config-transformer

Programmatically edit a wp-config.php file

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

'shuffle-salts' corrupts wp-config.php if semi-colon in original salt

cldevs opened this issue · comments

commented

Summary:
"wp config shuffle-salts" creates a malformed wp-config.php file if a semi-colon is contained in the original salt

Steps to reproduce:
Place a semi-colon in one of the salts in wp-config.php and run "wp config shuffle-salts"

Severity - High (Breaks site as it is unable to load wp-config.php)

commented

@cldevs What version of WP-CLI are you running? We fixed a similar issue in the transformer prior to 2.1.0: #9

commented

Sorry I missed that. It's v2.1.0

commented

@fjarrett Were you able to reproduce this issue?

commented

I’m able to reproduce what seems to be the same issue with wp cli 2.1.0.

My steps to reproduce:

# Prepare the environment
mkdir /tmp/wp
cd /tmp/wp
wp core download
wp config create --dbname=testing --dbuser=wp --skip-check

# Reproduce the bug
wp config set CSS_RULE '@import url("some-file.css");'
wp config set CSS_RULE '@import url("some-file.css");'

Expected result: the wp-config.php file should include the following:

define( 'CSS_RULE', '@import url("some-file.css");' );

Actual result: the wp-config.php file includes the following:

define( 'CSS_RULE', '@import url("some-file.css");');' );
commented

Thanks, @iamakulov, I can reproduce with the steps you've described as well.

commented

Additional comment from @cldevs from #15:

Again, the issue is that a semi-colon somewhere in the string of a value fools the transformer into thinking that's the end of the key-value declaration which results in a corrupt wp-config.php file and winds up taking down a Wordpress site.

WPConfigTransformer.php - Line 199-203

$contents = preg_replace(
   sprintf( '/(?<=^|;|<?php\s|<?\s)(\s*?)%s/m', preg_quote( trim( $old_src ), '/' ) ),
   '$1' . str_replace( '$', '$', trim( $new_src ) ),
   $this->wp_config_src
);

Is this just a matter of including the ending newline character at the end of each search string (e.g. after the semi-colon) so it matches right to the end of the line instead of stopping part-way? Then including a newline character at the end of the replace? Any other implications here?

commented

@fjarrett Any specific thoughts on what the best approach is here? As we already had a similar fix, there's the chance we're circling around...

commented

@schlessera I followed the steps above and I cannot reproduce this issue.

commented

@fjarrett I cannot replicate either with the latest release (v2.2.0).

@cldevs Is this still an issue for you? I think it might have been fixed in the mean time but the fix was only included with the latest release.

commented

Confirmed this is now fixed in v2.2.0! Thanks!