这是关于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中经典主题模板的移植，也许你现在正在浏览的正是其中之一。
因为是英文的主题模板，某些地方没有翻译可能会让部分浏览者比较困惑，以后学有余力的话再试着翻译并且做一些自定义。
自去年将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/目录。
网站迁移到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要好一些。
打开IMified.com，注册。
打开API文档，直接找到Example Hello World bot部分，将实例代码贴入编辑器，保存为helloworld.php。
<?php
switch ($_REQUEST['step']) {
case 1:
echo "Hi, what's your name?";
break;
case 2:
echo "Hi " . $_REQUEST['value1'] . ", where do you live?";
break;
case 3:
echo "Well, welcome to this hello world bot, " . $_REQUEST['value1']
."<br>from " . $_REQUEST['value2'] . ".<reset>";
break;
}
?>
将helloworld.php上传至你的空间。
登录IMified.com，点击New Application，添加一个新的机器人。
为bot取名，输入之前上传的helloworld.php的url地址。点击“Add new Bot”完成。
打开Gtalk，添加eric@bot.im为联系人，开始聊天吧。
看看时间，应该没到5分钟。
—————————— 我是华丽的分隔线 ——————————
Gtalk采用的是Jabber协议，也就是说能和使用Jabber协议的其他聊天工具互通。
IMified.com提供API，让你不用去关心Jabber协议。同时还为bot提供服务器。
helloworld.php中的_REQUEST、step、value、reset很好理解，所以这个bot做的事情也很简单。剩下的只需要发挥想象力：使用PHP能做什么呢？
把MSN Space作为聚合各站点内容的门户之后，准备为MSN Space启用自有域名。在设置中有“自定义域名”选项，但是必须启用Windows Live Admin Center。直接使用域名的Forward功能似乎是不起作用，理由是和dns有关。不懂，不解释，反正就是不行。
那就换个方法，用域名的首页直接把url重定向到MSN Space。
在GoDaddy购买域名后会附送Free Hosting Plan，包含Linux和Windows两种，Linux是PHP + MySQL，Windows是ASP.Net + MSSQL。功能一般，但够用。因为经常用基于PHP + MySQL的CMS系统，重定向的源地址使用的是Free Linux Hosting Plan，那就学学PHP的重定向代码怎么写吧。
记得在ASP里重定向的代码是
<%
response.redirect("url");
%>
用PHP和Redirect作为关键字查询，在about.com找到这篇。代码如下：
<?php
header( 'Location: http://www.yoursite.com/new_page.html' ) ;
?>
这段代码：
1. 能够快速地、无痕迹地将浏览者重定向
2. 当使用“后退”按钮，用户被带到最后浏览的页面，而非重定向的源页面。
3. 兼容所有的浏览器
注意事项：确保在该段代码前没有任何文本被发送至浏览器，如以下代码是无效的
<html>
<?php
header( 'Location: http://www.yoursite.com/new_page.html' ) ;
?>
写的有印象的第一段PHP代码竟然不是Hello World，很好很强大，挖个坑留念。
