我认为突破访问限制的终级方案是 VPN，可是设置 VPN 的技术含量有点高，到现在我还搞不掂 OpenVPN，只能徘徊于 PPTP。今天发现可爱的 php 也有了 proxy（或许早就有了，我不知道罢了），虽然我用不着，但对国内的朋友们确实是天大的福音。简单易行，一分钟就能搭一个！
我只发现 phproxy 三个不大的缺陷：
牛人真不少，还有一个 CHtml，竟然用 recaptcha 去实现突破，构思非常巧妙。
最近留意到一件奇怪的事：Magento 1.3 里还在的 AmazonPayments module 整个儿从 1.4 版拿掉了。
虽然 AmazonPayments 跟大部分英国公司没关系，但它还是造成一点小麻烦。因为它在 Magento 1.3 出现过，所以数据库里 system config 里留有 AmazonPayments 的一些配置信息；但是 Magento 1.3 升级到 1.4 时，为了减少麻烦，我把整个 1.3 源码目录删掉后再替换入 1.4 源码（而不是通常的 merge and replace），这样一来的现状是：数据库里有 AmazonPayments config data，但源码里没有 AmazonPayment module。这时，如果要新建一条基于 payment method 的 promotion rule （比如想鼓励大家使用 GoogleCheckout，给 GoogleCheckout 用户额外 10% 折扣），一点选择 payment method 就出错。
定位了一下出错的语句，原来是 getAllMethods() 不妥，因为它会根据 config data 去或取 payment methods，结果连源码都不存在的 AmazonPayments 成了返回数组里的一员，不出错都难。（我还用过一个 payment module ProtxDirect，后来有更好的 module 以后，把 ProtxDirect源码也给删了，这也是出错的原因。）
class Mage_Adminhtml_Model_System_Config_Source_Payment_Allmethods
{
protected function _getPaymentMethods()
{
return Mage::getSingleton('payment/config')->getActiveMethods();
}
}
我尝试地把 getAllMethods() 改成 getActiveMethods() 就不再有错误。但是我不喜欢因为这么点事去 override class——这个方法治标，我更喜欢在数据库中找出跟 AmazonPayments 和 ProtxDirect 有关的垃圾信息（既然用不到就是垃圾）直接删除——治本。
同时我挺奇怪 Magento 1.4 为什么不考虑一下向下兼容，即使 AmazonPayments 失效了也应该在发布时保留源码目录啊？或者，在升级之际执行一遍 config data clean up?
经历了好几个月沉寂之后，今天终于看到 Magento 一个新版 1.4.1.0。虽然我没去试用新版，但还是在第一时间关心了一下 Release Notes。我第一次逐行读完了 Release Notes，以前最多 scam it，这就是亲身体验者和旁观者的区别。
Improvements
* Added ability to use static URLs for media in WYSIWYG or image browser. Added ability to enable parsing store, skin and media directives on catalog frontend. (这个功能我已经实现了，就是在 description output 上再套一个cms filter，我称之为 text engine。当然 magento core 实现得肯定比我好，以后我就删了我的 text engine)
* URL rewrites history: ability to auto-generate custom rewrite with redirect from old to new URL when changing product URL-key (这个问题我也想过，我没 magento core 那么能干，能做 auto-generated redirect，不过我觉得即使有 auto-generated redirect，把 url key 改来改去也不是回事，所以我建议取名需谨慎，定下的 url key不要改)
* Added ability to exclude a category from navigation menu (这个功能我也实现了，不光能控制 exclude from top navigation，还能控制 exclude from sitemap)
* Various improvements in system configuration UI. Introduced ability to make actual configuration structure to be independent on the system.xml structure
* Added “Only X left” inventory feature
* Implemented Centinel functionality in iphone theme
* Upgraded TinyMCE to v.3.3.2 (不知是否有了 auto-save?)
* Improved PayPal integration, includes:
* Recurring payment profiles entity and purchasing of “subscription” products. In checkout they are treated as “nominal” items.
* Billing agreements
* “Pending Review” order state, “Pending Review” and “Suspected Fraud” order statuses and logic related with this. Triggers by PayPal IPR, FMF and Unilateral payments.
* Functionality of transactions listing/searching and fetching from gateway
* Fetching PayPal settlement reports via SFTP
* Various improvements of PayPal integration on the frontend and admin UI
* Added notice about creating offline creditmemo from order view page.
* Added getter for recurring payment methods in payment helper.
* Implemented abstract block ability to have arbitrary groups of child blocks and a method that returns such a group. Implemented a method that fetches data from child block by specified alias.
* Implemented ability to specify “sort_order” instead of “before” and “after” in the totals declaration. All nominal totals declaration utilize “sort_order”
* Added getter for specified object data by key in core/template block: method getObjectData()
* Defined payment methods grouping, implemented getter for payment method list (with option to group them). Added ability to render grouped options in the “select” grid filter.
* Moneybookers: utilized the payment methods grouping for all its methods; removed redundant “translate” attribute in the methods definition in config.
* Utilized payment methods grouping for PayPal peyment methods.
* Added more verbosity to PayPal NVP and IPN debugging
Changes
* Sales module database structure changed from EAV into flat tables (没觉得 eav 有多慢，不过 magento 这么改肯定有它道理)
* Product custom URL rewrites redirect to SEF URL, rather than to catalog/product/view/id/ (这也是我考虑得比较多的问题，不过如果一个 product 归属多个 category，此改进后的 SEF URL 时能否正确显示 main category breadcrumb，能否配合 rel=”canonical” 使用？)
* Reimplemented frontend top menu rendering logic (cross-browser and usability improvements)
* Reviewed logic of the sales reports: Orders, Tax, Invoiced, Shipping, Refunds, Coupons
* Reimplemented bestsellers report
* Implemented 3D Secure validation for Maestro International and JCB cards
* Changed Shopping cart methods output (top + bottom): removed
Fixes
* Fixed read/write connection issue during new customer order place. See http://www.magentocommerce.com/boards/viewthread/19363/P0/
* Fixed tax rule ZIP range matching (numeric values were matched as strings)
* Various tax fixes
* Optimized search reindex process
Known Issues
* PayPal and Payflow pro modules are officially backwards incompatible.
* The `sales_order_aggregated_created` table was re-created with new columns, it is not backwards compatible.
Upgrade Path
* Once upgraded, go to system configuration section and re-enter all PayPal-related settings carefully. Make sure to specify the proper merchant country and email.
* To avoid fatal errors with Payflow Pro and Amazonpayments modules, before upgrading cleanup their settings from database:
DELETE FROM `core_config_data` WHERE `path` LIKE ‘payment/verisign%’;
DELETE FROM `core_config_data` WHERE `path` LIKE ‘payment/amazonpayments%’;
(之前我已经亲自动手把 Amazonpayments 删出了数据库，倒没发现 Payflow Pro 的问题)
用 How to improve Magento speed 作标题，似乎合适又不合适。因为大凡讨论 Magento 速度优化，总是谈怎么配置数据库、apc、缓存、负载之类，今天我想谈点别的。
目前我碰到的实际情况是：启用各种缓存并尽可能地将缓存数据保存在内存中，访问cms page / category page / product page 的速度都很理想，但 shopping cart page 是瓶颈，cart item 越多越慢，生成时间超过 2 秒都是不可接受的。所以我一直在想怎么让 shopping cart 生成得快一些。
上周无意中发现，如果 after add product to cart, redirect to shopping cart，那么 shopping cart 其实在 add to cart 时已经生成了一次，然后 redirect to checkout/cart/index 又生成了一次。生成 shopping cart，最耗时间的是针对每个 cart item，去检验每条 sale rule，每个 sale rule 再来若干个 conditions and actions，不慢才怪，何况又执行了两遍！
目前我还没有找到一个干净利落的让 shopping cart 只生成一遍的办法。不过另有一个服务器计划（跟 shopping cart 速度无关）已经在进行中，希望光靠服务器升级就能让 shopping cart 在两秒内生成。
今天启动 VirtualBox 时提示说有 3.2.2 版可用，于是在第一时间下载了 rpm 来安装。可是安装时提示一大堆的文件冲突，我按经验就先卸载老版本
yum remove VirtualBox
可是以前管用的命令，在卸载 3.1.8 版时不管用了，提示
No Match for argument: VirtualBox
No Packages marked for removal
大概 VirtualBox 改了 package name，惭愧，我也不会用 yum 来查看已安装的 package list。Google 了一会，这条命令倒是管用：
yum remove /usr/share/applications/virtualbox.desktop
于是见到了久违了的
Loaded plugins: refresh-packagekit
Setting up Remove Process
Resolving Dependencies
–> Running transaction check
—> Package VirtualBox-3.1.x86_64 0:3.1.8_61349_fedora11-1 set to be erased
–> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
VirtualBox-3.1 x86_64 3.1.8_61349_fedora11-1 installed 90 M
Transaction Summary
================================================================================
Remove 1 Package(s)
Reinstall 0 Package(s)
Downgrade 0 Package(s)
Is this ok [y/N]:
卸载后安装 VirtualBox 3.2.2 倒很顺利，安装后我注意到 package name 是 VirtualBox-3.2，以后如要卸载它就可以用
yum remove VirtualBox-3.2
VirtualBox 3.2.2 首次被 Oracle rebrand，但我没注意到有什么其他改动。
最近在听有声读物《赵赶驴手机奇遇记》，一个人听时有时能把自己听得很感动。大概自己骨子里还是属感性的。但从另一个方面想，其实我不觉得此奇遇记的情节有多吸引人，有声读物的速度也是慢吞吞的，这两因素综合起来，我不应该如此感动才是。那我究竟是被什么感动？
其实还是被自己的臆想而感动。比如，听到妞妞发给小强的一封邮件中的 flash 附件，我就拿我纵横网络几十年所见过的最漂亮的 flash 去想象。
突然我有了个 idea，网络小说是不是可以直接加入这些道具的连接，而不是单纯用文字码出来？这样读者直接就可以把妞妞制作的 flash 拉到自己的电脑上看，是不是比 3D 电影更有现场感？
网络小说就要充分利用网络的优势。只是这对作者就提出了更高的要求，估计得像拍电影那样，成立个剧组才能制作一个像样的网络小说。
最近我还写了一个程序，是为了一个非常特殊的促销模型写的：买 X 送 Y。具体是这样：从产品 A 组里每买 X 件，可以从另一堆产品 B 组里任选 Y 件，白送。但 B 组产品同时也是独立销售的，如果有人买了 X 件 A 组里的产品，同时买了 Y+1 件 B 组里的产品，那么其中 1 件 B 组产品不白送，该卖多少价就是多少价。
我认为 Magento 自带的促销模型已然非常强大，能用一个非常好用的 GUI 组装出千变万化的规则。无奈 my client 脑子更强大，总是想一些 Magento 天然功能以外的点子。我研究了 Magento 天然的 Buy X get Y，发现它是针对 X 和 Y 是同个产品而作的规则。论坛上也有人变通作出 buy X of product A, get Y of product B，但我这个难点是 get Y of any product from B group，meanwhile all products from B group are for sale，我想是不可能通过 Magento 自带的促销模型完成的。
设想一下，顾客购物车里有三项产品
因为 Magento 是逐条套用规则，再逐条套用 quote item，所以上述情况下，product B1 和 product B2 都满足规则，统统赠送。为了解决不该送的数量被送掉了的问题，必须抛弃 GUI 了，动手编程吧。还好，这个特殊规则并不难写，我写了两个小时，搞掂。
附注：不编程的话，还有一个不是办法的办法——turn product group B into a configurable product, and all the products become options。然后告诉用户，如果想得到免费赠品的话，add this configurable product to cart。但这样生添了一个 configurable product，其实这是 product group B 里产品的同质产品，同质产品却不同效应？这会给用户带来困惑，所以不可取。
最近我写了一个小程序：Deal of the day for Magento。
它主要有以下功能：
每天定时按预设权重随机抽取一个产品作为 deal of the day；在产品名称前加上 “Deal of the day:” 字样；设定它的 is_deal_of_the_day 为 true；设定一个 special price；归类到一个 sales category 下；同时把昨天的已过时的 deal 重置为原先状态。
Magento 支持 cronjob 我是知道的，但测试的第一个环节倒不是这个程序能否定时启动，而是程序能否完成独立完成这一系列的操作。为求简单，我把整个过程写在一个 frontend controller 的 indexAction 里，然后用访问 url 的方式去触发这个过程。我没有用 backend controller，因为我考虑到 Magento wiki 上介绍的 cronjob 万一不管用（之前我没有用过 Magento conjob），我还可以用 curl + linux crontab （这个我很熟）去触发这个过程。当然我会把这个 url 做得谁都猜不到，以策安全。
但是，在 frontend controller 里一运行到 $product->save() 或 $productCollection->save()，就抛出以下错误：
Warning: Invalid argument supplied for foreach() in /path/to/magento/app/code/core/Mage/Eav/Model/Entity/Abstract.php on line 995
初看这个错误，我总以为是 product EAV 某个 attribute 损坏了，因为我经常修改 product attributes，一不小心，改坏了哪个不该改的 attribute 也不奇怪。可难就难在 attributes 那么多，我无法知道哪个坏了啊。我围绕着 Abstract.php 995 行左看右看，没有头绪整整一个下午，最后发现，如果把同样代码放在 backend controller 里，product 就可以 save 了。
整整一个下午的时间只给我一个启示：product model 在 frontend 是只读的，估计又属于 Magento 安全机制范畴。联想到以前碰到的一个问题：如果用户在 Magento backend 已登录，能否在 frontend 探知，以便针对 backend 用户访问 frontend 时显示不对外人开放的内容（就像 wordpress 那样会在每个 post 显示 edit link）。但 Magento 把 backend 和 frontend 严格地分开，我研究好久，也没有让 frontend 访问到 backend session。
我想，打破 Magento 苦心经营的安全机制去做一些事是不可取的。比如 deal of the day 定时切换的功能，就用 magento 鼓励的 cron.php 去启动，非常的方便，也非常的安全。只是我空下来还是想钻牛角尖： Magento 是怎么把 backend 和 frontend 严格地分开的？只有知道了原理，如果、万一、假如、倘若我要 frontend 执行 backend 操作，也能做到了。
我是在 VirtualBox 下运行 Windows，经常碰到 IETester 一启动就崩溃，个别时候则能用上十几分钟才崩。总结了一下，发现运行 IETester 前先开一个 IE 窗口，就能很大程度上延迟 IETester 的崩溃。不晓得我的情况有没有典型性。
虽然这个窍门只能延迟 IETester 的崩溃，但我已经很满意了，毕竟 IETester 是一年半载用一次。