這不只是一篇嘈唸的抱怨文。
這裡許多使用Drupal實際的狀況你可能遇過，或者也可能目前還倖存，但早晚都會遇到──對於一些入門的Drupal使用者，或還還未入門的，此文可讓你做為是否要繼續鑽研Drupal的參考，有些地方也為你提供了簡單的問題解決方法。
目前我使用Drupal已經有將近一年的經驗，從Drupal 6.17版開始使用，一直到現在的Drupal 7.2。期間遇到的狗屁倒灶事真的挺多的，原本想一件件寫出專文，但因過於忙碌而一一作罷。
拖到現在，也只能以回想的方式一口氣把所有想得到的都一一提出，而當時的解決方法，我也只能點一個方向，讓初學者自己去找具體與完整的答案。由於是回想文，所以文章不但雜亂無章，而且也只能「舉其大者」──那些較小的，就只能看是否還有機緣再遇到時能拿出來談了[不過我實在很希望別在遇到]。
虛擬主機代管的支援－真的很傷腦筋
可能是Drupal一些程式撰寫方式以及這套系統較龐大而複雜的關係，相較於其他CMS，虛擬主機代管業者對Drupal的支援相較之下實在很差──特別是若與WordPress相比的話。
如果你要架的是WordPress，而你找到一家ISP對於WordPress支援很差，那你大可以跟他丟雞蛋說：那你還跟人家開什麼ISP，關門算了。但如果他對Drupal支援很差，差到讓你架不起來，那也只是剛剛好而已，你最好摸摸鼻子走人，慢慢仔細找，還是可以找家支援不錯的。
這意謂著當你決定要用Drupal架站之後，可能遇到很多ISP業者的伺服器支援問題而讓你做不下去──甚至連架都架不起來。
具體及實務來說，經常會是.htacess及 php.ini設定問題，這些對於初學者來說不只是相當可怕而完全不知從何下手──有時候甚至因為虛擬主機業者的系統限制，就算你是大內高手恐怕也無法解決問題－－有些ISP會選擇由他們內部人員幫你另外解決，而不讓客戶自己去動這些相關設定。
以我所經歷過的幾家ISP來說，像目前所採用的iXwebhosting，其後台管理的自動安裝，獨缺Drupal，你問他們客服，客服會跟你說還是可以裝──可是呢，安裝時卻老是要他們幫忙。
↓ 這是IxWeb的EasyApps Colletion，獨漏Drupal，雖然安裝Druapl還是可以的，但我的經驗是，安裝時要跟他們的客服人員來段LiveChat請他們幫你解決.htacess及php.ini檔的問題，否則要裝上去恐怕有得拼
我的情況是：每次安裝時，一定會遇到register_globals及Multibyte string這兩個設定問題，然後就安裝不下去了。
雖然爬文之後知道問題在那，也有高手提供的.htacess及php.ini檔可用，但就是不管用。
最後都還是得透過Live chat找上他們的技術人員手動幫忙更換他們所特別撰寫的這兩個檔才能順利安裝。甚至我後來在裝新站時，也曾試著繞過他們客服，把他們先前提供的檔案拿來自己套用看看，就是不管用。
這種每次都要找客房幫忙的感覺，實在不好受。但iXweb還是有幫你解決，而且一定會幫你解決的──這算運氣不錯的。
先前我找到台灣一家叫遠振的，原本考慮採用他們的代管，所以先申請試用看看。但在一開始要試用時就遇到挫折。
在安裝Drupal時一樣遇到register_globals及Multibyte string設定問題攪不定，以MSN請他們客服幫忙，客服竟然一問三不知，總之最後也沒解決〔或許也有自助的解決方法我不知道，所以保守說：是我的功力還沒辦法在他們系統上安裝起Drupal，這算是我學藝不精的問題，不是ISP問題〕。
不過這家公司好像有提供一次免費安裝服務的樣子，所以這方面倒也不用太擔心，只是如果你和我一樣是屬邊架站邊練功夫的人，那麼就會經常重安裝網站──第二次以後就得付費了，而且問題不能自己解決就是很不爽。
另一家我用過的國外代管業者則是iPage。
這家對Drupal的支援是有的，後台的軟體安裝也有支援Druapl，按一按下一步不用一分鐘就完成架站了。
可是他們的伺服器似乎不相容於中文系統。只要把Drupal的clean URL（乾淨網址）功能打開，你網站就不能用：就是在乾淨網址之下，只要出現中文，網站就會出現500號錯誤訊息（HTTP Error 500 Internal server error）－－甚至連在上稿時某些欄位裡出現中文也會讓網站當掉──嚴格來說它們對於Drupal的支援是不錯的，只是伺服器對於中文卻是不相容，如果你不在意網址乾不乾淨，那還好。
這家代管業者因為系統很不穩定，三不五時就當機，連網速度又超級慢，所以在半年前我就跟他說881了。
目前我在使用的，而且應該還會繼續使用下去的則是台中一家叫「威普」的，他們對Drupal的支援非常好。後台Cpanel裡也有Installatron可以直接安裝，這是我相當推薦的一家。
使用他們的虛擬主機台灣機房方案半年多，系統相當穩定與快速，雖然沒有Live Chat等技術支援，但對於客戶的問題反應都相當快，電話打過去一定幫你解決，從來不會推拖說那是Application問題還是伺服器問題──而對Drupal的支援，我從國外用到國內，也還沒遇到更好的〔國內我用過iPage、iXweb，國內還用過智邦，智邦我在安裝Joomla時一樣有遇過register_globals及Multibyte string，所以我推論裝Drupal應該很可能也會遇到〕。
↓ 威普的虛擬主機伺服器環境不但對於Drupal相當友善，Installatron更讓你的安裝快速而無煩惱
總之，如果你決定要採用Drupal，而目前你所要用的是虛擬主機代管的方案，那麼，在代管業者的選擇上會更加的嚴格與龜毛，這一點是初學者一定要非常注意的──沒試用過確定它對於Drupal支援很好之前，不要輕易做出選擇。
而若要我推薦虛擬主機〔只是虛擬主機而已〕，我會建議選擇威普的。若要省錢，則可選擇他們的美國機房〔不過我用的是台灣機房，不確定美國機房是不是一樣的考靠穩定〕。
幽靈白螢幕
這是我在初學Drupal時遇到的。
如果你是初學者，還沒遇到這種事，那麼算你運氣──特別是Drupal 6。
通常這是發生在啟用新的模組之後，由於PHP記憶體分配不足，所以整個網站只剩下白茫茫的一片，什麼都沒有：你也無法進入主控台。就是整個網站都白爛給你看。
現在談的很輕鬆，但在事發時是完全不知花生什麼素，歷經好幾天的尋找答案，以及幾波的問題解決之後，後來也才知如何預防與應變。
這個問題在Drupal 6時代特別常見，主要是更新完一些Image Cache等耗PHP記憶體的模組之後──至於Drupal 7會不會發生？雖然我沒遇過，不過我想理論上是會的，我沒遇過是因為玩到Drupal 7時我都已經知道在一開始架站就要把PHP記憶體設定好，以免網站白爛那就麻煩了。
另一個Drupal 7較不會發生此事的原因是，Drupal 7已整合了Image Cache等這些耗記憶體的超級元凶，所以在安裝時就會在PHP記憶體需求上有較高的要求。
當遇到這種幽靈白螢幕時，唯一的解決方法，就是要能夠去設定.htacess及php.ini檔裡的PHP記憶體。
通常來說，要設到大約是64MB以上才比較保險夠用。但實務上到底究竟要設定多少？真的是見仁見智，先前爬文也有很多人討論這個問題，有人說是96MB，有人說是128MB………
由於設定.htacess及php.ini對於初學者來說是個很麻煩甚至無從下手的工程。如果你是Drupal 6使用者，那麼要介紹一個叫Drupal Tweak的模組給你。
http://drupal.org/project/drupal_tweaks
這模組可以讓你直接在Drupal 上設定PHP記憶體限制，真的很好用。只不過這模組用的人不多，開發維護者也似乎不是很積極。且在Drupal 7上也沒得用。
Wysiwyg無法使用
從使用Drupal以來，在文字編輯器上就一直是一場惡夢──昨晚我也才歷經過一場震撼教育。
Drupal的Wyswyg所見即所得的編輯器整合真的非常糟糕，除了設定及安裝相當麻煩之外──如果你是初學或入門使用者，而且還沒遇到過安裝好卻無法使用的狀況，真的算你運氣。
Drupal的Wysigyg對瀏覽器很挑，目前我還是常遇到瀏覽器不相容問題，最常見的就是IE完全不能使用，或者是用起來很不順暢。
Drupal 6遇到的是，若沒啟用Javascrript及CSS壓縮功能，那麼編輯器可能無法使用。
我另外還遇到的狀況是，如果把TinyMCE編輯器的語系設為中文，那麼編輯器就死在那裡。若設為英文語系就OK沒事。到現在，Drupal 7仍有這個問題。所以我已經習慣把wysiwyg裡的介面語言設為英語──不過介面還是中文的〔實在有點豬頭的設計，感覺那介面語言的選項設計根本就是來亂的！〕
另外，我在Drupal 7則常遇到相反的問題：因為壓縮或快取而讓編輯器無法使用的問題。
之前我遇到過幾次突然編輯器無法使用──部份原因雖是我所張貼的內容非常龐大，但元凶好像是瀏覽器快取或暫存檔問題──其實我不是很確定。
總之，我清了幾次瀏覽器的快取及暫存檔案，以及電腦再重開之後，也不知怎樣，就終於解決了。
而昨夜我遇到的情況，也是類似的問題。除了版型走樣之外，編輯器完全當機，也就是我完全不能更新任何內容。
後來抓了一整夜的蟲，才知原來也是網頁的CSS壓縮所造成。關閉了該功能之後才解決。不過，由於開啟CSS壓縮功能可以提高網站效能，所以我還在找可以正常把該功能開啟的方法──晚上可能試試把該壓縮檔案資料夾內的東西清空看看。
↓ 如果你的Drupal 7有開啟CSS壓縮功能（此功能能讓網站效能更好），網站運轉個幾個月之後，可能會出現網站CSS大亂，還有編輯器塴潰無法使用的情況〔內行人應該一看就知道編輯器不該長這樣的〕
模組更新Drupal的模組更新也是個相當繁雜的工作，如果你幾個月沒看後台狀態報告，登入之後滿江紅紅的情況可能會嚇死你。
在Drupal 6，你要下載新模組之後，解壓縮（以前還要解兩次）然後FTP上傳，然後執行update.php。
就這樣一個個操作。
雖然Drupal 7在這方面有所改善，但你心臟可能也要很大。
Drupal 7可以直接在後台的狀態報告勾選要更新的模組，然後直接在管理後台開始更新。
但前陣子在更新Location模組時差點讓我網站消失不見了：所以後來在用此法時，都怕怕的，不然就是得先去備份資料庫〔那又把事情弄得比Drupal 6時代還要麻煩了〕。
我的情況是這樣的：
從後台自動更新Location模組過程當中，遇到了問題，現在只隱約記得好像是與資料庫那一個資料表的關聯出了問題。
然後，因為網站自動更新過程中，會將網站改為維護狀態，所以我的網站因此就被迫關閉──直到我解決以上更新問題之後。
幸運的是，進入後台沒問題：只是看到是資料庫的問題，心都涼了一半了！
用錯誤訊息上網找了半天都找不到答案。後來就用了最笨的方法。把Location模組關閉。解除安裝，再透過FTP把它殺了。
然後再重新安裝，就這樣反覆了兩三次，也不知怎麼弄的，就好了。
而如果是Drupal 6.17升級到Drupal 6.2，或是Drupal 7升級到Drupal 7.2這種核心程式更新，就更麻煩了。前陣子我某個網站有升級失敗經驗，只好重新以備份救回網站，再重新更新一次。
模組瑕疵怎麼辦？由於Drupal模組開發模式與其他CMS很不同──他是以集中式控管。所以當模組有瑕疵時，就會讓你欲生欲死。
在其他CMS，同樣一種功能，此模組不行，你可能還有另一模組可選。但在Drupal，理論上，而且通常是，一種功能你就是一種模組可選。Drupal的集中式控管，通常不會為同一功能，再開出完全重覆的第二個專案。〔雖然也有些特例，但這是最常見的情況。〕
所以當你遇到模組瑕疵時，就要靠運氣了：運氣最好時，很多人和你一樣遇到且回報了，然後該模組的維護者很積極，馬上修補好，然後釋出更新，事情皆大歡喜。
運氣稍差些，但也還算不錯的情況是：有技術高超的好心人士幫忙找出問題了，但他不是模組的維護者，所以他只能教你如何把模組的檔案拿出來修改修改。有時候，一些修改，你不懂PHP程式真的完全沒辦法下手。有些則是不懂PHP也可以依樣畫葫蘆解決。
運氣最不好呢？就是問題都沒人管，而你也沒能力修改。如果該模組你可以捨棄使用還好，若它是一個你網站的核心功能，那麼你只能堪用就用，不堪用的話就是在那裡等死了。
以上這些狀況我不知遇到過多少次。這裡可以舉一些實際還記得的。
像是先前我介紹的Lightbox 2功能，就是還可自己簡單修改程式碼的。文章中也有一段是教大家如何修改程式碼。
而Gmap最早也遇到大問題──文章摘要無法在地圖上顯示（會使用gmap的人不就都是衝著這功能來的！）只是很幸運的，遇到問題隔周就有新模組釋出修補好了。
另外這個例子可能與模組不相關，但問題也類似，就是網站的e-mail系統在某些ISP那裡無法使用，無法寄帳戶開通信給會員，所以還得去修改include檔案夾裡的Mail.inc。
…………
所以呢，這一年來，我經常三不五時就恨不得發願買一本PHP的書回來開始學PHP。
而這些問題，並沒有因為Drupal 7的推出而更為改善，反而是更為嚴重！
至於升級到Drupal 7之後的狗屁倒灶事請看下回分曉．．．．
幽靈白螢幕
這是我在初學Drupal時遇到的。
如果你是初學者，還沒遇到這種事，那麼算你運氣──特別是Drupal 6。
通常這是發生在啟用新的模組之後，由於PHP記憶體分配不足，所以整個網站只剩下白茫茫的一片，什麼都沒有：你也無法進入主控台。就是整個網站都白爛給你看。
現在談的很輕鬆，但在事發時是完全不知花生什麼素，歷經好幾天的尋找答案，以及幾波的問題解決之後，後來也才知如何預防與應變。
這個問題在Drupal 6時代特別常見，主要是更新完一些Image Cache等耗PHP記憶體的模組之後──至於Drupal 7會不會發生？雖然我沒遇過，不過我想理論上是會的，我沒遇過是因為玩到Drupal 7時我都已經知道在一開始架站就要把PHP記憶體設定好，以免網站白爛那就麻煩了。
另一個Drupal 7較不會發生此事的原因是，Drupal 7已整合了Image Cache等這些耗記憶體的超級元凶，所以在安裝時就會在PHP記憶體需求上有較高的要求。
當遇到這種幽靈白螢幕時，唯一的解決方法，就是要能夠去設定.htacess及php.ini檔裡的PHP記憶體。
通常來說，要設到大約是64MB以上才比較保險夠用。但實務上到底究竟要設定多少？真的是見仁見智，先前爬文也有很多人討論這個問題，有人說是96MB，有人說是128MB………
由於設定.htacess及php.ini對於初學者來說是個很麻煩甚至無從下手的工程。如果你是Drupal 6使用者，那麼要介紹一個叫Drupal Tweak的模組給你。
http://drupal.org/project/drupal_tweaks
這模組可以讓你直接在Drupal 上設定PHP記憶體限制，真的很好用。只不過這模組用的人不多，開發維護者也似乎不是很積極。且在Drupal 7上也沒得用。
Wysiwyg無法使用
從使用Drupal以來，在文字編輯器上就一直是一場惡夢──昨晚我也才歷經過一場震撼教育。
Drupal的Wyswyg所見即所得的編輯器整合真的非常糟糕，除了設定及安裝相當麻煩之外──如果你是初學或入門使用者，而且還沒遇到過安裝好卻無法使用的狀況，真的算你運氣。
Drupal的Wysigyg對瀏覽器很挑，目前我還是常遇到瀏覽器不相容問題，最常見的就是IE完全不能使用，或者是用起來很不順暢。
Drupal 6遇到的是，若沒啟用Javascrript及CSS壓縮功能，那麼編輯器可能無法使用。
我另外還遇到的狀況是，如果把TinyMCE編輯器的語系設為中文，那麼編輯器就死在那裡。若設為英文語系就OK沒事。到現在，Drupal 7仍有這個問題。所以我已經習慣把wysiwyg裡的介面語言設為英語──不過介面還是中文的〔實在有點豬頭的設計，感覺那介面語言的選項設計根本就是來亂的！〕
另外，我在Drupal 7則常遇到相反的問題：因為壓縮或快取而讓編輯器無法使用的問題。
之前我遇到過幾次突然編輯器無法使用──部份原因雖是我所張貼的內容非常龐大，但元凶好像是瀏覽器快取或暫存檔問題──其實我不是很確定。
總之，我清了幾次瀏覽器的快取及暫存檔案，以及電腦再重開之後，也不知怎樣，就終於解決了。
而昨夜我遇到的情況，也是類似的問題。除了版型走樣之外，編輯器完全當機，也就是我完全不能更新任何內容。
後來抓了一整夜的蟲，才知原來也是網頁的CSS壓縮所造成。關閉了該功能之後才解決。不過，由於開啟CSS壓縮功能可以提高網站效能，所以我還在找可以正常把該功能開啟的方法──晚上可能試試把該壓縮檔案資料夾內的東西清空看看。
↓ 如果你的Drupal 7有開啟CSS壓縮功能（此功能能讓網站效能更好），網站運轉個幾個月之後，可能會出現網站CSS大亂，還有編輯器塴潰無法使用的情況〔內行人應該一看就知道編輯器不該長這樣的〕
模組更新Drupal的模組更新也是個相當繁雜的工作，如果你幾個月沒看後台狀態報告，登入之後滿江紅紅的情況可能會嚇死你。
在Drupal 6，你要下載新模組之後，解壓縮（以前還要解兩次）然後FTP上傳，然後執行update.php。
就這樣一個個操作。
雖然Drupal 7在這方面有所改善，但你心臟可能也要很大。
Drupal 7可以直接在後台的狀態報告勾選要更新的模組，然後直接在管理後台開始更新。
但前陣子在更新Location模組時差點讓我網站消失不見了：所以後來在用此法時，都怕怕的，不然就是得先去備份資料庫〔那又把事情弄得比Drupal 6時代還要麻煩了〕。
我的情況是這樣的：
從後台自動更新Location模組過程當中，遇到了問題，現在只隱約記得好像是與資料庫那一個資料表的關聯出了問題。
然後，因為網站自動更新過程中，會將網站改為維護狀態，所以我的網站因此就被迫關閉──直到我解決以上更新問題之後。
幸運的是，進入後台沒問題：只是看到是資料庫的問題，心都涼了一半了！
用錯誤訊息上網找了半天都找不到答案。後來就用了最笨的方法。把Location模組關閉。解除安裝，再透過FTP把它殺了。
然後再重新安裝，就這樣反覆了兩三次，也不知怎麼弄的，就好了。
而如果是Drupal 6.17升級到Drupal 6.2，或是Drupal 7升級到Drupal 7.2這種核心程式更新，就更麻煩了。前陣子我某個網站有升級失敗經驗，只好重新以備份救回網站，再重新更新一次。
模組瑕疵怎麼辦？由於Drupal模組開發模式與其他CMS很不同──他是以集中式控管。所以當模組有瑕疵時，就會讓你欲生欲死。
在其他CMS，同樣一種功能，此模組不行，你可能還有另一模組可選。但在Drupal，理論上，而且通常是，一種功能你就是一種模組可選。Drupal的集中式控管，通常不會為同一功能，再開出完全重覆的第二個專案。〔雖然也有些特例，但這是最常見的情況。〕
所以當你遇到模組瑕疵時，就要靠運氣了：運氣最好時，很多人和你一樣遇到且回報了，然後該模組的維護者很積極，馬上修補好，然後釋出更新，事情皆大歡喜。
運氣稍差些，但也還算不錯的情況是：有技術高超的好心人士幫忙找出問題了，但他不是模組的維護者，所以他只能教你如何把模組的檔案拿出來修改修改。有時候，一些修改，你不懂PHP程式真的完全沒辦法下手。有些則是不懂PHP也可以依樣畫葫蘆解決。
運氣最不好呢？就是問題都沒人管，而你也沒能力修改。如果該模組你可以捨棄使用還好，若它是一個你網站的核心功能，那麼你只能堪用就用，不堪用的話就是在那裡等死了。
以上這些狀況我不知遇到過多少次。這裡可以舉一些實際還記得的。
像是先前我介紹的Lightbox 2功能，就是還可自己簡單修改程式碼的。文章中也有一段是教大家如何修改程式碼。
而Gmap最早也遇到大問題──文章摘要無法在地圖上顯示（會使用gmap的人不就都是衝著這功能來的！）只是很幸運的，遇到問題隔周就有新模組釋出修補好了。
另外這個例子可能與模組不相關，但問題也類似，就是網站的e-mail系統在某些ISP那裡無法使用，無法寄帳戶開通信給會員，所以還得去修改include檔案夾裡的Mail.inc。
…………
所以呢，這一年來，我經常三不五時就恨不得發願買一本PHP的書回來開始學PHP。
而這些問題，並沒有因為Drupal 7的推出而更為改善，反而是更為嚴重！
至於升級到Drupal 7之後的狗屁倒灶事請看下回分曉．．．．
沒有留言:
張貼留言