Magento

I’ve upgrading Magento a few times in the past by first doing the recommend duplicate test site upgrade, so basically:

Duplicated site and database and changed:
Change db connection details: /app/etc/local.xml
Change core_config_data table
Clear cache and sessions in: /var/cache and /var/sessions
Updated pear.ini in download

But after logging into the test site admin it redirects to the live site dashboard. What’s going on? Have double-checked my work…

Is the duplication of the same key in /app/etc/local.xml an issue. Can’t really find any mention of it anywhere in relation to site duplication.

1) Table core_config_data - check values with key ºse_url%. Probably you leaved old url there, it’s common cause of this issue.
2) Clear cache

Hi

Did you find the reason/ solution for this? I have the exact same problem, I duplicated my store, changed all the configuration files/ tables, but when I log in to the test store admin, it goes to the live site admin. 

I noticed the test site admin menu the links of the menu items all go to the live site (https://livesite.com/....) whereas the menu headings have the correct https://testsite.com/…

I am going crazy, I have tried everything, anyone know what else I can do?!

Help

I have the same issue. Anyone find a solution to this?

As stated above, inside the core_config_data table within your Magento database are a few records pertaining to the Base URL settings.

Update all entries with the new domain.

Be sure to also update the ‘cookie domain’ in core_config_data if you had previously set it.

Next, empty your session data from the core_session table (just empty the table, don’t drop!) and remove the following from your files:

var/cache
var/session

Finally, load up the domain and log in - it *should* log you right in.

more_cowbell - 07 March 2011 01:41 PM

I have the same issue. Anyone find a solution to this?

You can run the attached (wouldn’t post correctly in forums) queries in sql

Then update the records returned with the appropriate urls of your staging area

IMPORTANT: If you had https enabled for admin, and you don’t have ssl installed on your staging area, it will redirect to the main url in my experience.

queries.txt  (File Size: 1KB - Downloads: 226)

Thank you both, will give it a try

So I have updated the base URLs, removed folders inside of /var and CHMOD’d my folders. When I try to go to my new server (localhost) the page never loads. I can put in localhost:8888/admin and that will load, but will not proceed to dashboard. Cant load any other page.

Any ideas?

My issue was running PHP 5.3 in MAMP. Needs to be 5.2!!!

Thanks!!! Simple-Helix.com is my current webhost and I’m doing exactly this right now. Now working on the update from 1.4.2 to 1.6.x stable… Now that dummy test domain works, I’m going to read up on the best way… go to final step first or hit versions in the middle first. :D

Thanks Simple-Helix,
Chris

SimpleHelix.com - 08 March 2011 01:41 PM

As stated above, inside the core_config_data table within your Magento database are a few records pertaining to the Base URL settings.

Update all entries with the new domain.

Be sure to also update the ‘cookie domain’ in core_config_data if you had previously set it.

Next, empty your session data from the core_session table (just empty the table, don’t drop!) and remove the following from your files:

var/cache
var/session

Finally, load up the domain and log in - it *should* log you right in.

I am stuck with similar problem.

I have done all the steps.

Checked that my staging db is being called and not my live db (it is)
Cleared cache, sessions (please don’t tell me to do this again)
Checked local.xml to ensure all settings are correct
Changed all url entries in core_config_data
Started all over and tried it many times. but nothing seems to work.

Help me to resolve this issue.

Prevention:

1) Prior to move, disable the cache, back up your database and pubic_html files and restore to new site.

2) Use phpMyAdmin or MySQL to set the following to your new domain, change https to http if you’re not sophisticated enough to set up a test secure server (not a bad idea to have this capability for preventing serving insecure content when you do template mods):

3) Change file permissions so Magento has a proper environment to start up in.

4) Finally, change settings in your app/etc/local.xml file so your database login credentials allow Magento to start.

It’s all pretty simple unless you’ve done weird things in your .htaccess, etc. Usually, people get antsy, stuff the database in, load public_html, start Magento and find it redirects to the old site.

The above order tends to prevent that because:
1) No cache being turned on means no old site configs get stuck in cache.

2) Changing the base_url settings before Magento can see the database means that Magento can’t run and store junk in the cache even if you forgot to disable it on the old site.

3) Having the file permissions set properly means that Magento doesn’t go off on a tangent and store its cache in system temp (/tmp) when it finds it can’t write to var/cache/* or var/tmp/*

4) Doing local.xml settings last finally allows Magento to start and any weirdness from this point on is truly weirdness that needs to be addressed, not some dumb config stuck in a dumb place where it refuses t go away.

After the fact removal of unwanted site redirection: (yep, you didn’t follow the above order and it just won’t move to the new site!)

1) Turn off the Magento cache (use phpmyadmin to open core_cache_option table and set all values to 0)

2) Set proper file and directory permissions on your Magento installation

3) Manually clear cache by deleting all the subfolders in var/cache/.

If var/tmp and var/cache permissions are messed up and Magento can’t write there, Magento will write to the system /tmp folder and you will get stuck as this is where Magento will more or less permanently store your cache till the server gets rebooted. Your website will still redirect to the old site because the core_config_data settings are cached in this bogus caching until you are able to force it to re-read the table.

Images below:
1) core_cache_option table contents,
2 & 3) File listings of Magento Cache storage forced to be in system cache (/tmp) because Magento file and folder permissions (especially var/*) weren’t set correctly on a Magento move.

Click thumbnail to see full-size image