這是 Drupal 分類的頁面，點擊下面标題查看詳細文章内容：
本人從2010年開始使用Drupal，比此前使用的MediaWiki更符合通用的建站要求，Drupal對多語言、多站點的支持也是我選擇它的重要因素。從最開始的6.x到7.x再到8.x，我一直都在使用，在這過程中需要修改模闆、自建模塊，也學會了PHP以及其它一些技術。在本博客中我也記錄了很多日常使用Drupal中遇到的問題、解決的辦法，希望對其他使用Drupal的朋友有所幫助。
昨天開始準備進行Drupal的升級工作，當天就查看了大量資料，下載了最新的版本，将幾個沒有實際内容的網站進行了升級，有從6.20升級到6.24的，也有一步從6.20升級到7.12的，還有分步從6.20升級到6.24再到7.12的，因為很少涉及第三方模塊，内容也極簡單，所以算是比較順利，也積累了一點經驗，增強了升級其他正在投入使用網站的信心。
今天首先就拿我的這個個人網站開刀，上午先把6.20下的各種第三方模塊升級到最新版本，然後再将核心升級到6.24，還算是比較順利，網站的外觀、功能都變化不大，極少報錯提示。
不過再升級到7.12就不是很順利了
2010年底我開始嘗試使用Drupal來建站，替代已經使用過多年的MediaWiki，當時Drupal的最新版本是6.19，在不久後的2011年初推出了Drupal 7的正式版本，但因為很多第三方模塊都還沒有與Drupal 7配套的，所以我也一直沒有用Drupal 7，為了省事就一直用的Drupal 6，隻是中途用一個簡單的複制文件的辦法"Drupal 6.x Upgrade - Files Only"來升級到6.20。
此後Drupal 6又陸續推出了6.21, 6.22, 6.23, 6.24，但都無法使用前面的直接複制文件的辦法來更新，所以我也一直拖着沒有再升級
Drupal系統的Views插件确實有着非常強大的功能，能實現各種數據庫查詢工作而又不用編寫程序代碼，所以我們在建站過程中也在不少地方用到Views。
用Views生成頁面的時候，涉及到頁面的Tilte，有多種情況記錄如下：
服務器上的sendmail等設置一直不太順，以前用MediaWiki的時候就是留言表單中的内容有時可以發送，有時出現錯誤丢失的情況。改用Drupal建站後，contact表單也是用的sendmail來發送，也是時好時壞，有我們自己設置的問題，也有被外部判為垃圾郵件的問題，需要我們修改設置、提交解封。
前兩天偶爾查看服務器上的root中的郵件，發現前一陣子丢失了很多留言郵件，其中一些提示被godaddy的郵件服務器盼為垃圾郵件了，就去提交解封了。
今天讓同事安裝了一個webmin來查看，找回了不少需要處理的郵件。
前些天在Drupal網站中為了設法解決服務器性能的問題，實驗了将MySQL中的一些表合并，雖然最後證實這個效果不明顯，但花了好些時間就還是把代碼記錄下來，以備後用。
過程步驟：
今年4、5月份在用Drupal搭建英文版中國郵編網站China Postal Code的過程中，為了讓浏覽者更方便、更習慣，采用了CCK字段+Views展示的擴展模塊，并進行一系列的比較複雜的設置，例如多個computed計算字段、Views查詢中嵌套多級查詢，算是基本上能實現所希望的功能。
但當時就發現在性能上有很多的問題，通過Devel模塊的開啟，可以查看到一些Views查詢數據庫所用的時間非常長，需要幾十甚至幾百秒，常常令服務器負載過高而影響網站訪問。後來找了一個自動檢測MySQL進程的小腳本，當發現超過限定值的進程時就自動kill掉，這個辦法确
用Drupal等CMS系統來搭建網站的主要好處就是不用太關心程序、數據庫等技術細節，把精力主要集中在網站内容本身。不過有些時候也不得不去關注這些技術問題，例如：無法用普通辦法實現的功能、遇到速度性能瓶頸等。
以前在用Drupal搭建網站的時候，就注意到添加新的内容類型(Content Type)後，用CCK設置的字段一般是放在同一個數據庫表中的，例如一個内容類型“名錄”就有一個表“minglu”，而compan, address, postcode這些字段就都在minglu這個表中，後來在一個網站中添加多
前段時間一直發現一個問題，就是我們Drupal網站的首頁沒有Boost Cache生成的文件緩存，而有一部分老的網站中首頁卻是緩存的，這個問題困擾了好長時間，找了好久都沒有找到具體原因。
今天在修改老的網站設置中，看到“站點信息 (Site information)”中的“默認首頁 (Default front page)”設置的是“頁面/首頁”，而我記得後來的網站中都是設置的“node/123456”這樣的Node ID，我換着修改了設置，果然問題就出在這
在一般的Drupal網站中，都是通過設置Cron定期運行來對Boost Cache、XML Sitemap進行更新，但我們在大數據量的Drupal網站中覺得需要進行一些改進。
首先來說Boost Cache，對于數十萬甚至上百萬的數據量，如果都進行靜态頁面緩存的話，占用硬盤過大，小文件太多，可能效率還不如不要靜态頁面緩存，這樣的時候我們一般關閉了詳細内容頁面的靜态緩存，隻對分類頁(Taxonomy Terms)、索引頁(Views)進行緩存，就是這樣，靜态緩存的文件數也有數萬個以上。這時如果通過Cron來定期讓靜态緩存失效的話，可能會出現删除時間過長而
上周同事開始在多個子網站更改各項設置，特别是添加多個Views後，服務器負載持續攀升，也影響到服務器上的沒有更改的網站，特别是幾個數據量達到數十萬、上百萬的網站，已經連續出現首頁報錯的情況了。
http://tx.bizdirlib.com/ 的首頁主要由兩部分組成：城市列表和行業列表，首頁報錯的時候，上半部分的城市列表還是可以正常顯示的，隻是下半部分的行業列表無法顯示，錯誤提示信息也是與sic行業代碼的查詢有關。
檢查兩個Views，城市列表的Views很簡單，而行業列表的Views中采用了Relationships，以便查
2002-2023 v11.7 a-j-e-0
