Magento db connection parameters won't change, crazy caching?

Question

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.

Solution 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?

Solution 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;

Comments

[Don Briggs]

I am not sure if the production server is "suing" the file system for it's cache. I know that they have not been getting along well, and the production server does have a very extravagant lifestyle. But suing the the file system does seem rather extreme. But seriously, thank you very much. I can't wait to get to work and try this. I did not think of searching outside the www directory for that password. By the way, you are "Alan Storm" I am reading all of your stuff to learn Magento development. So this is kind of like asking a question, and having it answered by Yoda.

[Alan Storm]

My small claw like hands lead to lots of typos.

[Don Briggs]

OK, apparently, this IS a feature. I did find our password in a backup file: 'configOLD.xml', but figured that it would not matter. Apparently Magento reads and merged ALL XML file. Important safety tip, when you wish to backup a file, make sure that your do NOT name your backup as an XML file. I won't fall for that one again.

[adprocas]

I have been searching for the answer to this problem for 45 minutes! Frig, shame on us for trying to make sure we're backing stuff up. Mine was local_OLD.xml and it was obviously reading from this file. SOOOOO frustrating....

[Don Briggs]

Important safety tip, guys. Always change the FILE EXTENSION of any file you wish to back up. Magento will read all files that end with .xml, wether you want it to or not.

[Don Briggs]

I remember reading somewhere, I think on the very first day that I started working with Magento, that it merges together ALL of the files with a .xml extension, but it is way to easy to forget... Until this happens to you once.

[Don Briggs]

You can keep your backup files in the same directory. You just have to change the file extension, as Magento will read ANY file in that directory that has a .xml extension, and merge it into your global config.

[Karl]

Thanks for this answer! For some reason the files were being cached in /tmp/magento/var. So my database details wouldn't change.

[Alan Storm]

@Karl If Magento can't write to ./var, it defaults to creating a var folder in /tmp/magento

[Karl]

Ahh that explains a lot! Thanks @AlanStorm

[Emizen Tech]

its because magento reads all the xml in app/etc folder if you want to have backup file for safety you can rename it to local.xml.backup, as Magento only reads *.xml files in app/etc

[Don Briggs]

@Emizen Tech: You have just re-stated what we have already said. Magento reads all files with a .xml extension.

[Don Briggs]

No, you are completely wrong. As stated, Magento reads ALL .xml files in the directory. It has nothing to do with alphabetical order.