爲何你不該該自行更新 Drupal 網站?

　　（譯註：這篇文章主要仍是針對於非專業人員及我的Drupal站長，對於專業的 Drupal 團隊和公司而言 Drupal 的升級更新都有規範的操做流程，徹底是屢見不鮮，不可能出現文中出現的這些狀況。儘管如此，裏面也仍是有一些內容值得你們瞭解。）

　　有時我但願Drupal的升級和維護可以像Wordpress那樣簡單就行了，輕輕一點，Wordpress就可以在不影響其運行的狀況下完成自身以及全部插件的更新。Drupal則徹底不同，稍有不慎你就會把你的網站搞癱。

　　Drupal 之因此這麼難搞是由於它的不少模塊都須要依賴於其它模塊才能夠正常運行，這正是它得以模塊化、靈活以及便於集成的優勢，但這同時也是一件壞事，由於你必須對全部這些關係有所瞭解，才能在升級出現問題時進行排查。

　　許多 Drupal 站點的管理者，並不瞭解蘊藏在 Drupal 表面之下的事物是怎樣結合和運做的。因此當他們看到「你有可用的安全更新」時，便以爲有必要試試進行更新——「嘿，我能夠更新Windows，更新一下Drupal能有多難？」——若是你不是Drupal工程師、建站人員或者任何瞭解站點構造的人，建議你仍是尋求專業人事的幫助和支持。

 

使用Drupal內置更新功能進行更新?

　　使用Drupal內置的更新機制進行更新是咱們所知道的最多見錯誤。儘管表面上它看起來即簡單又好用，但問題是若是一旦出錯，你便沒法回頭了——Drupal崩潰後你便再也不可以進入網站進行操做，即便有備份，也不能經過 Backup & Migrate 模塊進行恢復。

致使Drupal崩潰或失敗的常見緣由有如下一些：

• 下載內核或模塊更新出錯

• 網絡鏈接斷開中斷更新進程

• 更新版本與其它模塊不兼容

• 更新版本與服務器上其它組件不兼容，如當前使用PHP版本

• FTP出錯

• 文件系統出錯（如權限出錯）

　　不少用戶都是線上的網站直接進行操做，這樣作最壞的狀況是網站出錯而不能用了，你的用戶和客戶會所以流失。若是網站下線時間過長，也能夠同 Google 和百度說拜拜了。

 

使用FTP對Drupal進行更新?

　　若是你比較精明，使用 FTP 對 Drupal 進行更新或升級，相對而言會安全不少，但也不是絕對安全。若是你對Drupal的目錄結構不夠了解，則極可能將文件上傳到錯誤的目錄、覆蓋錯誤的文件，或者漏掉 .htaccess 這樣的隱藏文件。

　　曾經有一次，一個客戶將同一個模塊上傳到3個不一樣的目錄並疑惑網站爲何運行得那麼慢。他並不知道，Drupal嘗試3次加載那個模塊並致使內存泄漏。因此最好知道東西應該放在哪裏，不然極可能會出問題。

　　使用FTP進行更新的另外一個問題是，你依然是將更新模塊上傳到你的線上站點，不管是模塊或PHP不兼容，均可能致使出錯而讓站點下線。除非你從新恢復以前的文件或者找到問題的解決辦法。（譯註：若是升級以後還運行了數據庫更新，恢復文件可能也不能解決問題）

 

應該怎樣正確地進行升級？

　　首先，永遠永遠永遠不要在線上站點直接進行內核或模塊升級，永遠不要。專業的Drupal團隊會使用模擬服務器（或稱開發服務器、測試服務器）對你的網站更新進行測試和調試，從而確認是否全部的更新都是無害且不會致使網站損壞。這樣，能夠在不影響線上網站正常運行的狀況下對問題、錯誤進行處理和修復，儘可能保證用戶、客戶、Google和百度不會由於網站升級出錯而離你而去了。

　　同時，使用 Git 對全部更新進行版本控制，以便確保當升級出現問題時，能夠更方便地查找問題和進行恢復。

　　一旦全部更新都確認OK，即可以放心的將它們上傳到線上服務器。更新時使用 Rsync 或 Git，儘可能不要使用FTP，前者會更快速、更智能。

 

寫在最後

　　當Drupal更新發布後，應該至少在一個月內進行更新，若是更新涉及安全問題，則更新週期還應該更短。（譯註：若是是安全更新，應該儘快進行。若是非安全更新，沒必要操之過急）

　　雖然極可能平時 Drupal 網站的平常維護都是由大家本身負責，但須要對 Drupal 進行升級更新、或者網站出現問題、須要服務或技術支持時，仍是應該將將其交由專業人士處理。這樣會節省你的時間和減小頭痛，並讓你能夠將精力集中你的公司業務而非網站上。