您在這裡

首頁 » Forums » 綜合討論 » 閒話家常討論

為什麼不用 Drupal ？

kiang's 的頭像
由 kiang 在 2013-03-17 (周日) 13:25 發表

Drupal 功能強大，而且世界知名，但是經手的許多專案中，都是將 Drupal 換掉，針對需求重新改寫，這裡聊聊一些我所看到的原因。

# 沒辦法直覺找到需要的功能

傳統的程式設計中，我們會針對前台看到的選單設計對應的管理功能，讓使用者可以輕易的找到希望調整的內容。但 Drupal 將內容抽象化後運用在大部分位置，因此不管產品、新聞還是工作團隊的介紹，都統一透過一個介面管理，再依據內容類型的不同產生表單，這是許多習慣舊有程式邏輯的朋友面臨的第一個挑戰。對於一個年輕人來說，這樣的改變很容易接受，但年紀稍長的朋友可能就不這麼想了，他們還是希望清楚的分門別類就好。

# 要讓畫面長得跟畫出來的一樣，好難

許多網頁設計人員還是習慣著先將所有的畫面透過繪圖軟體完成，接著切割後套用到程式中，但這在 Drupal 行不通，或者該說，要花非常多時間去完成這件事情，而且讓人沮喪的地方是，很多小細節是牽一髮而動全身，很多的時間花在這樣子來回的調整中。有經驗的朋友知道，應該要先了解 Drupal 的架構，然後依據架構去產生設計，這樣才可以避免衝突情況發生，但這件事情要說服傳統設計人員可不是那麼容易，特別是那些已經在設計界小有名氣的設計師，他們總能夠把 Drupal 批評的一文不值，即使他們也知道美國白宮就用這玩意兒。

# 現有的資源豐富，但並不是每個模組都有成熟的發展

專案開發的程式最常會發生，為了要達到合約書上的要求，儘管使用的模組並不是非常穩定，也會把它放入交出的成果中，想辦法等到驗收完成，然後就不再回頭去想這件事情。但並不是每個故事都有完美的結局，這些不定時炸彈還是有引爆的時候，這時候如果不是避不見面，大概就是得熬夜一陣子了。即使有這樣的問題，人們還是習慣走上捷徑，因此這樣子透過不穩定的模組產生的網站還是陸續誕生中。我們遇過幾次這樣的網站，也曾經試著將它的問題修正，但我們發現這樣子要比重新改寫還花時間，所以我們後來都選擇全部改寫。

# 高度的彈性，也是高度的混亂

Drupal 的彈性設計讓玩家們似乎找到了一個宣洩自己想法的管道，因為不需要熟悉程式設計，就能夠透過多種方式組合出自己想要的功能，很多時候這樣的組合過程複雜到他們可能自己再也想不起來，但他們還是樂此不疲。但也因為功能的組合過程複雜，許多的資訊分散於資料庫與檔案中，當這樣的功能需要修正或延伸時，往往會不得其門而入。但並不是每個人都會就這樣放棄的，我們因此看到了許多更精彩的 "暫時作法" ，其中不乏直接針對核心程式開刀的情況，即使知道這樣子未來更新會很多狀況，但專案時程就在眼前了，想辦法度過這一關再說...

# 效能

預設的 Drupal 其實效能不差，效能的瓶頸往往出現在組合了大量的功能之後，因為 Drupal 將內容抽象化重複運用，造成了大部分的延伸功能都直接往內容( node )架構進行堆疊。在傳統程式設計，因為內容是各自獨立的，所以只有邏輯複雜的內容處理起來會比較費時，但 Drupal 讓網站中只要有邏輯複雜的內容存在，就 "大家一樣慢" ，也因此消耗了大量不必要的資源。

---

其實上面的問題都可以獲得解決，只是人們往往不願意花太多時間、資源在遵守 Drupal 的準則，這時候 Drupal 提供的彈性就成了它的原罪，出現了許多誤解。我們只是一個小規模的專案開發者，不太能夠在每個混亂的局面中引導客戶走向正確的道路，所以大多選擇了最快的方式：既然這條路打結了，我們另外開一條給你走

Drupal 的功能強大還是值得玩味的，不過有意願持續陪你玩的客人不多，畢竟大家都想把錢花在刀口上，是吧？

有些問題不是 Drupal 專有的，但我們遇到比較多混亂的狀況是在 Drupal 建置的網站，因此感觸特別深吧 ;)

來源： http://blog.twpug.org/527

這篇可以搭配服用：
http://twpug.net/modules/newbb/viewtopic.php?topic_id=4020&forum=39

Drupal 和傳統的網站製作方式或是其它的CMS比較起來，本來就複雜許多。要選擇用Drupal之前，就應該好好想想爲什麽要用這個CMS，而不是另外一個CMS或是傳統的HTML的方式。

針對不同的項目，各個解決方案都各有優缺點。事後才發現錯誤，這時就應該回想一下，當初爲什麽要用Drupal? 想必是經過衡量后才做的決定。

如果只是因爲個人能力的限制或是爲了追求時代潮流而用Drupal, 卻不是真正了解它的優缺點，事後才在想: 爲什麽不用Drupal? 這做事情的方式，真的是本末倒置了 。

Drupal 真的太難學，太難用。我想說的是， 如果沒有非常充分的理由的話，建議還是不要一開始就用Drupal 比較好。選用其它比較容易的CMS，可以省事許多。畢竟，只要能達成目標最重要。手段當然選擇越簡單的越好。

有些項目我會用Drupal 的原因，都是因爲有大部分的網站功能，是Drupal較其它CMS更省時省事。如果不是這樣，我根本不會用它。大部分的網站架設，其實wordpress或是joomla等就可以做的更好，更快，更漂亮。

要客制化Drupal, 有些人會亂搞，應該也是因爲想要求快, 要不然就是因爲不懂該怎麽做。我就發現，用Drupal 做一個大型網站，比做一個幾頁HTML的公司形象網站要容易的多。這也是因爲Drupal 太著重功能性開發，而忽略了網站設計方面的簡易性。

Kiang 說出了事實。

程式必然能改變，但想改變它的人不多，DRUPAL 本身更不適合大改動，因為它有一個模式。不拿 DRUPAL 作例，就說 bootstrap twitter 好了，你若要不按模式作事，就需大費一番功夫才能完成工作。

我相信 DRUPAL 放寬模組審核過程，會有更多優良模組出現。很多模組一大堆功能集一身，根本用不著，但 BUGS 會破壞整體。

我覺得本文的對象可能需要再聚焦一點，
個人認為無法多方面兼顧 Drupal 開發的個人接案者，的確是不太適用 Drupal 的；當然啦，也不是完全不能用，只是至少就會遇到文章所提到的一兩項問題。
要能兼顧使用經驗，系統開發，以及外觀設計的團隊，才能夠真正面面俱到。

# 沒辦法直覺找到需要的功能?

Drupal 一下可以當前端，一下可以當後端，因此管理資料，大體上還是圍繞著 Entity 打轉；再加上模組化的程式，要讓設定都在一塊就要多下點功夫，或是自己重寫模組(失去模組的意義了?!)
但是若單就資料管理來說，需要 Site builder 幫助使用者順利操作網站，而不是要使用者依著 Drupal 邏輯來走。

不過 Drupal 的確從 7 的版本起就非常重視操作的直覺性，8 應該會有更大的改進，期待吧

# 要讓畫面長得跟畫出來的一樣，好難?

對傳統的網頁美工，我想當然很難。
但是已經有越來越多網頁設計師都願意嘗試看 code ，或甚至升級到前端工程的領域。
Drupal 正適合那些進一步學習了 Frame work 或前端工程的人，同時也對於 CSS 甚至是 SCSS 得心應手的人。

難嗎? 我覺得不難，但是的確比較花時間。

# 現有的資源豐富，但並不是每個模組都有成熟的發展?

這的確跟目前 Drupal 對於模組開發的態度有關，商業化程度較低，審核條件高。
缺乏商業化，的確會降低長期開發維護的意願，
不過如果是好用受歡迎的模組，自然有比較多人願意協助，成熟度也會提升，這時候嚴格的審查條件反而讓程式好維護。

開發網站的程式設計師在此就顯得重要，要懂得選用或改進模組(至少也減少了開發時間不是嗎)，
甚至要能主動回饋回去原本的模組，而這也正是社群能夠永續的原動力。

# 高度的彈性，也是高度的混亂?

高度的混亂，不是因為彈性而造成，
應該就如你說的，是便宜行事，偷懶所造成。

把這點列出來，歸咎給 Drupal 的彈性，似乎不太中肯。

# 效能

hook 是 Drupal 的一大優點，但的確就是吃效能的怪獸。
他是把兩面刃，端看你覺得 Drupal 的優點與效能兩者間如何取其輕重了。

換個角度想想，當我們覺得 1G 的 CPU 很夠力的時候，總是有遊戲為了更好的畫面，更炫的效果把資源消耗掉，
不過硬體總有一天會追上，提供足夠的運算能力的。

當然啦，這個時候就只好先想盡辦法調整伺服器，調整程式，使用快取，看看別人怎麼做(http://groups.drupal.org/high-performance)
好讓自己的 Drupal 網站效能提升。

kiang,

先別管這篇文章可以套用在Joomla、Plone等等各種CMS
發這種戰文 / 宣傳文在這裡
實在不大像你對open source社群的作風...
看到後只能說，真是可惜了

BTW，專案的情境每個都不同
我們倒是都遇到選用「暫時」作法的客戶
因為上一個廠商code完後跑掉了，電話也不接，修個東西也不報價
因而跑來找我們尋求解決方案

換言之，現下請你們代勞的客戶
3年後，是否尋求你們解決有門路呢？
還是尋求協助時處處碰壁，因而得又再換一套系統？

有時候，出問題的是廠商，卻怪起軟體來了？
客戶換網站，關鍵在廠商品質、客戶能提供的金額是否合理、以及廠商是否願意維護問題吧..

--
from open mind to open source~

戰文與否就看你要用什麼角度看了，如果這兒只希望保留正面的討論，我想我以後會盡量避免發言吧 :)

我所說的是一個現象，一些從真實使用者們反應來的意見，藉由拋磚引玉，希望能夠有更多朋友願意分享自己實際處理類似問題的經驗，而不是只就文字去產生情緒，這樣子焦點只怕會越來越模糊吧

就如同 jimmy 的簽名檔， from open mind to open source ，共勉之 ;)

沒有情緒
只是以為你的背景會讓你說起來更公允些
如果今天是其他人寫這篇文章，我可能不意外，不過寫的是你...

你說的問題都沒錯
不過關鍵情境是「有時候，出問題的是廠商，卻怪起軟體來了」
看起來你遇到的接手的案子都很慘烈？真是可惜/辛苦

認真回的話，我也會純code，用過不少Framework，使用其他軟體，都有很多問題，其中不乏你提到的點：

  • 例如說jQuery，強大的功能很開心，但遇到不斷改版的相容性就很痛苦，jQuery-ui更是一日千里包山包海，但彈性和速度和肥胖度讓人憂心
  • 例如說PEAR的DB Library，很好很方便很齊全，但囉嗦的呼叫/文件的缺乏，讓人碰到問題得直往核心找Code，肥胖也讓他效能低落
  • 例如說PEAR的quickform，把form存在session很棒，multi-step form也很不賴，但高度的彈性，讓呼叫方式很難處理，長相又得另外處理，要跟畫面一樣好難～
  • 例如ROR的軟體，每個process就吃掉近200mb記憶體...

這些Library/Framework用起來，下面你提到的點也都可以一一批評，說說這些Framework的各種問題~
結果發現，用什麼不是都一樣：

  • 現有的資源豐富，但並不是每個模組都有成熟的發展
  • 要讓畫面長得跟畫出來的一樣，好難
  • 現有的資源豐富，但並不是每個模組都有成熟的發展
  • 高度的彈性，也是高度的混亂
  • 效能問題

但即使這麼多鳥事，我也不喜歡因為自己習慣而去責難軟體，責難Framework
因為不管怎樣就是會有蟲，就是不完整，就是資源不足，就是有效能問題
Open Source Project 需要的不是厭惡，需要的是有錯誤去修正，發展自己需要的方向，並且回饋
從這篇文章，我看不出來該怎麼討論你舉出的這些各種open source都會面臨到的問題呢？

以上，如果 Drupal 很明顯不是你愛的，那何必來社群挑戰？（看來沒有尋求解答之意）
如果你長久都用Drupal，也來社群希望有建樹
那與其分享你不用的理由，不如分享你碰到的挑戰案例（但文章只有觀察記錄結論結束，沒有脈絡，沒有案例）

如何將網站移轉至Drupal，或是如何將Drupal網站移轉到別的平台，也是很難的課題
站長也可以邀請你上台講講你們碰到的困難、如何克服
若高手眾多，社群的朋友也可以針對你碰到的特定問題，提出很多討論，互相切磋

就看你的心情和對這個社群的態度了～
說實在，我從這篇文章實在看不出來你對 Drupal 用心良苦的心意呢...

--
from open mind to open source~

就只是一個心得（或者該說吐吐苦水？）發表在 "閒話家常"，要說用心良苦還真有些沈重 :)

這麼問吧，不知道有沒有前輩能夠分享一下遇到下面問題你實際上怎麼處理？

# 客戶喜歡的那個設計師，基本上不願意（或者說沒辦法）將畫面轉為純 HTML + CSS ，你能夠拿到手上的就是一堆 table 標籤，或是那種繪圖軟體預設輸出的 css 格式（命名全都是沒有意義的名稱加序號），你會如何做？我選擇了改針對畫面做程式的開發，而不是堅持繼續使用 Drupal
# 客戶自己玩著玩著組合出了幾個功能，功能的組成使用了很多個未知的模組，畫面是透過 views 生出來的，但是他想要延伸的功能已經碰到了 views 的瓶頸，希望你接手把東西搞定，你會去做嗎？我選擇了提供全新改寫的程式獨立於 Drupal 運作來解決，但可以預期下一個要接手處理的人應該會很想哭...

有脈絡就好討論了

客戶喜歡的那個設計師，基本上不願意（或者說沒辦法）將畫面轉為純 HTML + CSS

有好幾種作法
其一在前期洽談時，客戶找自己的設計師，就會先驗證清楚該設計師功力
盡量把套版的預算放在我們這裡，切圖讓設計師來就好
這樣的話，設計歸設計，前端歸前端，也通常不會出事

不然就請客戶買版型，讓他喜歡的設計師就版型去發揮，也能解決部份問題
最差就是讓設計去做前端，通常沒好結果，這種hybrid人才本來就較少

客戶自己玩著玩著組合出了幾個功能，功能的組成使用了很多個未知的模組，畫面是透過 views 生出來的

看延伸什麼情況，可能會用 views_php 模組，或 views_get_view 客製解決
後續依循的還是可藉由views的彈性做些擴展
得看延伸到什麼地步囉～

--
from open mind to open source~

我講一下我的經驗談：

# 客戶喜歡的那個設計師，基本上不願意（或者說沒辦法）將畫面轉為純 HTML + CSS ，你能夠拿到手上的就是一堆 table 標籤，或是那種繪圖軟體預設輸出的 css 格式（命名全都是沒有意義的名稱加序號），你會如何做？

通常我只會要求設計師切圖給我，我再根據設計圖去拼出結果。畢竟設計師若不明白 Drupal 的架構，給出來的 CSS 幾乎肯定是沒用的。
設計師的工作就是設計出好看的畫面，套版是前端人員的工作。一個有能力做設計又可以直接進行 Drupal 套版的人，絕對是奇貨可居。
有必要因為畫面設計而放棄 Drupal 嗎？挑選一個適合套版的版型或培養一個 drupal oriented designer ，才是王道吧。

# 客戶自己玩著玩著組合出了幾個功能，功能的組成使用了很多個未知的模組，畫面是透過 views 生出來的，但是他想要延伸的功能已經碰到了 views 的瓶頸，希望你接手把東西搞定，你會去做嗎？

打死都不能給客戶可以碰 Views 的權限啊！客戶要就不保固。
如果真的不幸接了這樣的 case，了解對方想要什麼功能，建一個全新的 Views + 你自己熟悉的模組搭配才是王道。（如果真的堅持要用那些「未知的模組」來做，熟練的、有模組品味的 Drupaler 有什麼會搞不懂的嗎？）
而若這樣的功能已經建立在多個客製模組或程式碼上頭卻要你繼續接手，fire your customer ASAP.

總之，我是建議設計、套版、功能設定和程式碼都要分工啦，不同專業的思考角度和作業效率都不同。就像你是引擎製造商不見得很會拼裝汽車，你很會拼裝能跑能動的汽車也不見得可以讓車子有漂亮造型。

為了要快速打造特殊功能或外觀，而放棄彈性大、延續性長的組裝架構，總覺得是買櫝還珠哪。

tky

我想把這些問題拉高層次來看。

客戶付錢給你是想改變某些現實來符合他的理想，重點不在於是否要使用 Drupal，而在於工程問題中永遠無法同時擁有的三個角：成本、交期、品質。
專案管理就是在試圖在其中盡量符合客戶的期望～

現在提出的這幾個問題，也是 Drupal 改版一直要改變的方向，問題是，Drupal 改變了，但你有跟的上 Drupal 的改變嗎？

突然想到這句話，很詭異: "但是經手的許多專案中，都是將 Drupal 換掉，針對需求重新改寫."

一般不懂技術的人，根本搞不清楚CMS是幹什麽的，更別説Drupal 這個名字了。他們會決定換掉Drupal， 要求重新改寫，應該也是聽別人建議, 絕不可能主動提出的.

也許大家的專案規模都比較大吧，我所接觸的專案很少有前端工程師的參與，大部分都是由後端工程師或視覺設計去分攤其中的工作；一般還是希望視覺設計能夠將畫面輸出為 html + css 格式，更理想的情況當然是順著 Drupal 的邏輯去構思畫面進行提案，但能夠把 css 搞定的視覺設計師就不多了，更別說是針對 Drupal 的邏輯了。

視覺設計與軟體工程，客戶比較容易做出決定的還是視覺設計，即使一個設計師能夠熟悉 Drupal/CSS ，畫面提案沒辦法掌握客戶的訴求基本上客戶也不會採用，這也是為什麼我們大多建議將 Drupal 換掉的原因，因為我們所熟悉的範圍並沒有侷限在 Drupal 上面，而 Drupal 一般也不是我們最具有生產力的方式，所以對 Drupal 有高度堅持的客戶一般也不會找上我們，所以經手的、跟 Drupal 有關的案子大多比較棘手，自然能夠分享的也就這些牢騷話 :)

Drupal 還是有它獨到的地方，像是多國語言的處理，不過這一般不是專案決定性的關鍵就是了

傳統的網站設計方式， 已經非常不合時代潮流，很多客戶需要對他們進行再教育，只可惜一般技術出身的人，説服別人的能力有待加強。你的問題，一部分也是因爲對drupal的掌握能力不夠 (不過，就像你說的，你們並不局限在單一的CMS上)。

我身邊很多活生生的例子，都是將網站轉換成Drupal, 沒有聽過反著來的。

法國國家鐵路局的網站, 最近也改成Drupal : http://www.sncf.com 。 我家附近的10家圖書館網絡， 官方網站不久前也改成Drupal
: http://www.bibliotheques.cergypontoise.fr 。 這個圖書館網站擁有非常強大的功能 (大部分必須登錄后才能使用)， 我至今很訝異， Drupal竟然 能夠做這麽多的事情。

我們使用的方式也沒有那樣的傳統，像是 CakePHP, ZF 等，對我們而言使用類似工具的彈性會比 Drupal 要來的多，缺點也許是沒有那樣豐富的資源吧 :)

我覺得你說的彈性應該是寫程式的彈性而非使用者調整設定的彈性。
很多習慣手刻程式碼的工程師常會拿這些來批評各種 CMS，但我覺得這是老梗了。

我常舉的例子是 Microsoft Office，它裡面的功能包山包海，但你何時聽說微軟為只買一套的客戶做客制化把功能侷限到客戶要的部分來銷售？
更不要講每代的 Office 使用介面還都不太一樣，抱怨的人一堆，但乖乖付錢的人也一堆～

你不喜歡？那自己寫一套 Office 然後跟客戶銷售看看～這比你建議客戶用 LiberOffice 還麻煩～
很多時候做案子只是要客戶滿意就可以了，不需要完全滿足客戶心中最完美的那個理想的期待。

花一百個小時來熟悉 Drupal 跟常用的 49 個模組如何？
我覺得這會比你花同樣的時間去熟悉你常用的 Framework 來的值得～

即使是老梗，也還不至於全然沒有根據就是了 ;)

舉例來說吧：
http://travel.olc.tw/

這就是手刻程式碼做出來的，不過底層使用了 CakePHP ， 也許你可以試試用 Drupal 組合出一個這樣的網站，然後跟大家分享你遇到的麻煩

當然，我們處理的專案不會只有手刻的，不妨試試用 Drupal 去實做包括 Magento, SugarCRM, Moodle 等等應用程式的功能，你會知道通用型 CMS 還是有它的侷限在

不妨看看Drupal做的相近案例，把Drupal當成data pool、特製UI的，也多有人在：
http://www.pickupamerica.org/

而純粹旅遊行程網站，不複雜的話也滿多的：
http://www.voyages-sncf.com/
http://www.yachtico.com/

Drupal 的侷限性當然是學習門檻，以及客製的進入點需要更熟悉才有辦法評估
效能的提升，需要好的server經驗，以及不少server tuning / horizontal scale的經驗
是不是缺點？困難？麻煩？

對有經驗的Drupaller來說，當然用Drupal做進入點是很省時省力的投資
相較之下，叫一個Drupaller去用CakePHP從頭開始
看有多少人會願意？缺點是一體兩面的...
（不過叫我從nodejs開始，我可能會願意...）

相較之下，travel.olc.tw 的侷限性，看來就是資源問題
人手有限，但事情永遠做不完啊！
以 Drupaller 投注同樣資源在Druapl，可能會有不同的發展

總之，以侷限性來講，對一個工程師而言，個人偏好還是佔決定性因素吧
不過，我不會特別批評其他的偏好

--
from open mind to open source~

如果能改變外圍因素 ( eg. 要求客戶改動計劃 ) 或只用 49 個常用模組做出一個網頁，是幸運者。

XYZ 用 DRUPAL 做，我並不驚訝。令人吃驚的往往是它們花費了多麼 "大" 的資金及時間精力
直接點說，有些人能做到的事，你不能做到，

假如問題能在合理時間內解決，之後還怪 DRUPAL，這一定是開發者的錯
但若不是呢 ?? 這就有機會是 DRUPAL 問題了DrupalWTF !!!
DRUPAL CORE 的進步是改善普通人不能 (不願意重覆) 做到的事
多多少少我認同上文提及的問題是存在的，但未必每一個開發者都會遇上
也多多少少, 我又相信, 有些問題在合理時間內 DRUPAL 能做到, 而你用其他程式不能

像 DANNY 舉的例子，只能說有大機構認同 DRUPAL，不能說因為機構大，網站複雜性/難度就一定上升
略瀏覽網站，我大致會將他們歸於為文章類網站，這些都是架構極簡單，連複雜的 VIEWS 都沒有的，DRUPAL 很善於做這類網站，
就是建 10個欄位, 20個欄位, 30個欄位, 1000 個欄位, 然後直接存入資料, 再直接地讀取 A, E , D ,Z, Y, W，
並不是讀出 A, E , D, Z > X, Y < E, H = K, ORDER BY Z, GROUP BY Q.... (事實這也不是複雜的，至於真正難的是什麼，你有遇過一定明白，沒遇上的怎麼看都不是大問題)

Druapl 有些獨特之處是別家沒有的, 比如說 Accessibility 兼容性，這點可能是為什麼這麼多政府及組織選用的原因

Drupal Commerce, 有用過 VERSION 1 應了解增加商品及顯示多難，
我曾問過他們主開發者為什麼增加 PRODUCT 這麼間接，當時他說一是彈性，二是 DRUPAL CORE 限制，不易改變，
直到版本 2 進步了，證明了時間能解決難題，
但經歷的時間是不是一般網站能承受的，是否你能接受 ? 我認為我不能了

值得一提的是, Commerce Kickstart 是 PATCH 了核心的安裝包，有時候有些事該做的就要做

又比如說 jQuery, 改版改版再改版，你要花費時間修復升級 PLUGIN 不長，但相反 DRUPAL 5 -> 6 -> 7 -> 8 就很難；
變的不但是 API 字眼或使用方式，而是背後整個理念，像是版型系統由 PHP TEMPLATE 變為 TWIG, 你要做的是100% 重寫
不過我又覺得要衡量多久才碰上一次必然的改變?? 五年吧 ?

**EDIT: Druapl Commerce Version 1 / 2 指的是 Kickstart 1 / 2 (BETA / RC )

老梗也可以有新意，除了口水戰之外，也許分享一些實際案例會對彼此比較有幫助

我們都知道 Drupal 的彈性創造了許多可能，但除了用別人的例子，誰願意分享以 Drupal 處理特定需求的成功案例經驗呢？還是 Drupal 既有模組做不到(或難以做到)的事情大家就不去碰？

或者有人是否可以分享面對已經一團亂的 Drupal 網站，如何去蕪存菁？我實際遇到過業主委外請歐洲開發者協助製作了幾個模組，模組勉強可以動，但並沒有開發到 "完整" 的程度，加上各種變數、函式的命名，甚至備註、文件都不是用英文或中文，接手後光是把模組處理的功能確定就花了不少時間。

是的，面對混亂的情況或複雜的需求，我們的確沒有那樣的能力以 Drupal 為基礎去解決，我們大多選擇了透過其他方式。我只是好奇，國內有多少承接專案的朋友能夠有自信處理一些 Drupal 現有模組做不到的事情？比如說把透過 views 組合出來的畫面製作為一個購物流程等等？

特定功能較少，畢竟這還是CMS，總不能叫我用Drupal做個搜尋引擎吧@@

談去蕪存菁的案例當然好，我們做過改版後砍掉特定功能的網站，from Drupal 7 to Drupal 7，並砍掉不需要的 moooooodle，請見：
http://netivism.com.tw/portfolio/idemocracy.asia

以這案例來說，我們對於自己的工具熟悉、專業分工還算完整（網站規劃、視覺設計、前端工程、後端建置、伺服系統調校）、也能對客戶做出較多的技術之外的建議。再加上客戶摸索了一年，對自己真正的需求也有較好的沈澱與凝聚（不過，其實還是需求太多XD）

像 DANNY 舉的例子，只能說有大機構認同 DRUPAL，不能說因為機構大，網站複雜性/難度就一定上升
略瀏覽網站，我大致會將他們歸於為文章類網站，這些都是架構極簡單，連複雜的 VIEWS 都沒有的，DRUPAL 很善於做這類網站，

Kay:
如果你略瀏覽的網站，就是我提到的這兩個網站，那你就錯了，它們絕不是文章類網站。

法國鐵路局網站，可以讓我們綫上訂票，買票，查詢全法國火車&跨國公車班次時間, 查詢各個站點的最新出車狀況。不過，這些還不算什麽.

圖書館網站，可以讓我查詢圖書館網絡的藏書，調閲所有圖書館的藏書&DVD，綫上看電影，綫上上電腦課程，預定書(因爲有些書別人正在看)，延長還書時間, 預定圖書館裏的電腦，預定圖書館所有的培訓活動 ....等等。 這個網站，目前還不斷地在增加新功能。我所提到的，只是一小部分而已。另一方面，

我們借書和還書，都是用機器自動操作，不須人力介入。也就是說，這個系統，還外接了其它的終端 (書籍掃描入庫登記，和外界的借換書機器連接 ... 等)。

XYZ 用 DRUPAL 做，我並不驚訝。令人吃驚的往往是它們花費了多麼 "大" 的資金及時間精力

在法國因爲工時很貴(最低幾本工資每小時將近10歐元)，一般除了很有錢的私營企業，會量身定做自己的網站外，經費有限的公家企業 (法國政府的財稅收入一直很緊張)，只能在免費的CMS 裏面選擇。他們所用的資金和時間精力，絕對比客製便宜很多。

其實免費CMS的出現，搶走了很多網站服務公司的生意，或是造成了他們的收入減少很多 (因爲客戶有了更多的選擇，就會討價還價)，因此，在法國也有這麽一票公司，專門攻擊 open source 的CMS (或是所有免費的東西，都是爛貨)。

因此。我每次遇到別人說免費的CMS怎麽差的時候，我大都會附和。畢竟這種討論，完全忽略整體成本的考量，有什麽好討論的呢!

很久以前，要穿新衣服，一定要找人定做。但是今天這些裁縫店大部分都絕跡了，只剩下幫人改衣服的小店，或是非常高檔次的裁縫店才能為客戶量身定做衣服。用CMS做網站，其實是將網站製作大衆化了，那麽傳統的網站公司要怎麽轉型，就看他們的眼光盯在短期的利潤，還是長期的發展上了。

嗯，我好像又被冠上了許多罪名 :)

法國的情況我不清楚，不過在台灣我們應該是少數公開支援開放原始碼應用的，相較於很多公司把開放原始碼應用打包成自己的產品，我們選擇的是提供開放原始碼應用的週邊支援。也就因為支援了許多開放原始碼應用的延伸專案，所以我們比較常在比較各種開放原始碼應用的差異與它適合被用在哪些地方，而不是用單一 CMS 試圖解決所有問題。

青菜蘿菠各有所好，感謝那麼多人分享了自己的經驗 :)

你提出來的五點不用Drupal的原因，可能除了第四點彈性是Drupal的特色外，其它的4個缺點，幾乎所有的CMS也都有的。所以，你應該還是用自己的方法做網站比較順手吧!

至於Drupal 的強大彈性，這原本是它最大的優點，也是Drupal最吸引人的地方。沒想到 ... 我想到一個故事:

我有一個朋友小莉，決定要嫁給老王，問她怎麽終于下了這個決定，老王的優點在哪裏? 小莉笑著說: 因爲他很老實。我喜歡老實的男人。 沒想到，婚後兩年，小莉就想要離婚了，問她原因，她說 : 老王太老實了，從來不會對我甜言蜜語。 (而我，無語)

我的亂槍掃射不小心掃到你，真的很抱歉。我其實自己也被掃到了，只是抱怨無法改變事實，只好轉個念頭，順應時勢了 (就是趕快將Drupal 學精學通了)。