Magento db connection parameters won't change,

问题:

I have copied our entire www directory from our web server to my local workstation. I am trying to get Magento to connect to a local database. Yes, I changed the connection string values in the 'magento/app/etc/local.xml' file. I have verified about a hundred times that it has been changed. And before you tell me that it is cached, I have deleted the entire 'magento/var/cache' directory, just to be safe, and grepped all files in the www directory for our 'secret_password'. Below is an excerpt from my local.xml file.

<host><![CDATA[localhost]]></host>
<username><![CDATA[root]]></username>
<password><![CDATA[root]]></password>
<dbname><![CDATA[dev_xarisma]]></dbname>

I tried this on my laptop, and did find that caching was the issue. It took me hours to figure it out. But I finally ended up dumping the 'Varien_Db_Adapter_Pdo_Mysql' object, and that is when I saw that the values it was getting were not the values I had set in the 'local.xml' file; see partial dump below.

    [_config:protected] => Array
    (
        [host] => localhost
        [username] => root
        [password] => (*secret_pass_you_cant_see*)
        [dbname] => production_xarisma

I finally figured out that the older login credentials were cached by grepping the WWW directory for our strong password. I was surprised to find in in a bunch of files in the magento/var/cache file. I removed the offending files, and that solved the problem on my laptop. However, it's not working on the workstation. I have deleted the entire var directory, and the behavior continues. I have even rebooted my workstation several times in case it was something being cached by Apache, but no luck.

Both the laptop and the workstation are running Ubuntu 31.10, with Apache2, current mySql, and nothing freaky on either. And just in case you want to know why I would be doing this crazy "cloning the production server to my workstation" procedure, it because we are trying to chace down a problem that is only in Production. Yes, I checked all of the articles that even seemed to be related. Thank you in advance.

回答1:

OK, this took me two days to track down. But what I found is either a bug, or a feature, I don't know.

The problem was that there was ANOTHER file in the 'magento/app/etc' directory, that was OVERRIDING the correct database connection parameters in the 'local.xml' file. This file was called 'localOLD.xml'. Obviously, someone wanted to backup our database settings for safety; a good idea. But apparently, Magento was reading THAT file instead of 'local.xml'.

I was really surprised that it started working as soon as I deleted that file. In fact, I did not believe it. So I made a copy of 'local.xml', called it 'localOLD.xml', entered some test values for the connection parameters, and Magento tried to use them.

Is this a bug or a feature? Anyone?

回答2:

It's always a pain in the behind when this happens.

First — are you sure the production server is using the file system for its cache? Many production systems are setup to cache to something else like redis, memcache, etc. Clearing the cache through the admin UI or a tool like n98-magerun (if possible) is always a good idea.

Second — are you sure you're removing the correct cache folder? If Magento can't write to the var folder due to PHP permissions, it will store its cache files in the system temp folder.

Some debugging code in this method

#File: app/code/core/Mage/Core/Model/Config/Options.php
public function getVarDir()
{
    //$dir = $this->getDataSetDefault('var_dir', $this->getBaseDir().DS.'var');
    $dir = isset($this->_data['var_dir']) ? $this->_data['var_dir']
        : $this->_data['base_dir'] . DS . self::VAR_DIRECTORY;
    if (!$this->createDirIfNotExists($dir)) {
        $dir = $this->getSysTmpDir().DS.'magento'.DS.'var';
        if (!$this->createDirIfNotExists($dir)) {
            throw new Mage_Core_Exception('Unable to find writable var_dir');
        }
    }
    return $dir;
}

Should reveal where Magento is loading it's file cache data from.

var_dump($dir);
return $dir;

回答3:

I was fighting with this for a while as well. I ended up moving all of my backed up local.xml files to another directory and that fixed it. Thanks

回答4:

The way Magento works is that it reads all files in that directory, in alphabetical order. So backing up is OK, as long as you make sure the back up file is read before the real file.