转载：CMS功能
1.WYSIWYG Web 編輯器
所見即所得 （WYSIWYG）Web 編輯器是你編寫網站內容的最重要的工具，一個好的編輯器可以生產出優秀的代碼并讓你擁有高質量的網站內容，目前最好的 WYSIWYG 編輯器包括，TinyMCE 和 FCKeditor 兩種，這兩種編輯器在各 CMS 產品中被集成的最多，我個人最喜歡 TinyMCE，以為它更輕量。如果你想看到更多 WYSIWYG Web 編輯器，你可以訪問主流 WYSIWYG Web 編輯器功能對比表。
WYSIWYG Web 編輯器是任何 CMS 系統必備的功能，否則，讓用戶自己創建內容就成了空話。
2.模板
模板是 CMS 將內容和形式分開的很好的機制， CMS 系統必須允許使用者更改站點外觀，不管是使用模板還是可視化參數調整。但模板也常常是一個 CMS 系統最令人頭痛的部分，你可以下載免費的模板，也可以花錢請人做，若要自己做，你會發現那是實在不是個輕松的任務。
3.靜態 URL
友好的，靜態的 URL 不僅讓用戶，而且讓搜索引擎更舒服，現在的 URL Rewrite 技術已經可以很容易實現這個功能，對所有 CMS 來說，這是必需的一個功能。
4.全站搜索
CMS 系統一般使用后臺數據庫存儲網站內容，這讓全站搜索變得易于實現。讓訪問者快速找到想要的內容是 CMS 的首要任務，這是一個 CMS 系統必須擁有的功能。
5.站點地圖
站點地圖將全站內容的靜態鏈接放在一個扁平頁面中，對訪問者和搜索引擎來說，這都是一個方便之舉，自動生成站點地圖，是任何 CMS 系統都需必備的一個功能。
6.自動導航菜單
網站創作者一邊添加內容，系統一邊對這些內容進行自動組織，并生成導航菜單，這些自動生成的導航菜單可以有效地引導訪問者發現他們想要的內容。這個功能對所有 CMS 系統都非常必要。
7.自動面包屑導航
面包屑導航幫助訪問者在任意導航深度中都能從原路返回，這是網站易用性的一個重要指標，該功能非常重要。
8.自動縮略圖
用戶向網站上載圖片之后，CMS 系統應該能自動按當前工作區的大小生成縮略圖，該功能對任何網站都非常必要，畢竟不是所有用戶都知道如何使用縮小圖片，而如今主流的圖片源，數碼相機，即使放在最低分辨率模式下，其產生的圖片尺寸仍然遠遠大于網站的實際需求。
9.批量上載
這個功能允許用戶一次上載多個文件，該功能一般通過 zip 壓縮包實現，用戶直接將批量文件壓縮成 zip 文件，上載后，CMS 會將這些文件解開并防止在相應位置。該功能并非對所有站點都實用，如果你的站點并不需要大量資源的上載，該功能是可有可無的。
10.拼寫檢查
拼寫檢查一般通過兩中方式實現，一種是純客戶端方式，用戶在瀏覽器中創作內容的時候，客戶端的 Javascript 將用戶的拼寫同位于客戶端的字典進行對照檢查；第二種方式是，AJAX 方式，用戶在客戶端創作的同時，使用 AJAX 機制將當前拼寫同服務器端的字典進行對照，無論何種方式，拼寫檢查都會給客戶與服務器帶來額外的負擔，雖然拼寫檢查聽起來很好，但如果是在 Word 或 Excel 中，那當然沒問題，一切都在本地，在 Web 這個領域，拼寫檢查要復雜得多。
11.Captcha
Captcha 是這樣一種機制，網站在接收用戶提供的信息的時候，為了防止被一些自動程序濫用，會生成一段只有人類才能識別的識別碼要你輸入，用來區分人和自動程序。該功能對大型的，需要大量用戶提供信息的網站來說是非常必要的，比如 Craigslist.org ，為了防止人們在某些版塊使用自動發帖機重復張貼廣告，便使用了 Captcha 機制。但對小規模的網站，由于你的訪問量和知名度還達不到會被濫用的程度，Captcha 是可有可無的東西。不論怎樣，選擇 Captcha 機制之前，一定對該 Captcha 進行測試，我遇到g過很多人類無法識別的 Captcha 識別碼系統，只能說，他們的 Captcha 機制太極端了。
12.版本控制
按理說，版本控制是任何 CMS 系統必須擁有的功能，但在實際使用中，我發現，這個復雜的版本控制功能并不想人們想象的那么好用，內容管理中最可怕的是出現內容混亂，拿你自己的文件系統做比較，有多少人在自己的文件夾中為一個文件設立不同的版本呢，即使有，最終怕也將以混亂收場，版本控制在很多場合就是將簡單的問題復雜化。
但在某些場合，比如你的網站由很多人參與交叉創作，大家為了防止同一個文件被其他人錯誤地改動，版本控制可以幫你追溯較早的版本。版本控制功能的一個極端的例子就是 wiki，wikipedia 上的一個熱門詞條上會有數千個修改記錄，你可以憑借這些記錄將這個詞條追溯到幾天前或幾個月前的某個版本，當然 wikipedia 本來就是給 Geek 們用的。
13.更改審計與追蹤
這個功能的命運和版本控制一樣，人人覺得它很重要，但人人都不喜歡用。該功能可以記錄站點內容的更改歷史，誰在什么時候，對什么內容，做了什么樣的改動，如果你有一個網站內容創作團隊，為了防止團隊成員犯錯，這個功能是非常有用的，如果只是三五個人一起商量著做做內容，不審計也罷。
14.內容審批發布
內容經審批以后才能發布是除了版本控制之外，另外一個企圖將簡單的事情復雜化的功能，現在網站越來越注重內容的時效性，假如你發布了一條新聞，在等待主管審批的過程中別的網站已經搶先發布了，這種無形的損失是巨大的，與其將所有東西都完善了再做，不如一邊做一邊完善。
當然，如果你的內容如果失當會引起訴訟或其它麻煩，這個審批功能還是必要的。
15.電子郵件地址驗證
有一些網站，似乎特別看中用戶在注冊的時候所提供的電子郵件地址的合法性，盡管這些郵件地址對他們來說可能毫無價值。他們會向你提供的郵件地址發送一個驗證碼，你收到驗證碼之后，通過點擊一個鏈接完成驗證，這聽上去很嚴密，也很科學，但你到底為了什么，你花費了這樣大的氣力只為了獲得一個真實的 Email 地址嗎，即使是這樣，這個地址對你來說有什么用處？
這個機制還存在一個缺陷，就是很多人提供的免費 Email 地址在許多網站是壓根就不能用的，很多人等了一個下午也不見驗證碼回來，我的意見是，如果要求用戶注冊，如果用戶的信息對你沒有任何經濟價值，那只要用戶提供用戶名和密碼就足夠了。
16.輸出到 HTML 靜態文件
對一些可能遇到海量訪問的大型站點，將內容輸出到靜態 HTML 是非常必要的，Web 服務器直接從 Cache 中將靜態頁面推出，和經過服務器端渲染，再將內容推出在效能上的差別是很大的。但必須認識到輸出到 HTML 靜態頁面的問題，將站點全部生成 HTML 文件是非常耗時的，所以很多 CMS 系統使用了服務器上計劃任務來自動實現這個轉化過程，這就面臨著一個內容滯后的問題，就是說你的站點無法做到實時更新。這是個很大的問題，事實上，隨著服務器計算能力的成倍提高，現在的服務器已經可以在豪秒級完成一個頁面的渲染，這點時間比起網絡上本身的延遲幾乎是無法覺察的。
這里還存在另外一個誤區，有些人認為只有 html 后綴的網頁才是對搜索引擎友好的靜態頁面，事實上，任何不包含查詢字符串參數的 URL 都是 SEO 友好的靜態頁面，它們之間沒有區別，搜索引擎對 aspx, html, jsp 等各種不同后綴的 URL 是一視同仁的，只要你不包含查詢字符串。
17.內容采集
使用內容采集功能，你可以自動從別的網站抓取內容并發布在自己的網站上，這是個非常無恥的功能，一個網站最終是否成功，比的是內容，而且是原創內容。另外，內容采集是個很不可靠的功能，比如，被抄襲網站突然改版，內容采集只能重新定義采集規則，而那些規則是極其復雜的。
18.現場編輯
現場編輯允許內容創作著一邊瀏覽自己的網站，一邊在發現問題的時候，直接登陸到 CMS 系統進行現場修改。有一些 CMS 系統，分了嚴格的前端和后端，內容創作都是在一個獨立的后端管理系統中實現的，內容發布后，在前端可以看到結果。現場編輯是個非常好的功能，可以讓創作者在流暢的思路下進行創作。
19.回收箱功能
人難免出錯，但出錯了還有挽救的余地，這就很好，這個功能保證創作者即使不小心刪除了某個內容，仍然能從回收箱找回。
20.訪問統計
這個功能非常實用，好的統計功能可以讓你隨時掌握網站的訪問情況，以便調整自己的優化或廣告策略。訪問統計功能有兩種實現方式，一種是全內置的，所有統計功能由 CMS 系統自身完成；另一種使用第三方統計服務， CMS 系統只是將第三訪提供統計代碼插入所有網頁。目前，最好的第三方免費統計服務是由 Google 提供的，你可以到 Google Analytics 查看更多詳細介紹。
21.內容翻譯功能
這是個聽上去不錯，事實上卻很糟糕的一個功能，誰都想按一個按紐就把自己的中文網站翻譯成英文，但迄今為止，世界上最好的翻譯引擎 World Lingo 的翻譯結果仍差強人意，更不要說那些二流或三流的。如果你覺得好玩，這個功能自然好玩，但用作正式網站卻要十分謹慎，這些翻譯引擎的翻譯結果往往讓人苦笑不得。
另外，幾乎所有的 CMS 翻譯功能都是以調用第三方 Webservice 或以 Screen Scrape 方式實現的，這就為它們的可靠性埋下隱患，因為你不能保證這些免費的第三方借口什么時候會突然改變。
22.內容聚合
兩年前，內容聚合（RSS）炙手可熱，流行得不得了，現在社會網絡取代了一切，2008年你還在自己的網站上提供 RSS 鏈接將是很土的事。
23.多語種 （多國語言）
既然 CMS 提供的在線翻譯根本不可靠，就老老實實自己做多國語言內容好了。好的 CMS 允許創作者只是提供某項內容的不同語言版本，由系統自動對這些不同語言版本的內容進行組織。
24.支持 UTF-8
要支持多國語言，CMS 就應該盡可能地使用 UTF-8 編碼。
25.XHTML 支持
現在，越來越多的瀏覽器加入 W3C 陣營，包括 IE，支持 W3C 標準的 CMS 對生成的內容可以更好地掌控，支持更多的瀏覽器，對瀏覽器頁面渲染效率的支持也更好。XHTML 可以讓 CMS 產生的代碼更合乎規范，但需要注意的是，很多 CMS 系統靠 WYSIWYG 編輯器創作內容，這就要求你的 WYSIWYG 編輯器能夠產生 XHTML 代碼，目前，生成代碼最合乎 XHTML 規范的編輯器是 TinyMCE。
26.博客功能
博客和普通內容的區別是，博客基于時間，支持 Tag，對 CMS 來說，同時包含博客功能不是多么難的事，可能有人會說，何不使用更專業的博客系統。比如 Wordpress，問題是你很難將那些專業的博客系統無縫集成到你的站點，更不要說那些系統部署起來也并不容易。CMS 功能中包含博客的目的是，很多企業網站往往在自己的站點中推出團隊博客，以便拉近和客人之間的距離，在個人網站中加入博客，也會讓你的訪問者對你了解得更多一些，政府網站，或其它官僚機構網站也是這樣。
27.在線聊天功能
這個功能在90年代末非常流行，那是 Web 聊天和 IRC 聊天的時代，現在這樣的功能實在多余，人們更喜歡使用 MSN, Skype,或者 QQ.
28.廣告管理功能
下載一段廣告代碼（不管是來自Google，還是Alimama），放到自己的網站，然后等著別人上門送錢；或者你有自己的廣告渠道，CMS 的廣告管理功能就是在你的網站上部署廣告的，如果你對自己的網站的前途非常自信，這個功能可以很好地幫你管理廣告，然而如果你屬于不幸運的99%，你根本不可能從廣告中獲得真正收益。如果你是企業網站，或者政府網站，或者某些機構性網站，壓根就不該在上面部署任何第三方廣告。
29.論壇功能
CMS 中的論壇肯定無法和 Discuz! 一樣的專業論壇程序相比，但可以幫助要求不高的用戶減少部署時間，并能讓論壇功能直接集體成在網站中。但實際使用中我發現，這種系統往往成為雞肋，如果你要部署的是大型論壇，那應該使用專業的論壇系統，如果你的論壇可能沒幾個人訪問，干脆不要部署。
30.FAQ，招聘，產品管理等功能
我的想法是，如果這些簡單的功能都需要獨立的模塊去實現，最終一個 CMS 系統會被自己壓垮，這些功能完全可以象創建普通內容那樣創建，比如，如果你的企業要在網站上發布招聘信息，你沒有必要要求那個系統和智聯招聘一樣，僅僅是編寫幾段文字，幾個表格就可以了。
31.Guest Book
從功能上講，這個模塊無可厚非，但這個流行于90年代末的功能的實際價值實在值得懷疑。我想問的是，如今真的有人會在你的網站上留下一個問題，然后苦苦地等你的答案嗎？他/她為什么不直接給你發個 email，或者在你的 MSN, SKype 上留言或直接交流。Guest Book 也許是一種賣方市場時代的思維，它的含義是，好了，你來到我這里了，你想怎么樣，說吧，過兩天我答復你。實際的情形往往是，可能一個月也沒有人來留言，你也懶得去看，終于在第三個月的時候有人留了言，你看到時已經是半年以后了。
32.郵件列表
在90 年代末，如果你的網站上沒有個郵件列表供你的用戶訂閱，你都不好意思讓自己的網站上線，雖然這些郵件列表里面八成沒有什么有用的內容。如今，信息如此泛濫，RSS 都過時了，社會網絡，標簽，web2.0 將所有人的眼睛塞滿垃圾，我實在看不出誰還會老老實實去訂閱你那些東抄西湊的內容。
當然也有例外，如果你的內容非常有價值，而且你有非常固定的閱讀群，郵件列表從本質上講，比 Web2.0 時代的那些新鮮玩意好得多。
33.投票或調查系統
這個功能始終會有市場，畢竟，如果你的問題很別致，有新意，多數人會不吝點上一鼠標，投上一票。
34.電子商務
你要承認，一個功能稍微完備一點的電子商務系統的規模可能是一個 CMS 系統的十倍，很多 CMS 系統所配備的電子商務系統并非真正的電子商務，可能僅僅是一些產品列表，加上個購物車，然后把你引導到結算前臺，通過五花八門的支付方式要你付錢，我相信這種購物體驗是很差，又讓人不放心的。真正的電子商務系統有強大的后臺支持，庫存管理，物流，派送，安全的支付（必須使用 https 協議），防欺詐系統等等。
對于 CMS 系統中的簡單的銷售系統，建議調用第三方的支付平臺，用戶在你的網站選擇商品或服務，然后被引導到 Paypal, Google Checkout 一類的專業支付平臺進行。
自：http://www.cnblogs.com/celery94/archive/2008/12/03/1346491.html
轉載于:https://www.cnblogs.com/boy5d/archive/2009/01/03/1367524.html
總結
- 上一篇： [小功能]按阅读数、评论数、评论时间查看
- 下一篇： 心疼啊今天在四季青买衣服的时候在试衣服的