为什么你不应该自行更新 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 进行升级更新、或者网站出现问题、需要服务或技术支持时，还是应该将将其交由专业人士处理。这样会节省你的时间和减少头痛，并让你可以将精力集中你的公司业务而非网站上。