自觉，感受与理解

前几天帮一个人把本地搞的 WordPress 博客搬到服务器上去。（我觉得对于这种新网站开通前的测试与制作，好的做法是在某个服务器空间进行而不是在本地进行）

因为他的空间是纯静态的，所以我在自己的站作了测试。

这种在本地用 XAMPP 建好了的、有初步内容的站再搬到服务器上的安装我还头一次遇上。

现在的问题是什么呢？是：本地的 WordPress 程序对本地数据库的链接不能在服务器空间实现。为什么不能实现呢？因为本地 WordPress 程序所连接的数据库不能在服务器上创建——导入数据表并不意味着创建了数据库（下详）。为什么不能创建呢？因为 cPanel 中创建数据库及其用户的名称的前缀都是限定了的——以 cPanel 用户名为前缀。

这样，我们的思路便是：

1）如何让 WordPress 程序连接到新建的数据库中

2）而这个新建的数据库的数据又是与本地的一致

第一点的解决方法是修改从本地上传的 WordPress 程序中的配置文件里的数据库参数。

第二点，导入数据表。但把数据表导入数据库并未完成工作。严格地说，不仅仅是把数据表导入数据库，而是把原有的数据表的数据导入到新建的数据表中。

而要实现后者，则需要：

要点一、新建的表前缀必须与他在本地建的数据库的表前缀一致

否则，导入的数据无法被 WordPress 程序使用。

在未导入数据库之前我没有去检查他的那个在本地搞的数据库的表前缀，结果，我随意地用了别的前缀（因为我的数据库已经有了wp_为前缀的表），而导致无法用上他原有的数据。

总结一下正确的操作：

一、新建一个数据库，表前缀同本地数据库的

二、修改原有的 WordPress 程序的配置文件，把数据库名称、用户名、密码修改为新建的数据库的

三、

要点二、原有的数据库文件导入以后，必须修改 wp_options 里的两个参数： homeurl 与 siteurl

这是网站换域名时所必需要做的步骤。

如果这一步没有做，这个 Wordpress 程序就不能访问了。

此外，对于他的这种情况，说点别的。

要点三、内部链接不要使用从本地硬盘根目录开始的绝对路径

虽然这一点跟我无关，但它对本地制作内容来说很重要。

这是一个很容易犯的错误。

他也犯了这个错误，结果博客里的图片全部不能显示。

正确的方法是用从域名根目录开始的路径。用这种路径，即使换域名也不会受到影响。

值得注意的是， WordPress 程序的日志链接是“虚拟”的。意思是，诸如 /2010/4/xxx 这样的链接地址并不代表真实的文件（夹）结构，在服务器里，并没有2010、4这样的文件夹。所以，这个地址并不代表目录深度。同样道理，/xxxx.html这样的地址也不代表日志是真正的静态HTML文件——尽管服务器端脚本的确在用户请求发出后生成了HTML文件。

昨天傍晚，网站突然不能访问，提示信息是帐号被suspended。也不知道是别人的问题，还是自己的空间的问题。

一、新空间

本来准备启用备用的空间的。后来邵杰决定买了一个新的空间。配额如下：

空间大小：300M（应该是硬盘空间加数据库空间）

每月流量：4.5G

域名数不限

子域数量不限

数据库数量不限

价格：每年50元（月付5元）

此外，买了一个月的独立IP（每月15元）。

（日后需要留意流量，看看这4.5G是否够用。不够用再买更多的流量配额）

二、恢复网站的过程

之前数据是有备份的，但不是最新的。

到本地一看，数据库文件是6日前备份的；硬盘文件就更早，一个多月以前的了。总的来说，没有太多的损失。

好笑的是，昨天下午刚一口气发布了三篇日志。网站不能访问之后，不断地按退回键，居然能把三篇文章的内容取回！

新空间帐号开通之后，再等了二三十分钟，新IP也到了。于是开始恢复网站。（显然，CPanel是基于IP的，所以一定要等新IP生效）

在本地，找到最新版本的文件（由于不是一次性整站备份的，这一步花了很多时间来合并分次分部分备份的文件），之后就分三次压缩，上传到空间。（不知道每次CPanel能允许上传多大的文件。后来才看到是50兆）

然后导入数据库文件。（数据库文件gzip格式压缩后为2兆）

然后在域名商 name.com 那里进行新IP的解析。（name.com 的 A 记录几乎是马上生效的，这一点老夫一直蛮欣赏的）

然后在 CPanel 里新建数据库。

由于数据库名称与用户名的前缀是限定的，且与之前的空间不一样，所以要对各个博客的配置文件进行逐一修改。

这样，几个程序便恢复了。

前几天新建的两个 Elgg 社区（处在测试阶段）的数据没有备份，所以暂时也没有去安装 Elgg 。

剩下的工作，便是把最近一周的文章重新发布了。

从 Google Reader 处获得日志ID，以保持日志URL不变。

昨晚，发现了一个似乎很棒的免费空间。为了不过度公开而被滥用，这里还是不说去它的名字好了，就叫“心灵自由”主机吧。:)

于是今天进行测试。一来熟悉这个空间，二来对 WordPress 3.0 Beta 2 的多站点功能进行测试。

一、多站点，正本清源

先说说“多站点”这个东西。以前人们说的是某个博客程序是多用户版，比如 WordPress MU 中的 MU 就是 Multi-user 之意。然而，这个说法是不准确的，单用户版的博客（比如 WordPress）也是可以有多个用户的啊。其实MU的多“用户”是狭义的，是指拥有站点的用户。所以，干脆说“多站点”更为清楚明白。

要是更准确些，则是“多子站点”，哈。

OK，现在名正了，则言顺了。以下开始介绍安装过程。

二、安装  WordPress 3.0 Beta 2

安装过程跟这里说的一样。

所以这里只说一些特别的事情。

（一）常规安装

首先是常规的安装。这没有什么好说的，但是我首次却安装失败了。原来主机名这个字段不是一般默认的“ localhost ”。

这是思维定势造成的错误啊。

（二）开始配置多站点功能

我用这个“心灵自由”空间在安装了WordPress 之后在控制面板的文件管理器（File Manager）里是看不到 .htaccess 文件的。

于是我自己把多站点配置时系统提示的代码拷贝，建立一个新的 .htacess 文件。（因为这个空间用的控制面板是 VistaPanel ，而不是一般的 CPanel，而且是我第一次使用，对界面还不熟悉，没有在文件管理器发现有新建文件的按钮——其实是有的，所以我现在本地用记事本建了一个 .htaccess 文件，然后上传（当然是用文件管理器在线上传了）至服务器。）结果，博客打不开了，出现 500 内部服务器错误。于是我探索究竟是怎么回事。在文件管理器里查看 .htaccess 文件的时候，发现文件开头有几个乱码，于是删除掉 RewriteEngine On 之前的乱码。结果就正常了。

（联想到以前的 robots.txt 也有类似的情况：在某种操作之后，服务器会自动在文件头部多加一个问号的。……）

如果是用文件管理器新建一个 .htaccess 文件，就不会发生 500 错误了。

（三）多站点是用子域还是子目录？

多站点配置中，我选择了子目录的形式。因为自己不是BSP，没有必要用子域名的形式。而且，现在一百块年费以内的虚拟主机服务，一般提供的子域名数量都很少。一般是两个左右。而且，要是使用子域名的形式，你给别人开了一个子域站点，而对方不怎么写东西，那不是浪费了一个子域配额？

虽然，现在用的这个“心灵自由”主机很大方，有几十个子域配额，但它是免费方案，日后有什么变故而搬迁主机了，到哪里找有那么多子域的虚拟主机方案呢。

三、多站点是怎么回事？

多站点基本配置好以后，到控制面板的文件管理器和 PhpMyAdmin 一看，程序是一个的，只是在数据库里多了一组子站点的表。嗯，这就是多站点的本义。也就是多站点与一个站安装多个博客程序之间的分别。

多站点能不能实现超级管理员跨站点统一 cookie ？如果不能，那只是减少了硬盘里的程序数量而已。

此文就此打住，别的东西以后继续测试。

目前，本站用了三个数据库。

考虑到将来所用的空间可能只有一个数据库，于是就打算把所有的数据表放到同一个数据库里。

首先，我用的是把源数据库表导出，然后导入到目标数据库，结果 PhpMyAdmin 提示已经有了这个目标数据库。也就是说，不能这样地把A数据库的数据导入到同帐号下的另外一个B数据库。

于是我探索有没有别的方法，在 PhpMyAdmin 中，我发现了“操作”标签下有个“复制数据库到”的功能，于是试一下。

先备份源数据库与目标数据库（安全原因，非必须）

然后选中源数据库，把“复制前创建数据库 (CREATE DATABASE)”这个选项的勾选取消，再填入目标数据库的名称，点击“执行”。

就这样，源数据库的表复制到了目标数据库了。

然后，在控制面板里，把 Habari 的 config.php 文件中的数据库名称改成新的数据库名称。 访问 Habari 博客，正常！

用相同的方法，把 wiki 的数据也转移了。

一

昨天帮一位朋友安装一个WordPress博客。 他暂时没有域名，就用了这里的一个子域名。

我在控制面板添加了子域名之后，发现不能访问这个子域名地址。不知道是什么原因。

想了一会，才想到，我的域名的DNS地址是域名商那里的，所以添加子域名不能仅仅在空间的控制面板这里绑定目录，还要到域名商那里添加A记录进行子域名解析。

一如以往，name.com的A记录马上生效。

WordPress 3.0 Alpha 版的中文语言包还没有出来，而且这个版本的功能还不确定，于是就先安装2.9.2版了。（最新版本为 WordPress 3.0 Beta 1 ）

因为那个博客是份电子杂志，有许多的栏目，所以我想找个杂志型主题（或者叫CMS主题、格子主题），但许多杂志主题都是需要有图片的，而这个博客的文章很多，如果用需要图片的主题，那么在寻找图片、编辑图片上的时间就很多了。 看了两个小时的杂志型主题，没有找到合适的。期间挑了一两个试用了一下，发现在没有图（缩略图）的情况下，页面排版变形得很厉害。所以，最后还是选用了 Arjuna X 。虽然这个主题有不少人在用，但的确很好看，而且高度可定制。

二

大前天，给另外一位朋友装WordPress。装了个 3.0 Alpha 版，虽然设置为中文版，但安装好一看，还是英文版的，原来是没有中文语言包。

这位朋友两个月前在Godaddy买了个域名，域名商附送一份空间，但是IP是被封了的，所以她一直没有用。我当时想到我的空间可以添加一个附加域名（Addon Domains），于是我就试着添加。

附加域名是绑定在子目录的，在为她的站添加子域名的时候，发现，不能在这个子目录下在绑定二级子目录了，只能绑定到另外一个一级子目录上。

三

WordPress 3.0 预计五月份出炉，到时候又有事情要做了：

能不能利用它的多站点功能，把这个域名下的多个博客用一个统一的帐号管理？

此外，一些事情还没有确定：

1、CSS样式继续优化

2、首页博客改版？

新的WordPress 3.0默认主题 Twenty Ten 就不用了。它虽然有特色，但个人感觉还没有以前的默认主题那么好看呢。

一、简化站内搜索

前两天，我把首页博客的站内搜索改成一个链接了（见下图）。

点击链接后，就转到这个向google 的 site 页面：

让人们自个儿搜就是了。

原来是有输入框，有提交按钮的，加上标题，总共三个东西，而这三个东西之间的间隔和样式不好搞，也很难看，所以干脆就像现在这样用一个链接取代。

其实，这个站内搜索本来就是用代码实现对google的数据的调用。所以不必搞得过于复杂。

我觉得很多人不会用站内搜索的，我觉得这一功能是为了自己而设的。:)

（现在这样，我在想，对于那些不太懂电脑的人，他们会用site吗？）

二、两种搜索表单

其实，首页博客还有一个搜索表单的，就是 WordPress 自带的。

我把它放在文章页的侧边栏（如下图所示）。

因为两种搜索方式各有各的优势和不足，所以两个同时用是最好的。:)

第一种的好处是，

1. 关键词会用红色来表示（所谓的高亮）
2. 有上下文
3. 搜索范围不限于文章正文，可以是评论

不好的地方是：

1. 页面要被google收录了才可以
2. 搜索结果很重复，在分类页面、标签页面、作者归档页面都是对文章页面的重复。（还好，我没有使用按月归档）

WordPress系统自带的搜索功能的只搜索文章，不好的地方是没有没有高亮显示，没有上下文。不过，可以这样克服不足：点击进入文章后用浏览器的查找功能来搜索关键词——如果有必要的话。

附：图片没有边框不好看，以后改改样式表。

这是传说中的Wordpress 3.0 新的默认主题。如果是真的话，对外观设计感觉有些失望。

在 IE 6 下，作者头像跑到右侧屏幕边界上去了。而且在17英寸的屏幕里，色块的搭配显得怪怪的（估计在宽屏下显得适当）。

蓝色区域是整个页面的重点，但如果放背景图的话就会拖慢页面的加载速度，不放背景图的话，这么大的一块又浪费了屏幕面积，也不好看。如果把网站标题和副标题放进去，整个设计效果不知道会怎么样。

页脚处，白色和灰色过渡不美观。

另外，新主题是用日志标题作为一号标题的，这是好的，但跟旧的默认主题不能兼容。

一个使用此主题的网站。

要不是 header 图片的装饰，这个主题在外观上，又有什么好呢？

这个修改版的主题，正文背景色色块与整个页面的背景色色块太不协调了，想k2 主题那样难看。没有了圆角，色块和色块之间过渡太突兀了。Header 图片的多彩跟其余部分的苍白太不协调了，过渡也不自然。

可以期待的地方是这个主题的代码吧。

在控制面板上发现，蜘蛛爬行所占用的带宽太大了。

尽管设置了 robots.txt 文件，但蜘蛛还是爬行程序文件的。所以，用IP拒绝管理器拒绝 mofuse 蜘蛛（MoFuseBot） 的访问（它占了全站46%的带宽！）（IP 208.82.114.116）。

单纯以上一项，（同时禁止了某个发俄文垃圾邮件的IP [188.92.72.161] ，而这不会占多大的比例），（从17日开始）效果就非常的明显了。

本文试图记录对 Wordpress 默认主题（3.0之前）所做的修改进行记录。

一、缘起

现在，默认主题已经改了许多了。包括增加了一些代码（不喜欢用插件，能用代码实现的功能就不用插件）。由于当时没有做好记录，现在想换主题而保持原来的功能就出问题了。比如，那段实现不同页面调用不同边栏的代码，那段利用tags来生成页面关键词的代码。

新增的页面模板还好，因为代码在主题文件那里。而对原有的默认主题文件修改部分，就找不回来了。

所以，教训是：每次改动做好记录。

二、修改记录

有些功能是用不上的，比如日历。所以，可以把其样式去掉，减少样式表的容量。此外，样式表太长了，查找起来也很不方便。

以下语句去掉（在FF下显示双箭头的列表符号）：

.entry ul li:before, #sidebar ul ul li:before {
    content: "\00BB \0020";
    }

更新：这样做的话，在非IE浏览器下，整个博客的列表符号都没有了。所以还是暂时重新添加上。等到日后有了新的解决方案（为边栏和别处的列表选用不同的类）再搞。

rtl.css 去掉。

……

（未完，待续）

从这篇文章可以知道 Wordpress 默认主题（Kubrick）的历史。

过几个月，Wordpress 3.0 就面世了，新的默认主题也将诞生。很期待。会不会又是一个经典之作呢？

由于现在 web 2.0 风格盛行，不会是那种花哨的吧？要是不好，还是继续使用现在这个修改版吧。

用关键词“Wordpress 默认主题”搜索了一些文章，几乎所有曾用过这个主题的博客都换了别的主题。看来每个人的口味是挺不一样的。

由于原来的账户只有每月1G的流量，而 zuoyong.org 一天就要用100兆。眼看只剩下一天的流量了，所以立马换服务器。

步骤如下：

• 用控制面板压缩、下载文件
• 导出数据库文件
• 在新空间上传、解压文件
• 导入数据库文件
• 修改 wp-config.php 文件的信息
• 在域名商那里修改A记录

完成！

再次感叹 name.com的A记录解析速度：马上生效的。这样，换服务器就不会出现网站的暂时不能访问了。

昨天到控制面板（CP）看了看，本站每天平均用掉100兆多一点的流量。远超出想象。

看来绝大部分的流量都是搜索引擎的蜘蛛和那些 feed 创造的，不然不会有这么多。像 Google 蜘蛛每天就下载3兆多。

今天打开邮箱，域名商美满来了一封关于域名实名认证通知的邮件。

于是就搜索了一下关于域名的政策。

这样，用国外主机服务的 cn 域名在不能备案而会被停止解析的前提下，也不用实名认证了。也就是说，手头上所持有的三个 cn 域名完成历史使命了。

如果充分发挥创意，也许在国际通用域名那里也能找到好的域名。

Reseller 的帐号突然给停掉，所以最近几篇日志没了，只能从 Google Reader 中找回来。

文件名保持一致（特别是链接中的日志流水号）。

评论就没有办法恢复了。

昨天 reseller 的帐号给停了。于是换了个服务器。

不知道为什么，重新安装的时候，默认主题的自定义模板文件的开头加了个在高度上居中的“.”。导致自定义模板文件的中文变成了问号。

另外，根目录博客的 “postname-postid” 超链接格式失效，提示的错误是无法连接到数据库。在另外一台服务器也是这样，只能把链接结构改成 postname 了。

后来，怀着试试看的想法重新换成原来的“postname-postid”结构，结果也正常。估计是新服务器空间的.htaccess文件的配置需要重新生成的缘故。

评论启用的话，就会不正常。所以不要在评论启用这个功能。

打开旧的日志，以前的p标签就没有了。所以要用的话就不能用它保存旧日志。如果要修改旧日志，就要重新分段了。

此外，有三个FCKEditor。不知道那个最好。

此外，有几个功能是不常用的。比如“打印”、“斜体”，此外，能用键盘快捷键的功能也没有必要使用图标——图标太多了，不好找。

论坛长于交互性，个人主页强于对主题的全面考察（只是，现在的中文互联网，好像没几个这样的个人主页了）。所以，个人博客，介于论坛与个人主页之间。

以下来自我在商业哲学评论上《博客正在走向死亡？不，它在回归本质》一文的留言：

我一直以来都在想一个事情：博客是以互动为主还是以个人想法梳理、系统化的呈现为主。若是前者，博客的交互性不如论坛，不如去开个论坛或者参与现存论坛的互动中去；若是后者，互动部分的文字的杂乱倒是破坏了所梳理的系统、增加了整个站点的信息冗余度。

不知道你是怎么看的？

“思想者的博客，必然有统一的价值观与世界观贯穿”，呵呵，想看到你能用页面（或者别的方式）来介绍一下你的纲领性的想法。这里文章数量挺多，不太容易找到你一贯的、整体性的想法。

读者或许可以从多篇文章里把这个东西总结出来，但是，由作者自己来做，应该更好。

看了许多许多的博客，大多数是日志的线性堆积，很少看到有一个宗旨、中心这样的东西。

现在我有了一个方案，就是可以在博客上建特殊页面来整理、归纳日志的内容。这样，就保持了日志的互动性，同时也有一个地方来梳理、沉淀、归纳总结、精化。

吓了一跳。

以前在万网解析的时候，是要几个小时的。

这样是很方便的。

更新（一月十七日）

可以用这个方法来解决在后台自动升级由于内存不足造成的失败：

在config.php 加入这么一个语句：

define('WP_MEMORY_LIMIT', '64M');

此外，这语句不是对整个网站的，如果一个站有多个 Wordpress 博客，就要一个个地添加了。

失败一次以后，用以前的方法——暂时停用大部分插件——也不行。而在另外一个服务器的相同版本的程序却可以一次自动升级成功。

既然2.9没有什么特别的功能，下次再看看吧（也许在升级之前用301永久重定向到另外一个服务器了，这样就是直接上传最新的版本了（这种新程序就数据的方式可能有问题的））。

这个空间没有在线压缩功能，就先不折腾了。

另外，升级了的版本的后台不见得比以前快。

*

升级之前备份数据库文件的时候，试了试用 gzip 格式，压缩效果挺好的，接近1/5。

鉴于Wordpress的优异垃圾评论过滤性能，实验一下在后台把“评论者必须成功发表过评论”选项取消，也就是评论无需人工审核就直接显示，看看效果如何。之前的情况是，只有少量的人工广告评论。这问题不大。