最近在一个 Magento 网站上大幅调整了 catalog structure。我先在测试服务器上调整产品属性、目录属性等，然后把测试服务器数据库里所有 catalog 和 eav 开头的表导入到生产服务器。因为生产站点的销售没有中断，我不能简单地从测试服务器往生产服务器导入整个 magento 数据库。 这次升级初看很成功，随后就发现百密中有一疏。我装有 protx standard (for SagePay Form integration)，顾客在重定向到 SagePay 付款时，表单预填的数据是别人的。原因是测试服务器的跟销售有关数据是生产服务器若干天前的，eav_entity_store 表里保存有 increment_last_id，我从测试服务器往生产服务器导入所有 catalog 和 eav 开头的表，导致 magento 再次分配几天已分配过的 order ID 给新订单。如果顾客在重定向到 SagePay 后点击 cancel，会导致同订单号的老订单 status change to cancelled。 ID 重复是一个很低级的错误，我不应该去导入 eav_entity_store 表。我是知道这张表的作用的，这个错误应该归咎于我考虑不周到。 Protx standard 这个模块也不够周到，我用的版本比较老，不知新版是否在这方面有改进。
Day: August 5, 2010
Visual programming using Google Apps Script
Google 很强大，虽然我不止一次地说，但用了 Google Apps Script 以后，我还是想再说一次。 Many of Google Products are helping people use the web. Google Apps Script help me visually programme route jobs. 在工作流中，有很多变化着的因素，导致很多程序是一次性的。快速变化的环境不要求程序很智能，但要能快速响应业务的变化。很多时候我很郁闷——因为编程速度跟不上业务速度，导致人工重复劳动。 Google Apps Script 是目前跟我理想中的 crm, accounting 最接近的解决方案。
Install Zend Server with Plesk
据说 Zend 正在跟 Plesk 探讨怎么让他们的产品相互兼容。 我没那么高深，无法让 Zend Server 完全兼容 Plesk，但可以做到—— 前台用上 Zend Server 版的 php （Plesk 前后台使用两个安装的 php），尽管 Plesk 后台误认为 php module not installed。我强行修改了 psa 数据库里的数据，改了什么我不记得了。说实话，把 Zend Server 和 Plesk 跑在一起意义也不大。