Posted on June 20th, 2009 3 comments
Since writing this post on installing Magento, I discovered a lot of unique features of this amazing open source ecommerce platform. With that said, there’s still so much I need to learn about that I decided that I’d rather get a simpler site up for my home page URL, and move my Magento install to the ‘store’ directory on my server and create a subdomain for it (store.example.com).
Moving your Magento store to a new URL is actually incredibly simple, but I did run into one confusing step that I’ll warn you about in a moment.
Now, like the typical male stereotype, I don’t ask for directions. I’m the type of person that assumes everything will be easy, simple, and straightforward until I discover otherwise, hit a road block, or can’t figure it out on my own. I’ve been burned enough times over the years that I’ve learned one simple thing that can save hours, if not days or even a lifetime of anguish. Backup often.
- I start out by synching and creating an entire backup of my Magento install. I did this using Dreamweaver’s synchronize feature and phpMyAdmin to export the current database. I dropped the .sql.gz from phpMyAdmin into the root directory of my local working copy and the created a zip of the whole thing with WinRar.
- Next, I created a subdomain in CPanel, called store, and added a new cname record at my DNS provider.
- Third, I updated Dreamweaver’s profile for the site, by adding /store to the remote FTP path field. I clicked Test and it resolved ok.
- Next, in Dreamweaver, I clicked the top folder of the site in the Files panel and typed Ctrl-F. I searched the entire Magento installation directory for my original domain name. I figured with this technique I’d discover anywhere Magento’s web-based installer had written its config files to or any path information. This took a little while based on the rather large number of files required to run Magento.
- Oddly, I found something in the downloader/pearlib/php directory, changed it, and synchronized. I wasn’t changing my database username or password, so there was no need to edit etc/local.xml.
- Next, I logged into the database using phpMyAdmin. I clicked on the main database name in the left panel, then the Search tab on the right. I entered just the part of the domain without the extension, in MySQL wild-card fashion, like so: ‘%example%’ (for example.com, no quotes). I selected every table, and clicked Go.
- phpMyAdmin found two rows in the core_config_data table, and a few others in the cms content and log tables. I clicked on core_config_data table’s Browse link, and updated two rows with my new URL, http://store.example.com.
- After lunch, my TTL on the cname addition to DNS was propogated, so I gave it a test at http://store.example.com. It half worked. I was getting my site content (the php/html was working), but no CSS, just a blank white Times New Roman site with tell-tale blue links.
- Here’s where the hidden gotcha is, that I told you I’d warn you about above. I hope this saves you some time if you’re reading this post wondering why your Magento store has can’t find the CSS after moving it. Delete the contents of the /var directory. I did this using
> cd public_html/store/var > rm -rf cache > rm -rf session
I wasted an hour trying to figure out where else Magento could be set to look for the path to CSS files before having the idea that Magento may be making a cache somewhere. As a PHP Fusebox developer, and having used the Smarty template engine, I’d seen a web app create temp files before. It’s not too uncommon for web applications to create some kind of parsed files to help aid performance. Sure enough, Magento creates parsed files in the /var directory, which must be deleted (and rebuilt after applying the new settings).
- Browse the site. Did it work? It worked for me.
Thanks to Damián Culotta for his post on the Magento Forums on this same subject.