Tag: url rewrite

熟悉以后才知道它/他/她的缺点，这就是为什么离婚总是发生在结婚后。 我在了解wordpress的过程遇到这么点小麻烦：custom permalink structure为/%post_id%/%postname%/（其实seo并非非得这么设置，但这个设置是我们价值£750每月的引擎优化专家推荐的，姑且采用）。 我事先知道这个blog所在的服务器目前没加载mod_rewrite，因为这不是我的独立服务器，所以我并不能想加载什么模块就可以加载的。但我暂时不想为了贪图mod_rewrite就把blog转移到另一个服务器，至少在这个blog正式上市之前不想。保持一个主服务器在美国，一个大副服务器在德国，以后再弄一个二副服务器在英国当地，或者把大副二副换一换，这是我理想中的格局，不把鸡蛋放一个篮子里嘛。 但我有个毛病，明知不可为而为之，就是想看看什么后果。结果我知道了：后果很严重。一旦修改了permalink，wordpress就自动生成一个.htaccess，不管服务器是否支持，也不管blog是否真的需要这个.htaccess。由于服务器没有加载mod_rewrite，所以发生500 server error。于是我删掉了.htaccess，然后在后台想把permalink改回Default，wordpress不够体贴的地方就暴露出来了：只要一提交permalink的值，不管这个新值是什么，wordpress就自动生成.htaccess，这样我的服务器马上就500，php肯定就中止执行了，数据库就无法更新了。这个鸡先生蛋、还是蛋先生鸡的问题，我最后是直接操纵数据库才解决的（wordpress的数据库结构还是挺清晰的，我没看什么资料，凭着直觉找到wp_options table，再找到permalink_structure，删掉option_value就可以了）。 说了一个wordpress的缺点，作为补偿，我再说一个我感觉到的体贴，总是在细致之处。当初安装wordpress，ftp原码以后，installation要求把wp-config-smaple.php改名为wp-config.php，虽然改名不算麻烦，我还嘀咕它为什么不直接替我做了这件事。最近一次升级才让我理解它的良苦用心——升级时只要一股脑ftp所有文件，不用担心设置文件的备份恢复等等。我以前一直都不太愿意升级，就是怕备份恢复这些琐事，所以wordpress新版本出了很久了，可能新版本的新版本都已经出了n多个了，我才折腾了一下。有了这次无痛升级的过程，我以后一定会升级得很勤快的。 题外话：wordpress的permalink基于url rewrite，要求服务器服务器是apache+mod_rewrite，适用性小。要是谁能开发一个plugin，基于404错误捕获做permalink，一定会在广大小空间业主群里有市场。不过我不会想着去做这件事，从基于url rewrite到基于404，技术上是种倒退。要向前看，不是向钱看。