If you have a multi website or multi-store Magento store, you will come across the issue of presenting store specific messages to your users. How, for example, do you tailor store specific messages on the 404 Page Not Found page, for example?
Today I came across a really annoying issue with respect to Magento’s search functionality. In essence, regardless of the term the user was entering, Magento returned the same 10 products, & occasionally a correct match!
Looking in the search logs of a search extension I installed, I could see that loads of results were being returned but not being displayed in the actual front end results. Could it be a stale index, or a problem with the cache?
Well, after countless command line reindexing, clearing the cache, checking the search settings in Config (Like & FullText), checking that products were visible, etc, I checked on the display values in the categories. There I discovered that the store’s root category’s “Is Anchor” was set to yes, and there were 14 products assigned to the root category. Amongst these 14 products were the usual suspects appearing in the rogue search results!
In the spirit of trying anything, I set “Is Anchor” to No and removed the products. Bang – the search results started working as expected. I’m not sure why but by this time I was past caring tbh! However, it looks like these settings were restricting the products that could be displayed on the front end. Does anyone know the reason?
I had this occur on another site I’m working on – empty search results. This time the culprit was that none of the products that had been imported via a third party system had been assigned to a website/store.
Today I noticed that some product images on a client’s site were not displaying. This was puzzling because I had recently migrated the site to a new server and had spent quite sometime testing the site.
To cut a long story short, the cause of the problem was two fold. Firstly, the missing images were huge. Resizing one of them solved the problem for that particular product. This led me to the cause of the second problem – the php memory limit on the new sever was 64M. Increasing the memory limit to 258M resulted in all the large images displaying properly.
Ideally I would resize all the large images but that will have to wait for another day.
So, make sure to check your php memory size if you encounter a similar situation of your Magento product images not being displayed.
One of the (many) things that often gets overlooked when a company puts a Magento website live are the Sales emails. These are the emails that get sent to customers after they have ordered – the New Order email, etc. You can tell if these have been overlooked by studying the opening hours – if it says, “Monday – Friday, 8am – 5pm PST” , then it’s probably using the stock template that comes with Magento (presumably PST refers to Pacific Standard Time, which is pretty meaningless to a European customer).
Within Magento there are 8 email templates that you should modify before going live. This is because these all contain the standard PST opening hours. These templates are New Order, New Invoice, New Shipment, New Credit Memo. I usually rename them with the store name (“Quirk” in this example) so that its easier to manage in a multi store setup. This means you can add different templates for different stores or websites.
Changing the default email templates is pretty simple. Within Magento backend, navigate to System/Transactional Emails. Click “Add New Template” and then from the Template dropdown, select one of the 8 templates you should modify (see above). For example, the first template I modify is the New Order template. By default I just change the opening hours and then wait until the client has done some test orders before broaching the subject of deciding what content and style would best suit their shop.
When you’ve modified the templates, you then have to assign them. Go to Configuration/Sales Emails and then select the appropriate email for each section. For example, here I’ve set the New Order emails to be the “Quirk New Order” for a registered customer and the “Quirk New Order for Guest” for guest checkout customers.
Setting the transactional email templates is not difficult or particularly time consuming. However, it’s an important part of presenting a professional and consistent image to your customers. Paying particular attention to the details here will pay dividends later on.
One of Magento’s great features is the multi-site & multi-store capabilities. If you’re new to Magento, this means that you can run more than one website from the same Magento installation. Having just added yet another website to a client’s Magento installation, I thought I’d jot the steps down as an aide-mémoire. So below I’m going to outline a checklist of the actions required to set up a mutli-website store in Magento.
For the purposes of the this example, assume I already have a Mage website eddiemay.me.uk and want to add another website eddie-may.com. Also assume that I’m selling to the same country with the same Tax & shipping rules, payment gateway, etc. Also assume that I’m going to be using the same template but use a different skin to make it look different.
NB: This example is for Magento Community Edition 220.127.116.11 – earlier editions had different ways of routing requests using .htaccess or index.php.
Buy a multi-domain SSL certificate. Make sure that new domain is associated with this certificate.
Point your new domain name at your server.
Log into Magento and do a backup – peace of mind, etc.
Set up a new root category & then add any sub categories as required. This root category is going to be ‘home’ of the new website.
Go to System/Manage Stores. Next, hit the Create Website button & fill in the necessary information – keep a note of the value you put in the “code” field. In my example I’m going to use “may” as the code value.
Repeat the steps for Create Store & Create Store View. When you create a store you set the root category to be the one you’ve just created in step 4 above.
Go to CMS/Pages and create a new home page & associate it with the new Website.
Now go to System/Configuration and change the ‘Current Configuration Scope’ to your new website. You’ll notice that the values are a copy of the default website. You’re now going to have to go through a number of tabs and change the required values. Here I’ll refer only to the essential changes.
Under System/Configuration/Web change the Secure & Unsecure urls to your new domain name – in this case eddie-may.com. Also under Default Pages set the CMS Home Page to the page you created in step 7. Under the Session Cookie Management tab, add your new domain as the Cookie Domain like so -> .eddie-may.com
In the Design tab you now have a choice of determining how the website will look. Here I’m going to assume that you’ll use the same template but use CSS to change the style of the site.
So, upload a new skin under the /skin/frontend/default. Lets assume the new skin is called eddiemay, that means you’ll have a folder like so /skin/frontend/default/eddiemay
If that’s the case, the design settings will be Package = default; Skin (Images/CSS) = eddiemay; Layout & Default will be the same values as your first website.
Still under the Design tab, change the HTML Head, Header, Footer, etc as required. From an SEO perspective, make sure that the Default Title & Description are unique.
Now go to Store Emails – you’ll need to change email addresses to reflect the new domain name. Make sure that these email accounts actually exist before going live.
Under Contacts change the main contact email as required.
Under Sales/Invoice & Packing Slip Design – change the default logos to your new logo.
Under Sales/Sales Emails – you may have to change the email templates if you’ve heavily customised your default email templates (you may have hardcoded your store name, for example).
That’s more or less it for the System/Configuration settings.
Now go to CMS section. Here you may have to create new CMS pages & Static Blocks, or at least associate existing ones with the new website. At a minimum you’ll need to associate the Contact, About, Privacy, Terms, Shipping pages with the new website.
The next thing you’ll need to do is add the new website to your .htaccess file. You need to add the new domain like so:
You’ll notice that I’ve used the code “may” – this was the value I entered in the new Website code field in step 5 above.
Upload the new .htaccess file.
Now test your new website – chances are that you’ll get an error. Downloading the error report will give a cryptic “SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘database-name.catalog_category_flat_store_3′” doesn’t exist – or something similar. If this happens, log into your Magento administration UI, go to System/Index Management & you’ll probably see that several indexes need re-indexing. Once complete, your website should now work as expected.
If all is good, its now time to add some products. You could copy products over from the original website but personally I’d create them from scratch or upload new ones. This is because you can then optimise their descriptions, etc., to avoid duplicate content penalties, etc.
Well, I think that covers all the bases. This will probably take you about 2 hours to complete, depending on the amount of customising of Email template, Static Blocks, etc. The CSS customisations are another thing altogether.
If I’ve left anything out, please let me know. Either way, I hope you find it useful.
I was recently onsite helping a Magento client do some things on her store. During the course of our conversation, she asked about exporting her sales records. She was stuck because the sales report was empty. The reason for this was because her sales statistics needed refreshing.
When you go to the sales reports at the top is a warning that you should refresh the last day’s statistics. Doing this is ok if you’ve kept on top of this particular task. If you’ve never updated your statistics before, then this won’t work – your sales stats will be empty or incomplete.
If this is the situation you find yourself in, then you should refresh the life time statistics. This can be done by going to the Refresh Statistics tab under Reports menu item.
This will load the Statistics tab. Select the Orders row, select the ‘Refresh Lifetime Statistics’ option and then submit. A dialog box will warn you that your site could become unresponsive – this is a danger if you’ve never refreshed these statistics before. For this reason, I suggest you only ever do one row at a time.
Once you have completed this task, go back to the Sales Report and run the orders report again. This time the stats should be reporting correctly.
If your sales reports are out of date (have not been refreshed) then this points to a problem with your Magento cron job. A cron job is a scheduled task that runs at a determined interval. Refreshing the sales and other reports is one of the things the Magento cron job does. Setting up the cron job is really important and is a topic I’ll address in the future.
Today visiting one of the Magento sites I look after returned the 503 Server error, with the message that the server was down for maintenance or was out of resources. This was true for both the front end and the admin area.
Looking in my error logs returned this error message:
client denied by server configuration: MAGENTO_DIR/app/etc/local.xml
Google returned several possible solutions. But then I remembered I’d been in the back end, using Magento Connect Manager to upload a language pack. This had failed for some reason. It then dawned on me that Magento puts the store (CE 18.104.22.168) into maintenance mode when performing updates, etc. So, its probable that Magento did not return the site to live mode after the upload failed.
A quick look in the root showed that a file called “maintenance.flag” was there. Renaming the file meant both front and backend were now working as expected.
On May 26th the UK implemented the EU Cookie Directive. Only hours before it became law did the Information Commissioner’s Office (ICO) clarify what website owners were expected to do about cookies!
After many scare stories about getting users to opt-in for almost every type of cookie, and of massive fines for non-compliance, this latest clarification essentially seems to say the following: we can assume “implied consent” for most “non tracking” cookies. That is, if you have a shopping cart or use Google Analytics, etc, you can cover yourself by having appropriate statements in your terms and conditions. This is how Amazon.co.uk appear to have handled the issue.
So, crisis over? Well, I’m not a lawyer, so your mileage may vary!
I’ve just started work on a search engine optimisation campaign for a new client. They have a Magento shop, that’s been running for just over two years, and they’re obviously looking to improve its performance.
Before I start such a campaign, I first take some time analysing the market, etc, but also looking at the website itself, particularly at the conversion process and conversion rates. Its a simple question really, why send extra visitors to a website if they’re not going to convert into customers once they’re there?
The first step then is to look at the site’s Google Analytics (you are using Google Analytics, right?). What was clear is that nearly a third of the shop’s buyers were being confronted with the Magento default “enable cookies” page when checking out. I found this out by looking at the Ecommerce Product Performance report & using the “Landing Page” Secondary Dimension filter.
This report shows what page the user was on immediately before they enter the checkout sales funnel. In this instance, an unacceptably large number (ie, greater than none!) were being told that they had to enable cookies in their browser and were then confronted with how to do so (“in Internet Explorer, go to Tools …..”, etc).
The cause of this issue was a poorly configured Magento shop – setting the correct cookie path & cookie domain is all that was required to overcome this issue.
This is a classic example of the need to thoroughly audit any web property before embarking upon a search engine optimisation campaign. There’s no point sending lots more traffic to a website that’s not optimised for conversion. Its also a good example of the worth of a good analytics software – without it we would not have known that so many users were being told to mess with their browser’s cookie settings.
Yesterday a Magento shop owner contacted me because his shop was returning a “500 Server Error” page. Their web designer was at a loss to figure out what was going on, so the owner turned to me.
One of the main reasons for this error are file/directory permissions errors, often encountered when installing or upgrading Magento. A quick check revealed that this wasn’t the issue.
Taking a look at the configuration, I noticed that logging was turned on. So I looked at the log files, & exception.log was over 2.5 gb in size. Just turning logging off was enough to remove the server error. So, it seems Magento couldn’t write to the file any longer because of its sheer size.
So there’s something to look out for if you encounter an puzzling 500 error. Quite why the exception file was so big is another question!