If you are having difficulty with Firefox kicking off two events simultaneously and not happening in other browsers, the issue may lie with your $(document).ready or $(window).ready events. Normally it isn’t a problem to have multiple .ready blocks on your page. However, I ran into a pesky bug today that only affected Firefox. Consolidating my initialization scripts into the same $(window).ready() block cured the problem. This wasn’t ideal since I wanted to keep that code in a separate file, but the fix worked.
I just spent one too many times waiting while Magento uploaded to my server via FTP. And as it happens much of the time it failed. Rather than dealing with repeated FTP disconnects I headed off to see if there was a better way. The obvious choice had to be something over SSH. But to be honest, my SSH-fu isn’t as strong as your average sysadmin. Thankfully, there are some kind souls out there who put together a wonderful script and instructions on how to do just this.
This like any other SSH activity this isn’t for the feint of heart and should come with a standard disclaimer: you can really screw some stuff up using SSH so be cautious, use a strong password, and backup your stuff.
Ready? Good, head on over here for the detailed instructions. Let me tell you, this was substantially faster than the old-fashioned way over FTP and then manually running the installer. Figure this will take you a few minutes to parse the instructions, get your SSH client fired up, and start the script. This is compared to waiting eons on FTP to upload the 12, 194 files (I shit you not) in the standard Magento install. And in my experience using FTP doesn’t always work anyhow.
Keep in mind since you will need to navigate first to your Magento installation folder before getting started.
Note! make sure you have your PHP memory limit set high enough. For me at the MediaTemple DV default (I think it was 32MB) it failed. However, upping this to 128MB (I have a total of 768MB of RAM) made things work like a charm.
Thanks to the guys at Crucial web hosting for the article, you just saved me a ton of time and frustration.
Wish there were some friendly template tags don’t ya? Yeah you aren’t in WordPress-land anymore.
Need to show the category name anywhere?
Here you go:
$categoryobject = Mage::registry(‘current_category’);
I can’t take the credit for this one though, I actually found the object reference over here. He got me the object, I just added the line to grab out the name from the object. Many thanks to Richard for the post.
MediaTemple’s DV server is an excellent choice if you need to host multiple sites, resell hosting, or just need more power than shared hosting can provide. However one key feature is missing out of the box required for utilizing web services. PHP must be compiled with SOAP (for you to use Magento‘s web services for example).
You will first need root SSH access which can be enabled via MT’s “Root Access & Developer Tools” in the Account Center. Note: enabling SSH is a potential security risk so make sure you use a strong password (updated 4/25/17) or you can also try the generator here: http://comparitech.net/password-strength. Note: I have no affiliation with either of these sites, the key is to always use unique, strong passwords for your accounts.
Open your terminal (use putty or just use Terminal.app in OSX), and SSH into your server using root.
- Navigate to a relatively unimportant directory. I chose /home/
- Download PHP
- Unpack the PHP file
tar -zxf php-5.2.6.tar.gz
- Configure the new PHP to enable SOAP (will take a few minutes) (before enable is two dashes)
- Rebuild PHP (this will also take a while)
- Copy just the SOAP module into your existing installation of PHP
cp modules/soap.so /usr/lib/php/modules/
- Add the new SOAP configuration to your existing configuration
echo "extension=soap.so" > /etc/php.d/soap.ini
- Restart Apache
- Optional: You can now delete /home/php-5.2.6/ if you’d like, as you won’t need it any longer.
rm -rf /home/php-5.2.6/
- Check phpinfo() to confirm that SOAP is now enabled.
These instructions were originally posted here.
Changing domains with WordPress doesn’t have to be a headache. You might think that simply updating your wp_options table in the database might be enough… or that perhaps you could do it in… you know, the wp-config file? Well, you would be part right. Changing your database values for ‘home’ and ‘siteurl’ are key to getting your site to work on a new domain… but before you mark this task is done, you might want to make sure your images will work once you switch off (if you intend to) the old domain. See with each post image (images are saved as posts in the database) there is a GUID stored. This has an absolute path to where the image resides and doesn’t rely upon your database settings. So if you up and move your site off to another domain, you are going to want to update this as well.
Before we do anything, you have made a copy of your database, riiiiight? Good.
You will want to get into PHPMyAdmin and run the following SQL:
UPDATE wp_posts SET guid = REPLACE ( guid, 'http://exampleoldsiteurl.com', 'http://examplenewsiteurl.com');
Of course this assumes you have used the default table name and you replace the URLs in the query with your actual domain names.
Now, this gets you a good bit of the way there… but you are STILL going to have bad paths if you kill off your old domain… this is because in your actual post content you are referencing absolute paths to your old domain. Well depending on the scope of your site you can either edit each post/page manually… or do a find/replace in your database. This would be best done before you import your database onto the new server.
So if we rewind a bit, you should have 1. backed up your database and 2. imported into your new site and 3. updated your settings.
To make things a bit easier for you on the migration, stop after you do your export… open up your SQL in a text editor and do a find/replace for your old URL and replace it with the new one. Now that your SQL is clean, you should be able to do an import into the new database and all your links will work fine. Since you are doing a replacement of all of your data, there shouldn’t be a need to follow up with the query above.
For more information check on the WordPress Codex page about migrating your site.