The new kid on the PHP e-commerce block, Magento, has gotten a good amount of attention leading up to and since its initial release. Earlier this year, I was entasked with doing an analysis of its features and thought it might make for an interesting series of blog posts. What you see here is the result. Comments are welcome, thanks in advance for your contribution.
The new kid on the PHP e-commerce block, Magento, has gotten a good amount of attention leading up to and since its initial release. I was recently entasked with doing an analysis of its features and thought it might make for an interesting series of blog posts. This first one will cover the Analytics and Reporting feature set.
If you're not familiar with Magento, this series won't assume much prior knowledge. If you need to get familiar with Magento, this series might help you, but I recommend checking out the Resources area of the main web site, the Guide to Programming with Magento book available from php|architect, or their official Magento training course.
Some time after the initial release, Varien began offering an Enterprise Edition of Magento. One of the differences between the Community and Enterprise editions is that certain features are limited to the latter. Generally, a company that takes this approach will limit paid-only features to those that have high value, but are also supplemental in nature. Ubuntu, Zend, and MySQL are good examples of such companies.
In the case of Analytics and Reporting, this restriction applies to logging of administrator actions. I don't understand what the reasoning behind this could be. Whether security is the feature's primary intended application or not, it can be used for that purpose. Security is a very real, very serious concern, and users should have tools available to them for monitoring their storefront activity.
As best I can tell, this only amounts to a small section of the administrative configuration area that handles inserting the appropriate JavaScript include with your account identifier into your front-end markup. "Integration" seems a somewhat embellished term for this.
Shortly after the last Magento release (1.3.1 on 4/17/09 as of this writing), the Google Analytics API was announced on 4/21/09. The API offers an opportunity to facilitate tighter integration and provide a more tailored user experience, an opportunity that I hope Magento takes in a future release. That would actually make this a much better contender for the Enterprise Edition only feature in this section than administrator action logging.
The purpose of a dashboard is to provide summary information or quick access to features. The emphasis here is on the frequency of access. The contents of the Magento dashboard are mostly statistics that seem to lack a purpose, particularly for larger store fronts with high order throughput. It comes across as an area that, at the time of its design, everyone felt should exist, but no one knew what to put in it.
Magento's dashboard also offers no visible configurability a la Wordpress 2.7. The ability to choose and position modules maximizes the dashboard's ability to perform its intended function. While WordPress has certainly had its issues and growing pains in the past, I think most of its userbase would agree that its usability has only gotten better in the past few releases. I think a similar transformation is needed for this area of Magento to maximize its potential.
New Orders, New Reviews, and New Tags all have RSS feeds available. I'm unsure of how these are useful. People who want to monitor any of these events would most likely rather check them via their respective sections of the Magento administration area for new activity or receive e-mail notifications.
Reviews and Tags aren't currently included in the dashboard, which seems a natural place to put them since "Last 5 Orders" is already there. They also seem unlikely to remain useful for larger storefronts with higher throughput and simply add clutter to the interface.
This is a collective name I've chosen for a group of reports that deal mainly with incoming and outgoing funds. These include the Tax, Best Viewed Products, Best Purchased Products, Coupon Usage, Total Sales Invoiced, Total Sales Refunded, and Best Customers reports. They all share a fairly uniform interface, which is good for usability. Once you've learned how one report works, you pretty much know them all.
The table-based layout of report results isn't the most easily read thing in the world, however, and could do with a graphical equivalent to make it easier to view aggregated data at a glance. Think Google Analytics. Beyond that, a few more options in the existing features would be nice. A Week option in the Increment menu and a PDF option in the Export menu are good examples of this.
I refer to another set of reports by this name because they facilitate improvement of a storefront's user experience in some way.
The Tags report seems fairly functional and allows browsing of tags by product or originating customer. Aside from lacking the Increment menu and its associated suggested improvement, it shares the Sales report's areas of functionality that could be improved.
The Abandoned Shopping Cart report offers the ability to search by specific customer, which doesn't seem particularly useful. What might be more useful is the ability to search by specific product or to get a specific list of products in the cart at the time of abandonment.
The Low Stock report also shares the Sales report's faults. Having it report on trends (e.g. Product X goes out of stock approximately every Y days) might be useful. The report offers an RSS feed, but the earlier comment made about those also applies here.
The Search Terms report seems to be organized like its equivalent on Google Analytics, which limits its usefulness. Functioning more like the tags interface in del.icio.us might make it more effective, so that it's easier to navigate between search terms and find relationships between them.
The Product Reviews report aggregates product review counts and rating averages. Oddly, it uses only a percentile for the latter while a 5-star system is used when reviews are submitted, which proves a somewhat annoying inconsistency.
Out of the box, Magento certainly offers a feature set equivalent or superior to its competitors. However, I have uncertainties about the value of some features and the design decisions behind the current incarnations of others.
At this point, I think Magento has 80% of the users covered as per the Pareto principle. Focus should be placed on improving the corresponding 20% of features to add polish to the overall user experience.
This post is the second part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the product browsing features.
Each product has a designated Base Image. Using the default theme, a small section entitled More Views appears beneath that image with smaller thumbnails of that image and other images. Clicking on any of these opens a simple pop-up window that allows for navigation of all the images.
Unless the Exclude option (which is disabled by default) is enabled for that image, a thumbnail of the Base Image appears in the More Views section. This seems a bit redundant because the same pop-up window is already accessible by clicking on the Base Image itself. Use of a pop-up window also seems odd when libraries like Lightbox and Lightview both provide a more robust and fluid experience.
The Base Image for a product is limited in size when it is initially displayed. This feature positions a slider below the image and allows the user to zoom in on specific areas and drag within the image to navigate the larger version. You can get a better look at this feature by viewing any of the products on the Community Edition demo site.
It's fairly well-implemented and intuitive and I think it brings a touch of the real-life brick-and-mortar store experience to the online storefront. My only criticism is that it activates for images that gain very little from the zoom-in capability, which evokes a mental response questioning why it's activated at all. Some sort of threshold should be added.
Customers can submit product reviews including product ratings. Ratings use a 5-star system and specific traits that receive ratings (Price, Quality, and Value by default) can be managed on a per-store basis. Once submitted, a review goes into a queue pending review and approval. Aside from the Product, Customer, and Summary Rating, all other aspects of reviews can be modified by administrators.
As the previous post mentions, the display of rating quantities is not consistent between the front-facing web site and Admin area. Another annoyance is that the relevant User Guide section doesn't mention this feature being disabled by default, nor how to enable it. From the Admin area, go to System - Configuration - Catalog - Catalog - Product Reviews and set the "Allow guests to write reviews" setting to "Yes."
Overall, product reviews does not seem like a feature that would be commonly needed among all storefronts. As such, it seems a better candidate for a module than a core feature.
In the default theme, this feature shows up on the front-facing web site as a section of the right column. It includes short listings for products related to the main product being viewed. Related products are specified individually when editing that product from the Admin area.
This area functions a bit oddly, at least with the default templates and settings. Each related product normally has a checkbox next to it for adding the product to the shopping cart. If a related product is out of stock, that checkbox will not be displayed. As such, if all related products are out of stock, no checkboxes appear. In the default theme, instructions regarding the checkboxes are always displayed even when there aren't any visible. This case renders the feature somewhat confusing from a usability standpoint.
Another point of the confusion is that the form for adding related products to the shopping cart uses the Add to Cart button in the central product area. The use of space appears to disconnect that button from the form, making it unintuitive.
This feature isn't a bad one, but its implementation could easily be more intuitive.
This is managed from the Inventory area of the form used to edit products. Related configuration settings automatically inherit from a global configuration, but can be customized on a per-store basis.
The user guide section for this feature appears to be a bit dated judging from the user interface screenshot there. Nevertheless, this area is fairly robust and offers a number of useful features. These include setting bounds on the quantity a product that may be put into an individual shopping cart, the quantity at or below which the product will be labeled as being out of stock, allowance of decimal quantities, allowance of backorders, and stock quantity-based notifications (presumably in the Admin area or via e-mail).
Magento will manage stock automatically by default, decreasing available stock as orders are submitted. This can be disabled to allow you to handle stock manually if needed. One aspect of this feature that I find to be curious is that the out of stock status can be set manually even when Magento is set to handle stock automatically. I'm guessing this is an emergency button of sorts, but unsure as to what other purpose it might serve.
Another interesting aspect is that Grouped Products don't have stock management capabilities because they are handled normally at the individual product level. I'm curious as to whether this detail of the implementation has precluded its use in any way.
A screencast was done on this topic. It essentially functions like Related Products, but appears to exclude the option to add products to the shopping cart (at least in the default theme) and is intended to make "upgrades" from the current product more eye-catching.
The presence of the Related Products feature seems to make Upsells redundant. A more useful implementation might exist within Related Products where they could be tagged and retrieved by tag from product pages. This would add flexibility and freedom to the feature by allowing users to create any number of product groupings for any purpose, not merely those related to these two particular applications.
The relevant user guide section for this feature appears to be outdated, grossly oversimplified, or both.
The feature is accessed from the Custom Options section of the form for editing products. Its purpose is to allow administrators to add custom price-affecting options to products (such as size for shirts) and to allow customers to select those options before adding products with them to the shopping cart.
Overlooking the lack of documentation, the implementation of the feature itself appears to be logical and well-organized.
This allows Simple Products that don't have required custom options to be listed on a Grouped Product profile page with the ability to be added to the shopping cart individually. There's a screencast on how to use this.
In terms of being an item on the feature list, this is merely a more explicit mention of one the Grouped Product product type's features. The purpose of this is to make related products easy to purchase simultaneously. To that end, it's fairly effective.
Customers can maintain a wishlist of products as part of their accounts, similar to Amazon feature by the same name. This feature doesn't seem to be one that would be useful to all industries. Wedding rings might be an example of a bad use case for it. As such, it would be better implemented as a module rather than part of the core.
This feature is fairly self-explanatory. Though it's good in terms of security, in practice it's a bit unintuitive that the feature is disabled for guest users (i.e. users that are not logged into a customer account) by default. To enable it, go to the Admin area and navigate to System - Configuration - Catalog - Email to a Friend, expand Email templates (a rather odd place to put this in my opinion), and change the "Allow for Guests" setting to "Yes."
The number of recipients per transmission can also be limited from this area, as can the number of transmissions allowed per hour (both to prevent abuse by spammers) and the method of restriction (the "IP Address&Quot; option being the safest and the default).
Some of the features shown here are more appropriate for modules. Modifying them to be so could help to lighten the core installation somewhat.
A few others lack intuitiveness or flexibility, but nothing that couldn't be fixed with some reworking or a little polish. Several could be addressed simply by improving related documentation, either with notifications in Magento itself or in related sections of the User Guide. It's discouraging to see that features often lack a Help page on the Magento web site.
The overall feature set is pretty complete for most storefronts. Beyond fixing issues, the Magento platform could benefit significantly -- and quickly -- by improving the quality of their existing features.
This post is the third part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the catalog browsing features.
Some of the features in this area are restricted to the Enterprise Edition of Magento. As such, reviewing them required accessing the demo for that edition on the Magento web site. This requires filling out a registration form of sorts to receive an e-mail with the credentials needed to access the demo site. The e-mail content is not entirely explicit about the fact that the two sets of credentials provided for the admin area are listed in order for HTTP authentication followed by the authentication for the Magento admin area itself. This all adds up to a rather annoying experience.
By its description, this appears to be a more developed version of the Advanced Pricing Rules and support for Special Prices feature of Catalog Management (which will be covered in a later post in this series) limited to the Enterprise Edition of Magento.
There are two obvious differences between the implementation of this feature in the Community and Enterprise editions. First, the Enterprise Edition includes the ability to send invitations. This is accessed via Customers - Manage Invitations in the admin area and is essentially just a form-to-e-mail that allows the administrator to specify the store from which the e-mail is intended to originate and a specific customer group to which the recipient list should be limited.
The second difference between the two editions with respect to the Private Sales feature is the related inability to restrict access to category by customer group. This is done by going to Catalog - Manage Categories, selecting a category to edit, going to the Category Permissions tab, and clicking the New Permission button.
Permissions can be assigned by store and customer group and include the ability to limit browsing the category, viewing product prices on the category page, and adding products on the category page to the shopping cart. These combined with tier pricing for specific customer groups provide a fairly flexible feature set.
The only caveat appears to be that permissions can't be applied to an entire subtree of the category hierarchy; instead, they have to be applied manually to each category. I haven't been able to find much documentation on the feature to confirm to deny this. It's likely possible to automate the process, through a stand-alone script or module, but not having that capability within the native interface does seem like a large limitation of the feature.
This feature has a corresponding screencast and wiki entry. If you've browsed online storefronts like Amazon by category before, you're likely already familiar with this feature. While browsing by category, a left sidebar is presented that includes various criteria about the results by which you can further filter results.
It appears that filtering is limited to category, price range, and custom attributes. So, for example, products within a category cannot be filtered based on whether they're in stock or by the presence of a particular tag.
On a semi-related note, subcategories of the root category are expected to be displayed in the main navigation once they're created and enabled. However, they won't be until the default store record is edited and saved, a small and rather unintuitive caveat. This forum thread goes into more detail about that issue.
Intuitively, this feature is the same as the similarly named feature for categories, except that it applies to search results rather than product listings for a specific category.
One quirk specific to the feature's implementation for search results is that, by default, price range is not included as an option by which results can be filtered. Some searching turned up this forum thread, which details how to modify Magento's configuration to enable price filtering for search results.
A tutorial exists for this feature. I'll sum it up here. From the Magento admin area go to CMS - Static Blocks to create a block. After that, go to Catalog - Manage Categories and select a category to edit. From there, select the Design Settings tab. For Display Mode, select one of the two static block options. For CMS Block, select the block to display for that category.
While having the ability to limit the category page to a static block is nice, I think its use should be discouraged more often than not. From the viewpoint of an end-user, having to go through a static page to get to a product listing for a category seems like one click too many.
Additionally, it seems like the category form controls for this could be more intuitive. Instead of having a Display Mode menu that controls the presence of both a block and a product listing, it might be simpler to limit that menu's responsibility to toggling only the product listing and adding an option for displaying no block to the CMS Block menu.
I did a fair bit of digging, but found very little information on exactly how to use this feature.
From the Magento admin area, if you want a product-specific design, go to Catalog - Manage Products, opt to add or edit a product, and select the Design tab from the listing under the Product Information column on the left.
For categories, go to Catalog - Manage Categories, opt to add or edit a category, select the Custom Design tab, and find the Custom Design menu within that tab.
System - Design may be of some relation, which allows you to automate the modification of the current design within a given date range.
There's a blog post on this feature, as well as its section in the user guide. To access it, go to Catalog - Search in the Magento admin area.
Overall, the design and implementation of this feature make sense given that statistics are tracked independently for synonym usage. It offers an interface fairly consistent with that of the Reports - Search Terms area.
This feature comes in the form of a column in the default design of the user-facing web site. Products previously viewed by the user will be listed in the column with links to return to their respective product pages. This is certainly a useful feature to the end user, but that aside it isn't really much to write home about.
More information is available about this feature in this screencast. To summarize it, go to Catalog - Attributes - Manage Attributes. You'll notice in the attribute listing that there's a Comparable column by which you can filter. You can find that column's corresponding field under Properties - Frontend Properties when adding or editing an attribute.
The purpose of the feature is to allow for the inclusion of specified attributes when users perform product comparisons. This feature's design seems fairly sensible and full-featured for its intended function.
This is similar in function to Recently Viewed Products except that the products it lists correspond to those that the user has selected for product comparison. Listing this as a feature apart from Product Comparisons seems like an embellishment since the functionality is inherent to how product comparisons work. That is, a user views multiple product pages and opts to compare them. If that user wants to compare more than two products, that requires maintaining a running list of the products selected for comparison somewhere in the interface.
There's a screencast on up-sells. To access these features, go to Catalog - Manage Products in the Magento admin area, opt to add or edit a product, and seect one of the Up-sells, Cross-sells, or Related Products tabs.
Up-sells are better and generally more expensive products of the same type, such as a digital camera with a higher megapixel rating, that are displayed on a product page. Related products are complementary products, such as a storage card for a digital camera, that are also displayed on the product page. Cross-sells are similar to related products, but are displayed on the shopping cart page rather than the product page.
Having related products and cross-sells exist as separate entities seems to be a point of redundancy. It might make more sense to consolidate them and offer a configuration option to specify the areas in which any given record should appear.
A user guide section is available for this feature. When it's enabled via System - Configuration - Catalog - Catalog - Search Engine Optimizations - Popular search terms, a link is added to the site footer that leads to a separate page with the search term tag cloud. The effectiveness of the feature is a point of dispute.
This only appears to be available by following a tag link from a product page. It doesn't seem to allow for filtering by multiple related tags and isn't integrated into the functionality to filter products via their other attributes. The implementation is also lacking in terms of SEO, as it uses numeric tag identifiers in URLs rather than the text of the tag itself.
These are what they sound like: customer-submitted reviews of products. To access them in the Magento admin area, go to Catalog - Reviews and Ratings - Customer Reviews - Pending or All Reviews. One usability issue with this feature on the end-user side is that product reviews aren't displayed on product pages when they're first accessed, at least not in the default theme. A link near the top of the product page must be clicked before the reviews will show up.
On the admin side, while the interfaces for the Pending and All Reviews areas are similar, each lacks a key feature of the other. In the case of Pending Reviews, the button to add a new review is not present. In the case of All Reviews, a menu to perform operations like changing the status of or deleting multiple reviews and the accompanying convenience methods of selecting or unselecting visible product search results not present.
Categories, searches, and tag filtering on the front-facing web site all use this. The setting of which format to use, grid or list, persists once set via the user's session. Its implementation isn't very RESTful as it uses GET to establish this new setting rather than POST, the former being intended for read-only operations with regard to affecting the content of resources.
These are displayed on the front-facing web site just under the main navigation and are used to denote location within category hierarchies as well as searches. Oddly, no breadcrumb is shown when browsing by tag.
I encountered three issues while writing this blog post that are worth mentioning.
First, while installing a copy of Magento to explore the feature set described in this blog post, I got stuck on the database configuration screen. I would submit the form, but the installer would redirect me back to the same screen just as it had been before I entered anything into the form. Some searching seems to point to a bug involving cookies not being set when the hostname of the installation doesn't contain a period (i.e. localhost).
The second issue happened while I was attempting to register a customer account in order to tag a product. After filling out the form to create a new account, I received the error "Can't save customer". There are two forum threads on this issue, though both seem to suggest that the presence of the Mailchimp module is required to replicate the issue. One suggested fix involving adding missing validation-related files from Zend Framework appears to be confirmed by the error message I receive when I attempt to retrieve the password for a customer account with a .com e-mail address, which is shown below. Note that this is a fresh installation of Magento 1.3.2.2 with no existing customer accounts.
Warning: call_user_func(Zend_Validate_Hostname_Com::getCharacters)
[function.call-user-func]: First argument is expected to be a valid callback
in /var/www/magento/lib/Zend/Validate/Hostname.php on line 329 Trace: #0 [internal function]: mageCoreErrorHandler(2, 'call_user_func(...', '/var/www/magent...', 329, Array) #1 /var/www/magento/lib/Zend/Validate/Hostname.php(329): call_user_func(Array) #2 /var/www/magento/lib/Zend/Validate/EmailAddress.php(184):
Zend_Validate_Hostname->isValid('blueparabola.co...') #3 /var/www/magento/lib/Zend/Validate.php(157): Zend_Validate_EmailAddress->isValid('matthew@bluepar...') #4 /var/www/magento/app/code/core/Mage/Customer/controllers/AccountController.php(435):
Zend_Validate::is('matthew@bluepar...', 'EmailAddress') #5 /var/www/magento/app/code/core/Mage/Core/Controller/Varien/Action.php(376):
Mage_Customer_AccountController->forgotPasswordPostAction() #6 /var/www/magento/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(248):
Mage_Core_Controller_Varien_Action->dispatch('forgotpasswordp...') #7 /var/www/magento/app/code/core/Mage/Core/Controller/Varien/Front.php(158):
Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http)) #8 /var/www/magento/app/Mage.php(459): Mage_Core_Controller_Varien_Front->dispatch() #9 /var/www/magento/index.php(65): Mage::run() #10 {main}
Finally, the last I encountered came about when I was attempting to test features requiring the existence of a product. Even if all required fields for a new product are filled out and the product is saved, that product will not show up anywhere on the front-facing web site unless it is assigned to at least one category, even if it's the default category. Without any warning to indicate this, it's a fairly annoying and unintuitive quirk.
Aside from these related issues, this area of Magento has an overall evaluation much like my previous blog post in this series. Category browsing is fairly feature-complete and implemented well overall in Magento. However, a small assortment of behavioral oddities, usability issues, and lack of organized documentation need to be addressed.
This post is the fourth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the catalog management features.
This feature was covered in the previous post in this series and is simply restated in this feature set section because it pertains to both catalog browsing and catalog management. The post on the former described it in a fair amount of detail, so there's no need to restate it all here. Enough said.
This feature implements global settings for minimum and maximum allowed product quantities in the shopping cart and minimum stock quantity at which products move from in-stock to out-of-stock. It also includes automated inventory management (i.e. product stock decreases appropriately as orders are placed) and a global setting option to allow backorders of out-of-stock products. There's a corresponding section in the user guide on this.
To access global inventory options from the Magento admin area, go to System - Configuration, click the Inventory tab under the Catalog section on the left, and collapse the Product Stock Options section of that page. To access inventory options for an individual product, go to Catalog - Manage Products, opt to add or edit a product, and click the Inventory tab on the left.
There's a wiki article that covers the basics of this feature. It's accessible via System - Import/Export - Profiles. Profiles are a combination of PHP components and XML configuration that instruct Magento on how to import or export data in a particular format. Magento ships with profiles to import and export products, product stock quantities, and customers.
Sadly, the internals of this feature have little to no documentation, which make it difficult to supplement the native profiles with custom ones. One use case that users have had to puzzle through is importing products with multiple images. Another is importing categories and category-product associations, which took some rather extensive finagling.
There have also been issues with the scalability of this feature for larger stores, to which the only solution seems to be investing in the Enterprise Edition to get official support from Varien.
A blog post and user guide section accompany this feature. To access it, go to Catalog - Manage Products, check off multiple products in the left-most column of the grid, then in the top-right corner of the grid select either the Change status or Update attributes option from the Actions drop-down menu and click the Submit button next to it. This will cause the form for editing products to be displayed, except that it is restricted to relevant sections and fields common to all selected products and will update those products upon submission.
A video is available for this feature.
To summarize the video, go to System - Configuration in the Magento admin area, select the Google API tab from the Sales section in the left-hand navigation, and collapse and fill out the Google Base section of that page. Be sure to enable the Update Google Base item when product is updated setting to Yes. Hit the Save Config button to save your changes.
After that, go to Catalog - Google Base - Manage Attributes and click the Add Attribute Mapping button to add a mapping between an existing Magento attribute set and a Google Base item type. Finally, go to Catalog - Google Base - Manage Items, search for and check items in the bottom section, select the Add to Google Base action in that grid, and hit the Submit button. From that point on, the top table can be used to publish changes, delete or hide products, or synchronize products with the data in Google Base.
I can't say that I've ever met a developer who's used Google Base before, nor have I heard that it has a significant userbase. As such, this seems to be an edge case feature to me. In and of itself, the feature has proven to have limitations in the quantity of data that it's capable of handling as well as synchronization issues for even small numbers of products.
The user guide describes these in more detail, but I'll summarize it here.
Aside from the lack of documentation on bundled products, the types listed here and in the sections of this blog post to follow appear to cover most use cases for product implementations. To create a product of any of these types, go to Catalog - Manage Products, click the Add Product button, and select the type of product you want to create from the Product Type drop-down menu in the form that appears.
Added in Magento 1.1 along side bundled products, virtual products are what they sound like: products that are not tangible and require no shipping or stock management. These also aren't documented in the user guide, but are explained in some detail in this forum thread. Services like an online training course are a good example of a virtual product.
Again, these are just what they sound like. They're very much like virtual products, except that the digital assets for sale are made available for download following the purchase. This feature was added in Magento 1.2 and is accompanied by a wiki article and a segment in a You Ask, We Answer Q&A video done by the Magento team at Varien.
Added in Magento 1.1.1, this feature allows custom options to be added to products to personalize it for the customer, such as text for embroidery or monogramming. This blog post describes the feature and links to a video that showcases it. The name of this feature appears to be used inconsistently between the feature list and the user interface. The file upload option type included in this feature appears to have been added after its inception judging from the video.
The user guide has a section on using this feature, though it appears to be out of date as the current version of Magento does not include multiple rate fields on the form to add a new tax rule. Tax rates can be set by location, customer group, and product type by going to Manage Tax Zones and Rates, Customer Tax Rates, and Product Tax Rates respectively under the Sales - Tax menu in the Magento admin area.
These are fundamental to how Magento works and are part of its EAV implementation (an approach that I've disputed in the past). Appropriately, there's a fair bit of documentation on this feature: a wiki article, a screencast, and of course a user guide section. Products are assigned an attribute set when they're created, which cannot be changed later. Attribute sets are intended to provide a grouping for products representative of their type to allow changes to be made easily across that group.
To make use of this, you'll need to create some attributes first. To do that, go to Catalog - Attributes - Manage Attributes and click the Add New Attribute button. Fill out the form that appears, submit, and rinse and repeat until you have all the attributes you want to include in the set. When that's done, go to Catalog - Attributes - Manage Attribute Sets - Add New Set to select the attributes to include in the set and assign it a name. Once you've submitted that form, the set should become an available option in the Attribute Set drop-down menu that's included in the first screen of the product creation form.
This specific feature doesn't appear to be documented anywhere. My only guess is that it refers to two particular capabilities of Magento's attribute implementation, albeit in an unintuitive manner. One of these capabilities involves scope of an attribute, which can be global, per web site, or per store. The user guide section on attributes covers this in more detail. The other capability is adding an attribute to an existing attribute set and having that attribute propagate to products that are assigned that attribute set, hence the "on the fly" description. (Does anybody else hate that phrase? Comes off like a buzzword to me.)
This feature appears to refer to the Images tab of the form for editing products (Catalog - Manage Products), which includes automatic image resizing. Watermarking of product images is also supported and the end of the Images subsection of the user guide section on creating a simple product touches on this briefly. This screencast covers it in a bit more depth with some visuals and this blog post reviews the process using a concise textual description. It seems a stretch to call this feature a media manager, as the only type of media that's supported is images. Video and audio are possible additions that might make use of this title seem more warranted.
See the Catalog Price Rules or Shopping Cart Price Rules sections of this user guide chapter or this wiki article on Shopping Cart Price Rules for more information. To access this feature, go to the Promotions menu in the Magento admin area and select either of the Catalog Price Rules or Shopping Cart Price Rules options. From either area, click the Add New Rule button.
The interfaces used for these appear very similar, but the available conditions and modifications to pricing are specific to the catalog or shopping cart. Options are included that allow for short-circuit evaluation in rule processing and free shipping as well as price-based discounts (fixed and percentage) and quantity-based discounts.
It proved rather difficult to search for this feature as most results that came up had to do with URL rewriting, which is a different matter entirely. The feature does, however, include a user guide section that turned up after a bit of searching. To access the feature, go to Catalog - Search in the Magento admin area, then opt to add or edit a search term. The Synonym For field allows for specification of a search term alias such that, if a user searches for the synonym, the results for the original term will be displayed. The Redirect URL field causes a user searching for the term to be redirected to the given URL, which can be hosted on a completely different domain.
The user guide has a section on this feature. Users can submit tags for a product which can then be approved by an administrator in order to appear on that product's page on the front-facing web site. To administrate tag submissions, go to Catalog - Tags - Pending Tags. The All Tags option under the menu also allows for the addition or modification of tags.
These are what they sound like: customer-submitted product reviews. See the user guide section for this feature. It can be accessed in Catalog - Reviews and Ratings - Customer Reviews - Pending Reviews or All Reviews. Reviews were covered in the previous post in this series.
This is one of the few areas of information where an RSS feed actually makes sense as a data format, since receiving an e-mail every time a low stock notification is generated for a product would likely become annoying very quickly. To access this feature, go to Catalog - Manage Products and click on the Notify Low Stock RSS link denoted by an RSS icon.
Some features mentioned in this post were merely restatements of features already described in the post on Catalog Browsing offerings, seemingly included merely because there are corresponding administrative areas to their counterparts on the front-facing web site. Others, like the various product types and attribute sets, are at the core of how Magento operates. Still others, like batch product updates and advanced pricing rules, are fairly impressive in their capabilities. Standard bases like variations in tax rules and inventory management are well-covered.
Several, like the batch import/export and several newer product types, are sorely lacking in documentation, which seems to be a persistent thorn in the side of developers using Magento. Some features like the batch import/export and Google Base integration have a record of performance issues, another concern often raised with Magento. While it does seem like the newer product types indicate that Varien is receptive to its target market, the lack of more than one response from a Varien representative to the forum threads cited in this post cast an equal amount of doubt on that assertion.
This post is the fifth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the customer accounts features.
Once a customer has registered and logged in, they are presented with a dashboard screen that is also accessible from /customer/account/ under the base Magento path or by clicking the My Account link in the default theme. Most features discussed here are made available from the navigation on this dashboard page, located in the column labeled MY ACCOUNT on the left-hand side.
To compile portions of the feature evaluation below, I used the Enterprise Edition demo which requires registration.
In order to review this feature, I first had to place an order. As part of this process, I registered a new customer account in order to be able to view the customer dashboard. An annoyance I encountered during this process was that upon completing the order, I attempted to go to the dashboard via the My Account link and was prompted to log in. I've already verified my identity, so requiring this seems needless.
A table for the order history is prominently placed at the top of the Account Dashboard page on the left-hand side. The same table is also accessible via the My Orders page linked to from the same navigation area. It contains the order number, date, total, status, and shipping recipient if applicable (it's left blank for virtual and downloadable products) and provides a link per order to view all information for that order.
In addition to the link to view order information, a Re-order link is also provided. This link will add the contents of the selected order to the shopping cart (without removing any existing items in the cart) and direct the customer to the shopping cart page to reflect this effect.
This feature comes in the form of a block that displays individual products recently ordered by a given customer. You can find it at the bottom of the left column in the My Account area as well as the bottom of the right column on category pages in the demo store. Oddly, even though the label for the block is pluralized, it only ever seems to show the single last product purchased.
Downloadable products function similarly to virtual products in that neither shipping nor inventory apply to them. Unlike virtual products, however, they offer a downloadable asset following the purchase. These are available via the My Downloadable Products page. Products can have a limited or unlimited number of downloads per purchase, be locally or remotely hosted, and optionally offer a separate limited sample version.
Sadly, the only documentation on this feature is this wiki article, which isn't as comprehensive as it could be. It doesn't cover some options specific to the downloadable product type, like shareability and separately purchasable links, and no user guide page currently exists as of this writing to fill in those gaps. Odd, considering this is not a recent feature addition.
Available from the Address Book page, this feature lists existing addresses for the current customer and allows customers to enter new addresses. In the checkout process, the customer can select an existing address from a drop-down menu or opt to create a new address within the checkout page using a form identical to the one used by the Address Book page.
Addresses can be selected from the Address Book to serve as the default billing and shipping addresses. This is controlled using checkboxes at the bottom of the form to add and edit addresses.
The user guide covers this feature. When displayed in a category listing and the like, products include an option to be added to a wishlist for the current customer. In the demo store, this wishlist area provides a listing of products currently on the wishlist including the name, price, default photo, link to the product description page, the date it was added to the wishlist, and an optional comment entered by the customer. Products can be added to the shopping cart from the wishlist, individually or all at once. A feature similar to the Last Ordered Products exists for the last product added to the wishlist in a block that appears in the right column of the product description page in the demo store.
Noticeably absent facets of this feature include multiple wishlists per account, quick access to a direct wishlist link, and prioritization of products in the wishlist, features that are normally available on systems such as Amazon.
From the My Wishlist page, a SHARE WISHLIST button leads to a form-to-e-mail intended for sharing wishlists with one or more e-mail addresses. The sharing feature didn't appear to actually work on the demo store, as I never received the e-mails. Oddly, it also doesn't appear to have validation to catch the same address being entered multiple times or a visible cap to prevent the form from being used for spam.
The source code appears to indicate that Magento will only use the sendmail transport for e-mail on Linux, which means you're forced to hack the core if you want e-mail functionality if you don't have a sendmail installation because there's no way to override this to use a different transport.
A section of the user guide details the admin area dealing with this particular feature. From the customer side, the Newsletter Subscriptions page displays a list of newsletters (in this case only one called "General Subscription") with checkboxes for enabling or disabling the subscription. There is also a Sign Up for Newsletter checkbox on the form for creating a new customer account.
The documentation and layout of the admin area and the single checkbox on the customer account creation form appear to indicate that only one newsletter is supported per installation (insofar as customers being to subscribe to multiple newsletters or those newsletters being listed in the admin area somewhere), which seems contradictive the related area of the customer dashboard. It's possible that support is or was planned to have support for multiple newsletters.
Under the hood, this feature uses the Sendmail transport of Zend_Mail, which is simply a wrapper around the PHP mail() function. Sadly, there doesn't appear to be an easy way to change this without hacking core code.
Customer-submitted were discussed from an administrative perspective in a previous post in this series. For customers, submitted reviews can be viewed from the My Product Reviews page regardless of their publishing status. The table on this page includes the name of the product and a link to its description page as well as the review's overall rating, text, and submission date. A link is also included to show a bit more information with the review including the default product photo and average customer rating.
Two notable traits of this feature are the inability to edit or delete reviews once they're submitted and the ability for the same customer to submit multiple reviews for the same product. The latter capability implies the ability of a malicious user to spam the moderation queue, though I only submitted two reviews for the same product and can't confirm or deny that a cap may exist on the number of reviews for the same product and customer.
The My Tags page lists tags added to products by the customer. Tag names are linked and produce a listing of products that the customer has tagged with that tag. A link is provided for each product in this list to add that product to the customer's wishlist. Tags can be renamed or deleted. There doesn't appear to be a way to selectively remove a tag from particular products once it's added to them, only deleting the tag entirely.
A blog post was done on this feature prior to Magento's initial release. The demo store and a stock installation of 1.3.2.2 differ in the contents of this area. The demo store does indeed include recent orders and reviews, but the stock installation includes neither of those blocks and instead includes recent tags. I'm assuming this has to do with the demo store having a customized theme. Both present a list of newsletter subscriptions, primary billing and shipping addresses with links to edit both, account contact information, and a link to change the account password.
For the most part, this area deals with features that are common to the point of being expected in any e-commerce package worth its weight. Those that aren't, such as wishlists, newsletters, reviews, and tags, all appear to have quirks or shortcomings that make them appear embryonic in their development and potentially better suited for third-party modules rather than core features.
This post is the sixth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the customer service features.
The user guide section for this feature describes it in a bit more detail, but it's essentially a simple form-to-e-mail. It can be enabled or disabled fairly easily and the sender and template used are fully configurable. With the default theme, it is accessible on the front-facing web site from the footer navigation on any page. A wiki tutorial and a related forum thread describe how to add custom fields to the form. A blog post is also available on how to position the form within its containing page.
It appears that no data from the form is stored in the database, which suggests that it's possible for submissions to get "lost in the mail". Were they stored in the database, a page in the admin area could be used to get a listing and even mark items as resolved to help with organization. A natural extension of this functionality would be integration with popular CRM software packages such as SugarCRM. This possibility about which some users have inquired in the forums.
This seems like a very odd feature to have on the list in this section. Customer Accounts seems like it would have been a more appropriate place for it. Using the phrase "feature-rich" within the feature listing itself also seems redundant and a rather bare assertion. In any case, customer-focused features are described more in detail in the user guide and the previous blog post in this series.
In terms of the administrative side of this functionality, the Customers menu offers a Manage Customers section to create, edit, remove, search, and other wise manage customer accounts. For existing customers, all data accessible from the front-facing web site is also accessible in Manage Customers. Customers can be organized into groups for tiered pricing. Lastly, an Online Customers area allows session information to be viewed for both registered and anonymous customers.
This feature is also present in the Customer Accounts feature list and is covered in more depth there. For a screenshot, consult the user guide. Magento's implementation of it is par for the course as its implementations in various shopping carts go.
Customers can also track status updates via RSS, which is covered in a bit more depth at the bottom of this user guide section. The instructions there aren't as clear as they could be, though. To enable this feature, go to System - Configuration - Catalog - RSS Feeds - Order in the admin area and set Customer Order Status Notification to enabled.
At that point, when a customer views an individual order on the front-facing web site, a Subscribe to Order Status link with an RSS icon next to it should appear to allow status updates for that order to be tracked. The link appears to used a hashed identifier for security reasons.
The user guide states that, if an order has an associated shipping or tracking number, that order will be listed (in the My Orders page of the customer dashboard) with a link to a pop-up window that retrieves the status from the shipping or tracking gateway.
Unfortunately, it doesn't go into much more detail than that and the demo store doesn't appear to use that feature, so there's no way to review it unless you have a live store handy. This feature will likely be covered in more depth from an administrative perspective in a later blog post focused on shipping features. In the meantime, for more information on that, check out this user guide section.
Another standard feature of most shopping carts enables customers to reset their password by following a link sent to their registered e-mail account, which Magento naturally supports. On the login page in the default theme, a "Forgot Your Password?" link can be found at the bottom of the login form for registered customers. This displays a form where the customer can enter their e-mail address to receive an e-mail containing a new password.
This feature can also be used from the admin area when editing a customer: go to the Account Information tab of the form, check the Send auto-generated password box, and click either of the buttoms to save the customer record. An option is also available to manually set a new password. In either case, an e-mail with the password is sent off to the customer.
The user guide describes this feature in some detail. When certain events occur, such as when a new customer account is registered, a customer's password is changed, or a new order is placed, Magento fires off an e-mail to the customer. These e-mails are configured to use specific originating e-mail addresses and templates.
This old screencast, which is rather outdated but still somewhat accurate, reviews this feature in some detail. Ironically, the Designer Guide doesn't appear to address it at all, when it seems likely that a designer would be tasked with the responsibility of this particular area of Magento customization. This wiki article and this blog post both do a bit to fill in the gaps by providing a list of template paths, variables, and more information on customization.
The admin area provides functionality for creating orders similar to the front-facing web site. It also facilitates modification of existing orders. This is covered in the user guide. Both features are fairly common in e-commerce software for order cancellation or issue resolution. To access the feature from the admin area, go to Customers - Manage Customers, add or edit a customer, and the form for doing so should include a Create Order button near the top.
One common issue I noticed throughout while working on this blog post is that all operations involving e-mail appear to return a message indicating success, regardless of whether the operation was actually successful or not. Not returning sensitive information is understandable, but giving a false success message is misleading at best. It appears that users have had no shortage of issues with e-mail — or even debugging it — since at least Magento 1.1 with very little official guidance or support.
In looking at source code related to this issue, the default Sendmail transport for Zend_Mail is used and there is no easy way (at least not one that's obvious or documented) to globally switch it out for a different transport without hacking the core. Among other things, this appears to mean that it's not possible to have e-mail features work on a local Linux installation (like mine) without installing and configuring an MTA.
Overall, as with the last post in this series on Customer Accounts, most features addressed in this post are commonplace in e-commerce solutions. The user guide covers most of these relatively well, but documentation on customization and inaccurate success messages are still painful points.
This post is the seventh part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the order management features.
This was covered in posts on Customer Accounts and Customer Service and the user guide has a chapter on the subject. Orders can be created for customers by going to Customers - Manage Customers, creating or editing the customer, and clicking the Create Order button in the top right area of that form. Upon creation of an order, that order will be displayed just as it is if accessed via Sales - Orders. Clicking on a row for a specific order, either under Sales - Orders or in the Orders tab of the form used to add and edit customers, will display that order with buttons to Hold, Invoice, Ship, or Reorder that order near the top of the page.
Shipping to multiple addresses — or split fulfillment — is touched on in the user guide, but doesn't agree it from a customer perspective; I didn't notice the link in the default theme initially. Luckily, there's a screencast on shipping to multiple addresses from the customer side.
Go to edit an order, either from Sales - Orders or from the Orders tab when editing a customer under Customers - Manage Customers. Click the Ship button at the top right corner. On the next page, scroll down to find the Items to Ship section. On the far right, you'll see the quantity ordered and invoiced for each item and a text box allowing you to adjust how many to ship.
A validation check on the quantity field prevents shipment of a larger quantiy of an item than was ordered. However, it doesn't appear to be affected by an item being out of stock, presumably because automatic inventory management tasks are performed when the order is placed rather than when it is fulfilled.
The user guide touches on how to create these for invoices and shipments, but it's pretty simple. From Sales - Orders, select an order. Click the Invoice or Ship buttons on the top-right if needed to create a new invoice or shipment. Once that's done, go to the Invoices or Shipments tab, click on a record in that grid to view it, and then click the Print button on the top right corner of the page. This will generate a PDF version suitable for printing.
I'm not sure why this is stated as a separate feature, as it's simply one potential application of the features for managing orders in the admin area as described earlier in this post. I will say that I wouldn't recommend this particular application unless you have fairly powerful hardware for supporting it. On my system — a laptop with Intel Core2Duo 1.83GHz with 4 GB of RAM, admittedly not intended to be a server — this area of the admin interface feels sluggish, and I'm one user compared to a call center of users.
In addition to creating new orders, one useful addition to this area would be the ability to more easily access a list of orders taking more than a certain number of days to process in order to enable proactive resolution. This is currently possible with the search feature, but requires manual date calculations.
When viewing orders from the Orders tab of the form for adding or editing customers under Customers - Manage Customers, a Reorder link is shown per order in the order list. Likewise, when viewing the same order under Sales - Orders, a Reorder button provides access to the same functionality. In both cases, the same interface for creating an order for a customer is displayed with all data from the previous order prepopulated into form fields as appropriate. The reorder can be modified as needed at that point before it is submitted.
No documentation appears to exist for this feature in the user guide and little support has been offered to address why this is. It's addressed for customers in the user guide, but not for admins. I think part of the reason for this is that it's the same functionality being used and admins are just copied on e-mails already going out to customers. To configure this, go to System - Configuration - Sales - Sales Emails and look for fields labeled Send * Email Copy toward the bottom of the Order, Invoice, Shipment, and Credit Memo sections.
From Sales - Orders in the admin area, a New Order RSS link with an appropriate icon next to it appears centered above the order grid. I imagine this feature is useful for smaller shops without a large order throughput insofar as e-mail notifications may not make it to their destination and logging into the admin area seems too intensive an operation just to check for new orders.
Features in this section are overall well-implemented. Some have been covered before due to overlap with other sections, some have limited usefulness depending on the customer's needs, and most are still lacking in the way of documentation. Despite that, this does appear to be an area where Magento shines.
On a semi-related note, while reviewing the features for this post I decided to do a small experiment. I installed Firefox 3.5 via aptitude shortly after it was released and I'm currently running 3.5.2. However, there's an annoying bug that causes Firefox to crash sporadically when I close a notification from Magento that appears immediately after I log in to it. As such, I decided to give Opera 10 a try.
Firefox has been my primary browser for years, but I must say that I'm impressed with Opera. I did run into an odd issue where Opera wasn't propagating cookies in my local installation (1.3.2.3) when Firefox was. Even stranger, this issue didn't occur with the demo store in either browser. A simple core hack cited in this forum thread seemed to fix the issue and I'm told that it will be included in future Magento versions.
This post is the eighth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it reviews the payment features. Many features in this post have a corresponding configuration area in System - Configuration - Sales - Payment Method.
This feature is only available in the Enterprise Edition of Magento. No online documentation covers this feature. The Magento User Guide book appears to, though it's difficult to judge basedly solely on the table of contents.
To manage store credit for a customer, go to Customers - Manage Customers and click the Store Credit tab on the form to add or edit a customer. The interface for this feature is fairly intuitive: a current balance is shown, that balance can be adjusted by a given amount, an e-mail is optionally sent to the customer to inform them of the change, and a history of balance modifications is shown in a grid at the bottom.
On the customer side, a corresponding Store Credit tab exists on the customer dashboard. It merely presents the current balance and offers a link to go to the Gift Card page. The admin and storefront demos for the Enteprise Edition do not appear to be the same installation (i.e. they don't share data), so it's not possible to explore the customer side of this feature further because store credit can only be managed from the admin side.
A few alternatives to the Enterprise Edition's implementation of this feature include the J2T Points & Rewards extension as well as rolling your own by following the related chapter in the php|architect Guide to Programming Magento.
Some online payment gateways give you the option to either authorize and capture funds at the same time or only authorize and capture at a later time. In the latter case, Magento will capture funds when an invoice is created. The user guide covers how to do this.
To summarize, simply go to the configuration area for the payment method you're using and set Payment Action to Authorize Only. After that change is made, funds will be captured when you create an invoice for an order. This is useful if you want to delay charging for items until after they are in stock or have already been delivered.
Checkout by Amazon and Amazon Simple Pay are both supported payment gateways. They have no documentation on the user guide or wiki, but their configuration areas can be found in the same admin area page as other payment gateways. The configuration areas themselves include related links to sign up for service or view FAQ documents.
Payflow Pro, Express Checkout, Website Payments Pro (Express and Direct), Website Payments Standard, and Website Payments Pro UK (Express and Direct) are all supported. Aside from Payflow Pro, signup links for service are included in the configuration area for each service, but nothing else in the way of links or explanation. See this section and subsequent sections of the user guide for more information.
This is another feature that is available only in the Enterprise Edition. There is a screencast available for it, though like the screencast to introduce the Enterprise Edition it is more for marketing than support. This feature also is also not documented in the user guide, as with most features specific to the Enterprise Edition.
The demo store provides a good idea of how this feature works on the storefront side. Physical gift cards can be purchased and shipping like any other tangible product to be used at a local brick-and-mortar store in the recipient's vicinity. Virtual gift cards are also available, where a link is e-mailed to the recipient who can follow it to add the gift card credit to their account in the online store.
The Authorize.net payment gateway is supported. More information on its configuration can be found in the user guide. No signup link or other documentation is included in the configuration area; it's all settings.
The user guide covers configuration for the Google Checkout payment provider. Because Google has a separate Google API section under System - Configuration for integration with services such as Google Analytics, the configuration area for Google Checkout is placed there rather than with other payment gateway configuration areas under Payment Methods.
Obviously, multiple payment gateways are supported by Magento that are consulted to authorize and capture funds on checkout. There's also the option of saving credit card information locally, which the user guide covers. Aside from recurring payments, there is really no advantage to this approach and it incurs a large amount of liability because of the sensitive nature of the information being stored. Nevertheless, for organizations that have that particular need, Magento supporting them is a point in its favor.
Yes, there is a land beyond credit cards: checks and money orders. See the user guide for more information on configuring Magento to handle them. Information like who to make checks payable to and where to send them are displayed when this payment method is selected by a customer. Its availability can be restricted by country of the billing address as well as a minimum or maximum order amount.
Like checks and money orders, this payment method has a user guide section and a configuration section under Payment Methods. The same available country and order amount restrictions are available. Upon selecting this as the payment method, the customer is prompted to enter a purchase order number.
Magento Connect is similar to the Mozilla Firefox Adddons site in that it hosts downloadable Magento extensions and provides a searchable categorized directory of them. Roughly 200 payment gateway extensions are available at the time of this writing. My only gripe with this feature is that the Magento Connect web site makes it difficult to link to a particular set of search results very easily.
The level of support for various payment gateways and other payment methods is impressive, as is the level of flexibility offered by the Enterprise Edition features. Online documentation remains scant for the latter, though at least configuration for the former is covered in the user guide.
This post is the ninth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it will review the shipping features. Several of these features can be configured by going to System - Configuration - Sales - Shipping Methods in the Magento admin area.
A screenshot from the user guide gives you an idea of how this feature looks on the customer side. Widespread use of these services is a likely reason why the Weight attribute is required when entering tangible products (i.e. not virtual or downloadable) into Magento, because shipping cost is generally based on the weight of the item being shipped. This feature is supported for UPS, UPS XML (account rates), FedEx (account rates), USPS and DHL.
If using a specific shipping provider is not a business requirement, I'd recommend using the Magento forums to research the capabilities of modules for any shipping provider you consider in addition to the services and rates they offer. Issues encountered with shipping modules have ranged from installation and configuration issues and issues with SSL to lack of support for multi-package quotes, particular shipping methods, or shipping outside the United States. As such, using a particular Magento shipping module may not be as cut-and-dry as enabling and configuring it.
This feature has an associated section in the user guide as well as a screencast. While this feature is certainly useful, its implementation in Magento is lacking for two reasons.
First, the ability to use the feature is dependent on the customer having an account beforehand. While this isn't a huge hindrance, it's not ideal in terms of usability either. It's puzzling because I see no obvious technical reason for this requirement.
Second — accessing the feature when the default theme is used requires noticing a rather inconspicuous link (which I didn't notice until I watched the screencast) beneath a significantly more conspicuous "Proceed to checkout" button, rather than allowing the user to choose how they want to handle shipping after they opt to check out.
I apparently already discussed this feature without realizing it. I'm guessing the item in Customer Service was referring to the order status within the store, as opposed to its status with the shipping carrier which was discussed in that blog post and should have been discussed here.
This feature allows for creating multiple shipments when handling orders from the admin area. The user guide has a section on creating new shipments for an order. Go to Sales - Orders, select an order, and click the Ship button on the top right of the form to do so.
As described in the user guide, all shipping methods can be restricted based on the country of the customer's shipping address. In the Shipping Method configuration area, expand a shipping method section and change Ship to applicable countries to Specific Countries. This will enable the Ship to Specific countries menu to allow you to select the countries to which the shipping method in question should be restricted.
In addition to methods for specific shipping carriers, Magento also offers several options to allow the store administrator to set shipping prices based on various criteria. The user guide describes the flat rate method, one of the options for which is to set a flat shipping rate per order. To do this, go to the Shipping Methods configuration area, expand the Flat Rate section, and set the selection for the Type menu to Per Order. Other options for this method include setting a handling fee, which can be flat or a specified percentage of the order amount.
In the same Type menu used to enable per-order flat rate shipping, there is another option called Per Item. When this is enabled, the flat rate will be multiplied by the number of items in the order to calculate the shipping charge for that order.
This shipping method is also covered in the user guide and has its own section in the Shipping Methods configuration area. Its availability can be restricted based on a minimum order amount.
The user guide covers this method, the configuration for which can be found in the Table rates section of the Shipping Methods configuration area. This method will export or import a CSV-based table in a predefined format containing shipping rates based on both order weight and shipping destination (country, region, and zip code).
Note that to access this feature, you must select a Website-level option (Main Website in a default installation, versus the default option Default config or a Store-level option) from the Current Configuration Scope menu on the top left-hand corner of all System - Configuration pages. Unfortunately, this prevents use of a single global set of shipping rates across multiple websites, instead requiring each website's shipping information to be configured independently.
To enable this particular type of table rate, select Weight vs. Destination from the Condition menu in the configuration section. You may need to uncheck the Use default checkbox next to the menu in order to do this.
The implementation for this feature is structured in the same way as table rates for weight and destination, but uses the product subtotal instead of the weight for one table dimension. The Price vs. Destination option in the Condition menu corresponds to this type of table rate. This corresponds to product subtotals (i.e. individual product price multiplied by quantity of that product for an order) so that rates can be applied to items within a single order being shipped to multiple addresses.
Ditto the last section, except that # of Items vs. Destination is the Condition menu option for this table rate type.
The flexibility with regard to availability of shipping methods and setting rates based on various criteria is good. One feature of the Table Rates shipping method is that quantities for weight, price, and items can be specified as 0 in order to use the table as a list of prices specific to location. I think rate configuration for shipping modules could be improved by adopting a more rules-based approach (in terms of both user interface and functionality) as with the advanced price rules feature for catalog management.
Aside from some issues with modules for particular shipping carriers, Magento makes a good showing in this area in terms of functionality and documentation. To Magento's credit, I agree with the tools guy in the USPS flat rate commercial: in general — and in particular as it relates to development — Shipping is Complicated.
Note: All references to the user guide in this post refer to the public user guide available on the Magento wiki, as opposed to the user guide book for the Enterprise Edition of Magento.
This post is the tenth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it reviews the checkout features.
While doing research for this post, I came across information on a known issue where customer ISPs that dynamically change IP addresses can cause customers attempting to check out to be returned to the website landing page with an empty cart. This is because by default Magento implements a security measure to avoid session hijacking attacks. Though this could stand to be better documented in the user guide, the implementation and configurability of this security measure are well done.
From a security perspective, this measure is a good thing. If for some reason you really want to disable it, here's how: access the admin area, go to System - Configuration - General - Web - Session Validation Settings, and change all settings except Validate HTTP_USER_AGENT to No. This should be done only if absolutely necessary.
A screencast accompanies this feature. The user guide doesn't cover the process in much detail, but it has the same steps that you would expect from most shopping carts: billing and shipping addresses, shipping method, payment information, order review, and finally order submission.
I don't consider the "one-page" visual aspect of this feature to be as important as how it functions. I think all facets of this functionality can still be included without this visual aspect.
While some vendors choose to use a third-party payment processor to hold significantly less liability at a higher cost, most choose to accept credit card information behind an SSL certificate and use a merchant account with a payment gateway to provide a more transparent shopping experience. Unfortunately, configuration of Magento to use SSL isn't covered anywhere in the user guide that I've been able to find.
There is a wiki article that goes into some detail on the topic. Settings for secure URLs can be found under System - Configuration - General - Web - Secure. These allow you to force use of SSL on either the storefront, the admin area, or both. If you use secure URLs and find that customers are receiving browser warnings about non-secure items, check out this blog post.
This feature was discussed in the post on shipping. It's included here because the feature list restates it in this section, presumably due to its relevance to the checkout process.
While some customers may wish to register in order to expedite future orders, some may simply wish to get the order done as quickly as possible and move on. For this, there is a guest checkout option to allow the customer to check out without signing in with an existing account. There's a screencast on this feature. The user guide also covers it briefly.
In terms of usability, it would be nice if opting to either check out as a guest or to register a new account was a single-click operation, rather than using radio buttons to obtain the user's selection before requiring them to click a submit button to formally opt in to that selection.
It's also strange that Magento prompts the customer for this information at this point in the process because, as the screencast for this feature points out, it's not needed until the end of the process anyway. If the user wants to register, the only difference it makes to the process is that they must specify a password before the order is submitted.
The user guide section on the checkout process includes mention of this with a screenshot. In the default theme, there is an ESTIMATE SHIPPING AND TAX section below the product listing on the shopping cart page. This allows the customer to provide information about their location and get a subtotal for shipping and tax corresponding to their order before opting to check out.
This block doesn't appear to list quotes from the Table rates shipping method even when rates applicable to the destination and cart contents are available. I've filed a bug report for this issue (requires login to view).
This feature is addressed briefly in the user guide. Customers who register are able to select from a drop-down menu of previously entered addresses when entering the billing and shipping address for a new order, alleviating the need for the same information to be entered manually again.
All previously entered addresses as well as those selected by default for new orders can be controlled from the Address Book page in the customer dashboard and the Addresses tab of the form for editing customers under Customers - Manage Customers in the admin area.
The feature was discussed a bit earlier in this post. The option for creating a new account is presented when a customer attempts to check out without being logged in. They are presented with options to log in, create a new account, and check out without creating a new account (as a guest). The only difference between creating a new account or not is entering a password.
The user guide covers this briefly toward the end of the section on the checkout process. This feature isn't enabled by default; to enable it, access the admin area and go to System - Configuration - Sales - Sales - Gift Messages — the user guide is either outdated or doesn't make this particularly obvious.
This section has two Yes/No options, Allow Gift Messages on Order Level and Allow Gift Messages for Order Items. Within the step of the checkout process for specifying the shipping method, these options will enable the customer to specify a message for the entire order or a message per item within the order. These are intended to serve as what one might write on a card for a gift being shipped to its intended recipient.
This feature doesn't appear to be covered anywhere on the wiki, user guide, or screencasts. I had to search the forums to find out how this feature is configured. Go to System - Configuration - Sales - Checkout - Shopping Cart. The Quote Lifetime field controls the number of days for which a quote (i.e. the quoted price when a product is added to a shopping cart) will remain valid.
Several features described here, such as guest checkout and SSL support, are fairly commonplace among most e-commerce software packages. A few others, like shipping and tax estimation, are less common but welcome additions.
The usability of several areas such as the one-page checkout are admirable, but still have room for improvement. (Speaking of usability, if you're looking for a good book on the subject, I highly recommend Don't Make Me Think.) Overall, checkout is another area in which Magento is a strong competitor.
Note: All references to the user guide in this post refer to the public user guide available on the Magento wiki, as opposed to the user guide book for the Enterprise Edition of Magento.
This post is the eleventh part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it reviews the search engine optimization features.
Other features in this section seem objective and well-defined, but this one comes off as more of an assurance from the marketing department to lead into the rest of the feature list. It's rare that an assertion of a product being 100% anything is unembellished.
If you'd like a slightly less biased claim, check out this blog post. It links to several other good resources, outlines what Magento already does for SEO, and points to supplemental measures that can be taken to improve it. Another blog post includes a number of related links as well.
Google supports use of the sitemap protocol through its Google Sitemap service, which allows site administrators to inform them of sites that offer site maps for consumption by crawlers. The user guide only touches briefly on where to find configuration options for Google Sitemap, but this wiki article helps to fill in the gaps.
To generate a site map, make sure that Magento can temporarily write to the directory intended to house the sitemap.xml file. From the admin area, to go Catalog - Google Sitemap, click the Add Sitemap button, enter a filename (ex: sitemap.xml) and path (ex: /), and click the Save and Generate button.
While a record of the sitemap will be maintained in the database, generating the sitemap from this area only updates it at that time. In other words, it doesn't automatically update as data changes. To do that, go to System - Configuration - Catalog - Google Sitemap - Generation Settings, set Enabled to Yes and appropriate values for Frequency and Start Time. At that point, all sitemaps will automatically be regenerated on the specified interval provided a cron job is a set up for it.
This feature is covered well in the user guide. URL rewrites allow for more search engine-friendly URLs to pages for products, categories, and anything else within Magento. You can manage them by going to Catalog - Url Rewrite Management. Rewrites for categories and products can also be modified using the URL key field in the default tab when editing an individual instance of either.
This feature works whether or not you have Apache's mod_rewrite module. The only difference is that "index.php/" is included in URLs when URL rewriting is not used. To prompt Magento to begin using web server URL rewriting, go to System - Configuration - General - Web - Search Engines Optimizations in the admin area and set Use Web Server Rewrites to Yes.
Note that Magento's .htaccess file will add rewrite rules for mod_rewrite if it's enabled; this configuration setting merely instructs it to exclude the "index.php/" segment in the links it returns. Also, while the system requirements for Magento are specific about Apache, there has been some success in getting it to run on other web servers like IIS.
The user guide makes mention of this for products and categories.
For products, go to Catalog - Manage Products, create or edit a product, and access the Meta Information tab to set the page title (not sure why this is labeled Meta Title) and meta description and keywords. If the Meta Description field is left blank, the meta description will default to the value of the Description field under the General tab when editing a product. Likewise, the page title will default to the product name. Meta keywords will default to a set for Magento itself.
For categories, go to Catalog - Manage Categories, create or edit a category, and look for the Page Title, Meta Keywords, and Meta Description fields in the General Information tab. Defaults for these are the category name, a set of keywords for Magento, and the string "Default Description" respectively.
I looked around in the configuration section of the admin area, but couldn't find any way to control the defaults used when any of these fields are left empty.
The user guide covers this feature. It is enabled by default, but can be disabled by going to System - Configuration - Catalog - Catalog - Search Engine Optimizations and setting the Autogenerated site map option to No.
Two site maps are made available, one for a category listing and one for a product listing. The former can be accessed using the Site Map link in the footer of the default theme. From that page, the Products Sitemap link on the top right corner provides access to the product listing. Configuration for that site map can be found in System - Configuration - Catalog - Catalog - Sitemap in the admin area, allowing the visual structure of themap to be changed (list or tree) and the number of results per page to be changed.
With regard to the earlier item claiming 100% search engine friendliness, this feature is one area where I find that claim to be a bit flawed. The links to the category and product listing pages themselves have a title attribute, but none of the links to categories and products on those pages do.
This feature is also addressed in the user guide, albeit briefly. It's enabled by default; that can be controlled in System - Configuration - Catalog - Catalog - Search Engine Optimizations by toggling the Popular search terms selection.
When this feature is enabled, a Search Terms link is included in the storefront footer. This link goes to a page that implements a tag cloud of phrases commonly used in the storefront search with each phrase linking to its respective search result page.
The contents of this page can be managed by going to Catalog - Search in the admin area. That's also covered in the user guide, though more in the context of improving site search than SEO.
While this feature in and of itself is great, its placement is less so. Ideally, the tag cloud would be placed inline (rather than on a separate page) and early on (as opposed to in the footer) in the landing page's content so it would be more likely to be picked up by crawlers. I imagine it's possible to customize Magento to make this change, but it would improve Magento from an SEO standpoint if the native theme was implemented this way.
Sitemap support, common search terms, and URL rewrites are great SEO features. While metadata are nearly irrelevant for SEO these days, the ability to control it for products and categories from the Magento interface is a nice feature. In the age when content is king, it falls to users of Magento to implement quality content that caters to their business. Much of what Magento can do to support them in this endeavor, it does and does well.
Note: All references to the user guide in this post refer to the public user guide available on the Magento wiki, as opposed to the user guide book for the Enterprise Edition of Magento.
This post is the twelfth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it reviews the international support features.
The admin area and demo store theme support multiple languages, though Magento documentation doesn't make it obvious as to how this feature works. This blog post helped me to figure it out. With a default installation, you can change the locale by going to System - Configuration - General - General - Locale options - Locale. However, this alone will result in minimal translation.
In order for all language used by Magento to be translated, you must install a translation pack. These are available as extensions from the Magento Connect repository. This wiki article describes how it works. Basically, go to the Magento Connect web site, view the page for the translation pack you want, get its extension key, then go to System - Magento Connect - Magento Connect Manager and specify that extension key to download and install it.
Even once the translation pack is installed and the Locale setting is updated, the change does not take effect immediately. You have to log out and log back in to see it applied through the admin area.
There's a screencast for this feature. Navigation has changed a bit from how it's shown in that screencast: you now go to System - Configuration - General - Currency Setup - Currency Options and Scheduled Import Settings. Webservicex now has a section specific to it for specifying a timeout. System - Manage Currency is now System - Manage Currency Rates. The user guide also has a section on this feature.
Magento allows for the selection of a Base currency (in which all transactions will be processed), Default display currency (in which prices are presented to customers — this can vary per store), and Allowed currencies (to which customers can switch if they don't like the default currency). Note that both the Base and Default display currencies must be explicitly selected in the list of Allowed currencies; otherwise, an error message is displayed and configuration changes are not saved.
This feature is covered well in the user guide. Tax rates can be managed individually from Sales - Tax - Manage Tax Zones & Rates or imported and exported in bulk from Sales - Tax - Import/Export Tax Rates.
Tax classes are used to collectively apply tax rates to customers and products. They are assigned to customers via customer groups (Customers - Customer Groups to manage these; Customers - Manage Customers, add/edit a customer, Account Information tab - Customer Group field to place an individual customer in one) and assigned to products individually (Catalog - Manage Products, add/edit a product, Prices tab - Tax Class field). Tax classes can be managed from Sales - Tax - Customer Tax Classes and Product Tax Classes.
Once rates and classes are created, rules can be created to determine which rates are used for which customers and products. To manage rules, go to Sales - Tax - Manage Tax Rules. Each rule can be applied to multiple tax classes for both customers and products.
Support for fixed taxes at the product level were added in Magento 1.2, allowing taxes such as the State Environmental Fee in the USA and WEEE/DEEE in EU. I wasn't able to find any real documentation on this addition aside from API docs for the Mage_Weee component. Neither that nor the source are very helpful in discerning how the component works or how it's intended to be used.
From the Wikipedia article on the subject, localization (often abbreviated L10n) is defined as "the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text." The "minimal translation" mentioned earlier in the section on Multi-Lingual support applies to, among other things, dates and currency, the types of locale-specific variations that localization is intended to handle. This is covered in a bit more depth in the user guide.
This list can be found under System - Configuration - General - General - Countries options. It is used to filter available options in menus for user account registration, shipping destination addresses (per shipping method), and billing addresses (per payment method).
Menus that pull from this list appear to be displayed even if only one country is allowed. If that country is selected as the default country, it's selected automatically in such cases. Those menus generally contain a blank option, but are required, so little harm comes from them being displayed. If you'd rather they be hidden from the customer, see this forum thread for tips on how to implement that change.
Internationalization and localization are areas in which I still have a lot to learn as a developer. That said, Magento appears to cover its bases where features related to those areas are concerned. Lack of documentation that specifically covers those features seems to be the biggest potential point of improvement. Tax rate support is a good example of the level at which documentation for other areas needs to be, as it seems to be fairly comprehensive.
What are your experiences with Magento's international support?
Note: All references to the user guide in this post refer to the public user guide available on the Magento wiki, as opposed to the user guide book for the Enterprise Edition of Magento.
This post is the thirteenth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it reviews the marketing promotions and tools features. The majority of the features listed in this area have already been covered in this series. As such, sections for those features in this post are simply linked to other posts where appropriate.
See the Catalog Browsing post.
Coupons are implemented as part of the shopping cart price rule system, which is discussed in the user guide. These price rules allow for things like fixed or percentage-based discounts as well as free shipping and can be restricted to specific stores, products, product categories, ranges of product quantities in the order, customer group, coupon code, or any combination of the above. To manage them, go to Promotions - Shopping Cart Price Rules in the admin area.
Another area of the user guide describes the section of the storefront interface used for entering a coupon code. When using the default theme, go to the shopping cart page and look in the page's center immediately below the shopping cart listing. A block labeled DISCOUNT CODES allows for the entry of coupon codes to apply to the other.
This refers to catalog pricing rules, which are covered in the user guide as well as a webcast. They're similar to shopping cart price rules but apply to individual products instead of entire cart contents. Unlike shopping cart price rules, catalog pricing rules do not use coupon codes and cannot be published to an RSS feed. They can be managed from Promotions - Catalog Price Rules in the admin area.
See the Shipping post.
See the Product Browsing post.
See the Catalog Management post.
The user guide and a screencast cover tier pricing, which is basically a fancy expression for discounts given when items are purchased within specific quantity ranges (generally what would be considered "in bulk"). Tier pricing is managed by going to Catalog - Manage Products in the admin area, creating or editing a product, and going to the Tier Price section within the Prices tab. Prices can be applied to all or select customer groups.
This feature allows for the creation of custom landing pages that can pull in Magento blocks. It's detailed in both the user guide and a screencast. As of this writing, the user guide includes mention of a Store View field that no longer exists in Magento 1.3.2.3. This presumably implies that CMS pages could at one point be restricted in scope to particular websites or stores, but that capability is no longer available.
See the Search Engine Optimization post.
See the Search Engine Optimization post.
See the Catalog Management post.
See the Catalog Management post.
This feature isn't covered anywhere in the user guide. This forum post implies that it did exist at some point in the 1.2 branch, but none of the referenced files exist in Magento 1.3.2.3. Another forum post suggests that the feature didn't exist in mid-2008, between the 1.0 and 1.1 releases. There's at least one community module available on Magento Connect to fulfill this need. It's odd that the feature list would include something developed well after initial releases but already removed from the application.
See the Catalog Browsing post.
See the Catalog Browsing post.
See the Product Browsing post.
See the Customer Accounts post.
The New Tags feed is mentioned in the Analytics and Reporting post. A section of the user guide covers the New Products and New Specials feeds. New Products is controlled by the Set Product as New from/to Date fields in the General tab when editing a product from Catalog - Manage Products in the admin area. New Specials is also controlled by editing a product, except that the Special Price and Special Price From/To Date fields in the Prices tab are used.
In order for RSS feeds to be available (via an RSS icon in the site footer when the default theme is used — a rather out-of-the-way place to put it), you must go to System - Configuration - Catalog - RSS Feeds and change default configuration settings. Set Enable RSS to Enable in the Rss Config section and the setting for the appropriate feed to Enable in the Catalog section.
See the Search Engine Optimization post.
See the Search Engine Optimization post.
The user guide and a screencast cover this feature. To manage polls, go to CMS - Poll Manager. Polls can be opened or closed by changing the value of their Status field. Each contains a single question and a variable number of answers, each of which has an associated vote count that can also be changed from this area. The dates of polls being opened and closed are recorded for reference purposes.
Potential additional features include automated opening or closing of polls on specified dates or allowing customers to select multiple answers. It appears that this feature was intentionally kept simple to meet the needs of the lowest common denominator in terms of the features it offers.
See the Customer Accounts post.
In terms of this list of features as a section, it seems like it was stuffed with any feature that could remotely be related to marketing or promotion. That aside, pricing rules and tier pricing are well done and come out as the saving grace of this section. RSS feeds are nice, though they could be placed a bit more prominently (and perhaps with a bit more redundancy) in the default theme. Landing pages really only provide routing configuration for custom pages. Polls are a nice feature, but the implementation is very simplistic and the feature itself seems like a better candidate for a community module than a core one. Overall, this feature section seems quizzically defined insofar as the mixture of features seem to imply a lack of certainy about what its contents should be.
Note: All references to the user guide in this post refer to the public user guide available on the Magento wiki, as opposed to the user guide book for the Enterprise Edition of Magento, unless otherwise explicitly stated.
This post is the fourteenth part of a series covering the feature set of the Magento PHP-based e-commerce package. In particular, it reviews the site management features. Several of the features listed in this area have already been covered in this series. As such, sections for those features in this post are simply linked to other posts where appropriate.
This feature is limited to the Enterprise Edition of Magento and is covered in the Magento User Guide book — Chapter 9 Website (content) staging beginning on page 28. A screencast also explains the feature's function, which is to allow for a variable number of staging websites to be created where content and design changes can be developed internally before being made visible to customers. Both on-demand and scheduled merges and rollbacks of content are supported and staging sites can be password-protected to limit access to them.
While it seems fairly nice on paper, this feature is focused on content entered into Magento. That is, it doesn't handle things like Magento upgrades or installing Magento modules. The recommended practice is to maintain a separate Magento installation where these things can be tried and tested before being deployed manually. Methods for this range from rsync to Subversion for synchronizing filesystem changes as well as a few database tools for implementing database upgrades or locating and copying new content.
These same tools could be used for pushing content changes to production as well, so aside from the Magento EE feature being the sanctioned method, little seems to be gained by having two different methods for doing these things when one will suffice.
One section of the user guide provides a conceptual description of this feature with excellent visuals while another section describes how to use it. What the feature facilitates is operating multiple stores from a single installation, allowing them to share inventory and offer support for multiple languages under the same domain name. Websites, stores, and store views can be managed from System - Manage Stores in the admin area.
See the International Support post.
See the International Support post.
See the International Support post.
This feature is covered in the user guide and a screencast. It's accessed via the Users and Roles options in the System - Permissions menu. Each user is assigned a single role with associated access privileges, which can be changed in the User Role tab when editing a user. Likewise, all users assigned to a role can be viewed and removed from that role from the Role Users tab when editing a role. Leaving a user account without a role is equivalent to setting its Status to Inactive: the user won't be able to log in.
This feature was added in Magento 1.1, with WSDL support being added in Magento 1.3. While it makes sense that no documentation would be included in the user guide for this feature, Magento Core API seems a rather misleading title when searching the Magento web site for it. This feature is also interesting insofar as it's one of few that are included in the feature list and aimed at customization or integration.
The Introduction section of the Core API documentation provides some basic examples, but like the Technical Docs offer very little useful information beyond that. A wiki tutorial provides a few more in addition to information on accessing permissions for the API, which are located under System - Web Services in the admin area. An ACL system similar to the one for Magento itself is provided to restrict acces to API methods. A forum thread clarifies that the username and API key are used for authentication and provides an example. The Core API documentation also provides examples of how to implement custom extensions to the web service API.
The API structure appears to be compatible with REST ideology, but REST isn't currently supported. Magento 1.3.x is based on Zend Framework 1.7.x and improved support for implementing REST services only began to surface in Zend Framework 1.9, so this isn't especially surprising. More surprising is the lack of JSON-RPC support, since the version of Zend Framework used in Magento does bundle a server component for that purpose.
That said, it does make sense that support for XML-RPC and SOAP were added first. SOAP in particular is fairly common in the enterprise, especially when integrating with external systems based on Java or .NET. XML-RPC is a bit more antiquated, but provides a more lightweight alternative for client systems that support the standard. Both allow clients to interact with them using very little code and without having to implement a custom library as would be required with REST. JSON-RPC remains the newer protocol with smaller adoption, but also a smaller bandwidth footprint, and seems a likely candidate for future support.
See the International Support post.
Like the Core API web services documentation for developers, designers also have their own documentation in the form of the Designer's Guide. Rather than focusing mostly on a bare-bones API listing, however, the Designer's Guide is organized more like a reference guide and includes more visuals for explaining different areas of the templating system. There's also an accompanying screencast. Aside from the claim of "Full 100%" customizability sounding like an embellished sales pitch, it's difficult to further review this feature without more extensive experience using the templating system. As such, this will likely be covered in more depth in a future post.
The user guide explains how to manage these. They are what they sound like: categories for customers. Each customer may be in exactly one customer group. They can be managed from Customers - Customer Groups in the admin area. There is unfortunately no option to manage which customers are in a given group from this area. Instead, the customer group assigned to a particular customer must be changed by editing that customer from Customers - Manage Customers and changing the Customer Group selection in the Account Information tab. Tax rates, which are covered in the post on International Support, are assigned per customer group.
While the upgrade process itself is relatively simple, it's not necessarily "one-click" nor as simple as that phrase is intended to imply. Conflicts with customizations, including themes, aren't unheard of. Looking at the forums for upgrade issues is a good way to look before you leap. It's also recommended to apply the upgrade to a testing copy of your production installation and manually migrating changes over as per earlier recommendations for content staging and merging, rather than doing an in-place upgrade on a live site.
See the Landing Page Tool for Campaigns section of the Marketing Promotions and Tools post.
From the Google Website Optimizer Beginner's Guide, the service is described as "a free tool which allows you to test different variations of your site's content to find out which combination results in the highest number of conversions." Magento integration for it was added in the 1.1.7 release. An hour-long webcast was later published to provide a walkthrough of what A/B testing and multivariate testing are and how they can be performed with this feature. Unfortunately, there appear to be no other documentation resources for this feature and it's not without unanswered forum posts.
Some features covered here, such as customer groups and the permissions system, are integral to how Magento works. A few, like the templating system and upgrade process, come across as sales pitches where the devil is in the details. Google Website Optimizer integration and the web services API don't have the level of documentation they really need. CMS pages and content staging and merging seem superfluous. All of this, added to the redundancy in the feature list, make this stand out as an area for potential improvement.
