技術角度wordpress結構優缺點分析

我還是覺得自己開辟搭建一個獨立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外，它還被改成了新聞網站，企業網站，電影網站，甚至是商城系統。這些足以說明，他前端程序一定有過人的設計架構，有它足夠靈活性。

1. 看下他的目錄結構吧

 

從這些目錄，真的還沒有發現它比較獨特優越性。現在網上常見的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大優點，一個是函數封裝數據操作，一個是它完善消息功能。那它有何種確定呢？

• wordpress源碼不足

 

任何一個系統，有優點，一定有不盡人意的地方。

首先，因為它要做到自己很多函數，可以直接讀取一些循環數據。或者直接讀取數據庫配置項。它啟動時候，采用了大量的全局變量。一個大的blog,可能啟動后全局變量有幾百個。 有的是數據記錄，有的是字符串，有的是對象。你可能會發現，這些數據可能有1，2M；無論有沒有使用，這些都會先創建。可想而知，他將帶來大量內存浪費。另外一個就是，可能會影響調用速度。 很多網友使用wordpress就明顯有這個感覺了。

另外一個問題，其實正式來自它的消息處理模塊。 它跟我們網上看到的不一樣，它的消息模塊是同步模塊。以上面打的比方來說，盡管做到發送消息，跟處理模塊代碼分離。 但實際上執行過程沒有多大變化，也是要先注冊用戶完，然后完成一些列處理功能。最好這個php頁面才算處理完了。 需要時間還是那么些。 如果真的，能把這類跟功能無關接收消息，處理模塊異步到后端。 那么估計再沒有人抱怨wordpress打開一個要4，5秒了。

 

• 后記：

 

就說這么些了，估計很多同人告訴我說。居然它性能不好，又慢。 你干什么還要用它呢？ 這個就看你主要關注的是什么了，如果你需要快的開發模版，而且非常容易開發各種擴展。那么它是你最好選擇了。 況且，性能問題，一但靜態化后，幾乎解決了。

估計還有人說，你既然提到它性能這么些不足，那么你有什么好的調優方法沒有。 呵呵，這里歡迎大家交流意見，我也有一些想法，就先不詳說，還不成熟。歡迎交流！！！祝朋友們，周末愉快！

 

作者：chengmo  QQ:8292669
原文網址：http://blog.chacuo.net/67.html
訂閱保持關注：http://blog.chacuo.net/feed
本文版權歸作者所有，歡迎轉載，請務必添加原文鏈接。