Magento | ASchroder.com

Posted on October 25, 2011

Magento Cloud Backup 0.3 RC – new features and an end to the beta program in sight

We now have over 300 downloads of our Magento Cloud Backup extension, with users storing over 300GB of their store data safe offsite using Amazon S3. As we near a post-beta release I thought it might be worth announcing an early RC, for both initial feedback from other developers/admins and because some of the features in this RC have been asked for, and I’d like to allow those users to gain early access to features they need.

What’s new in CloudBackup?

Auto-cleanup of old backups
Probably the single biggest feature request is the ability to delete old backups automatically. I have implemented a simple, delete backups older than 3 months process. However if you want more or less backup storage, it’s easy to change like so:

Edit Backup.php and change private $NUM_MONTHS = 3; on line 31 to your desired number of months.

(I’ll probably make this a fully fledged configuration option for the actual RC when it goes live on Magento Connect.)

You need to enable the setting as shown in the screenshot above. Once enabled a nightly cron job will look for backups that are older than the specified threshold, and delete them from S3.

Native Database backup support

This is a MySQL only, power-user only feature that allows you to skip the Core backup if it takes too long on large stores (>2GB of database data).

It’s important to note a couple of things with regard to running native Database backups. The first is that while it’s running the mysqldump will take a lock over the database, for really really big databases that could be a problem as it may block checkouts/new accounts, for example.

The second is that mysqldump is run via a system() call this means you need security setting on PHP to allow this. It also means the mysqldump binary needs to be accessible to the PHP webserver user. To help that I have added a simple variable in Native.php (the native equivalent to Db.php provided in Magento core).

I’ll just let the code/comments do the talking with regard to configuration:

// if mysqldump binary is not on the webserver user's path
private $PATH_TO_MYSQLDUMP = ""; 
 
// For example on a MAMP based OSX install you might use: 
// private $PATH_TO_MYSQLDUMP = "/Applications/MAMP/Library/bin/";

This feature should really only be used by people who see it and think ‘great the answer to my prayers’ anybody else is likely to get themselves in to difficulty – it requires fairly deep access to your server environment – For example; if you’re on GoDaddy hosting, I’d be very surprised if you could run a native backup from PHP!

Trying the new features

You can get early access to the code over at Github, we’re using Github pages, it’s really quite a nice feature.

Once you have the code, you can install it manually in whatever manner you like, here’s some suggestions I wrote up a while back.

If you’re patient, I’ll have the RC release up on Magento Connect within the next few weeks. It needs a little more polishing before I’ll be happy with it though.

The End of the Beta Program

We’ve been running the beta program for over 12 months and I consider it a great success from a technical point of view – the software has matured gradually and with plenty of testers I feel comfortable about the quality of the backups being created, and the consistency with which they’re being made. It probably doesn’t take much business savvy though, to realize that with 300 downloads, and a bit over 300GB of data in a first-GB-of-data-free beta program, we’ve been shouldering quite a burden for everyone’s backup storage.

As I’ve said before, we would never take anything away from those that have been helping us test, so I’d assure everyone upfront that the initial GB of free storage will remain for those already using the extension. What will most likely happen once the extension is released as a 1.0 stable, is the extension will cost some small amount to buy, or the first GB won’t be completely subsidized. I’ll be sure to update everyone once we are clear on which direction the extension will go.

Anyone who has had a beer with me and endured my rant about the folly of selling not-scarce digital copies of things (including software) will know where I stand philosophically on the matter.

In any case, if you are considering offsite backups for your Magento store, or your client’s – now would be a pretty good time to jump on the bandwagon.

So that’s pretty much the update on our Magento Cloud Backup extension, if you have any questions/gripes, please don’t hesitate to comment below!

Posted on September 18, 2011 July 2, 2013

Using SMTP Pro and Ebizmarts’ MailChimp extension in Magento

This is just a quick blog post that will hopefully help people facing the clash in Magento between my SMTPPro email extension and Ebizmarts’ MailChimp extension.

The clash occurs only in one class Mage_Core_Model_Email_Template which we both override to extend the default Magento email sending capability.

Because it only makes sense to use either SMTPPro or MailChimp as your ESP if you want to use SMTP Pro you can safely disable the MailChimp core class override and then SMTPPro will send the store emails using whichever method you have configured.

Update July 2013: I have since released a premium extension for sending email using Amazon SES called MageSend, if you’re having toruble sending email with Magento, please check it out, it was created to solve many common Magento email issues.

To remove the core override edit code/local/Ebizmarts/Mailchimp/etc/config.xml and remove the following XML:

<core>
    <rewrite>
        <email_template>Ebizmarts_Mailchimp_Model_Email_Template</email_template>
    </rewrite>
</core>

When/Why is this safe to do?

You can do this when you are not using the MailChimp STS capability and want to use SMTPPro to send your emails. If you don’t want to send via SMTPPro, just uninstall it to resolve the conflict.

You can see in the first lines of the override class Ebizmarts_Mailchimp_Model_Email_Template why this is safe:

if(!Mage::helper('mailchimp')->isStsActivated()){
    return parent::send($email, $name, $variables);
}

This means that if you are not using STS, then the whole override is basically a noop.

One caution I have for you though, once you modify an extension, you have to remember to apply the same patch each time you upgrade it, otherwise the clash will creep back in!

Update: I missed some emails notifying me of comments, I missed this fairly important one from Ebizmarts with basically this fix in it… On a related note, if I didn’t reply to your comment for the last few weeks, that’s why.

Posted on July 6, 2011 July 6, 2011

Monitor your Magento Store with MageSpeedTest.com

I snuck/sneaked out a new feature for MageSpeedTest.com last week: Performance Monitoring.

Basically it’s the same simple Magento performance test you know and love, run every 6, 12 or 24 hours. If the results of the regular tests differ by more than your preset tolerance, you get an email warning you – simple.

I wanted to soft launch it to a) try it myself in production for a while and b) get some tester feedback.

So with positive results from both I am now officially announcing the new Magento Monitoring feature and inviting you all to try it for free!

Continue reading Monitor your Magento Store with MageSpeedTest.com

Posted on June 30, 2011 July 2, 2013

SMTP Pro with Magento: A sort-of user guide.

This blog post is about the SMTP Pro extension. It is my attempt at full explanations to some very good questions/feedback from Chris Last in his comment on an earlier post. I decided that I should give thorough explanations to the questions and they probably belong in a blog post rather than a reply comment. Hopefully it’ll form a mini user-guide, I’ll try to update it as such over time.

There are too many sections in Config->Advanced->System for me to make complete sense of:

Mail Sending Settings – do these have any effect?
Disable Email Communications No
Host localhost
Port (25) 25
Set Return-Path no

1) The Mail Sending Settings are the built in Magento ones, they don’t work very well for custom SMTP servers and you can safely ignore them. One thing to note though. I do adhere to their disable configuration in my extension. So if you disable all emails using the core config here, all emails do stop even if sending via SMTP Pro.
Continue reading SMTP Pro with Magento: A sort-of user guide.

Posted on May 2, 2011 May 2, 2011

Magento and Amazon’s CloudFront CDN – The Easy Way

In this post I will cover a simple way to configure Magento to use the Amazon CloudFront CDN service and to create a CloudFront distrubution that mirrors the static files in your site. This method relies on the custom origin functionality announced late last year when CloudFront came out of beta. But first, a little background.

A CDN (content distribution network) is a network of servers that puts your files and content closer to the user requesting them, and thus they can get the quicker. Using a CDN has a nice side effect of offloading some work from your own server too – which if you use Apache means less processes on your server for each customer.

When Amazon first announced CloudFront I got very excited about the prospect of writing an extension to automatically sync a Magento store’s media with an S3 bucket, to enable this simple, affordable CDN solution. Alas, it turned out to be quite hairy dealing with the subtle race conditions that can occur when first accessing a specific media file that may not be available on the CDN yet.

With the introduction of custom origin functionality there is no situation where the CDN won’t have the file. If the CDN doesn’t have the file, it gets it from the underlying source server, if it already has it, it serves it. This means the first request for a file will be a bit slower, but after that it’ll be quick.

So to make a CloudFront distribution work in Magento it only takes two steps.
Continue reading Magento and Amazon’s CloudFront CDN – The Easy Way