Any general web development topics are covered here, ranging from ecommerce web stores, search engine optimisation or store optimization to framework discussion.
It’s been a while since I have written any updates on my Gmail and Google Apps email extension for Magento. I have just released version 0.5 and thought now would be a good opportunity to write a quick update on the changes and what I have planned for SMTP email support in Magento.
Version 0.5 of Google Apps Email/Gmail Magento Extension
Firstly the changes in the latest release of the Google Apps/Gmail Magento extension. Both have been inspired by user feedback so two ‘thank you’s to follow. Firstly thanks to Blue Acorn for pointing out the lack of multi-store capability on the self test. It’s actually a little clunky getting the store parameters in the admin of Magento, my custom button needed to add the parameter like so:
The other change was a bit of a curve ball. I had a Magento + Gmail user named Matt contacted me with what seemed to be an unrelated issue. I have been poking around in the installation code trying to figure out what has been happening. It wasn’t until I did a full fresh install on Magento 1.3.2.3 that I noticed what was going on. My extension has a dependency on Mage_Core (obviously, right?) and the wiki guide on how to package Magento extensions says to include this dependency. However if you do then the downloader will download the Core files and a whole bunch of other required files. This is no problem if you have been a good boy or girl and made your changes to the themes outside of the default files, but if you have changed the default templates then there is a risk of your changes being lost!
So, the change is to remove this dependency, even though the guide says it should be there. It’s kind of obvious that you need Magento in order to run my extension anyway!
Magento SMTP support
The other update I wanted to post was that I am working on porting my Magento Gmail / Google Apps extension to also support full SMTP capability. I will be releasing the changes as a new extension, as it is important to me that the original goal of this extension (extreme simplicity and ease of use) is not lost under the weight of full SMTP configuration.
I know that there is already an older SMTP extension for Magento. I think I can improve upon it in several ways, I have developed Magento SMTP self test capability, and I have support for Magento newsletter sending. The current SMTP extension hasn’t been updated for nearly a year, and I have an opportunity to create a more modern, user friendly extension.
I’ll be working on it over the next few days and would invite feedback from anyone with ideas on ways to improve the Magento SMTP functionality.
It’s been a while since I have done any of my Magento Hosting Reviews but I’ve finally gotten around to reviewing Crucial Web Hosting. Ages ago (I mean months) a reader specifically requested I review Crucial for their Magento hosting capability, and they were very keen to participate.
Crucial have gone ahead and pre-installed Magento on one of their split shared hosting programs. I’ll talk a little about what that means during the review. Crucial have also kindly offered to keep their Magento demo install up and running so that you guys can try the Crucial Magento demo out for yourselves.
In this Magento Hosting review, just as with my others I’ll be looking at the hosting proposition itself, the value and the price and how they stack up. I’ll also look at the responsiveness of their data centers and comment on the general access levels the hosting provides.
I noticed that my last Magento Hosting Review became a bit of a monster and probably put a lot of people off because it was too long and not that well structured. This time I’ll try and give the whole review a little mini-index so that you can jump to the parts you actually want to read about, if you are not interested in the whole thing.
In this section I’ll discuss the actual hosting solution offered by Crucial. I’ll look at the hardware they’re operating, explain the notion of split-shared hosting and how that relates to other shared hosting solutions. I’ll try to weigh up the offering with other similar solutions for value.
Right off the bat the hardware offering is definitely high-end. The Crucual website claims “Quad Core Intel Xeon Harpertown 3.0 GHz, 32 GB DDR-2 RAM, 15K.5 RPM hard drives, and a Gigabit uplink”. I checked this out on the command line and sure enough 8 3GHz processors from cat /proc/cpuinfo! A look at the output of top on the box reveals the beast is hardly even raising an eyebrow at the work it’s doing, an avg 0% cpu usage and over half the RAM is free. Although this is a shared hosting solution, it is definitely not a machine that is being over worked or put under any pressure by too many clients having to share the same hardware.
Split-shared hosting is a way to divide up the available computer resources (the hardware) among more users without having to share the resources with so many people.
In a traditional shared hosting arrangement all of the users on a server are in the same ‘system’. That means they are basically all users on the same Linux box. If everyone is playing nice then there’s not too much of a problem with that. Provided the host is not overselling. The problem is that with so many clients on a box, if one of them has security problems, or get’s ‘slashdotted’ then the entire system is put at risk.
With split-shared hosting the single Linux box is virtualized into several small Linux boxes. Each is not a real server, but a virtual one isolated from the others by a special underlying piece of software. Each virtual server has it’s own allocated resources which means that if someone in a neighboring virtual server is slowing a server down, it will not affect your virtual server.
Does this really help? Well, yes and no, there is much less chance that you’ll be affected by the shenanigans of one of the clients you share with, when there are fewer of them, but you are fundamentally still sharing a server with others and exposed to the problems that can accompany that. So it’s better than pure shared hosting, but still no match for a VPS or an actual dedicated server.
Now that we know how the hosting works and how grunty the servers are, what do you get for your money? For $25/ month (less if you pay in advance) you get 50GB of bandwidth and 5Gb of storage space. With ecommerce I always think that if someone is doing 50GB of bandwidth they probably have tens of thousands of visitors and should be making enough sales to warrant a much bigger hosting solution, so bandwidth is probably nothing to worry about. With disk space, 5 gigs is probably more than enough for most webstores, even if you used ultra high-res product photos (say 300kb) and had 3 such images per product, that would be 4500 products (with leftover for the actual Store install etc). In general for small Magento stores the disk space and bandwidth will be adequate. For larger ones, do not look at shared hosting!
To put the price in context, for the same monthly amount you could get the SIP account from Nexcess which in my review I do really rave about. How does Crucial’s Magento hosting option stack up in the performance stakes against Nexcess’s Magento optimized SIP? Read on 🙂
The Performance
I normally look at page load time and latency when deciding how well a Magento host performs. To test latency I use the free and excellent service just-ping.com. The results of the test against the Crucial Demo server show that the ltency to large parts of the world in in and around that 100ms sweet spot. Us poor antipodeans in NZ, Aus and SA get a bit slow communication, but hey, no-one cares about that right?!
WatchMouse test results for the Crucal Magento Demo
And here is even more!
Even more WatchMouse test results for the Crucal Magento Demo
What’s interesting is that even though this is a shared host and there is no advertised performance optimizations carried out on the Magento install, the response times are snappy (around or under 1 second) in most places the tests are run from. That’s really good to see, and if you actually browse around the demo you’ll get a feel for how punchy the pages show up.
Access and Support
Of all the hosting companies I have dealt with I’d have to say I have never had any real problems with the service. Crucial is no exception, the contact I dealt with at Crucial has been polite and really helpful, setting up Magento and installing sample data, responding really quickly to emails and tickets and generally being the good host everyone says they are.
The server access is top notch as well. SSH access is granted by default, and the initial support ticket had all the access details required. Anyone who has approached me for Magento installation help/advice will know that as soon as someone tells me they only have cPanel or (far far worse) only Plesk access, I normally run for the hills and advise others to do the same. As far as I am concerned if you are serious about running a webstore and you want at any time to get a professional involved in support or customizing your store, you need to have the ability for them to access your server using SSH.
Conclusion
Geez this is really tough for me to say! On paper I’d say Nexcess’s SIP looks the better plan for the same money, it’s been optimized for Magento and offers slightly more value. But, I’ve tried out the Crucial demo, I’ve looked at Crucial’s server and I have to say it is as fast or faster, the support is great and I can’t really fault them either. In the end it will probably come down to preference. Both companies offer a money back first month, so perhaps you should sign up for both and decide for yourself based on your interaction with their support and sales team!
PS: As with my other reviews I’m inviting feedback from my readers on personal experiences with the hosting company, because often (as was the case with Simple Helix) the negative experiences that come out of the woodwork can be a real influence in the hosting choices we make.
I normally always want to remove the Compare/Add to Compare functionality from the Magento stores I create, and in the past have changed the template files as though the compare functionality is being hidden in the theme. In a lot of ways that’s probably a fairly reasonable way to disable it, but something seems clunky about going through a bunch of phtml files in Magento directories grep‘ing and replacing Add to Compare everywhere. I recently did it a different way, that although may be slightly less well separated from the core Magento functionality (in terms of keeping the changes at the UI layer) – I think it makes it clearer.
There are really only twothree four (Thanks Matt and Paulo) steps to removing the compare functionality, and they’re all fairly easy, here’s how to do it:
Disable comparison functionality in Magento
I did this on the command line, but I’ll explain the commands for those of you stuck in cPanel/Plesk/GUI hell. These commands are all run from the root of your Magento store.
Making this local code directory that mirrors the core Mage folder structure will allow Magento to pick up your custom file. WHich we now make by copying the original from app/code/core/Mage/Catalog/Helper/Product/Compare.php and putting it in the new directory we made app/code/local/Mage/Catalog/Helper/Product/:
Now we just make one small change to the file, by basically telling this helper to never return a comparison URL, the front end will never show the add to compare links. The change is made in the getAddUrl() function.
publicfunction getAddUrl($product){#return $this->_getUrl('catalog/product_compare/add', $this->_getUrlParams($product));
# We disable compare functionality by commenting out the real return statement and returning false instead.
# Returning a boolean from a function that should return a string, somewhere, a kitten dies.
returnfalse;}
public function getAddUrl($product)
{
#return $this->_getUrl('catalog/product_compare/add', $this->_getUrlParams($product));
# We disable compare functionality by commenting out the real return statement and returning false instead.
# Returning a boolean from a function that should return a string, somewhere, a kitten dies.
return false;
}
Save the file and you’re done. Now when you refresh the product/category page (you disabled the Magento cache right?) then you’ll no longer see the ‘add to compare’ links by the add to cart buttons.
Remove the Compare sidebar element
There is also the matter of the sidebar element, here’s the easy way to get rid of that.
Edit your theme’s catalog.xml file which is found in the app/design/frontend/X/Y/layout/ directory, where X and Y are your theme and package, possibly just default and default.
Remove the part that looks like this within the first <default> element:
This has the nice side effect of removing the back to school specials block too, obviously if you are actually running a back to school special, then only remove this line from the <reference> element:
To remove the compare sidebar from the My Account section of the Magento store edit the file: customer.xml inapp/design/frontend/X/Y/layout/. Find the section:
Edit: And thanks to Paulo for pointing this out – the compare sidebar is also included in the reports.xml file, so remove it from there in the same way:
And that should be it, no more compare functionality. Maybe it’d be nice to make this into a Magento extension, so that it can be enabled and disabled on the admin interface. If there is enough interest in that, I’ll bundle up my code change, it’s really only one file, after all. If you’re after something like that – let me know.
Update March 2013: There’s an extension for doing this now guys, thanks to Roman. Go get it!
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.
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:
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 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 localhostcat/etc/hosts
# 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
# 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:
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 WHEREVALUELIKE"%domain.com%";
-- Be on the look out for something like this:|513|DEFAULT|0| web/cookie/cookie_domain |DOMAIN.com |
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:
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 twothree 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.
