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.