3

I have just installed a live site onto a development domain. I changed the web/unsecure/base_url and web/secure/base_url fields in core_config_data but I accidentally misspelled the new domain. I then loaded the site and noticed my mistake. I've since corrected the spelling but it seems to have cached the wrong domain. I've tried re-importing the database and changing the urls, I've deleted everything in the cache directory but still the js and css files are using the wrong domain in every link in the admin back-end. And the admin back-end is pointing to the wrong domain too.

Any suggestions? It's an old Magento 1.3 install.

mrk
  • 4,999
  • 3
  • 27
  • 42
iamjonesy
  • 24,732
  • 40
  • 139
  • 206

5 Answers5

13

If you don't have proper permissions on the var/ folders, Magento can write its cache information to the system /tmp folder.

This can lead to a situation where you've changed the base URLs in the Magento database, cleared cache (manual deletion of all mage-?? folders in var/cache), (cleared APC cache if you're running the op-code cache), (manually disabled the compiler (1.4.x.x and later)) and the system still looks for the original site.

Most people who own their own server discover that the site magically starts working after fixing, clearing and resetting permissions and then rebooting the server. The server reboot clears /tmp of the Magento cache files and Magento finally starts looking at its own configuration to find where it's located.

Screen shots of this in action...

The Magento directory found in /tmp...

The Magento directory found in /tmp

And the Cache living in that directory. Note the path -> /tmp/magento/var/cache

Magento Cache subdirectories...

For finding that misplaced cache directory, if you can install n98-magerun, use the command n98-magerun.phar sys:info to get a basic system info listing with one item being Cache Directory location.

Fiasco Labs
  • 6,457
  • 3
  • 32
  • 43
  • 1
    I assume `rm -rf /tmp/magento/*` OR `rm -rf /var/tmp/magento/*` is the suggested fix then (based on your OS) – Artjom Kurapov Nov 11 '13 at 10:46
  • Yes, if you don't want to go through an OS reboot and have access outside of your user directory, this will remove the obstacle. Do it **after** correctly setting file/folder permissions so the web server can read/write to your var/ tree and you shouldn't ever have this stuck config problem again. – Fiasco Labs Nov 11 '13 at 16:19
4

When you move or change your Magento installation to a new domain name, you need to do make sure of four things:

1) Replace any instance of the old domain in any files on the server. This can be done on some (if not all) *nix by the following:

 find ./ -type f -exec sed -i ‘s/olddomain/newdomain/’ {} \;

2) Remove the var/cache and var/session files.

3) Update web/unsecure/base_url and web/secure/base_url in your database. (And any other instance of your domain - normally will not be more)

4) But ultimately folders require permissions of 775 and files have permissions of at least 664. This can be done with the following *nix commands: (Note: var folder and sub may need higher permissions)

 find . -type d -exec chmod 775 {} ;
 find . -type f -exec chmod 664 {} ;

A little history of how I found this out. Had to move a Magento website from one server to another. This was to test to make sure everything would transfer properly. After taking the hour to mass import the database (~3,970,000 rows - largest database I have seen for any CMS, and I have created/modified home-brew and other common CMSs), I was left with www.domain.com when I wanted developer.domain.com.

James Williams
  • 4,221
  • 1
  • 19
  • 35
  • 1
    Good information. However, I would skip the first step and have never had a problem by doing so. I too have seen large database dumps and like to [clear the log tables](http://stackoverflow.com/a/8201036/471559) beforehand. – clockworkgeek Feb 28 '12 at 15:21
  • The first step was actually needed because some of the core/theme files where changed to include the old domain. No clue why the last person did that. – James Williams Mar 09 '12 at 17:17
  • Lifesaver! After chmodding the folders and clearing all cache files all's fine. – Switching Brains Feb 21 '13 at 13:45
3

when you change something always rm -rf var/cache/* if you change base url then regenerate all indexes as well

Anton S
  • 12,750
  • 2
  • 35
  • 37
  • Also I can't re-index as the forms won't submit on the admin area without the JS being loaded – iamjonesy Jan 20 '12 at 11:24
  • Are you sure all inside cache dir was deleted once you executed a command suggested by Anton? – user487772 Jan 20 '12 at 14:23
  • 1.4.x.x allows for command line reindexing, not sure how to programatically do this for 1.3.x.x as I didn't stick with it long enough to require making a PHP script to do this. – Fiasco Labs Jan 20 '12 at 21:06
  • try a different browser. The browser will sometimes cache a 301 and keep redirecting you even though you have since fixed the site. – iJeep Jan 20 '12 at 23:53
1

This can lead to a situation where you've changed the base URLs in the Magento database, cleared cache (manual deletion of all mage-?? folders in var/cache), (cleared APC cache if you're running the op-code cache), (manually disabled the compiler (1.4.x.x and later)) and the system still looks for the original site.%

0

Check your config.xml -- it probably has the live site database config.

For Magento the path is /app/etc/config.xml but I'm not sure if that's the same in your version.

Zachary Schuessler
  • 3,644
  • 2
  • 28
  • 43