In comparison with most web platforms, Magento is big. Like, really big. The published user guide for the latest Enterprise version – 1.13 – is 545 pages long. It’s safe to say most site owners don’t read such a tome cover to cover, and it’s just as likely a bet that, if you maintain a Magento site, there are options hidden at your fingertips that you haven’t fully leveraged.
It’s not uncommon for a client to come to us with a site tweak they expect to have to pay for, and we’re instead able to show them how they can accomplish it themselves. That’s a satisfying conclusion. Sure, we love getting paying work, but when merchants discover how to get more value from Magento, that becomes a win for everyone!
So if you’re a merchant running Magento, did you know that you can . . .
Tweak Your Catalog Page Layouts
By default, when displaying a product with configurable attributes or custom options, a Magento product page places these elements beneath the top-most columns of product info, moving the Add to Cart button there as well:
This can work well for some product configurations, particularly when there are many such options. Quite often, however, you’ll want your options and “call to action” displayed more prominently above:
A developer will approach this modification ready to dive into layout code and templates. But in this case, “by default” means simply “the default value for a particular product attribute.” More specifically, nestled in the Design tab of every product edit page in Magento’s admin is an attribute called “Display Product Options In,” which defaults to the value “Block after Info Column.” Set it to “Product Info Column” instead, and you get exactly the layout shown in the second screenshot above. (This works as long as your site’s theme hasn’t been too heavily customized.)
This is a particularly dramatic example of a way to modify catalog page appearance from the admin; few settings have as significant an impact on a layout, but there are still other worthwhile ways of tailoring your catalog experience. The System Configuration area of the admin (System -> Configuration from the main menu) contains several. The Catalog section in this area contains a group of settings called Frontend, where you can modify details of your category pages like the number of products per page. The Layered Navigation settings in the same section contain an option for whether to show the count of matching products next to values in your filterable attributes.
For per-product or per-category customizations, every product and category edit page in the admin has a Design (or Custom Design) tab, where you can change the number of columns on the page or even apply an entirely different theme than the rest of the site. And for the adventurous, the same tab contains a Custom Layout Update field where Magento’s XML syntax can be inserted for more dramatic modifications. Learning a bit about this layout XML can be well worth it. (You’re also likely to find snippets for common layout needs with a little searching on the web.) Below is an example that will remove the product page’s mostly useless “Tags” section with a single line (though admittedly this is better suited for a layout file in your theme than being added to every product):
<remove name="product_tag_list" />
Change Standard Text with Translation
It’s easy to disregard translation as something relevant only to a site that supports multiple languages. But have you considered what a useful tool translation can be just to change one bit of text to another? Let’s say you run a site where the phrase “shopping bag” more closely represents your shop’s style than a “shopping cart.” Such text is buried in the site’s template code (likely in many places), but Magento’s translation features can come to the rescue.
Now, the admin does offer a method for configuring translations without touching any site files. It’s called Translate Inline, and it’s to be found in the Developer section of System Configuration. Be warned, however, that this system can be as unwieldy as it is ambitious. Enabling it turns your site into a point-and-click interface for finding the exact text you want to translate and simply typing in its replacement. (This makes it necessary to enter your IP address in the Developer Client Restrictions settings; don’t forget this step on a public site, or else anyone visiting your store will see the translation editing interface!)
By all means, try out Translate Inline for yourself. But if you find the system a bit fiddly for your tastes, know that it’s actually exceedingly straightforward to use Magento’s translation files for the same purpose. Doing so involves the use of a simple CSV file, with not a jot of development knowledge required. To implement a few instances of the “shopping bag” translation described above, I need only create a file called translate.csv with the following contents:
"Add to Cart","Add to Shopping Bag" "In Cart","In Shopping Bag" "My Cart","My Shopping Bag" "My Cart (%s item)","My Shopping Bag (%s item)" "My Cart (%s items)","My Shopping Bag (%s items)"
That’s it; two pieces of text on every line. The first is the text being translated, and the second is the translated text. Once I have my translate.csv file, I need only FTP it to app/design/frontend/{package}/{theme}/locale/{locale} on my site and clear the Magento cache. (“{locale}” in the preceding path refers to the standard ISO language/region code for your site’s locale. “en_US” would be the code for a typical US English site.)
There’s only one trick to this: Each line must consist of the exact chunk of text passed through Magento’s translator in a particular instance, no more or less. (This is why I cannot simply translate “Cart” to “Shopping Bag.”) So how do you know for sure the exact strings of text you need to deal with? Magento actually makes this very easy by providing an exhaustive set of primed translation files in app/locale/{locale}. Virtually (if not definitely) every snippet of text that’s used in the code can be found in these files. (The filenames provide a good clue about where to find text dealing with certain things, but a good filesystem search tool won’t go amiss.) You can actually edit the translations directly in these files, although the translate.csv file in your theme is generally a better way to go.
You may also be wondering about the “%s” snippet in a couple of my translate lines above. This is a token to be replaced by dynamic information (like the number of items in the cart), but the fact is that it’s not necessary to understand what it’s for. Just make sure your translated text includes the same tokens in the same order, and you’re good to go.
Customize Your Site Emails
All too frequently, a site’s emails don’t get the design love that the browser storefront does. The emails your customers receive when registering for accounts or placing orders are often an afterthought if they’re thought of at all. But emails are an extension of your site’s branding, and a sharp, well thought out design is important to ensure your customers easily absorb the relevant details at a glance.
This one does require some knowledge of HTML to format really good looking emails. Apart from that, while the makeup of Magento’s email templates can be a bit technical, the platform does a great job of setting you up for easy customization. Head to System -> Transactional Emails from the admin main nav and add a new template to see for yourself.
While you’re initially presented with a blank slate, the interface actually requires you to choose a default system template on which to base yours. Choose from the list in the Template dropdown and then Load Template, and the subject and main content fields will immediately be pre-populated with the default code for that email, including all of the needed tokens for dynamic information. If I choose “New Order for Guest,” for example, I’ll already have tokens like “{{var order.increment_id}}” (which outputs the order number in this particular template) to work with in the default content. As long as you leave these tokens in place, you can modify the text and HTML around them to your heart’s content.
In fact, go on and delete those tokens if you like. You can always get them back later, and you won’t even have to load up a new template from scratch to do it. The “Insert Variable…” button immediately above the content field provides a one-click interface for dropping in this kind of info. It contains all the tokens that were defined for the particular template, and some general purpose store information variables too.
There’s one easily missed final step. Once you’ve finished and saved your new transactional email, all you’ve got is a template sitting in the system doing nothing. Sure, you based it on a system template with a particular purpose, but considering that you can create a dozen templates based on “New Order for Guest” if you please, how do you tell Magento which one you actually want to be used?
This is handled in a different area of the admin, which is what may initially trip you up. In fact, the appropriate settings are somewhat scattered around, but all within the System Configuration interface. If you navigate there and take a look at the Sales Emails section, you’ll find the right options for specifying all the major sales related email templates. For the example we’ve been following, look for “New Order Confirmation Template for Guest” under the Order group of settings. The corresponding drop-down lets you choose from any of the transactional email templates you’ve created in the admin.
Some of the more obscure automated emails may take some more digging to find the appropriate place to assign your template, but if you scour the System Configuration sections related to the appropriate features, you should find what you’re looking for. (The Customer Configuration section contains some more of the most common.)
Track Admin Activity
Apologies to merchants on Magento Open Source Edition, but this one is a Magento CommerceE only feature.
However careful a process you may have for managing your site’s configuration and content, problems are going to occur sometimes. And far be it from me to suggest that when they do, you’ll want to find someone to blame! Nevertheless, knowing exactly what has changed between the time your site was running beautifully and the moment the home page layout blew up is probably going to be the best way to fix things fast. Especially when you have a team of multiple people managing your store, the Admin Actions Log can be a valuable tool.
To view a record of activity, navigate to System -> Admin Actions Log -> Report. The resulting list shows the date/time and username for every action taken in the admin. Take special note that all actions are logged here, not just changes; just navigating the admin and viewing settings and content will be tracked, so note the Action column for the specific type. The Action Group column details what admin area was involved, and the Full Action Name and Short Details Columns contain further detail (such as the ID of a product that was viewed or edited).
When you view a particular log, the results can be a bit cryptic, but helpful nevertheless. Here’s what one log looked like after I edited a product’s details:
Note that price is the only attribute the system bothered to record a “Value Before Change” for, indicating this is the attribute I modified. You won’t always find the information quite as detailed (a System Configuration change, for instance, seems to record no information about which values changed), but the Admin Actions Log puts you in a much better position to track down offending changes than you’d be in without it.
If you’re already using these tools, pat yourself on the back! And then spend some time poking around the Magento admin to discover what useful settings you haven’t found yet.