谦卑的程序员

　　这是关于ASP.Net常被问到的一个问题，很老很老的概念，但也是一个比较容易一知半解的问题。自问了一下，似乎揣着明白说不清楚，于是做点功课整理一下。

首先，为什么会有Web服务器控件、Html服务器控件和Html控件

　　Html控件无需多说，最常用的控件，ASP时代的唯一选择，世界开始的时候它就在那。当微软推出.Net后，为了提供ASP.Net Web Form开发以和Win Form开发相似的开发体验，推出了Web服务器控件（Server Control），又称ASP.Net服务器控件。而Html服务器控件（Html Server Control），则可以看做是为了向下兼容，便于原本基于ASP系统的移植而推出的一种介于Html控件和Web 服务器控件的权宜产物。

Web服务器控件、Html服务器控件和Html控件的区别

• Html控件的标签：<input id=”Button” type=”button” value=”Button” />
• Html服务器控件的标签：<input id=”Button” type=”button” value=”Button” runat=”server” />
• Html服务器控件其实就是Html控件的基础上加上runat=”server”所构成的控件
• Web服务器控件的标签：<asp:Button ID=”Button” runat=”server” Text=”Button”/>
• Web服务器控件会根据情况在浏览器端产生一个或多个对应的Html标签。

• Html服务器控件位于System.Web.UI.HtmlControls
• Web服务器控件位于System.Web.UI.WebControls
• Web服务器控件与Code Behind的Class文件相结合，提供了包含属性、方法和事件的完整对象模型。

• Html控件不能在服务器端控制，只能在浏览器端通过javascript等脚本语言操作。
• Html服务器控件设定了runat=”server” 属性后，页面对象会将该控件载入控制器，服务器端的代码就能对其进行控制。
• Html服务器控件在页面执行完毕后会被转换成Html标注，然后当成字符串流发送到浏览器端，浏览器端的脚本能够进行操作。
• Web服务器控件的操作则是由页面把Form发回服务器，然后完全由服务器端代码处理。

• Html控件的事件处理发生在浏览器端，除非Submit，否则不会发生Postback
• Html服务器控件的事件处理发生在浏览器端。
• Html服务器控件如果要Postback到服务器端，调用服务器端的方法，需要添加onserverclick之类的事件。
• Web服务器控件部分默认为AutoPostback，或者可以设置AutoPostback。

• 在产生Postback或是重新生成页面时，Web服务器控件自动保存状态到ViewState。
• Html控件和Html服务器控件需要自己编码实现。

Web服务器控件、Html服务器控件和Html控件的优缺点

• Html控件和Html服务器控件需要编码以保持浏览器兼容。
• Web服务器控件能够检测浏览器的兼容性，保持表现的一致。

• Html服务器控件通过为Html控件添加runat=”server”以实现ASP程序的移植。
• 将ASP程序移植成使用Web服务器控件的ASP.Net程序相当于重写新的应用。

• Html控件和Html服务器控件是标准控件，能够用浏览器端脚本语言操作。
• 使用Web服务器控件提供的对象模型，能够得到和Win Form类似的编程体验，而且无需再学习不同的脚本语言。
• Web服务器内部的代码并不开放，你无法获得比较直接的控制。

小结

　　个人认为，Html服务器控件作为一个过渡的实现，虽然能够兼顾浏览器端和服务器端，终究是一个奇怪的存在，尽量少使用为妙。从微软的角度，良好封装的Web服务器控件提供了大量的便利，同时Web Form和Win Form开发模式的差异使得相互的经验能够互通，当然是多使用Web服务器控件为好。不过Web服务器控件的缺点是占用服务器资源，页面Postback过多（Ajax啊Ajax）。所以现实是存在的就是合理的，Html还是要会地，Javascript当然是要好好学地，Web开发各种奇奇怪怪的标签共存于Page中的场面短时间内是不可能消失地。

参考资料

《html控件、html服务器控件和web服务器控件的区别》 （原出处不详，请Google）
<Difference Between ASP.NET Server Controls,HTML Server Controls and HTML Intrinsic Controls>

按照来源区分，可分为兼容MU的Wordpress插件和针对MU开发的插件

　　Wordpress MU是Wordpress的多用户版本，因为程序结构的关系，Wordpress MU并不一定能兼容Wordpress的插件。这里我们谈到的兼容，是指无需做任何修改即可在MU中直接使用的Wordpress插件。针对MU开发的插件中，分为在原Wordpress插件基础上修改的和针对MU全新开发的两种。

按照作用范围区分，可分为全局插件和分站点插件

　　Wordpress中按照影响范围将插件分为两类，全局的插件和针对单个站点的插件，分别存放在不同的目录。

　　/wp-content/mu-plugins/ 目录下存放的是全局的插件。此类插件一般属于比较简单的插件，没有插件目录，而只是由一个php文件组成。上传后该类插件后不会出现在各个博客后台的Plug-ins菜单里，而是出现在Site Admin菜单里（必要的话）。此类插件无需逐个博客激活插件，默认就已经自动调用。

　　/wp-content/plugins/ 目录下存放的是分站点的插件。此类插件上传到后，需要用户手动在Plug-ins菜单的管理面板中启动（前提是管理员为该用户开启了该权限）。用户启用该插件仅影响该站点，而不会影响其他站点。

Wordpress MU插件的管理

　　如果是单文件的简单插件，则直接作为全局插件上传即可，无须也无法做任何管理。（有一个为含目录的插件创建调用的文件并作为全局插件的方法，查询无果，略过）

　　对于分站点的插件，如果管理员不想把启用和禁用插件的权限下放给用户，而想统一地为特定的博客启用和禁用插件，可以使用Plugin Commander或者WPMU Plugin Manager插件（两者孰优孰劣还没来得及比较）。

Wordpress MU插件的选择

　　首先当然是选择针对MU开发的插件，相当部分在WP平台上广受欢迎的插件都有针对MU的修改版本，既经受过时间的考验而且在使用习惯上能够得到延续。无论有无WP的经验，首先查询WP的相关插件，然后查询在MU平台上是否有衍生品是不错的方法。

　　当然针对WPMU全新开发的插件也有其优势，就是完全定制，在跨博客的兼容性方面会有比较全面的考虑。WPMU的官方站点的插件列表在这里。可惜的是数量与WP相比相差太多，活动也并不十分活跃，反倒是有相当一部分不错的插件被放在了需要付费的Premium区，当然这个WPMU的定位有关。

　　至于那些默认兼容的插件，需要注意的就是不会有任何跨站点兼容的支持。比如通过Tag获取相关文章，其影响范围只能限于单个博客，在不修改的前提下想跨博客建立关联是不可能的，这很显而易见。

兼容性的问题

　　因此Wordpress的部分简单的插件虽然可以默认兼容到Wordpress MU，但是还要谨慎对待。如何辨别是否兼容，区分的尺度方面，比如涉及到数据库的表，文件目录的操作，由于程序结构的关系，不修改恐怕是难以兼容的。其它的无非是多查询现有的资料以及自己尝试了。

　　即使功能运行正常，在比如升级、创建新用户、创建新博客时还是将插件先关闭为好，同时要注意不同插件之间冲突的可能。

本篇是没有技术含量的口水贴

　　博客运行了一年左右，WPMU升级过一次，插件也用过若干，但总体还是抱着尽量简单的态度，博客么，内容为王。

　　因此主题一直使用的是默认的Kubrik，蓝白色，二栏式，支持Widgets，支持目录的树形显示。除了单调了一些，唯一的缺点就是默认的字体稍小了一些。

　　这两天准备稍微收拾收拾，因为WP和WPMU的主题模板并不完全兼容的缘故，到WPMU官方提供模板的地方看了看。首先模板的选择不是很多，其次更新也不是很频繁。其中有一位Farms提供的多个主题的打包相当不错，有多次的更新，最新的版本是Farms 100 big ones theme pack，里面有近百个主题模板，都针对WPMU进行了修改以兼容。

　　容量不小，其中的个别还有些显示的问题，比如不显示Slogan，不能树形显示目录，有多余的换行，正文部分宽度不够同时不支持图像缩放导致越界等等，大家可以在本地的环境测试后再有选择性地上传。上传的目录是/wp-content/themes。

　　经过一番比较，没有上述问题且个人比较喜欢的主题模板有Bluebird、Connections、Contempt、Edublogs Default、GloriousDay、Jakarta、LetoPrime、Ocean Mist、OceanWide、RadMod、Rubric、WordPress II Silver。这之中有一些应该是WP中经典主题模板的移植，也许你现在正在浏览的正是其中之一。

　　因为是英文的主题模板，某些地方没有翻译可能会让部分浏览者比较困惑，以后学有余力的话再试着翻译并且做一些自定义。

　　突然发觉不同Linux发行版之间还是有一定得区别的。最近一直在用Ubuntu（从之前的文章可以看出来），也看到了一些对于Ubuntu的炮轰，比如兼容问题，比如对社区的贡献少，比如背后商业公司的利益导向等等，但总的来说Ubuntu的Live CD，简易的安装，打包好的软件，漂亮的界面对于推广Linux还是起了不小的作用的。

　　当然作为“有追求的专业人士”，将自己在知识方面的精力投资在一个更为通用、更为广泛接受的对象上无疑是明智的选择，所以还是需要介意一下的。

　　Novell的SUSE Linux版本没什么研究，只知道大致上是SUSE Enterprise和OpenSUSE两个分支。版本的定位和Redhat差别不大，之后再讨论。

　　Mandriva Linux，法国的发行商。最初基于Redhat，后来分道扬镳。使用GNOME、KDE桌面，使用rpm包，部分兼容Redhat/Fedora。这个基本没怎么见周围的人用过。

　　剩下的就是基于Redhat和Debian两种发行版的居多。最近很火的Ubuntu就是基于Debian内核（Debian本身反倒关注的人少了），简单来说就是预编译的.deb软件包可以兼容。Ubuntu分为针对服务器的Server版，针对桌面用户的Destop版，针对专本设备的MID和Netbook版。

　　Redhat方面，在与Fedora Project合并后，分为两条线路，RHEL（Redhat Enterprise Linux）和Fedora Linux。两者的区别在于Fedora由社区支持，每6个月更新；RHEL由Redhat公司支持，每18个月更新，面向企业用户，提供需要付费的subscription服务，相对于Fedora经过认证的软件包较少一些。具体的比较请看这里。总的来说，可以把Fedora看做是RHEL的基础，试验田，两者在定位上有区别导致在发行版内容的侧重上会有区别，但是技术基础没有区别。在RHEL上能干的事情，在Fedora上应该都能干，区别是RHEL上出了问题，你可以找Redhat支持，Fedora上除了问题，你得靠自己（还有社区）

　　到Redhat的网站上看了看，RHEL也分为Server和Destop版本，需要Buy，但是有30天的试用。但是请注意，Linux是Open Source的，RHEL也不例外。你购买的是7年的技术支持服务，而不是Linux本身，这意味着你在试用30天之后可以继续合法地使用RHEL，当然是在你不需要支持自己能搞定的情况下。

　　当然也有一些定位于RHEL替代的“免费”的Redhat分支，如CentOS、Tao Linux等。

　　RHEL下载还需要注册，感觉麻烦。跑到Fedora那看了看，一张光盘的Live CD，只有Desktop版本（当然你把它配成Server也没问题），可以Live CD直接引导，也可以配置成USB引导（不知道是不是学Ubuntu的）。于是中午下载了一个，决定之后开始玩起来。

　　总的来说各个发行版对于初级的应用来说差别不大，无非是桌面的使用习惯、预编译软件包的数量、对硬件驱动的支持。考虑到这么多年，公司里还是Redhat应用得比较多，所以最近有从Ubuntu叛逃到Redhat线路的意图。（当然其实学好了都一样，这个纯属个人问题）

　　自去年将Wordpress mu 2.6安装设置完毕后已经运行了几个月了，近日从空间商Dreamhost那里收到邮件，因为Wordpress 2.6的安全漏洞，建议升级到2.7。如果是使用他们提供的Wordpress一键安装，则一键升级即可，可惜我的是Wordpress mu，只好自己弄。

　　升级这个事情，可大可小。一般我的态度是，如果一切正常，就不去升级到什么新版本。况且作为一个无名小站来说，看都没什么人看，想来也不会招惹到什么强人来关心我的安全漏洞。不过耐不住连收到两封提醒邮件，警钟长鸣啊，升级就升级吧，总得经历一下，权当是为以后需要升级的时候做预演。

　　首先到Wordpress mu官网下载安装包，解压后找到readme.txt，跳到Upgrading部分，根据提供的链接打开Upgrading WPMU的说明页面。

　　因为Wordpress mu是基于Wordpress的多用户版本，所以首先需要阅读一下Upgrading_WordPress。

　　总得来说从2.6到2.7代码没有结构性的变化，升级过程很简单，唯一需要注意的是如果使用了太多的插件的话，可能有不兼容的情况产生，建议首先禁用插件。

　　如果不想读太多的文档，按照以下步骤即可

升级步骤

1.备份数据库，备份程序文件
2.将新文件上传，覆盖源文件
3.用admin登录，点击Site Admin –> Upgrade升级，完成升级。

　　2.7将Site Admin的界面做了重新组织，其它部分没有太明显的感觉。

　　如果想要启用用户cookie加密的话，还需要按照管理页面上的说明修改wp-config.php。

　　之后将禁用的插件重新启用，尝试各部分功能，如果没有问题的话，升级就告结束了，就这么简单。反之之前的备份就要发挥作用了。

问题：无法插入javascript,object等代码

　　在Wordpres mu中是无法插入javascript,object等代码的，这些在Wordpress中是可以的，但在Wordpress mu中据说是基于安全考虑而屏蔽了。这样就导致无法插入很多网站的wadge以及flash，比如flickr的图片展示，youtube的视频等等。

　　其原理也就是在提交内容的时候，使用了filter函数将如script、object等关键字过滤掉而已。

解决方案1：直接修改代码

　　可以通过修改代码的方法来解决此问题，需要修改的文件是/wp-include目录下的kses.php文件，在这个链接中有详细的说明。

　　方法一是将过滤的代码注释掉。这样会导致所有的文章和注释都能够使用诸如<script>和<object>等标签。但将这些开放给注释用户会存在潜在的隐患。

　　方法二是添加全局变量$allowedposttags的值，添加你所需要启用的标签。这样将只对提交的文章启用标签。这篇文章专门说明这个问题，可读性更强。

　　不推荐这个方法，如此修改的地方多了需要专门的记录，每次升级以后还需要验证代码的有效性（代码的结构有可能变化），然后需要重新修改。总得来说原则是能使用插件就尽量不修改源代码。

解决方案2：使用有针对性的专门插件

　　可以通过有针对的插件来解决该问题，比如要插入flickr的图片wadge就找flickr的插件或是图片插件，需要插入youtube的视频就找youtube的插件或是视频插件。

　　坏处是这样的插件比较多，而且相当一部分是针对wordpress，筛选起来比较困难，水平也有点参差不齐。况且明明就是一件事情，却弄得有点头痛医头脚痛医脚，兼容性太差。

解决方案3：寻找通用的插件

　　所以需要找一款能够关闭对嵌入javascript、object等常用的关键字过滤的插件。

　　Widgetize-AnyHTML插件，让你能够在widget中嵌入标签，但只能在widget里，而且只支持一个AnyHTML Widget，不很实用。

　　All text allowed插件，让你能够在文章（post）和页面（page）中嵌入标签。在主页的注释中提到了会移除<p>标签的问题。

　　Unfiltered MU插件，让你能够在文章（post）和页面（page）中嵌入标签，经测试widget也可以。这个就是最终的解决方案。下载压缩包，解压后得到unfiltered-mu.php，如果要安装为全局插件则复制进wp-content/mu-plugins/目录，如果要逐个blog激活则复制进wp-content/plugins/目录。

　　之前有记录过一篇《便携式WinPE》，介绍如何将别人已经做好的WinPE改成Portable的。现在移动硬盘里装的就是这个，重新安装系统也不用到处找光盘什么的，只要主板支持USB启动就好，可谓是居家旅行之必备。

　　于是也会好奇这个WinPE是怎么弄的，前几天在codeproject的newsletter里读到了一篇<How To Make Your Own Windows Live CD>，虽然还是使用工具，但好歹是一个小小的进步。

以下翻译自上文，有兴趣的同学可以DIY

　　Live CD允许你从光驱启动计算机并对你的系统实现不同的功能，比如Live CD非常适于恢复数据、修复问题或者当你使用不是自己的计算机时拥有一个由自己支配的自定义桌面。

　　Live CD在Linux世界相当普遍，但并不常听说Windows Live CD

　　今天我们要向你展示如何创建自定义的Windows Live CD

需要的工具
Bart PE
你的Windows安装盘（注：或者i386文件夹）

步骤

1. 下载并安装最新版的Bart PE。运行PE Builder。这是程序的主窗口。

2. 所有你想要添加的额外功能通过插件的手段实现。有很多插件可供选择。插件不过是向你的Live CD添加额外软件的手段而已。你可以从这里访问Bart PE的插件库。（注：相当多的插件，这张Live CD被打造成什么样子，或者说要实现怎样的功能，完全取决于你选择的插件）

3. 为了实现我们的目的我们需要一个叫做Windows XPE的插件以使我们能够启动进入图形化界面环境。你可以自由的为你想添加的功能选择其他的插件。那里有磁盘恢复、办公、备份、磁盘镜像等插件。

4. 现在插入你的Windows安装盘，为PE Builder指定包含Windows安装盘的CD驱动器或者其复制文件的路径。（如果你有一台笔记本和i386文件夹就更好了）

5. 点击底部的plug-ins按钮。你可以添加更多的软件或是调整现有的软件/插件。如果你得到错误提示，可能是你之前提供的源路径不对。

6. 点击add按钮，指向你存储Windows XPE插件的位置将其添加。我们使用了XPE插件后你可以安全地禁用Nu2shell，PENETCFG和A43插件因为它们提供的功能XPE插件已经包含。

7. 点击close。现在你可以刻录光碟或者保存一个ISO用于测试以便之后刻录。点击build之后PE Builder就会开始工作。

图略

8. 如果编译的过程无错误地结束，你已经创建了你自己的Live CD。

　　注：我的编译过程5分钟不到，生成的文件大小270MB。作者在Virtual Box虚拟机中测试生成的iso的贴图略去。以下是运行的WinXP PE的桌面贴图。感觉运行速度比较一般，还有待调校。

　　有其他的小技巧使你可以自定义启动时的文本，墙纸以及其他东西。不过是需要编辑一些文件的小麻烦而已。不管有没有这个可视的自定义环境，现在你都已经拥有了一个包含符合你特定需要的工具的，功能完整的Live CD。通过探索这样一个工具，还有无数其他的可能性在等待着你。比如你可以创建一张包含了所有你喜爱的程序和文档的Live DVD。
————————————————–

Bart PE的简介

　　翻译完上面的动手文章后，我们来介绍一下其中用到的Bart PE。引用自Bart PE的主页。

什么是Bart PE和PE Builder？

　　Bart是作者的名字，他开发的PE Builder帮助你通过原始的Widnows XP或Windows Server 2003安装盘创建一个基于BartPE（Bart Preinstalled Environment Bart预装系统）Windows启动光盘，非常适用于PC维护。

使用Windows内核的优势

　　对NTFS分区的完全读写访问

BartPE vs. Windows PE?

　　BartPE不是由Microsoft支持的。Windows PE才是Microsoft官方产品。
　　BartPE有图形化用户界面。Windows PE有一个命令行界面。
　　创建BartPE安装盘的工具是免费软件。Windows PE只针对Microsoft OEM用户。
　　BartPE允许无限制的自定义插件。Windows PE只有有限数量的插件选择。

BartPE和Windows PE的技术差别?

　　目标 - Microsoft把Windows PE看做一个安装平台。Bart把Windows PE 看做下一代的拯救回复平台。

　　开始菜单 - Bart的builder提供简单、动态、功能强大的开始菜单(Nu2Menu, 见截图). Microsoft的builder不提供开始菜单，只有命令提示符。

　　创建的源 - Bart的builder能够从Windows XP Home Edition或者一个 预装的Windows XP版本创建(不需要CD).

　　插件 - 通过PE Builder你能使用插件轻松添加应用程序、驱动和工具。这使PE Builder特别强大。最终用户能将不同软件商的插件整合到一个光盘镜像中。

　　网络支持 - PE Builder包含自己的网络支持工具(bartpe/penetcfg) 来启动TCP/IP和Microsoft Client. 各种TCP/IP设置如: dynamic/static ip-address, subnet-mask, default gateway, dns-servers computer-name, workgroup能即时修改。你也能创建一个供选择的预定义档案。Microsoft Windows PE只支持DHCP或是使用winbom.ini的固定的设定。
　　此外还有一个Erwin Veermans制作的插件(NwDskPe) 能为BartPE载入 Netware Client(IP/IPX).

　　文件共享- BartPE能够开启文件共享支持。

　　VNC - 因为支持文件共享，你同样可以运行UltraVNC。

　　Dos支持 - Bart’s builder有一个”dospe”插件。

　　授权- Microsoft Windows PE只针对企业/OEM客户，BartPE面向所有人。

　　64-Bit - Bart’s builder不支持Windows 64-bit版本。

————————————————–

后记

　　比较了生成的文件结构，和原来的老毛桃版本不一样，怎样把自制的版本Portable暂时还没什么头绪，以后再研究。

　　默认生成的只是一个可以运行的GUI，并没有太多的功能，还需要根据需要选择插件自己定制。看着长长的插件列表，仿佛又看见了一个时间杀手。需要查询一下是否已经有在Bart PE基础上提供的插件方案。

　　网站迁移到Wordpress不久，几天没关心就评论十几页，可惜都是卖蓝色小药丸的，我XX。看来这个域名被锁定了，以后配置Anti-spam校验的优先级看来要提前了。

　　Anti-spam的方式多种多样，Wordpress的插件也是数不胜数。不过以前在drupal平台上使用的就是reCAPTCHA（这里有相关介绍），除了校验顺便还能帮着识别一下古籍，虽然评论会麻烦点不过小众站点也就无所谓了。

　　照例还是在WPMU DEV里面找，WP-reCAPTCHA插件倒是Wordpress和Wordpress mu通用。

　　下载安装包后解压得到wp-recaptcha目录，上传到/wp-content/mu-plugins/，将该目录下的wp-recaptcha.php移动至上层目录（真是很神奇的说明）。插件无需启用即已运行。
　　通过[Site Admin] –> [reCAPTCHA]打开设置界面。

　　左边是常用的评论和注册保护设置，右边是邮件地址保护设置，意思都比较清楚。需要注意的是Public Key和Private Key需要到recaptcha的官方网站免费注册获取。设置完成后点击Update Options保存，再打开评论，你将可以看到如下的验证框。

　　除了提交sitemap之外，对网站点击的流量、来源等进行分析，并对网站的内容进行相应的调整也是SEO不可或缺的一部分。
　　Google Analytics（Google分析）是Google提供的这样一款免费工具，可以对访问者、流量源、内容等方面生成详尽的报告，并且还可以很好的和Google Adsense结合。

　　使用你的Google账号登录Google Analytics后，为网站创建一个Analytics的Account，将得到一段js代码，将该段代码复制到想要跟踪分析的网页的</body>标签之前即可。

　　CMS的网页大多是动态生成，不可能逐页复制，因此需要将这段代码复制到模板中。修改模板的缺点是如果更换模板或者系统升级则需要重新更改，因此有人开发了插件来实现。
　　Wordpress的Ultimate Google Analytics就是一款插件，设置项也非常多，但是它只能为整个站点添加一个Google Analytics跟踪，对于Wordpress mu的用户来说，如果你想为站点里的每个博客添加分别的Google Analytics跟踪，UGA恐怕满足不了你的要求。
　　于是继续在WPMU DEV里需找适合Wordpress mu的插件，找到了一款Google Analytics Plugin For Wordpress MU - Revised- English。

　　下载安装包后解压，得到一个rafik_ga.php文件和一个rafik_ga目录，将其上传至/wp_content/mu-plugins/目录，无需启用即开始运行。
　　如果想要为整个站点设置Google Analytics，打开[Site Admin] –> [Google Analytics]。
　　如果项要为某个特定的博客站点设置Google Analytics，则打开[Setting] –> [Google Analytics]。

　　设置的界面很清爽，只需要将js代码中的一串类似”UA-xxxxxxx-x”或 “UA-xxxxxxx-xx”的字符串填入文本框，然后点击Update Options保存设置即可。接下来的就是耐心等待Google Analytics的分析数据了。

　　为站点生成站点地图能够方便用户浏览，而生成XML格式的Sitemap文件则方便Google等搜索引擎了解网站的结构和更新情况，更好更快地收录网站的内容，为网站带来浏览量。

　　一般Sitemap文件都是由发布平台的插件自动生成，比如Wordpress平台上有Google (XML) Sitemaps Generators。Wordpress mu是Wordpress的多用户版本，因为涉及到多用户独立配置的需要，两者的插件并不完全能通用。为了符合要求，有时还需要修改插件的源代码。当然，修改源代码一般是最后的解决方案。
　　在WPMU DEV列出了一些专门适用于Wordpress mu的插件，目前总共有150多个，每页10个，没有分类也没有站内搜索，翻翻找找找到了Standard XML Sitemap Plugin。
　　这个插件会为Wordpress mu中的每个站点分别生成sitemap文件。比较特别的是它并不生成静态的XML文件，而是在每次收到请求的时候自动生成。

　　下载安装包后解压，得到两个php文件。将’xml-sitemap.php’上传至’/wp-content/mu-plugins/’，将’feed-sitemap.php’上传至’/wp-includes/’。因为这是全局的插件，上传完成后无需启用就已经在运行了。
　　如上所述，该插件不会在站点的根目录生成sitemap.xml，要确认效果只需要访问http://your-wordpressmu-site/blog/sitemap.xml即可。

　　接下来就是向搜索引擎提交sitemap，比如Google Webmaster Tools，一般按照界面提示将sitemap的URL地址填写并提交即可。

问题：
　　在作者的站点，有几位用户留言提到了两个主要的问题：一个是日期格式如’2008-10-07T19:35:50 +0000’当中的空格会导致Google Webmaster Tools提示Invalid Date的警告信息（这个问题很奇怪的在我的两个站点中只有一个提示）。一个是sitemap.xml列出的post数量太少。
　　对此一位名叫sirjoe的用户给出了他的修改。文章是用意大利语写的，但代码就是最好的交流语言。

　　编辑feed-sitemap.php
　　源代码第19行和39行，将‘Y-m-d\TH:i:s +0000′修改为‘Y-m-d\TH:i:s+00:00’，去除+前面的空格，在00前添加: 。解决Invalid Date的问题。
　　源代码第26行，将‘SELECT … DESC LIMIT 100’中的100改为你想要的数字。

　　最终还是修改了源代码，不过开源软件就是这样。修改一个Wordpress mu的插件的问题还是比修改一个Wordpress的插件让它来适应mu要好一些。