芳草苑

Magento store owners are having a challenge when using rcah 0.1.0, especially for homepage. The nature of homepage is CMS, most content of it static.

Store owners want their visitors (especially first time visitors) to read static content on the homepage, but static content become obstacles filling in the central area of the page when visitors start to click on filters for refined results.

Root category as homepage 0.1.1 is released to address the problem. It conditionally hides the CMS Block on category pages. It only hides CMS Block in Display Settings of a category (category landing_page attribute). Static CMS Blocks used for others purposes (in sidebar, footer, etc) are not affected.

I must say the conditions when hiding the CMS Block are subtle. Please refer to readme file with the release for details.

Download RootCategoryAsHomepage.tar.gz

为什么不要在 Magento 下使用过高像素的图片？其实这个命题跟 Magento 没有多大关系——任何网站都不要使用超过实际需要尺寸的图片。

只是 Magento 强大的图片处理机制容易让人产生惰性：如今买个相机动辄 10m pixels，拍完照一上传，只要 php.ini 允许足够大的值，Magento 也认可，但是，如果你真的这么做了，至少有这几点不良后果：

• Can not send large images to Google Base (now called Google Merchant Centre). 虽然 Magento 能在自己的网站上缩放图片，但显然没有为 Google Base 考虑到。若为了让 Magento 缩放图片兼容去修改 GoogleBase module，在我看来有点头痛医脚的感觉。
• Cost longer time to generate images in cache. 如果整个网站最大图片也只要 600×600px，那么何必为每次清空 image cache 后等上几秒钟来一张 10 兆像素的照片缩小成 600×600px？
• Waste bandwidth to synchronise / backup media folder. 或许 unlimited bandwidth 不值得担心，但为数据同步／备份节省点时间不好吗？
• My daily backup excludes some over-sized folders. 我有每日备份的机制，但这个机制无力顾及一些体积过大的文件或文件夹（通常也是不常更新的文件）。所以我会排除某些文件让备份文件保持小巧。

作为最佳实践，图片处理不应该依赖于 online resizing。我想 Magento 在管理图片上，也可以更周到一些，适当时提示说，“照片太大，需要缩小保存吗（不保存原图）？”。

Magento 官方推荐以 blank interface 为基础开发个性化的 interface。这说法没错，但有局限性。如果不熟悉 Magento interface 的构成，blank interface 确实一个很好的出发点，如”blank“的名称所言，它没有花里胡哨的背景影响你的构思，如果你是设计师，blank interface 给了你极大的方便。

但世上难有两全其美的事情——blank interface 方便了设计师，但不方便最终用户（我指后台用户）。设计是一时的，用户是一世的，所以我认为两者有冲突时应该更多地照顾用户。Magento interface 有三层 fall-back 机制，在 System > Configuration > Design 可以设置 theme 和 default theme，系统还有最底层的 fall-back to base/default。

设想一下，如果基于 blank interface 开发 my_wonderful_theme，那在后台只能设置 theme 为 “my_wonderful_theme”，设置 default theme 为 “blank”。同时，严格按照 Magento 的规范，只把 “blank” 中需要修改的文件拷贝到 “my_wonderful_theme” 中进行修改。最终 “my_wonderful_theme” 保存了一些修改文件。如果全站页面统一使用 “my_wonderful_theme”，则没有问题；可是，Magento 允许个别 cms, category 或 product page 使用不同的 theme，通常会是 “my_wonderful_theme” 局部的变种，这样就有问题了。假设需要对某个 category 下的页面使用 “my_fantastic_theme”，而 “my_fantastic_theme” 只是在“my_wonderful_theme” 基础上修改了 header 部分，但 “my_fantastic_theme” 无法就它所缺的文件 fall-back to “my_wonderful_theme”——很可惜，Magento 只提供了三层 fall-back 机制，假如它就多给一层 fall-back，那就没有我这篇文章了。

简言之，如果基于 blank interface 开发，那么 cms, category 或 product page 里的 custom design 功能就成了鸡肋。如果设计师/开发者交付一个基于 blank interface 的 theme 和若干变种，用户无法方便地完成切换，这就是个败笔。以后还是以 base/default interface 为起点开发吧，其实也很方便。