this should only happend when installing, so unsure if its config_protecting that is not working in webapp here even before i did etc-update was overwrited :( Reproducible: Always Expected Results: it should be config_protect config.php waiting for update with etc-update
Did you follow the instructions at the end of the emerge: * One or more files have been config protected * To complete your install, you need to run the following command(s): * * CONFIG_PROTECT="/var/www/localhost/htdocs/wordpress//" etc-update *
Hmm, I see this happen with portage-2.1.8.3 but not portage-2.2_rc67. I've no idea why.
That was on the 2.9.2-r1 -> 3.0.1 update, btw.
(In reply to comment #0) > this should only happend when installing, so unsure if its config_protecting > that is not working in webapp here > > even before i did etc-update was overwrited :( Same here. > Expected Results: > it should be config_protect config.php waiting for update with etc-update Agreed. (In reply to comment #3) > That was on the 2.9.2-r1 -> 3.0.1 update, btw. For me: 2.8.4 -> 3.3.1 - Raising importance to high/major. - Adding planet@g.o. to CC due to entry in metadata.xml
same issue in version 3.4. After looking into the ebuild and the tar I think it should be enough to remove the line [ -f wp-config.php ] || cp wp-config-sample.php wp-config.php in src_install() I don't see the point of this line anyway. It is a default config and wordpress doesn't work with this config so there's no reason to install it as default config. This doesn't explain why webapp_configfile doesn't respect config-protect, but it would be a workaround for this (annoying) problem.
Still happens on upgrade to 3.4.1. Raising importance, this bug sucks big time.
I have three vhosts-based wordpress sites on one server. The config_protect works only on the latest/newest wordpress installation, on the others the upgrade process happily overwrites the wp-config.php file (fortunately I have both on-and-offsite backups). Last happened today while upgrading from wordpress-3.5.1 to 3.5.2 via webapp-config.
I have many vhosts-based wordpress installs, some got their wp-config.php overwritten during the upgrade, some did not. I could find no pattern in that behaviour. Quite annoying indeed.
The bug is (obviously) still present in 3.6 The line mentioned in comment #5 is meant to create a standard config file, based on the sample, in the temporary work directory. My undestanding of the webapp.eclass is not deep enough, but removing that line altogether causes the ebuild installation to fail.
I have finally managed to reproduce the bug consistently. Scenario A) Wordpress 3.4.2 is installed. Config file is edited after installation. When upgrading to 3.5.2, config file is UNTOUCHED. When upgrading to 3.6, config file is OVERWRITTEN. :-( Scenario B) Wordpress 3.4.2 is installed. Config file is edited after installation. When upgrading to 3.5.2, config file is UNTOUCHED. Config file is modified again after upgrade. When upgrading to 3.6, config file is UNTOUCHED. Hooray! When using --debug, I can see that if the config file was modified between installed, webapp-config will output "!time wp-config.php" (content.py, lines 638-640). It looks like webapp-config operates under the assumption that a config file that hasn't been touched since the preivous install can be safely overwritten. This assumption is incorrect.
(In reply to Romain Riviere from comment #10) > I have finally managed to reproduce the bug consistently. > > Scenario A) > Wordpress 3.4.2 is installed. Config file is edited after installation. > When upgrading to 3.5.2, config file is UNTOUCHED. > When upgrading to 3.6, config file is OVERWRITTEN. :-( > > Scenario B) > Wordpress 3.4.2 is installed. Config file is edited after installation. > When upgrading to 3.5.2, config file is UNTOUCHED. > Config file is modified again after upgrade. > When upgrading to 3.6, config file is UNTOUCHED. Hooray! > > When using --debug, I can see that if the config file was modified between > installed, webapp-config will output "!time wp-config.php" (content.py, > lines 638-640). > > It looks like webapp-config operates under the assumption that a config file > that hasn't been touched since the preivous install can be safely > overwritten. This assumption is incorrect. Did you try webapp-config-1.51-r1 because there was a commit to fix config file overwriting using md5 as the guide.
(In reply to Anthony Basile from comment #11) > Did you try webapp-config-1.51-r1 because there was a commit to fix config > file overwriting using md5 as the guide. Excellent! webapp-config --debug reports !sum wp-config.php and leaves it well alone. Thanks :)
(In reply to Romain Riviere from comment #12) > (In reply to Anthony Basile from comment #11) > > Did you try webapp-config-1.51-r1 because there was a commit to fix config > > file overwriting using md5 as the guide. > > Excellent! webapp-config --debug reports !sum wp-config.php and leaves it > well alone. Thanks :) I'm pretty sure this is the same issue as bug #243260, which is resolved fixed. If someone doesn't think so, then please reopen with an explanation why they are different. *** This bug has been marked as a duplicate of bug 243260 ***
