我多次把 Magento 从一个服务器移动到另一个服务器，一直认为 Magento 不在意安装路径的改变，因为 Magento 总是在运行时检测安装位置（对比 WordPress 把 server absolute path 保存在数据库里，而且每个上传的文件都要保存一遍，不可取）。但今天我发现我错了：Magento downloader 仍保存有部分 server path 的信息，迁移 Magento 到新服务器后，Magento connect 不能正常工作。 有人提供了以下方法查找替换 downloader 目录下所有文件里的 OLD_PATH 成 NEW_PATH： //shows all files with OLD_PATH element find . -type f -exec grep -q “OLD_PATH” ‘{}’ \; -print //Replaces OLD_PATH string in all occurrences in every file to… Continue reading Magento downloader remember server path
Tag: wordpress
I am with Fedora
今天 Fedora 11 alpha 发布了。Fedora 10 我还没摸熟呢，Fedora 11 就来了，真让我高兴之中疲于奔命。 无意中还发现 drupal, mediawiki, planet, wordpress 都包含在 Fedora 发行包中，这是不是跟 Fedora Project 自身使用了这几种技术有关？我的意思是：为什么不包含别的 packages，比如 magento, joomla, etc? Fedora 倡导的东西咱就支持一下。不管有用没有，咱全安装了（也就 drupal 暂时派不上用场）。
No deplicate posts any more in WordPress
刚用上WordPress后，我发现WordPress一个不足之处——同一个post_id的post，可以用不同的url来访问。 以此blog为例，我设置permanent link structure为/%post_id%/%postname%/。我认为post_id查询最快，postname又是meaningful string，最有利seo，所以我把两者结合起来了（后来据说顶层目录的文件最利于seo，所以我更喜欢设置permanent link structure为/%postname%_%post_id%.html，但据说Google不吃这一套，那我就没必要为一些小引擎去劳师动众修改现有的blog，扯远了）。 当permanent link structure存在post_id和postname两个参数时，post_id起决定作用。早期版本会完全忽略postname，造成只要post_id是正确的，任何杜撰的postname都会被承认。设想一下，如果我发布了一个post以后修改了postname，搜索引擎读到不同url上的相同内容，肯定会降低对此blog的评价。 所以，当时我想改一下WordPress程序逻辑，当post_id存在但url中的postname不等于数据库中的postname时，返回404页。但是我还没来得及做这个修改，今天惊喜发现WordPress 2.6 (可能更早的版本已经实现了这个修改) 已经会把/(post_id)/(incorrect_postname) 301跳转到 /(post_id)/(postname)，这应该比我设计的方案更完好，我非常喜欢WordPress的体贴。
Change WordPress Table Prefix
WordPress 安全白皮书里倡议其中一条是采用别人猜不着的数据表前缀。 想必很多WordPress Blog安装时都是采用默认的数据表前缀”wp_”，那么要让”wp_”迁移到”unguessable_”，要做三部分工作： 修改表中数据，就WordPress当前版本2.6.5而言，有三处要改 在表”wp_usermeta”中，”meta_key”字段，把”wp_capabilities” 改为 “unguessable_capabilities” 在表”wp_usermeta”中，”meta_key”字段，把”wp_user_level” 改为 “unguessable_user_level” 在表”wp_usermeta”中，”option_name”字段，把”wp_user_roles” 改为 “unguessable_user_roles” 重命名数据表（RENAME TABLE tbl_name TO new_tbl_name[, tbl_name2 TO new_tbl_name2] …） 修改wp-config.php，$table_prefix = “wp_” 改成 “unguessable_” 还不算复杂吧。有个plugin据说能帮你自动迁移表前缀，但我没试过，毕竟表前缀前年改一回，何必依赖一个素不相识的plugin呢？ 顺便说一句，如果不做第一部分工作（修改表中数据），前台能可以工作，但后台会有”You do not have sufficient permissions to access this page.”，这错误提示很容易让人联想到密码的hash变了，是老密码无法使用了吗？其实不是，错误跟密码无关，密码还是那个密码。
qTranslate Update
我很喜欢qTranslate这个插件，尽管我没在这个blog上使用。 qTranslate更新很快，最近几次我注意到每次WordPress一有更新，qTranslate随后就有更新。 但我就不明白了——每次WordPress更新后，老版本的qTranslate就工作不正常了。编辑时，qTranslate is disabled（当然这也不是什么大不了的缺陷，反正我更习惯于直接写代码）。非得qTranslate出一个更新，这个毛病才能解决。 是不是秦谦老兄写的qTransalte不太符合WordPress Plugin规范？
Create Effective Backlinks
要有好排名得有好的backlinks，这个道理我很早就知道了，但一直未及深入研究。最近读到一篇文章很有可操作性，我准备依样画瓢。 Use wordpress.com for creating your blogs. – WordPress has grate on-site SEO and blogs on WordPress.com get indexed pretty quickly. Once you create an account there, you can create unlimited number of blogs without having to register any new accounts. 不指是直接使用wordpress.com的blog好，还是自己安装一个wordpress blog好？ Write more then one post per blog. – Google loves backlinks that… Continue reading Create Effective Backlinks
What Makes A Good Web Program
我看问题可能有局限性，但我现在判断程序好坏的必要非充分条件之一是：这套程序能否充分利用Apache Url Rewrite。换句话说，如果是php程序，这套程序的前台页面是否由一个index.php来产生。 以这个条件来看，Zen Cart算好，Magento当然更好，osCommerce就不算好；Drupal / Joomla 都算好，WordPress 当然算是典范，Xoops 就不怎么样了。 也是因为这个原因，我放弃关注Xoops——痛苦地放弃，尽管曾经它是我的最爱，尽管它有某些功能很独到。
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两张表里大动干戈了。
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解决方案。它至少无法： 批处理 动态过滤产品 (按自定义属性) 产品套装模型 复杂价格政策 客户分组 自定义报告 在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就够了。… Continue reading WordPress Commerce