芳草苑

Category: 小小草

IT 技术领域学海无涯。其实任何领域都学海无涯，无非 IT 发展太快了，让我有更多嘘唏。希望我掌握的技术有如小小草，虽然渺小，却有旺盛的生命力。

  • More About WordPress Uploads

    昨天写了一篇Migrating WordPress Uploads，我意犹未尽。

    每上传一个文件，WordPress会把它放在”Store uploads in this folder”指定的目录，但在post中都已转化成绝对路径来记录 Path 和 URL 。我不欣赏这种做法，因为这对服务器环境养成依赖。

    WordPress核心对”Store uploads in this folder” 和 “Full URL path to files (optional)” 不重视，造成某些插件也无视这两个options的存在。比如WP Shopping Cart，根本不去探测这两个值，直接就把产品图片等文件保存位置设定为wp-content/uploads/wpsc/… 。

    为了让WP Shopping Cart能够按照我的要求摆放文件，我只好修改了wp-shopping-cart.php，在 $upload_path 和 $upload_url 被调用之前，给它赋予正确的值。

    $myuploads = wp_upload_dir();
    $upload_path = $myuploads [‘basedir’];
    $upload_url = $myuploads [‘baseurl’];

  • Migrating WordPress Uploads

    我的blog迁移过一次，上次主要是为了更换domain name。今天我又成功地迁移了两个blog，这次主要是为了享受WordPress 一次安装，多处使用 带来的方便。

    但我不得不承认，WordPress迁移不是件容易的事。大部分的迁移工作是更该数据库里uploads文件的路径，这些值都是用绝对路径保存在数据库了。必须一一更改这些值（我喜欢export-replace all-import），否则文件位置的变动将导致链接失效。

    WordPress用了两个options来设置Upload Path & Upload URL，为什么不基于这两个值用相对位置来管理上传文件？相对位置的好处是：如果移动或改名了uploads文件夹，就只要修改两个options，而不必在posts和postmeta两张表里大动干戈了。

  • The First VirtualHost Is The Default

    今天在apache上搞基础建设，为一个小小的问题排错排了很长时间，事后想想，不就是一个简单的VirtualHost默认值的问题嘛！排完以后我才想来，其实以前已经碰到过这个问题，在一个问题绊住两次脚，浪费了一天，真是不应该！

    每个VirtualHost里有一个ServerName，还可以有零个及以上ServerAlias。假设一个 domain name example.com 的 ip address 是 201.202.203.204,  如果 example.com 在 .conf 文件里找不到同时匹配的 VirtualHost 和 ServerName (或ServerAlias)，那么 example.com 将使用首个匹配的 VirtualHost （通常是 *：80 或 201.202.203.204：80）的设置。

    我把apache VirtualHost的心得写下来，免得以后再绊脚。

  • WordPress Commerce

    在WordPress基础上建设网店不是不可以，但毕竟blog和e-Commerce各有侧重。要做e-Commerce，自然而然就要求设置产品属性，相关产品链接，库存管理，价格管理，客户管理，销售报告等等。WordPress装个插件，如Instinct Entertainment e-Commerce plugin （WP Shopping Cart) for WordPress，做得相当不错，能完成基本的e-Commerce需求。

    但WP Shopping Cart只能是个轻量级的e-Commerce解决方案。它至少无法：

    1. 批处理
    2. 动态过滤产品 (按自定义属性)
    3. 产品套装模型
    4. 复杂价格政策
    5. 客户分组
    6. 自定义报告

    在WP Shopping Cart基础上改进一下，让它完成以上功能也不是不可能的。但我认为，如果你有以上需求，选择WP Shopping Cart就是个错误（谨记：WP Shopping Cart只能是个轻量级的e-Commerce解决方案）。

    此外，我在考虑：装了WP Shopping Cart plugin，所有的产品页面都是通过一个WordPress页面 (默认叫product-page) 调用，产品页面都是product-page子页面，本身不利于搜索引擎优化。而且，WordPress自身或WordPress SEO Plugins带来的搜索引擎友好的众多特性，产品页面无法享受到。虽然WP Shopping Cart针对SEO做了很多考虑，但WordPress SEO是众人拾柴，WP Shopping Cart SEO features无法与WordPress SEO features匹敌。

    其实大部分企业网站并没有购物车需求，只是一个简单得不能再简单的产品或服务展示厅(brochure site or showrooms)。如果WordPress category, tag, cusom field, search应用得恰当，不借助于e-Commerce plugin，也能用WordPress组建一个brochure site。如想要SEO，一个post对应一个产品是最佳方案。设计一个brochure theme就够了。

    找来找去，我没找到一个像样的 (适合摆放产品的) brochure theme。

  • An Ideal Way to Take Repeat Payments for Phone and Mail Orders

    We have lots of regular customers place orders over the phone. I am looking for a solution which can satisfy:
    1. We would not like ask credit card details every time;
    2. We can not store credit card details;
    3. It looks like a combination of Virtual Terminal and Recurring Payments, but these recurring payments do not have a fixed date and fixed amount;
    4. If possible, we create profiles for our regular customers. So, we, the mechant, can enjoy the facility of express checkout.

    Does PayPal, WordPay, or any other payment providers offer this solution?

  • Use Google App Mail In Corporation

    这里我只是想谈谈企业和个人在使用email中冲突，以及如何有效地应用Google App Mail来避免冲突。

    员工一录用，很多企业都会给员工一人一个企业域名、个人名字前缀的邮箱。作为对外业务联系的邮箱，应该保持稳定，但员工跳槽是普遍现象，英国人更喜欢跳槽，造成企业邮箱地址更新频繁。试想以下两个情景：

    情景一：企业开有 paypal 帐号以及多个银行帐号，由会计人员负责，每个帐号都会要求一个或一个以上联系人的电子邮件。会计人员换动，要一一更新这些帐号里的电子邮件地址吗？

    情景二：企业对网上业务的依赖度很高，企业对网上业务进行了细分，并有多名专员各自负责某项业务。网上业务对应的活动会直接通知到专员的邮箱。专员离职或岗位调动都要在网上业务的后台程序进行调整专员的电子邮件地址吗？

    我们很难找到一个现成的工具能在情景一和二快速、批量地修改电子邮件地址。

    也有企业干脆用sales, accounts之类的position 描述作为邮箱前缀，对外进行业务沟通。我不喜欢这样，发自sales@company.com的邮件给客户的第一感觉是冷冰冰，缺少personal contact的感觉。

    我们需要在稳定性和个性化之间取得一个平衡。My best practices are –

    1. 创建基于个人名字（personal.name@company.com）的邮件帐号
    2. 创建基于岗位名称（position.name@company.com）的邮件列表
    3. 把员工邮件帐号添加到他的岗位的邮件列表（基于这种目的创建的邮件列表通常只有一个邮件帐号，但一个邮件帐号可以加入多个邮件列表）
    4. 情景一和二采用position.name@company.com注册和发布联系人地址
    5. 发邮件时，发件人显示personal.name@company.com
    6. 客人第一次联系，如果是通过填写网上询价单的方式，业务的信息通过position.name@company.com的列表送达了personal.name@company.com，回信就没必要再通过position.name@company.com。
    7. 因为position通常比personal稳定，在情景一和二时，我们所要做的，就是在Google App Mail, Manage this domain, User accounts, Mail list里更新邮件列表
    8. User accounts, Nickname 方法 alias position.name to personal.name 也可以取得跟Mail list类似的管理效率，但如果position.name@company.com是一个nickname，如果要改变它的归属，就必须先删除position.name@company.com，然后到别人名下再创建一次nickname，虽然这过程最快可以在几秒钟完成，但在几秒钟内仍存在丢失发给 position.name@company.com的邮件的可能。用mail list就很完美（可以先添后删）

  • Windows更新安装失败的解决办法

    Windows毛病还不少，而且还摸不着原因，这不是，Windows更新下载来安装却总是失败。幸好，尽管原因不明（真搞不懂，Windows设计出这么复杂的自动更新，却无法把自己装上去，那还叫自动更新吗？），办法还是有的。

    办法一，把以下命令一个个敲一遍（太多了吧？！那看看办法二）

    1. regsvr32 wuweb.dll
    2. regsvr32 wuapi.dll
    3. regsvr32 wucltui.dll
    4. regsvr32 wuaueng.dll
    5. regsvr32 wups.dll
    6. regsvr32 wups2.dll
    7. net stop wuauserv
    8. net start wuauserv
    9. net stop bits
    10. net start bits
    11. net stop w32time
    12. net start w32time
    13. net stop msiserver
    14. net start msiserver

    办法二：（与办法一出处不同，对比之下只是办法一的简化版，可能办法一适用性更广，但我只用办法二就能解决我自个儿碰到的问题）

    1. net stop wuauserv （停止自动更新服务）
    2. 32位版的用户：regsvr32 %windir%\system32\wups2.dll
      64位版的用户：regsvr32 %windir%\syswow64\wups2.dll
    3. net start wuauserv （这里当然是重启自动更新服务啦）

  • 系统还原和安全模式

    办公室有台电脑得了怪病：如IE能正常访问网页，但打印不出网页，每次打印都是空白，而且页脚的url不是网址，而是本地缓存的internet临时文件名；又如outlook express里试图直接打开一些.doc附件，word启动以后就停止响应…

    我实在google不到解决方案，只好用上系统还原。无奈，无论我选择哪个还原点，电脑重启以后都遗憾地通知我系统无法还原到这个系统检查点。难道要我用绝招——重装系统？汗，幸好用”system restore not working”搜到一个方案：进入安全模式，然后再运行系统还原。一试，果然管用！

  • 关于WordPress一次安装，多处使用的构想

    首先，我不能用WordPress Mu版。因为某些plugin 和 theme不支持Mu版。况且，WordPress Mu版相对于WordPress的特有功能是用户自助申请Blog功能，而我所谓“多处使用”，只需要集中管理一个WordPress框架下多个网站，多个网站能同步升级WordPress程序部分，所以，Mu版在此没有优势。

    其次，我肯定不是有WordPress一次安装，多处使用需求的第一人。我参照了前人的做法，但觉得它们不够完善。不完善之处主要是前人的想法要求多个网站指向同一个document root，而不同的网站很可能装有其他程序，还会有不同的图片等其他文件。例如，domain1和domain2共用一个WordPress，那WordPress以外的静态页面或静态文件，比如domain1/static-page-or-file-outside-of-wordpress，就会被domain2/ static-page-or-file-outside-of-wordpress访问到。

    再次，我的构想适合在独立服务器LAMP环境下实现。以下是具体的实现步骤：

    1. 在一个主控域名上按常规安装WordPress。假设主控域名是domain1，它的document root是/www/domain1。
    2. 假设第二个域名是domain2，它的document root是/www/domain2，WordPress甚至可以安装在子目录/www/domain2/wp。
    3. 除.htaccess和index.php以外，把/www/domain1下WordPress其他文件和文件夹用软连接的方式连接到/www/domain2/wp。多数情况下，不同网站会有不同.htaccess的要求，所以我建议.htaccess还是单独建立为好；domain2的index.php则需要稍作修改（大家看着改吧，应该是很简单的）。
    4. Domain1的wp-config.php则需要为新增的domain2添加一些配置，为不同的域名启动不同的数据库、表、keys等。
    5. Domain2的WordPress安装完成后，进入后台，调整uploads目录的位置，默认是wp-content/uploads，应该改为绝对路径，如/www/domain2/wp/wp-uploads。Full URL path to files (optional)不再是optional，必须作相应修改以便前台能访问到上传的文件。我曾经为隔离domain1和domain2的uploads考虑得死去活来，为了属于domain1 的 static-page-or-file-outside-of-wordpress 不被 domain2/static-page-or-file-outside-of-wordpress访问到，我想过在domain1下建立软连接到domain2的uploads目录，然后用防盗链的方式防止 domain1 和 domain2 对各自 uploads 目录的相互访问。但最后才发现，WordPress uploads folder本来就支持绝对路径（默认值是相对路径），一个复杂的问题就这样轻松解决了。

  • 802.11n果然不同凡响

    我不是追新族。在802.11g还大行其道的今天，我本没有打算升级至802.11n。但因为需要在一幢大楼内组网，我想了好多方案，比如：

    • 用homeplug（怕途中电表太多干扰太大，觉得这个方案不好）
    • 用WDS，也就是wireless repeater（买了belkin的802.11g repeater，经常死机，换了一个也是如此，退货；linksys也有一款repeater，贵于belkin，但我对linksys的产品没信心，懒得买来再退了）
    • 用高增益天线（ebay HK有人卖得很便宜，贪便宜买来发现是烂货，教训啊，千万别上ebay买东西——其实我知道的，但就是禁不住便宜的诱惑，抱着反正几镑钱，就当扔水里也不太心疼的心理又去买了个教训）
    • 用高功率无线路由（恰好我有一台2Wire 2700HGV，但就算调到100mw效果也不理想）

    802.11n的优越的传输性能我有耳闻，但百闻不如一见，我用买一个linksys repeater同样的价格买了一套Tenda 802.11n (draft 2)无线路由加USB无线网卡，两地用802.11n接通以后，效果出奇得好，已经完美解决我中长距离组网的需求。尽管走了很多弯路才落实这个方案，但我还是非常高兴。

    而且，我发现Tenda的无线路由还带有WDS功能，这可是802.11n级别的WDS啊，比起单纯一个linksys repeater，仅是802.11g级的，要划算好多好多啊。