关于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环境下实现。以下是具体的实现步骤: 在一个主控域名上按常规安装WordPress。假设主控域名是domain1,它的document root是/www/domain1。 假设第二个域名是domain2,它的document root是/www/domain2,WordPress甚至可以安装在子目录/www/domain2/wp。 除.htaccess和index.php以外,把/www/domain1下WordPress其他文件和文件夹用软连接的方式连接到/www/domain2/wp。多数情况下,不同网站会有不同.htaccess的要求,所以我建议.htaccess还是单独建立为好;domain2的index.php则需要稍作修改(大家看着改吧,应该是很简单的)。 Domain1的wp-config.php则需要为新增的domain2添加一些配置,为不同的域名启动不同的数据库、表、keys等。 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本来就支持绝对路径(默认值是相对路径),一个复杂的问题就这样轻松解决了。

WordPress编辑应该避免使用浏览器的后退

我刚才吃了点苦头:我写了两篇贴士,一篇贴士写好发布后,我使用了浏览器的后退按钮,回退到post-new.php页面,这时页面表面上看跟Write Post的页面一模一样,但post_id已经产生,而且跟第一个贴士的id一样,结果第二个贴士保存时,就把第一个贴士给覆盖了。郁闷,只好重新输入。 所以我想提醒大家,尤其是WordPress的编辑,应该避免使用浏览器的后退功能。不过,WordPress也应该更贴心一点,post-new.php应该关闭cache,这样每次进入post-new.php,不论是用浏览器的后退或是点击Write -> Write Post,每次都更新post_id,这样就不会覆盖以前的贴士了。这时的post_id应该是临时的,所以不用担心多次进入post-new.php页面导致数据库保存了空内容的贴士。 我特别喜欢程序在处理完post data以后作一个redirect,这样也可以避免上述数据覆盖的问题,而且解决后退时浏览器提示页面过期、要重新发送数据种种的不友好问题。Header redirect已成我的习惯,这么做好处很大,迄今也没遇到一起redirect after post带负面影响的情景。不过,我发现有同样习惯的人不多。难道有很多不好的scenarios我没想到?

节选设置

大家普遍认为WordPress自带的excerpt功能太弱,于是extend excerpt plugin很多,但我没找到我想要的。这些excerpt plugin大多为了解决html标签截断的问题、字数还是字节的问题、显示格式问题。 我想找的excerpt plugin是为了解决excerpt的缺省值问题,我最喜欢的excerpt值是: 如果post excerpt不为空,显示该excerpt字段; 否则,如果post content中含有<!––more––>标签,显示<!––more––>标签之前的内容; 否则,读取post content的既定字数。 我就这么一个简单的要求,怎么没有现成的excerpt plugin呢?

WP Shopping Cart Not Support utf-8

Recommended by WordPress, I installed one of business blogging plugin – WP Shopping Cart. Although I don’t think it’s a good idea to sell anything on this blog, I wanna try the plugin by categorising under WP Shopping Cart my investigation to hundred brands in Bicester Village. To my disappointment, this plugin (ver 3.6 beta… Continue reading WP Shopping Cart Not Support utf-8

Why Google Analytics Tracking Code Was Not Included In Source Code?

这个博客从一开始就装了Google Analytics for WordPress,但我在前台页面的源代码里总看不到tracking code,我为解决这个问题陆陆续续花了不少时间找原因,把plugin反复deactivate and activate,甚至卸载plugin再重装、切换theme,都没见source code 包含任何analytics的字眼。 我在wordpress.org寻求前人的经验,也有人说Google Analytics for WordPress这个plugin无法工作。他最后是放弃了Google Analytics for WordPress,还推荐了另一个google analytics plugin叫sem google analytics。但是我见Google Analytics for WordPress功能远比sem google analytics强大,不舍得放弃。 试装sem google analytics后,我查看了前台页面的源代码,代码里有一行注释,说sem google analytics不追踪admin登录状态。一语惊醒梦中人!同理,我的Google Analytics for WordPress一直就是正常工作着的,只是我一直在admin登录状态去查看源代码,也就无法看到tracking code,但Google Analytics for WordPress一直没给任何提示说明这一点,导致我瞎折腾,这是Google Analytics for WordPress做得不够好的地方。 花了很多时间,总算搞明白一个粗显的道理:Google Analytics for WordPress不追踪admin登录状态。

wordpress title不见了

昨天在公司的blog上做搜索引擎优化,做到后来既然把blog homepage的title弄没了,一时没找到原因。 今天在这个自己的blog上只想要添加一个analytics,我用的是google analytics for wordpress plugin 2.0,当我把track帐号输入以后,发现title又一次消失了。title的消失是不是由这个plugin引起的?这有待进一步试验。可现在头痛的问题是:无论我删除了track account,还是deactivate plugin,title还是不回来。难道我错怪google analytics for wordpress plugin?

wordpress在不同域名间的迁移

忙乎了一天终于把这个blog从另外一个域名、另外一个服务器迁移过来了。迁移的过程是比较痛苦的,因为我一开始把迁移想得太简单了。这怪我想当然,前几天wordpress版本升级给我的印象太方便了,只要把文件一股脑上传就可以,因此我以为迁移也只要把文件一股脑拷贝、数据一股脑导出再导入就可以啦。 我一股脑做好迁移以后,敲入新网址,满怀信心期待出现的页面没出现,确切地说是一片空白(我原以为最糟的情况也就是出现带有一些broken links的页面再作调整)。费了好久才查出是memory_limit值太低,这时我已经把wordpress那几个table的数据 delete/import了好几个来回了。 虽然这次迁移费了点时间,但总算有了经验:不要相信那些所谓wordpress data migration插件,甚至连wordpress内置的export/import也不好用(export/import仅适用于给数据做备份和恢复)。wordpress(2.3.1版)内置的export/import至少有以下缺点: 不能自动转换域名 不能自动转换document root 不能导入option import采用web upload,自然文件大小受到upload_max_filesize限制。 import后个别category出现了两次(原因不明) manage uploads丢失了thumbnails的链接 我认为最好的办法是,把原数据库里的数据导出成sql格式,用文本编辑器在这个sql文件里做两次查找和替换,新老域名和新旧document root各做一次(文本格式就是好啊,给人一种看得见摸得着的感觉,踏实)。然后在新数据库导入这个sql文件就可以。只要网站的directory structure保持不变,我相信这就是wordpress blog迁移要做的全部工作。

发现一个wordpress不够体贴的地方

熟悉以后才知道它/他/她的缺点,这就是为什么离婚总是发生在结婚后。 我在了解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,技术上是种倒退。要向前看,不是向钱看。