本Blog也乘着MovableType发布4.2版的东风，于昨天升级了系统，今天进一步改进了设置，换了一个同原先的模板相似的模板，粉色的。
这里对于MovableType 4.2 的重建效率，再次有了认识。
在升级后，重建的时间花了很久都没有好，一直挂在那里。
原先以为是Dreamhost的系统对于资源的限制，后来才发觉是没有打开模板缓存，造成不断的调用数据库，甚至有几次都出现超时错误。
现在我设置为，Widget模板中的，最近帖子，最近留言，和tag cloud都有缓存，重建本Blog，也只用了15分钟，共715篇文章。速度还是不错的。
升级的过程参考这里。
知道MT4.2 rc版发布后，就马上在我的MT测试平台上试了一下，升级非常简单，同之前我介绍的升级程序没有什么两样，都是直接SSH上主机，然后wget文件包，解压，复制覆盖原文件，然后用Firefox登录，提示升级，接着升级。
据说有非常好的性能，不过就我们这样的条件还真测试不了，也验证不了。
重建整个Blog的过程感觉没有快多少，不过在最后的一个页面有显示重建的时间。
其他部分从界面上来看同4.1没有差别。
最后我们来看在升级过程中MT的升级程序都做了些什么。
上个星期，收到Dreamhost的Email，他说我MovableTyp Blog所占用web服务器的CPU资源很高，超过200，不知道这是一个什么参数。
造成最大负载的两个文件，分别是
mt-comments.cgi
mt-search.cgi
当然他已经修改了该文件名，用户都已经访问不了了。
因为我使用的MT已经是最新的版本，不存在版本太旧的问题，那样我就只能修改着两个文件名，并且在mt-config.cgi中相关的参数，然后重建了所有有关的Blogs。
为了观察CPU负载的情况，按照Dreamhost的说明，我激活了resources的报告。
Users > Manage Users > Edit ， 在CPU Reporting的地方打勾，24小时候，就可以看到报告了。该报告是统计在此帐号下所有网站所占用的资源。
要查看的话，就是在浏览器输入http://www.yoursite.com/stats/resources/
用该帐号下任意网站的网址就可以。当然有password保护，这些查看的帐号设置，需要点击，Status > Site Statistics > yoursite.com ，选择# Users w/Access部分，就可以赋予一个查看权限的帐号。
目前我用的Blog系统是MovableType 4.01，相当强悍的一个系统，可是也免不了Spam的攻击。
一般Spam有两种，一个是留言Spam，一个是Trackback Spam。留言好办，通过图像验证文字来识别是否机器人还是活人，绝大部分都可以杜绝。而TrackBack 则比较麻烦，每天每分钟都有很多TrackBack过来。
那么系统内置的防Spam机制是怎样的呢？让我们来看看。
其Plugin系统中有一套SpamLookup的Plugins，一共三个。
分别是：
SpamLookup - Lookups 2.11，主要是针对IP地址进行检查，通过对几个数据库内IP地址的核对，来发现有问题的Trackback发送地址。在设置中可以设置IP黑名单服务器，域名黑名单服务器，还可以设置白名单。
SpamLookup - Link 2.11，主要是针对留言而来的，如果留言中有超过指定数目（比如三个）的链接，则认为有问题。
SpamLookup - Keyword Filter 2.1，主要是针对关键词进行比对，我们可以指定一些关键词，如果出现在Trackback中，就认为是Spam。
通常我设置这些Plugin都是在系统级别设置的，因为一个MovableType系统可以管理几个Blog，所以呢，Trackback扫描时会全部扫描的，在系统级别设置可以更为有效。
这里呢我把很常见的一些英文Spam关键词列出来，方便以后设置。
cialis
viagra
tramadol
ambien
amoxicillin
ultram
valium
ephedra
drug
oxycodone
ephedrine
xanax
今天在修改一个Blog的时候，想添加一个独立页面，就是MovableType 4.0 中的pages。
当我添加完这个页面之后，选择发布，返回的结果也是发布成功，可是在目录中就是找不到这个文件。
太奇怪了。
整整花了我20多分钟，才找到问题的根源。
先说说我走的弯路好了。
1）怀疑是权限问题，可是其它文件都可以生成啊！
2）怀疑是mt-config.cgi的设置文件，没有结果。
3）怀疑是Blog Setting中的设置有误，看了一遍，没有问题。
花了10分钟在Google上，也没有答案。
最后才知道是，模板文件没有做好mapping。
就是说pages模板文件，没有Archive Mapping到page去。
修改之后，再次发布，就没有问题了。
那么怎么会发生这种Archive Mapping没有设置的情况呢？就是因为我的Blog，MT4是从MT3.35升级而来，原来模板Mapping到归档文件，而修改模板时，没有把这个pages模板修改好，所以就发生了这种事情。
我相信Sixapart也有责任，在没有做好Archive Mapping的情况下，直接发布有关的页面，应该给予一个发布错误信息，而不是告诉用户，发布已经成功了。
这些天把Blog程序升级到MovableType 4.0之后，就在不断的修改模板。昨天在测试W3C的HTML标准时，发现一个问题。
就是MovableType 4.0的默认模板的一个问题。
单篇文章归档中有个留言表单，其中有两个属性，name 和 ID，根据W3C的说法，这是相同的，需要保持一致。
NAME and ID are the old and the new name for the same attribute. If both are defined, they should be equal.
而在MT4.0的默认模板中是不同的，name="comments_form" id="comments-form"。
修改如下：
Design > Templates >
在右侧可以选择Template Modules
接着选择 Comment Form
在第十五行，找到上面的代码，修改为 name="comments-form" id="comments-form"
重建单篇归档后就可以了。
第二个问题，不是错误，而是看着不舒服，对用户不好。MovableType 4.0的Atom模板中默认的是文章不断行，那么在输出后，用户看到的就是一长串文字，没有段落，没有分行。
修改的方法如下：
Design > Templates >
接着选择Atom模板
在第三十，三十一行的地方，可以看到这样两行代码，
<$MTEntryBody encode_xml="1" convert_breaks="0"$>
<$MTEntryMore encode_xml="1" convert_breaks="0"$>
那么只要把convert_breaks="0" 这部分删掉，重建这个atom.xml文件就好了。
这样在Google Reader里看到的也不会有问题了。
