那么，为什么我还要专门写一篇日志来介绍这款插件呢？一来，为我这久不更新的博客带来点生气。二来，Google XML Sitemaps 即将迎来一项革命性的变动。OK，那么接下来，我就把这款插件即将带来的新功能做下简单介绍。

自从 WordPress 3.0 发布以来，很多插件都针对主程序的变动做了相应的调整，Google XML Sitemaps 也不例外。但是，当 WordPress 3.0 启用 Multisite 功能后，各位会收到一条警告信息，它会通知您的插件无法在 Multisite 模式下使用。虽然网络上已经找到如何修改这款插件的代码来让它可以使用。但为了以后方便插件的更新，以及出于一些安全性的考虑，很多人还是希望插件作者尽早开发出适合 Multisite 模式下的插件。

当然，插件的作者也没有闲着，而且已经放出了早期的测试版插件供大家试用（看清楚，是试用，而不是使用）虽然我在测试站上安装后，并没有发现什么大问题，但毕竟不是正式版，各位还是先行测试然后再投入正式使用。

本次更新，也为我们带来了一些新的特性：

• 动态创建 Sitemap
  不再创建静态的 Sitemap 文件，而是动态的生成 Sitemap 信息页面。这将解决大多数索引页面出现的问题。
• Sitemap 索引页面变更
  文章等链接将收录到子页面中，主索引页面仅对这些子页面进行索引。所以，我们可以收录比以前更多的内容。而收录的内容按月份或日期进行分页。
• 支持 WordPress MU
  由于不再创建静态的 Sitemap 文件，所以新版将支持 WordPress MU 和启用了 Multisite 功能的 WordPress。
• 全新的开发接口
  使用新的开发接口，开发人员可以在 Sitemap 中支持更多的站内内容类型。

说了这么多，各位可以到官方的插件目录中进行下载，下载链接可以在 Google XML Sitemaps 下载页面中找到。本文编写时，最新的测试版本为 4.0a4。

在这里再次说明一下，从 WordPress 3.0 开始，已经将原 MU 程序进行了合并。所以可以认为之前的 MU 2.9.2 和 WP 2.9.2 的升级版，都是 WordPress 3.0。

再有一点，本团队并非 WordPress 所属公司授权的简体中文团队，尽管我们叫 WordPress 中文团队，但也请各位不要将概念混淆。我们只是希望能够给各位带来完整、完善的中文环境而已。

WordPress 3.0.1 对应的简体中文语言包也已经制作完成。各位可以在下面的链接中找到。

下载：WordPress 简体中文语言包

发布的压缩文件中，语言包文件对应的功能如下：

• \wp-content\languages\continents-cities-zh_CN.mo
  时区和地域信息编译后的二进制的语言包文件
• \wp-content\languages\continents-cities-zh_CN.po
  时区和地域信息语言包源文件
• \wp-content\languages\ms-zh_CN.mo
  多站点部分编译后的二进制语言包文件
• \wp-content\languages\ms-zh_CN.po
  多站点部分语言包源文件
• \wp-content\languages\zh_CN.mo
  核心部分编译后的二进制语言包文件
• \wp-content\languages\zh_CN.po
  核心部分语言包源文件
• \wp-content\themes\twentyten\languages\zh_CN.mo
  默认主题 Twenty Ten 编译后的二进制语言包文件
• \wp-content\themes\twentyten\languages\zh_CN.po
  默认主题 Twenty Ten 语言包源文件

同时本站还为您提供了从 WordPress 3.0 开始独立出来的那些导入工具的语言包文件。具体信息可以参考：WordPress 导入工具简体中文语言包

本站仅提供语言包文件，程序本身各位可以到官方站点下载英文原版自行安装语言包。或者等待 WordPress 中文团队制作的简体中文版本 WordPress。

本站以及中文团队发布的语言包中，包含了我们团队的论坛地址。而且会在安装语言包后，显示于后台页脚位置。如果您感到任何不适，可以使用 poEdit 打开我们的语言包源文件，并查找相应的网址，将对应词条中的相关网址去掉即可。

另外说一下，目前国内没有任何一个经由官方授权的简体中文论坛。所以不要再问我，为什么放自己的论坛地址而不放置某“官方”论坛的地址。这个真没有……

我们不要求，也不奢望所有的中文用户都能认可我们翻译的东西。大蒜还有人不吃呢，你咋让人家吃蒜香干丝呢？从官方翻译团队，到国内民间翻译团体，数量维持在三到五个左右。有持续翻译及时更新的，有偶尔弄一下的，也有昙花一现的。不管是谁做出的语言包，在我的印象里，好像都是免费放出来给大家用的吧？

抛开各个团队翻译的语言包其质量方面的事情，咱就说说这个语言包正常的翻译流程是啥样的。我这里不会涉及到技术相关的内容。而且，翻译语言包也没啥技术含量。像某些人说的，可以用繁体的转嘛，可以用机器翻译嘛，可以只挑重点的翻译嘛，……嘛。滚，自己翻去，那他妈是人干的活吗？

翻译某款软件，基本上有两种情况：

第一种是全新翻译。比如我给 BuddyPress 制作的语言包就属于全新翻译。因为软件本身诞生较晚，之前没有人做过早期版本的翻译。那么我只能是从一张白纸开始写。在获取到语言包模板文件后，对其中的词条进行翻译。而当中的词条与以前其他软件中的词条没有太多的重复，所以词典方面的作用在这个时候也不是很大。我也仅仅能够保证翻译风格和以前的作品类似而已。

第二种是后续翻译。比如我给 WordPress MU 做的翻译。由于像 MU 这样的程序，其核心部分与 WP 相同。所以有很大一部分词条可以直接使用。我可以直接在 WP 的语言包上，导入 MU 的 POT 文件来获得针对 MU 的语言包文件。接下来就是扩展翻译了。而且在翻译的同时，要尽量保证两个语言包内的大部分词条要同步。如果发现错误，要同时在几个语言包中同时进行修改。

为了保证语言包能够在程序本身发布的当天或者是最晚三天内能够面世，那翻译人员需要几乎每天去看一下 SVN 中程序的更新情况。而且几乎每天需要对新生成的 POT 文件进行对比，看看有没有新的词条生成。这样做的目的是避免连续多天不对比，一旦积累的词条量太大，而这个时候程序正式版却发布了，语言包不能及时完成的情况。

好了，有人会问，为啥不用繁体中文的直接转换成简体中文的对外发布呢？哥哥们，你们是真的不懂还是在那装傻？拿个简单的例子来说一下，台湾和香港称呼“Software”为“軟体”，而在大陆，我们翻译为“软件”。我现在能把文字的编码改成“软体”。可我怎么把这个“体”改成“件”？这也仅仅是一个例子而已。一个语言包里面词条量动则数千条，我一个一个的去修改，还不如他妈重新翻译来的快。更何况，WordPress 中文团队的简体中文语言包要比繁体的出来的早。我偷谁的翻译去？

还有人会说，每次更新不就增加了几个功能而已嘛。你说的完全是他妈 2B + SB 的话。从核心程序的开发，到语言包的更新，哪个是轻松完成的？你爹妈制造你也没非啥大劲，完全是冲动的副作用。这种人，不想和他多说，浪费我键盘。

还有一件事儿，就是有人说使用我们的语言包后，在后台下方会多出来我们团队论坛的地址。还有人说为啥不放 XX 论坛的地址而放我们自己的。哎，我实在无话可说，我也想放官方中文论坛啊。可人家到现在还没开放啊。看清楚域名再说话不行吗？别总拿某论坛当成官方中文论坛好不好？而且我自己有论坛，我为啥要放别人的地址啊？各位要不要一起去要求美剧压片小组，让他们在影片里面把自己网站的地址都去掉啊？语言包的源代码都给你了，你要看不惯我加的地址，你可以用软件给去掉啊。

最后，还是要臭不要脸的自我宣传一下。本站上方项目列表中，有迄今为止 Automattic 公司四大件儿（WordPress、WordPress MU、bbPress、BuddyPress）等的简体中文语言包。看上眼，想用，那就下载。如果感觉无非是几个破文件放那糊弄人，那你就当我放屁解闷。语言包我还会继续做下去，我们需要的是支持，这当中包括一声谢谢和来自各方面的修改意见。WordPress 中文团队还会一如既往的为大家提供更完善的中文化软件。

想骂就骂，不过骂人之前，先他妈查清楚了。别自己给自己脑袋上扣屎盆子。

本次更新到 1.2.5，主要修正了 1.2.4 发布以来爆出的若干问题。最主要的修复，就是针对 WordPress 3.0 进行了调整。修复了在将首页显示设置为“Activity”时，页面出现“该页面无法找到！”的问题。这是由于 WP 3.0 在日志队列中不允许非空日志的存在所造成的。本次更新还修正了 49 个其它被报告的问题。

与此同时，WordPress 中文团队负责维护的 BuddyPress 官方简体中文站也为您带来了最新的简体中文语言包。语言包方面并没有太大的变动，只照比 1.4 版更新了少量几个词条。

最新的简体中文语言包可以到 BP 的简体中文官方站上下载。插件程序可以从后台的插件管理处进行安装或更新。

感谢您长期对本团队的支持，如果语言包在翻译方面有任何问题，请及时在本页面内反馈。您的支持是我们工作的最大动力来源。

WordPress 中文团队已经为您翻译完毕并对外发布，各位可以到本站相应的项目页面中进行下载，其中还包括该插件的简单介绍以及语言包的安装方法。希望对各位有所用处。

项目页面地址为：WordPress MU Domain Mapping 简体中文语言包

原来的两个模板文件分别用于主程序的相关词条翻译和时区及国家名称的翻译用途。而最近分离出的模板文件，是将 WordPress 3.0 中的多站点相关内容独立了出来。

这样做的好处是显而易见的。在程序运行过程中，可以有效降低站点运行内存的占用量。而翻译方面，也可以将不同的部分分配给不同的翻译人员。毕竟，多人共同翻译同一个 POT 文件，想让翻译的风格统一和协同工作方面，还是存在一定困难的。

据不可靠消息透露（= = 不可靠消息！！）官方人员还准备把 3.0 中的帮助信息独立出来。如果真这么做了的话，可以将翻译工作分配的更加细化。偶喜欢……不过，目前为止，还只是这三个模板文件。

如果您想翻译并使用这些语言包。那么请将 PO 和 MO 文件按照以下格式保存并上传：

• wordpress.pot 文件翻译完毕后，保存成：<locale>.po 和 <locale>.mo
• wordpress-continents-cities.pot 文件翻译完毕后，保存成：continents-cities-<locale>.po 和 continents-cities-<locale>.mo
• wordpress-ms.pot 文件翻译完毕后，保存成：ms-<locale>.po 和 ms-<locale>.mo

文件名中的 <locale> 代表您翻译的目标语言代码。例如：zh_CN。

然后将以上三个 MO 文件（或六个文件，包括 PO 文件）上传到“wp-content\languages”目录中即可。

按照官方开发人员的套路，以后如果再分离出来新的子语言包模板文件，其命名的方式估计也会是“wordpress-xx.pot”这种形式。而翻译并编辑的时候，文件名也差不多应该是保存成“xx-<locale>.po”这种形式。只是猜想，具体情况还要看以后官方是怎么定的。

这也是本站第一次被黑。估计是篡改了主题的某个文件吧。具体修改了哪里没有仔细查。干脆就把整站的核心程序重新传了一下解决问题。还好，数据没有任何损失。估计是没看上我的站，没爱给删除吧。看来备份还是要继续做地。

昨天正好是我结婚一周年纪念日，专挑这一天黑我，是不是故意的啊。太不着调了。

现在本站的程序是一直跟着 WordPress 的 SVN 走的。开始怀疑是不是某个插件有漏洞呢？有啥好办法排查一下没啊！

实际上来说，WP 3.0 可以看成是 MU 的增强版本，又可以视为升级版。而且数据结构方面并没有特别大的区别。所以，直接从 MU 升级到 WP 3.0 是完全可行的。

按照下面介绍的几个步骤，我们可以将自己的 MU 站点升级到 WP 3.0。当然，升级完毕后，WP 是处于 Multisite 功能开启的状态的。

第一步，覆盖原站点中的程序文件。

从官方站点下载 WordPress 3.0 的安装压缩包文件。撰写本文的时候，WP 3.0 已经发布了 Beta 2 版。各版的操作方式相似。删除原站点中的 wp-admin 和 wp-includes 目录。然后上传 WP 3.0 的文件到站点，覆盖所有文件。（之所以不对 wp-content 目录进行删除操作，是因为其中包含了原站点使用的插件和主题等重要文件，以及用户上传的附件文件，故绝对不要删除该目录。）

第二步，更新网络站点。

登录到您站点的后台，并且根据提示的链接，对网络（Network）中的站点（Sites）进行更新操作。如图：

第三步，更新 wp-config.php 文件。

WordPress 会对您的 Cookie 进行加密的。但是您仍然需要将页面上方出现的代码加入到 wp-config.php 文件中。根据每个人的情况，代码中的随机字段是不同的。例如本例中的代码为：（切记，不要直接复制本文中的这行代码，每个人安装的是不同的，请复制您后台页面上方出现的那一段代码。）

define( 'NONCE_SALT', 'a<.4I)#p^-iy?sbb3JPu+W~-Zk|aPLMN[TvoiHIKGI_bbB-h?iliBb2ra' )

将这行代码加入到：

/* That's all, stop editing! Happy blogging. */

这行代码的上方。添加完毕后如：

define( "WP_USE_MULTIPLE_DB", false );

define( 'NONCE_SALT', 'a<U3S[ g<.4I)#p^-iy?sbb3JPu+W~-Zk|aPLMN[TvoiHIKGI_bbB-h?iliBb2ra' );

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

第四步，更新重写规则。

在 WordPress 3.0 中，原 MU 的 wp-content 目录中的 blogs.php 文件已经不在使用了。并且已经更名为 ms-files.php。所以，我们需要在 .htaccess 文件中做出相应的修改。

可以参考以下修改完毕的 .htaccess 文件：

RewriteEngine On
RewriteBase /

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>

另外，wpmu-settings.php 文件也已经没用了，确切的说，原来以“wpmu-”开头的系统文件，基本上都被替换为了“ms-”开头。所以，类似这样开头的文件，都已经没有什么用了。各位可以根据需要进行删除清理。

到这，按照以上几个步骤的操作。您就成功将站点从 MU 升级到了最新的 WP 系统了。不过，在升级之前以及过程中，还需要注意一些事情。

最重要的一点，就是升级之前，一定要对数据库进行完整的备份。并且将原来的站点程序最好也备份一份。以免出现任何问题。

其次，升级之前，禁用掉所有站内的插件，并且移除（当然得留着，别彻底删除。只是移动出该目录即可）mu-plugins 这个目录中的插件。因为这个目录中的插件不需要人为启用，所以为了避免部分插件不兼容 WP 3.0 的情况导致升级失败，故升级之前，先移除这里的那些插件。

最后，部分插件，当初是为 MU 特别开发的。可能会硬性调用某个核心文件（例如捆绑域名的插件，调用了 wpmu- 开头的文件，而升级后，已经不再使用这些文件了）。那么升级之后，我们需要对部分插件做少量的修改才可以在 WP 3.0 下面正常使用。

升级的过程虽然简单，但是还是希望各位在升级的过程中小心行事。本文只是做为 WP 3.0 正式版发布之前的一个简单升级方法。不知道等 3.0 正式发布后，会不会仅仅是在 MU 后台出现升级提示信息，然后一键升级呢？如果真是那样，各位就不用这么麻烦的操作了。

参考文献：Upgrading WordPress MU 2.9.2 to WordPress 3.0 with MultiSite

从 WordPress 2.9 系列开始，核心程序提供了一个叫做日志缩略图“Post Thumbnail”功能。而如何将这个功能加入到您的主题中，就需要对现有主题进行一些修改了。

修改主题的步骤还是相对简单的，各位可以通过下文的讲解来了解整个步骤。

1. 需要在主题的 functions.php 文件中插入调用该功能的代码。这样，在编辑文章的时候，才会在编辑页面出现插入缩略图的功能项。

if(function_exists('add_theme_support')) {
	add_theme_support('post-thumbnails');
	// add_theme_support('post-thumbnails', array('post')); // 添加到日志
	// add_theme_support('post-thumbnails', array('page')); // 添加到页面
}

各位可以根据需要，去掉相应代码前面的注释代码。

2. 还需要告诉 WordPress 我们需要多大尺寸的缩略图。

set_post_thumbnail_size(570, 200, true); // 宽，高，是否裁切(true or false)

括号中的键值可以根据需要自己定义。

3. 在站点内的某些地方，可能还需要一些不同尺寸的缩略图。那么，也可以通过以下代码获得：

add_image_size('single_post', 200, 120, true); // 名称，宽，高，是否裁切

括号内的键值可以根据需要自己定义。如果您需要定义多个尺寸的缩略图，那么可以多次使用该代码。

4. 接下来，我们就需要定义缩略图在主题中显示的位置了。各位可以将下面代码加入到主题中想要插入缩略图的地方。

<?php
if (has_post_thumbnail()) {
	the_post_thumbnail();
	// the_post_thumbnail('single-post');
	// $image = get_the_post_thumbnail();
} else {
}
?>

各位可以根据需要，去掉相应代码前面的注释代码。

结合以上的步骤，我们就在主题中加入了日志缩略图的显示功能了。那么如何在 RSS 输出中也同样调取这些图片呢？需要将以下代码加入到 functions.php 文件中：

function rss_post_thumbnail($content) {
  	global $post;
   	if(has_post_thumbnail($post->ID)) {
   	    	$content = '<p>' . get_the_post_thumbnail($post->ID) .
   	    	   	   '</p>' . get_the_content();
   	}
   	return $content;
}
add_filter('the_excerpt_rss', 'rss_post_thumbnail');
add_filter('the_content_feed', 'rss_post_thumbnail');

这样，在 RSS 输出的时候，也可以同时将日志缩略图显示出来了。

参考文献：Getting the most from WordPress Post Thumbnail

这是由于 WP 后台编辑器使用了一套自己的样式表，而且其与所使用的主题没有直接关系。这也就是为什么后台编辑器中的效果和前台显示的效果有出入的原因。这也让“所见即所得编辑器”这个名字显得有点言过其实。

不过，我们可以通过在所使用的主题中增加一些样式表的信息来让默认编辑器和前台主题的显示效果保持一致。

在 WordPress 2.9.x 以及之前的版本中，可以使用以下方法：

将以下代码插入到主题的 functions.php 中：

add_filter('mce_css', 'my_editor_style');
function my_editor_style($url) {

  if ( !empty($url) )
    $url .= ',';

  // Change the path here if using sub-directory
  $url .= trailingslashit( get_stylesheet_directory_uri() ) . 'editor-style.css';

  return $url;
}

这将告知编辑器，主题为它提供了一套新的样式。

从 WordPress 3.0.x 开始，程序已经提供了相应的自定义编辑器样式的代码，只需要将下面代码加入到主题的 functions.php 文件中即可：

add_editor_style();

然后，在主题的目录中，创建一个 editor-style.css 文件，并且将主题现有样式表文件中的必要内容复制到该文件内。主要是将一些譬如日志文章中文字排版的相关样式信息，以及图片显示效果等代码复制进去。像主题的整体布局以及侧栏和除了日志本身以外的代码，可以不进行复制。

这样，当您在后台对文章进行编辑的时候，就可以最大限度上让前台页面与后台编辑器中的内容看起来一样了。

参考文件：Can themes style the visual editor?

不过架设起来的站点，总会出现废除掉或者恢复为单独站点的时候。又或者您仅仅是出于测试的目的开启了多站点功能。这时，我们就可以考虑将多站点功能关闭掉，并且将整个 WordPress 3.0 站点恢复到开启之前的样子。

其实，将开启了多站点支持的 WordPress 3.0 恢复成原装，并没有想象中的复杂。仅仅是根据创建过程的一个逆向操作。以下我们分成几个步骤进行操作，希望能够让您的思路更明确。

第一步，当然是对现有数据库进行备份。（其实风险不是很大，就算不成功，只要您手不抖别删除数据表，一般不会出现啥问题。）

第二步，找到之前您备份的单站点模式下的 .htaccess 和 wp-config.php 文件。（啥？当初没备份哦，那……见文章结尾部分吧。注1）

第三步，将上述两个文件上传到站点目录下，覆盖当前文件。（当前文件最好也备份一下，并且做好标记，分清哪个是多站点模式下的，哪个是单站点模式下的。）

现在您访问 WordPress 后台，应该看到针对多站点的管理项目已经消失了，理论上，现在已经恢复成单站点了。但出于洁癖的原因，我们还要进行以下几步的操作。

第四步，登录到 MySQL 管理工具界面，一般主机商都会提供一个，或者自己装个 PHPMyAdmin。

第五部，删除掉除了“commentmeta、comments、links、options、postmeta、posts、terms、term_relationships、term_taxonomy、usermeta、users”这 11 个默认安装生成的表以外的数据库表。（看清楚，不要删除这 11 个数据表，别整反了哈！注意事项见文章结尾。注2）

经过上面步骤的操作，您的站点就恢复成单站点模式了，很简单吧？

其实按照以上的方式恢复为单站点模式后，存在一个问题。就是如果您已经在分站点中有一些内容了，或者是建立了多个分站点。而这些站内的内容想在删除的同时，合并到主站点中，该如何是好呢？其实，我们可以通过在分站点中，将站内文章使用 WP 自身的导出功能全部导出，然后再在主站内倒入即可。但导入后，需要注意一下 GUID 的问题，相信介绍可以参考《我的 WordPress 站点合并过程》这篇文章。

注1：如果当时开启多站点功能时没有备份 .htaccess 和 wp-config.php 文件。.htaccess 文件可以通过访问后台的永久链接设置页面，直接点保存，让程序重新生成一个。而 wp-config.php 文件，可以根据默认安装的时候，手动编辑 wp-config-sample.php 文件然后保存为 wp-config.php 来得到。

注2：在站点的使用过程中，可能某些插件也会生成一些数据库表，在删除表的时候，要区分哪些是插件生成的，哪些是 WP 针对多站点支持而生成的。以免误删除后造成部分插件的记录丢失。

本文发布在 Dreamcolor's Cote，转载请保持文章完整并注明出处。

使用该代码，您可以在 Feed 输出中每篇日志都添加一些版权信息或者其他的自定义内容。

// add custom feed content
function add_feed_content($content) {
	if(is_feed()) {
		$content .= '<p>This article is copyright &copy; '.date('Y').'&nbsp;'.bloginfo('name').'</p>';
	}
	return $content;
}
add_filter('the_excerpt_rss', 'add_feed_content');
add_filter('the_content', 'add_feed_content');

您可以将 $content 一行的内容替换成您想要的信息。

如果您想同时使用前文和本文提到的功能，可以将两段代码合并来写，代码如下：

// add custom content to feeds and posts
function add_custom_content($content) {
	if(!is_home()) {
		$content .= '<p>This article is copyright &copy; '.date('Y').'&nbsp;'.bloginfo('name').'</p>';
	}
	return $content;
}
add_filter('the_excerpt_rss', 'add_custom_content');
add_filter('the_content', 'add_custom_content');

这样，将在日志和 Feed 输出中同时插入相同的内容。

还要注意一下，一旦使用合并的写法，请注释或删除掉单独使用的代码，以免出现日志或 Feed 中出现重复内容。各位可以根据需要来选择插入的代码。

本文发布在 Dreamcolor's Cote，转载请保持文章完整并注明出处。

来源：Digging into WordPress

当然，我们可以简单的对 WordPress 主题中 single.php 这个主题文件进行编辑来实现这个功能，但是当使用框架主题时，我们也许希望不对原主题进行修改，而仅仅使用外部文件来实现这个功能。

那么，您可以将下面的代码插入到主题的 functions.php 文件中，其中需要显示的内容可以根据需要进行替换。

// add custom post content
function add_post_content($content) {
	if(!is_feed() && !is_home()) {
		$content .= '<p>This article is copyright &copy; '.date('Y').'&nbsp;'.bloginfo('name').'</p>';
	}
	return $content;
}
add_filter('the_content', 'add_post_content');

您可以对 $content 这行内容进行替换来加入您需要的功能。

本文发布在 Dreamcolor's Cote，转载请保持文章完整并注明出处。

来源：Digging into WordPress

如何执行 MySQL 查询语句

通常情况下，我们可以直接进入服务器的 MySQL 命令行中执行。也可以使用非常著名的 WEB 程序 PHPMyAdmin 进行查询。如果我们想在 WordPress 后台直接进行查询，还可以使用 SQL Executionner 这个插件对数据库进行操作。

注意：虽然以下提供的查询语句都已经经过测试。但是请不要直接在生产环境下运行，或者经过一定的测试再执行，毕竟每个人的站点环境可能略有不同。操作之前切记要对数据库进行备份操作。

1. 手动修改密码

某些情况下，我们忘记了管理员的密码。或者站点遭受攻击后，管理员密码被恶意修改了。这个时候，我们能做的就只有重新设置管理员的密码了。

以下查询语句，使用 MySQL 的 MD5() 函数将我们的密码进行 MD5 加密。

UPDATE 'wp_users' SET 'user_pass' = MD5('PASSWORD') WHERE 'user_login' ='admin' LIMIT 1;

来源：http://www.wprecipes.com/how-to-manually-reset-your-wordpress-password

2. 批量转换日式的作者

大多数刚使用 WordPress 的人可能都是直接使用 “admin”这个用户来直接发布日志。等您新建一个用户后，如果想将原来日志的作者批量修改为新用户的时候，可以使用以下查询语句。

在执行之前，您需要知道老用户和新用户的用户 ID。

UPDATE wp_posts SET post_author=NEW_AUTHOR_ID WHERE post_author=OLD_AUTHOR_ID;

来源：http://www.wprecipes.com/how-to-change-author-attribution-on-all-posts-at-once

3. 删除日志修订版本和其相关的信息

日志的修订版本功能在多用户共同维护一个博客的时候非常有用。不过该功能在数据库中添加过多的记录数也是很让人恼火的。

执行以下语句，可以将数据库中的日志修订版本记录以及其中的其他信息（包括自定义区域等等）删除掉。执行后，会节省很多数据库空间。

DELETE a,b,c FROM wp_posts a WHERE a.post_type = 'revision' LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id);

来源：http://www.onextrapixel.com/2010/01/30/13-useful-wordpress-sql-queries-you-wish-you-knew-earlier/

4. 批量删除垃圾评论

在您的博客没有安装 Akismet 或其他替代品的前提下，一段时间没有进入后台进行评论审核。可能会出现几百甚至上千条未审核的评论。而且大部分可能是垃圾评论。这个时候，如果您在后台进行删除，可能会浪费掉您很多时间。以下语句可以在数据库中批量删除掉所有未审核的评论。

奉劝一句，还是安装 Akismet 或类似的插件吧，可以省却您很多烦恼。

DELETE from wp_comments WHERE comment_approved = '0';

来源：http://www.wprecipes.com/mark-asked-how-to-batch-deleting-spam-comments-on-a-wordpress-blog

5. 查找未使用的标签

标签的记录是存放在 wp_terms 这个数据表中的。有时，可能部分标签创建了但是没有被使用，他们仍然会在数据表中。以下语句可以对这些未使用的标签进行查询，您可以安全的将其删除。

SELECT * From wp_terms wt INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id WHERE wtt.taxonomy='post_tag' AND wtt.count=0;

来源：http://www.onextrapixel.com/2010/01/30/13-useful-wordpress-sql-queries-you-wish-you-knew-earlier/

6. 查找并替换数据

该语句不光是在 WordPress 的使用过程中能用到。您可以在很多地方用到该 MySQL 查询语句。其使用 MySQL 的 replace() 函数将一段字符串替换成您指定的另一段字符串。

UPDATE table_name SET field_name = replace( field_name, 'string_to_find', 'string_to_replace' ) ;

来源：http://perishablepress.com/press/2007/07/25/mysql-magic-find-and-replace-data/

7. 获得发表评论访问者的电子邮箱地址列表

该语句可以返回一个在您博客上进行评论的用户的电子邮箱地址列表。语句中的 DISTINCT 参数用来保证每个电子邮箱地址只显示一次。

SELECT DISTINCT comment_author_email FROM wp_comments;

来源：http://www.onextrapixel.com/2010/01/30/13-useful-wordpress-sql-queries-you-wish-you-knew-earlier/

8. 一次性禁用掉所有插件

虽然新版的 WordPress 已经可以直接在后台对插件进行批量的启用和禁用操作。但是当某些插件引起整个站点不能正常访问的时候，我们就可以使用以下语句禁用掉站点内所有的插件，然后再进入到 WordPress 后台进行调试操作。

UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins';

来源：http://www.wprecipes.com/how-to-disable-all-your-plugins-in-a-second

9. 删除所有标签

标签的信息是存放在 wp_terms 数据表中的。而且，是和分类以及其他一些信息存放在相同一个表中。如果您想删除所有的标签记录，是无法简单的清空 wp_terms 这个数据表的。这会导致分类信息丢失。

执行以下语句，可以仅仅删除掉标签记录以及与日志的关联信息，而其他的分类等信息不会发生改变。

DELETE a,b,c
FROM
	database.prefix_terms AS a
	LEFT JOIN database.prefix_term_taxonomy AS c ON a.term_id = c.term_id
	LEFT JOIN database.prefix_term_relationships AS b ON b.term_taxonomy_id = c.term_taxonomy_id
WHERE (
	c.taxonomy = 'post_tag' AND
	c.count = 0
	);

来源：http://wordpress.org/support/topic/311665

10. 列举无用的日志信息

日志的 Meta 信息通常是由插件或自定义区域建立的。它们非常实用，但也会让您的数据库尺寸快速的变得臃肿。以下语句会显示 postmeta 表中那些没有在 post 表有对应关系的记录，便于您对数据库进行清理。

SELECT * FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;

来源：http://wordpress.org/support/topic/337412

11. 禁用老日志的评论功能

某些时候，您希望把以前的日志评论功能关闭掉。可能导致您这么作出决定的原因有很多，您可以使用以下语句将指定日期之前发布的日志评论功能关闭掉。

UPDATE wp_posts SET comment_status = 'closed' WHERE post_date < '2009-01-01' AND post_status = 'publish';

来源：http://perishablepress.com/press/2008/02/20/wordpress-discussion-management-enable-or-disable-comments-and-pingbacks-via-sql/

12. 替换评论者的链接

上文提到了 MySQL 的 replace() 函数。该条语句就是一个很好的例子。如果您的站点域名发生了改变，您可以使用该语句将您在自己站上发表的评论中的链接批量替换为新的域名。

UPDATE wp_comments SET comment_author_url = REPLACE( comment_author_url, 'http://oldurl.com', 'http://newurl.com' );

来源：http://perishablepress.com/press/2008/07/14/wordpress-link-author-comments-home-page/

13. 替换评论者的电子邮箱地址

和上一条差不多，批量替换掉电子邮箱地址。

UPDATE wp_comments SET comment_author_email = REPLACE( comment_author_email, 'old-email@address.com', 'new-email@address.com' );

来源：http://perishablepress.com/press/2008/05/18/wordpress-tip-update-email-address-in-the-wordpress-database

14. 删除包含指定链接的评论

某些垃圾评论发布者还是很会钻空子的。经常发布一些貌似与文章相关的评论，可评论内容中通常包含恶意网站的链接。等你发现的时候，可能这样的评论已经很多了。使用以下代码，可以方便的将包含指定链接地址的评论一次性删除掉。

DELETE from wp_comments WHERE comment_author_url LIKE "%wpbeginner%" ;

来源：http://perishablepress.com/press/2007/07/25/mysql-magic-find-and-replace-data/

本文发布在 Dreamcolor's Cote，转载请保持文章完整并注明出处。

原文地址：10+ life saving SQL queries

这几天，WordPress 3.0 的第一个 Beta 版本也对外发布了，虽然还处于紧张的开发调试阶段，但大家不妨先行进行一些测试。也好为以后的开发工作积累一些经验。

3.0 的多站点（Multisite）功能从最开始合并完毕后，直接可以在后台点击激活，到现在需要经过一些配置才可以使用，估计是考虑到某些用户可能会误点击而导致不必要的麻烦发生。

下面就介绍一下如何激活 WordPress 3.0 的多站点支持功能：

第一步，当然是下载最新版的 WordPress 程序，并进行安装。和以前的安装步骤并没有什么区别。

第二步，将以下代码加入到 wp-config.php 文件当中：

define ('WP_ALLOW_MULTISITE', true  ) ;

第三步，在 wp-content 目录中创建一个 blogs.dir 目录，用于存储子站点用户上传数据。

第四步，在后台的“Tools”（工具）菜单中会多出一个“Network”（网络）的项目。点击进入……

第五步，根据页面提示，对 wp-config.php 文件进行修改。（切记，修改前请备份。）

第六步，根据页面提示，覆盖 .htaccess 文件中的内容。（切记，修改前请备份。）

好了，通过以上六步的设置，现在刷新一下后台，也许会要求重新登陆。看一下原来左侧的导航栏上，是不是多出来一个“Super Admin”（超级管理）的栏目？点击里面各个功能项，如果您之前使用过 MU，您一定会觉得特别亲切。

在启用多站点功能之前，有几点需要大家注意：

第一，做好 wp-config.php 文件和 .htaccess 文件的备份。只要备份在手，恢复到单站点模式将易如反掌。

第二，在启用之前，请尽量将站点链接形式从默认形式改为其他形式。

第三，您的主机必须支持 Rewrite 功能。否则，您看到这里，属于浪费时间。

本文发布在 Dreamcolor's Cote，转载请保持文章完整并注明出处。

在不更改 BP 核心程序的前提下，程序本身提供了一些可以让用户进行自定义的配置项。这些配置信息，只需要加入到 WordPress 安装目录中的 wp-config.php 文件中即可。

目前提供了如下配置项可供使用，也许以后可供自定义的项目还会更多：

忽略所有已废弃的代码（不进行读取）：

define ( 'BP_IGNORE_DEPRECATED', true );

在 WPMU 程序中，允许 BuddyPress 在多个站点内运行：

define ( 'BP_ENABLE_MULTIBLOG', true );

档案页面位于站点跟目录（例如：http://example.org/username/）：

define ( 'BP_ENABLE_ROOT_PROFILES', true );

更改打开用户档案时默认的标签（默认为活动）：

define( 'BP_DEFAULT_COMPONENT', 'profile' );

设置运行 BuddyPress 的博客 ID：

define ( 'BP_ROOT_BLOG', $blog_id );

禁用所有页面顶部的管理导航条：

define ( 'BP_DISABLE_ADMIN_BAR', true );

禁用 BuddyPress 默认主题的自定义页眉功能：

define( 'BP_DTHEME_DISABLE_CUSTOM_HEADER', true );

在 WordPress 管理页面中禁用“您需要启用一个兼容 BuddyPress 的主题……”的警告信息：

define( 'BP_SILENCE_THEME_NOTICE', true );

允许在 LDAP 用户名中使用“.”：

define( 'BP_ENABLE_USERNAME_COMPATIBILITY_MODE', true );

更改 BuddyPress 组件的链接缩略名：

define ( 'BP_ACTIVITY_SLUG', 'streams' );
define ( 'BP_BLOGS_SLUG', 'journals' );
define ( 'BP_MEMBERS_SLUG', 'users' );
define ( 'BP_FRIENDS_SLUG', 'peeps' );
define ( 'BP_GROUPS_SLUG', 'gatherings' );
define ( 'BP_MESSAGES_SLUG', 'notes' );
define ( 'BP_WIRE_SLUG', 'pinboard' );
define ( 'BP_XPROFILE_SLUG', 'info' );
define ( 'BP_REGISTER_SLUG', 'signup' );
define ( 'BP_ACTIVATION_SLUG', 'enable' );
define ( 'BP_SEARCH_SLUG', 'find' );
define ( 'BP_HOME_BLOG_SLUG', 'news' );

更改头像的尺寸信息：

define ( 'BP_AVATAR_THUMB_WIDTH', 50 );
define ( 'BP_AVATAR_THUMB_HEIGHT', 50 );
define ( 'BP_AVATAR_FULL_WIDTH', 150 );
define ( 'BP_AVATAR_FULL_HEIGHT', 150 );
define ( 'BP_AVATAR_ORIGINAL_MAX_WIDTH', 640 );
define ( 'BP_AVATAR_ORIGINAL_MAX_FILESIZE', $max_in_kb );
define ( 'BP_AVATAR_DEFAULT', $img_url );
define ( 'BP_AVATAR_DEFAULT_THUMB', $img_url );

更改 BuddyPress 中所有群组论坛的父级版面：

define ( 'BP_FORUMS_PARENT_FORUM_ID', $forum_id );

为 BuddyPress 设置自定义用户数据库表：

define ( 'CUSTOM_USER_TABLE', $tablename );

为 BuddyPress 设置自定义用户信息数据库表：

define ( 'CUSTOM_USER_META_TABLE', $tablename );

经过以上设置，各位可以更加自由的对自己的 BuddyPress 站点进行自定义。本文翻译自官方 Codex，欢迎各位共同研究。本文发布在 Dreamcolor's Cote，转载请保持文章完整并注明出处。

参考文献：Changing Internal Configuration Settings

对于小型站点，我们通常的做法是使用 Cache 来提高服务器响应速度。不可否认，像 WordPress Super Cache 一类的缓存插件，在提高网站访问速度，降低服务器负担方面做的非常好。它可以将站点内很多相对变动不是很频繁的内容生成静态化的页面，可以有效降低数据库查询次数。无形中，提高了页面返回速度。给用户带来更好的体验。

但世事无绝对，缓存类的插件有时也无法胜任所有的服务器优化工作。总有些方面是缓存插件无法做到的。这个时候，我们就需要考虑换一种方式来加快网站访问速度了。

对于 MySQL 数据库的查询，有时是无法避免的。例如相对比较活跃的站点，页面变更比较频繁的站点。以及要求事实行非常强的网站。这个时候，就需要考虑 MySQL 的查询能力了。

而单一的服务器或单独一个 MySQL 数据库，在很多方面都无法完成大型网站的要求。这个时候，我们可以考虑使用集群数据库或者类似的数据库架构来保障网站的响应速度。

本文主要讨论的内容是使用 MySQL 异步复制（Replication）结合由 WordPress 开发的 HyperDB 来实现基于 WordPress 的大型网站部分服务器功能的架设。

一、配置 MySQL Replication 部分：

本文将以把 exampledb 这个数据库，从主（Master）服务器复制到从（Slave）服务器为例进行讲解。Master 服务器 IP 地址为：192.168.0.100，两台服务器系统都为 Debian。不过，在其他发行版 Linux 下的配置方法类似，各位可以自行尝试。

两台服务器的 MySQL 服务均已安装完毕，示例数据库 exampledb 以及数据表和数据已在 Master 服务器中创建。

MySQL Replication 可以通过很多种方式架设完成，本文只是抛砖引玉给大家一个思路。

1. 配置 Master 服务器

首先，我们需要编辑 /etc/mysql/my.cnf 文件，允许 MySQL 接入网络，并且允许它监听所有 IP 地址。因此，我们在配置文件中注释掉以下内容（如果存在的话）：

#skip-networking
#bind-address            = 127.0.0.1

其次，我们需要让 MySQL 哪个数据库要记录到日志中（Slave 服务器需要根据日志文件来了解 Master 服务器中相应的数据库都有哪些改变），以及写入到哪个日志文件。这样，该服务器我们便称其为主（Master）服务器。我们希望对 exampledb 数据库进行复制，因此，需要将以下代码加入到 /etc/mysql/my.cnf 文件中：

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=exampledb
server-id=1

保存并退出编辑器后，重新启动 MySQL 服务：

/etc/init.d/mysql restart

然后我们以 root 身份登录到 MySQL 中创建一个用户，该用户拥有复制的权限：

mysql -u root -p
Enter password:

登录 MySQL 后，执行：

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY '<some_password>';
FLUSH PRIVILEGES;
（修改 <some_password> 为您的密码）

然后执行：

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

最后一条命令，会在屏幕上显示类似以下的内容：

+---------------+----------+--------------+------------------+
| File          | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 183      | exampledb    |                  |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)

记录下这些信息，我们将在 Slave 服务器上用到！

然后，可以离开 MySQL 控制界面：

quit;

涉及到数据传输方面，现在有两种方式可以将 Master 服务器上 exampledb 数据库中的表和文件传输到 Slave 服务器上。

第一种方式是转存（Dump）数据库，第二中则是在 Slave 服务器上使用 LOAD DATA FROM MASTER; 命令。第二中方式存在一定的弊端，就是进行操作时，数据库会处于锁定状态，所以当您的网站访问量非常大的时候，不建议使用第二种方式，而希望各位使用第一种方式。

不过，第二种方式也是最快的一种，所以，在这里会对两种方式都做一下介绍。
如果您想使用第一种方式，可以这样进行操作：

mysqldump -u root -p<password> --opt exampledb > exampledb.sql
(将 <password> 修改为您的 MySQL 中 root 的密码！注意一下：-p 和 <password> 之间没有空格！)

这将会创建一个 exampledb 数据库的转存 exampledb.sql 文件。将该文件上传到 Slave 服务器上！

如果您想使用 LOAD DATA FROM MASTER; 方式，那么现在您不需要再做什么了。
最后，我们还要解除 exampledb 数据表的锁定：

mysql -u root -p
Enter password:
UNLOCK TABLES;
quit;

到此，Master 服务器的配置就完成了，接下来是 Slave 服务器的配置……

2. 配置 Slave 服务器

在 Slave 服务器上，我们首先要创建一个 exampledb 数据库：

mysql -u root -p
Enter password:
CREATE DATABASE exampledb;
quit;

如果您已经在 Master 服务器上对 exampledb 数据库进行了转存，并将备份文件上传到了 Slave 服务器上，那么现在就可以将数据导入到 Slave 服务器上新创建的 exampledb 数据库中了：

mysql -u root -p<password> exampledb < /path/to/exampledb.sql
(将 <password> 修改为您的 MySQL 中 root 的密码！注意一下：-p 和 <password> 之间没有空格！) 

如果您想使用 LOAD DATA FROM MASTER; 方式，那么现在您不需要再做什么了。
现在，我们要在 Slave 服务器上进行设置，让其知道它自身为 Slave 服务器、Master 服务器的 IP 为 192.168.0.100、Master 服务器的数据库监视着 exampledb 数据库。因此，我们在 /etc/mysql/my.cnf 文件中添加以下内容：

server-id=2
master-host=192.168.0.100
master-user=slave_user
master-password=secret
master-connect-retry=60
replicate-do-db=exampledb

然后重启 MySQL 服务：

/etc/init.d/mysql restart

如果您没有导入 Master 服务器 exampledb 数据库的内容，而是想使用直接读取数据（LOAD DATA FROM MASTER;）的方式，那么现在您可以使用以下命令从 Master 服务器获取 exampledb 数据库的信息了：

mysql -u root -p
Enter password:
LOAD DATA FROM MASTER;
quit;

如果您在 Slave 服务器上安装了 phpMyAdmin，那么您可以使用该程序查看一下 Slave 服务器上的数据表和数据是否可用了。

最后，我们必须执行以下一下操作：

mysql -u root -p
Enter password:
SLAVE STOP;

下一条命令您需要适当替换掉部分参数：

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='<some_password>', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183; 

• MASTER_HOST 是 Master 服务器的 IP 地址或主机名（本例中为 192.168.0.100）。
• MASTER_USER 是 Master 服务器上被我们赋予了复制权限的用户。
• MASTER_PASSWORD 是 Master 服务器上 MASTER_USER 的密码。
• MASTER_LOG_FILE 是 Master 服务器在执行 SHOW MASTER STATUS; 命令时 MySQL 返回的文件。
• MASTER_LOG_POS 是 Master 服务器在执行 SHOW MASTER STATUS; 命令时 MySQL 返回的文件的位置。

现在，剩下的工作就是启用 Slave。我们可以运行：

START SLAVE;
quit;

好了！现在无论 Master 服务器上的 exampledb 数据库做出任何变动，都会复制到 Slave 服务器上的 exampledb 数据库中啦！

数据库服务器的设置告一段落，接下来便是 WordPress 方面针对数据库进行的设置了。其中使用到了由 WordPress 官方开发的一个数据库类。被其做成了插件的形式，命名为 HyperDB。

二、配置 WordPress 和 HyperDB 部分：

HyperDB 和常规的 WordPress 插件有一定区别，而且需要使用在 WordPress MU 系统中，不过等 WordPress 3.0 成熟后，应该可以在激活了多站点功能的 WordPress 3.0 中使用。安装方法可以参考插件的安装说明。在以后的文章中，争取着重对该类插件进行介绍。

本文不同程度参考或翻译了相关文章，并加入了自身理解的内容。希望能够让您的站点可以承受更大的访问压力。欢迎各位讨论。文中的错误在所难免，希望各位能够指出，谢谢。

本文也许会以系列文章形式发布，请随时关注本站。本文发布在 Dreamcolor's Cote，如需转载，请保持文章完整并注明出处。谢谢合作。

参考文献：
Scaling WordPress Part 1: Using MySQL Replication and HyperDB
How To Set Up Database Replication In MySQL

MU 程序更新，主要是修正了一些 BUG，并且增加了开发者长久以来都想加进去的一个称为“全局条目”的功能。该功能主要的作用是修复博客中分类和标签索引的错误。

本次语言包的更新，可以说改动比较大的。主要是将原语言包中“Widget”全部翻译成了“微件”。这也是查了好些资料，最后选择了一个相对准确的中文翻译。希望大家领会精神，毕竟，不是所有的英文单词都可以翻译成一个确切的中文词组。再一个词就是原语言包中“Blog”一词。之前总觉得翻译成“博客”会有歧义，不过看现在国内的通俗叫法，大家已经可以辨别这个词在不同位置所代表的不同意思。所以这次更新也将其翻译为了中文。

最后，还修正了一些之前翻译的错误，以及不统一的地方。错误在所难免，还希望各位在使用的过程中能够将发现的问题反馈给我。让我们一起来完善该语言包。谢谢……

老规矩，语言包文件可以点击这里进行下载。

PS：不是说 MU 停止开发了吗？咋又出来个新版本。估计 WordPress 3.0 正式发布之前，MU 还能继续折腾……

首先就是从 BuddyPress 1.2 开始，将不光是支持 MU 系统了。您可以在您的单用户 WP 上面安装 BP。将您的 WP 站点变成一个私人的 SNS 站点。

同时还为我们提供了一款新的 BP 主题。您可以把该主题作为一个模板的框架，在其基础上开发出自己的站点主题。

BP 的安装更加方便，您只需要在后台插件的“添加”功能中，搜索“BuddyPress”，并进行安装就可以。无需费时费力的用 FTP 进行上传了。

由于程序照比之前的 1.1.x 系列作出了重大的修改，所以各位在升级的时候请参阅该文档进行升级。

由于过年放假的原因，导致简体中文语言包没有能及时发布。在这里先说声抱歉。WordPress 中文团队已经为您精心准备了一份语言包，各位可以在这里下载到对应的语言包文件。

虽然我们一直在不断的修正语言包文件，但是错误还是难免的。希望各位在使用的过程中，积极提出宝贵意见。您的支持是我们工作的动力。

希望各位在新的一年里学业进步，事业有成。最重要的一点，身体健康。身体乃革命的本钱哦～

更多关于 BuddyPress 1.2 的信息，可以参考官方的发布博客。

本次更新，主要是将 WordPress 2.9.x 系列的几个新功能加到了 MU 当中。包括回收站、图像编辑器、批量插件更新以及视频嵌入等新奇的功能。还有就是修正了一些以往留下的问题。

各位在从老版本进行升级的时候，需要注意一点。新版程序为每个子博客都增加了一个名为“commentmeta”的数据库表。请在升级到 2.9.1 之前，先将您的站点升级为 WordPress 2.8.6，然后下载 MU 开发人员在其博客中提到的文本文件。重命名该文本文件为“add-commentmeta.php”并复制到“mu-plugins”目录中。最后，进入“站点管理 -> 升级”对全站的子博客进行升级。这样，该插件会自动为所有的子博客增加所需的数据库表。升级 2.9.1 的方式和之前就没什么区别了，直接覆盖，然后按照提示就可以了。（注意：该插件只能在 2.8.6 下运行，所以务必先升级到 2.8.6 再运行该插件。）

本次更新的语言包，可以访问这里下载：WordPress MU 简体中文语言包下载最新的语言包。

感谢各位的长期支持，谢谢！

[root@hosts ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: mirror01.idc.hinet.net
* base: mirror01.idc.hinet.net
* extras: mirror01.idc.hinet.net
* rpmforge: fr2.rpmfind.net
* updates: mirror01.idc.hinet.net
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: liblzo.so.1 for package: lzop
---> Package lzo.i386 0:2.02-3.el5.kb set to be updated
---> Package postfix.i386 2:2.3.3-2.1.el5_2 set to be updated
---> Package rsyslog.i386 0:2.0.6-1.el5 set to be updated
--> Finished Dependency Resolution
lzop-1.01-2.el5.rf.i386 from installed has depsolving problems
--> Missing Dependency: liblzo.so.1 is needed by package lzop-1.01-2.el5.rf.i386 (installed)
Error: Missing Dependency: liblzo.so.1 is needed by package lzop-1.01-2.el5.rf.i386 (installed)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.
[root@hosts ~]#

大概含义就是无法更新 liblzo.so.1 所在的软件包 lzop-1.01-2.el5.rf.i386。

引起以上错误的原因是我们在 ISPConfig 3 的时候 需要安装 mod_fcgid 组件。而 CentOS 官方更新源当中并不包含该组件。因此安装过程中，我们增加了一个 位于 centos.karan.org 的测试源。而在该源当中，又没有错误信息中提及的那个软件包，所以更新的时候就出错了。具体当中的纠缠我就不多说了，总得来说就是俩源里面的东西不太对付，还是直接说解决方法吧。

大家可以使用以下两种方式进行系统更新，第一种是跳过错误信息中提到的文件，直接对其他组件进行升级。命令格式为：

yum update --exclude="lzo" --exclude="postfix"

第二种方式是禁用掉添加进去的测试源地址。命令格式为：

yum update --exclude="postfix" --disablerepo=kbs-CentOS-Testing

现在看看您的系统是不是可以正常更新啦？

在使用的过程中，不可避免的会出现程序上的错误以及对新功能的追求。因此，官方会不断的修正源程序，使其功能更强劲、更稳定、更安全。

相比 WP 的升级过程，WPMU 在升级的过程中，并没有变得复杂。从 WordPress MU 2.7.x 系列开始，核心程序提供了自动更新的功能。站点管理员只需要用管理员身份登录到 WPMU 后台，然后点击“工具”中的“升级”功能。在有新版本程序发布的时候，后台页面上方会有相应的提示。点击升级链接，其他的按照指示进行升级就可以。升级结束后，还要进入“站点管理”点击“升级”以更新所有子博客的相关设置。（感谢超凡不脱俗友情提示。）

如果自动更新由于服务器或程序本身的原因无法自动完成。那么您也可以直接下载官方压缩包进行覆盖。

不过这些升级的步骤，前提是您没有对原核心程序进行过修改。否则，自动更新后，您修改过的部分将被覆盖为官方原文件的代码。如果您对核心程序的修改是为了增加或改良某些功能。那么覆盖后，功能将消失，改良的部分也会还原为默认。

那么，怎么样才可以安全的对 WPMU 程序进行升级呢？以下是我觉得比较稳妥的方式。虽然照比自动升级略显麻烦。但毕竟您使用 WPMU 架设博客系统，以为着您站点上的用户不是您一个人。稳定安全才最重要。稍微麻烦一点，有就显得无所谓了。

第一步，备份您的数据库。别嫌麻烦，一旦出错了，起码您还可以恢复原先的数据。虽然出现严重错误导致数据库混乱的可能性不是很大。

第二步，翻出您曾经修改过的文件的记录。（咋？修改过啥你居然没做记录？那你只好等下看下面的笨招了。）

第三步，删除除了“wp-contents”目录、“wp-config.php”文件、“.htaccess”文件等其他的文件和目录。（其实不删除也行，只是不是每次升级都会增加系统文件，有时某些文件也会被删除掉。该步骤只是为了去掉站点内的垃圾文件而已。）

第四步，上传新版程序。并且对原来修改过的文件做类似的修改。（如果新版程序包含了你以前添加过的功能，那你省事儿了。）

第五步，登录后台，并且在站点设置里面更新站内的博客。

这样，您的 WPMU 站点就升级完成了。

至于之前说的修改过的文件没有记录，您可以下载一个老版的 MU 程序，然后跟站内的程序做下比较。自然就看出来您修改过哪些文件了。

说在最后：升级 MU 程序以后。我们还需要对站内原来的主题和插件做相应的升级或修改。所以，在升级之前，最好是能在本地或其他服务器上架设起来一个与老站点完全一样的环境，先在测试服务器上升级并测试主题以及插件。待全部通过后在着手升级。免得升级以后导致主站出现问题。

欢迎各位进行讨论。

而且由于 2.8.4 刚发布，就被发现有一个文件合并的有问题，所以马上又出了一个 2.8.4a。

总得来说，各位可以通过后台的自动更新进行下载或者直接到官方站下载新版程序。

简体中文语言包可在这里下载，地址为：

WordPress MU 简体中文语言包

建议各位马上进行更新，以使您的站点更加安全。

见于在 MU 2.8.2 中自动更新有一些毛病。现在有个修正的办法可以解决该问题。在更新之前，请各位找到 wp-admin/includes/class-wp-upgrader.php 文件并用文本编辑器打开，找到第 697 行，如下代码：

if ( !$wp_filesystem->copy($working_dir . ‘/wordpress/wp-admin/includes/update-core.php’, $wp_dir . ‘wp-admin/includes/update-core.php’, true) ) {

将其中的“/wordpress/wp-admin/includes”修改为“/wordpress-mu/wp-admin/includes”，如下：

if ( !$wp_filesystem->copy($working_dir . ‘/wordpress-mu/wp-admin/includes/update-core.php’, $wp_dir . ‘wp-admin/includes/update-core.php’, true) ) {

然后保存并上传该文件覆盖原来的文件。这样，自动更新就可以正常工作了。在 2.8.3 中已经修正了该问题，以后应该不会出现这个毛病了。

各位也可以直接下载最新的压缩包进行覆盖方式的升级。可以访问 WordPress MU 下载页面进行下载。

在此同时，WordPress 中文团队也发布了最新的简体中文语言包。照比前一版本，修正了部分词条的翻译错误，并使用官方提供的 POT 文件更新到了 2.8.3 的词条。各位可以到这里进行下载。

希望各位在使用的过程中，多多提出宝贵意见，让我们共同完善 MU 的简体中文语言包环境。谢谢各位长期的支持。