我还是觉得自己开辟搭建一个独立blog平台，我常用linux服务器，因此选择php环境。 这样，我可以选择的开源博客系统会有很多。这里不对博客系统进行纵向对比。我说下，对wordpress认识过程，一些自己的体会。纯属代表个人意见，欢迎讨论！
刚开始，下载一套wordpress 3.5，然后一路安装下来，比较简单，跟常见其它一些开源平台查不到。 只要配置好数据库连接，然后一路下一步，分把钟就可以做好。 也是由于，对wordpress 早已经有所耳闻，而且感觉它名气很大，这类系统中佼佼者。
11张表，实现了强大的博客功能，首先表示不简单。现在很多cms 基本上都是40-50个表。其中很有几张表，设计为窄表，基本上类似，类型，键值名，键值。类似近年的NoSql类型数据库。都是键值对。读取灵活，扩展方便。 可能就是，开发时候复杂些。这类基本设计是：posts,postmeta表，所有文章都具备的通用字段，就放到posts表，而针对文章进行属性设置，如：访问数，tag，权限等。都放到postmeta表。如：
窄表，可以任意对一篇文章新增键值，扩展新的属性。 这也是wordpress 插件几乎可以做到无所能一个原因。 这类表可以非常灵活。新增一个属性，只需要在这个表里面，对posts ID 增加这类属性的一条记录。而且这类窄表，字段少，读取速度也很快。
感觉到表设计不足之处(个人认为，欢迎交流）
Posts表里面字段，一张表里面，居然有6个text 字段。如果读取时候，不小心select *,该会有多少磁盘IO,一条记录，该会占多少的数据块。记得刚刚，分析wordpress时候，当时一下子就看到这样情况。我毅然选择放弃该系统。也因此让我忽略了，他窄表设计优点。 个人认为，一些字段可以设置为varchar,另外text 可以移到单独posts_data表。里面只存放text字段,PostID 信息。欢迎高人指点。
现在wordpress插件有成百上千个，它基本上可以做各种系统。除了blog外，它还被改成了新闻网站，企业网站，电影网站，甚至是商城系统。这些足以说明，他前端程序一定有过人的设计架构，有它足够灵活性。
- 看下他的目录结构吧
从这些目录，真的还没有发现它比较独特优越性。现在网上常见的MVC 结构，有独立模版目录。 这个wordpress,实际只能算，MC，而没有V，它实际上前端是通过php 直接调用include 目录里面函数而已。如：
这个也是它的一个独特特点了，国内很多模版，都会开辟自己的标签，如smarty的是：{$smarty.config.aa} 等。 而wordpress里面没有自己标签，要读取，通过函数去读。它省去了标签省去了大家学习标签成本，但大家也需要掌握N多的函数。 可以把它的函数，理解为其其它系统中定义标签。
无论是函数，还是标签，只要你在前端页面都使用这些方法，去读取你要的数据，实际上都对后端数据库做了隔离。从而让使用者不关系数据库数据了。 数据库结构修改，只要调用函数做相应跳转。前端页面还可以照样那样用。而不需要任何修改。从而保证它的稳定性。
它函数封装，不光做到从DB读取数据，通过函数，读模版，读公共包含文件，等等都做到了，函数封装。几乎做到了，所有读取数据封装（DB,file,request中），这样封装，在目前国内系统中很少见，因为为每个功能去写一堆函数，切实很多工作量。国内框架，基本上喜欢封个方法，做到很通用，然后自己去调去吧。 这个方法，可能可以读取用户表，也可以读评论，也可以读文章。 其实，看起来很通用，实际用起来就会很复杂，也会增加上手难度。我们看看wordpress 设计方法。
这只是其中的很少一部分函数，真正差不多1000把个函数呢。 因为，wordpress 函数几乎封装了所有数据调用，因此前端开发只用调用函数，就可以完成。简单容易，这也是灵活性，及得到广泛使用一个原因。
2. 看看它代码实现优点
如果说，wordpress 光只有，强大的含数据库，做到前端页面与数据直接分离。现在很多标签调用也能做到分离。 真正wordpress灵活性，以及能够扩展出各类插件，完成独特开发功能，与它独立系统分不开。
它有一个 消息机制，还有一个队列过滤模块，任务队列处理模块。这2个模块，都建立在它的一个消息机制上，普通开发方式如下：
消息机制，可以做到，前端跟实现地方解耦。这里打个比方，如一个用户完成注册，我要给用户发一个邮件，然后给管理员发一个站内信。我们以前做法是：
如果发完站内信后，还有发一个手机短信，我们必须修改注册逻辑，在接下来再增加一个发送手机短信功能。 这时，你发现任何前端修改，都需要在原先逻辑里面修改一通。 如果我们采用消息机制，程序将变为:
这个图，是改用消息模式结果，用户注册功能模块，跟接收到消息处理各个任务直接，代码没有直接关联。如果需要增加一个接收注册消息，给其它人通知一下，只需要新增一个模块，订制注册消息，然后处理一个新流程即可。
目前各类开源项目里面，消息机制已经变得非常常见了。 但在wordpress这个blog框架，它的消息主题非常完善。几乎任何动作都有消息主题发送消息。 这样让开发者，只要订制相关主题，就可以，增加自己额外处理功能。 例如： 用户发一个帖子后。检测下用户是不是有广告信息，只要订制：发帖消息，然后，增加新功能，检测内容。发现不满足，直接屏蔽帖子。
有人估计要说，这类功能，现在很多框架有类似东西，例如，页面开始有个start事件，结束有个end事件。 确实，消息概念在很多框架里面确实有用。 但是，没有这么完毕的消息主题抛出。 几乎做到整个系统任何操作，都能有消息，这样没有什么功能不能进行扩展了。
有兴趣可以去研究下，wordpress add_filter,apply_filters ，还有add_action，apply_action ，只是收到消息后，一个按顺序进行一系列元内容过滤，一个是接收元内容，进行一系列任务。
wordpress 2大优点，一个是函数封装数据操作，一个是它完善消息功能。那它有何种确定呢？
任何一个系统，有优点，一定有不尽人意的地方。
首先，因为它要做到自己很多函数，可以直接读取一些循环数据。或者直接读取数据库配置项。它启动时候，采用了大量的全局变量。一个大的blog,可能启动后全局变量有几百个。 有的是数据记录，有的是字符串，有的是对象。你可能会发现，这些数据可能有1，2M；无论有没有使用，这些都会先创建。可想而知，他将带来大量内存浪费。另外一个就是，可能会影响调用速度。 很多网友使用wordpress就明显有这个感觉了。
另外一个问题，其实正式来自它的消息处理模块。 它跟我们网上看到的不一样，它的消息模块是同步模块。以上面打的比方来说，尽管做到发送消息，跟处理模块代码分离。 但实际上执行过程没有多大变化，也是要先注册用户完，然后完成一些列处理功能。最好这个php页面才算处理完了。 需要时间还是那么些。 如果真的，能把这类跟功能无关接收消息，处理模块异步到后端。 那么估计再没有人抱怨wordpress打开一个要4，5秒了。
就说这么些了，估计很多同人告诉我说。居然它性能不好，又慢。 你干什么还要用它呢？ 这个就看你主要关注的是什么了，如果你需要快的开发模版，而且非常容易开发各种扩展。那么它是你最好选择了。 况且，性能问题，一但静态化后，几乎解决了。
估计还有人说，你既然提到它性能这么些不足，那么你有什么好的调优方法没有。 呵呵，这里欢迎大家交流意见，我也有一些想法，就先不详说，还不成熟。欢迎交流！！！祝朋友们，周末愉快！
