Archives For May 2009

Just a quick note to say I have added some new functionality to the Gmail or Google Apps email sending extension I wrote for Magento.

Basically several people asked for reply-to functionality, that would use the Magento store addresses that were being used on the outbound email. The change was very minor, I guess I just didn’t see it as being important at the time. Anyway, it’s a configurable option now, so feel free to either use it or not. You can get the extension from Magento Connect.

The change for those interested was very small, just a simple reply-to header as shown below:

// If we are using store emails as reply-to's set the header
if (Mage::helper('googleappsemail')->isReplyToStoreEmail()) {
      $mail->addHeader('Reply-To', $this->getSenderEmail());
}

Also here are some screenshots showing the new configuration option and also how emails sent using the option or not using it.

The Gmail and Google Apps email configuration for Magento is very easy.

The Gmail and Google Apps email configuration for Magento is very easy.

You’ll notice no real changes here, just one new Yes/No option that if enabled will use the reply-to functionality shown below. Basically the reply-to email will be the one Magento is configured to use from the below Store email addresses screen.

This shows an example of some store email addresses configured in Magento

This shows an example of some store email addresses configured in Magento

These are the email addresses you will see in the reply-to field as shown in the examples below.

The default behavior is to send with no reply-to, as it seems the trend is toward automated emails that do not receive responses.

The default behavior is to send with no reply-to, as it seems the trend is toward automated emails that do not receive responses.

This image shows the default non-reply behavior, the from email is used as the to email for any replies.

This shows the new feature, a reply-to field that email clients will use to populate the reply to field.

This shows the new feature, a reply-to field that email clients will use to populate the reply to field.

This screenshot shows the use of the reply-to where Gmail will send the reply to the given email rather than back to the original sender address.

If you have any questions, feedback etc I’m always keen to hear it so please comment or contact me directly.

I was asked this week by a reader about using Google Apps email with Magento. There are solutions available that will allow you to configure the Magento SMTP server settings, or even your linux server SMTP settings so that you can use Gmail or Google Apps email to send outbound emails with Magento. In this post I will quickly cover a simple little open source Magento extension I made that makes setting up Gmail and Google Apps Email child’s play.

The Google Apps and Gmail Magento extension

You might be wondering firstly why you would want to use Google Apps or Gmail for your outbound emails from Magento.

  • Easier to set up a stable, secure and robust solution than if you try to run your own SMTP server.
  • Easy to administer with either the Gmail or Google Apps interface. You can set up auto replies, and auto forwards.
  • Excellent search capability for finding messages that have been sent to customers.
  • Acts as a log or archive of all emails sent by Magento, which means you can make sure it’s not sending any you do not want sent, and easily track any that are sent.

So hopefully everyone knows how sweet it is using a hosted ‘in the cloud’ email service, now on to how to do it!

Installation

You can install the module from Magento Connect by getting the extension key. Then using your store backend Magento Connect manager, you’ll need to change your settings to accept alpha modules (on the settings tab) and then just paste in the extension key and click install. Too easy. You can change the alpha back to stable afterwards, by the way.

Configuration

The Module is configured in the System -> Configuration -> System section. There are only three things to choose, so it’s very easy to setup.

Using Google Apps or Gmail with Magento is made easy with my purpose built Magento extension.

Using Google Apps or Gmail with Magento is made easy with my purpose built Magento extension.

It’s hopefully redundant, but for completeness here is some documentation:

The Enable Google Apps Email option allows you to turn the extension on and off easily. When enabled the extension will use your supplied Google Apps or Gmail credentials to send email from the Magento store.

The Email Address field is where you type the full address of you Gmail account or Google Apps account. It is important you type the whole address, even for Gmail where you might be more familiar with just entering a username.

Finally the Password field is where you type you Email account password. There is currently no way to test the connection (i.e. to make sure you have the right password) but that is planned functionality for a later release.

The Technical Details

The module is very simple, it’s just two Model files that overwrite the email sending functionality with Magento.

The key is in the setup of the Zend transport object as shown below:

public function getGoogleAppsEmailTransport() {
 
	$email = Mage::getStoreConfig('system/googleappsemail/email');
	$password = Mage::getStoreConfig('system/googleappsemail/password');
 
	$config = array('ssl' => 'tls', 'port' => 587, 'auth' => 'login', 'username' => $email, 'password' => $password);
	$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', $config);
 
	return $transport;
 
}

It’s annoying that for all the flexibility Magento allows, the way that the email sending has been coded really doesn’t allow much scope for extending the functionality without re-writing a sizable amount of Magento code. This means that maintenance becomes more difficult and the value of the inheritance structure is lost.

Setting up your Google Apps account

Sign up for a Google Apps account and then you’ll be able to create a ‘user’ to do your Magento email sending. In my current configurations I use email addresses like ‘mailer@xyzdomain.com’ or ‘no-reply@xyzdomain.com’. This means that to the end user the from email address will appear like a sophisticated CRM mailer, when in fact it’s just a free Google Apps account!

I also recommend setting the account up to forward a copy of all email to your own personal Gmail or Google Apps account. This way if any users do actually try to reply to the mailer address, the message will still make it to someone. If you wanted to you could even set up an auto responder that informed users to contact you in a preferred manner.

Feedback

I’d appreciate some feedback on this little module – I know the functionality exists elsewhere, but sometimes just making a good solution really easy for everyone, can be beneficial, hopefully you agree. If you spot any bugs or would like to suggest some new functionality, I’m all ears. Keen readers who check out the source code (which is totally open by the way) may notice I have some code in there for sending test emails, I just haven’t wired it up to the admin interface (backend) yet.

This is a Magento hosting review for Nexcess Hosting. Savy readers will recall, Nexcess sponsored my last Free Magento Hosting competition by giving away one year of free hosting on their entry level plan.

For this review I’ll be looking at the latest offering from Nexcess, the Magento SIP platform. This is a purpose built ecommerce hosting environment that is both secure and optimized. In this review I’ll look at what that security means, and also be running some tests for performance. I have a demo Magento SIP environment set up that you can try, to see for yourself how fast it is.

If you can’t be bothered reading the review below, my bottom line is; if you are prepared to spend the money, this is the fastest, most convenient Magento hosting solution I have seen to date, get it here.

Continue Reading…

This is just a quick post about the Magento javascript giving a 404 error because it tripped me up and really shouldn’t trip anyone up. Basically the problem is the javascript include in Magento that looks like the one below gives a 404 error and causes javascript errors on the page:

<script type="text/javascript" src="http://example.com/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js..../>

The problem

Trying to load the javascript URL directly in a browser gives a 404 error, which in turns breaks everything javascript related in Magento. For example the checkout page will no longer work, the Magento admin menus do not display which then causes the whole admin interface to be unusable.

The fix

Set the correct permissions on the javascript files in you Magento installation.

cd /path/to/your/magento/
chmod -R 755 js/*

That should get the javascript files showing up again without the 404 error, and once they are, your Magento admin interface, add to cart, checkout and everything else that relies on javascript, will also work, yah!

This is just a quick little note to suggest two ways to solve the problem that you cannot log in to your Magento admin interface after a fresh install of Magento.

The Problem

The problem will manifest itself as a redirect back to the login screen, even though you typed the right username and password. If this problem is affecting you, you will be redirected back and see no error message. This indicates you have the right credentials, but the Magento Admin is just not letting you in. You can verify it by typing the wrong username and password, you’ll see you get redirected back and it shows an error message.

The problem occurs because the Magento backend tries to set a cookie on your browser, and then for some reason when you next make a request, the cookie is gone(or was never there). This makes Magento think you have never logged in, and of course it redirects you to the login screen. So the real guts of it is the missing cookie, we need to find out why it’s missing.

There are two three solutions (Update: now with bonus 3rd solution) I have come across that will solve this, there may be others too, so please feel free to post them below. Both of these solutions have been suggested in the comments of my post on Setting up Apache Virtual Hosting.

Solution 1: Domain Name with no dots

This is the most common solution, if you have set up Magento to run locally (on MAMP for example) then you may be accessing the Apache webserver using the localhost hostname. A security setting in browsers means that the cookie will not be set, though apparently in FF3 at least, this behavior is a bug?.

So simply stop using localhost, you can use your localhost interface (e.g. 127.0.0.1 or 127.0.1.1). To determine your localhost interface you can look at the contents of your hosts file:

# Look for the number to the left of localhost
cat /etc/hosts

or your interface configuration.

# Look for interface loX with the LOOPBACK flag (probably lo0)
ifconfig

Once you know which number to use, you can replace localhost with the number. If you have already installed Magento using localhost then it will keep writing out links to localhost, even after you have changed to using the IP address, you will need to change the base_url values in the core_config_data table, you can run a query like this to find the right config values to change:

SELECT * FROM core_config_data WHERE VALUE LIKE "%localhost%";

This should identfy two config values that will need to update with a query like:

UPDATE core_config_data SET VALUE="http://127.0.0.1/" WHERE path IN ('web/unsecure/base_url','web/secure/base_url') ;

I’m going to assume you know to put the right value into that query, and not use the example one I have provided!

After changing that value you should delete your var/cache contents, and then refresh the page. Now you should have Magento running on an IP address, not a hostname with no dots in it. Of course you could always set up a fake domain name like www.testing.com by using a Virtual Hosting setup like I describe in my post on how to configure a MAMP Virtual host.

Solution 2: Timezone differences between server and client

One other, less likely problem, is that the cookie is being set, but expiring immediately. To check this you can inspect the cookies your browser is holding, and check if there is one there from Magento. If there is then check both the timezone your magento installation is using , and the one you have set locally, perhaps your local time is not set properly?

Solution 3: Cookie domain does not match server domain

This caught me out when I was replicating a remote site on my local mac development environment. I thought it’d be worth adding this solution here, seeing as this post still seems to rank well for Magento install problems. I had changed the base URLs but had forgotten to check the core_config_data table for any other Magento configuration data that might have been interfering with cookies. The config path in question is: web/cookie/cookie_domain.

You can check the table with an SQL command like this – you should be on the look out for config values that have hard coded the old URL:

SELECT * FROM core_config_data WHERE VALUE LIKE "%domain.com%";
 
-- Be on the look out for something like this:
|       513 | DEFAULT |        0 | web/cookie/cookie_domain               | DOMAIN.com                                     |

And update it to an empty string (less secure) or the new actual domain (more secure) as shown below:

UPDATE core_config_data SET VALUE = "" WHERE config_id = 513;
-- or
UPDATE core_config_data SET VALUE = "domain.com" WHERE config_id = 513;

But wait, there’s more….

Thanks to Kristof aka Fooman for this gem:

Th solution here is to clear all your cookies related to the store domains and subdomains.

And yet still more possible issues, this time from Mauro Spivak:

This is an example of the more general issue that sessions are not able to be created. That could be because local.xml is instructing Magento to store them in a non-exsistent location such as in Maruo’s example – or may also be caused by permission issues on the filesystem when storing sessions in var/session. I’d suggest checking there is a session matching the session ID for your cookie to see if this issue is affecting you.

Hopefully one of these two three four solutions will get you back on track and able to log in to your newly installed Magento. Feel free to post problems or suggest other solutions in the comments below. I’m always more than happy to update my posts with helpful tips from readers.