這是 Drupal 分類的頁面，點擊下面标題查看詳細文章内容：
本人從2010年開始使用Drupal，比此前使用的MediaWiki更符合通用的建站要求，Drupal對多語言、多站點的支持也是我選擇它的重要因素。從最開始的6.x到7.x再到8.x，我一直都在使用，在這過程中需要修改模闆、自建模塊，也學會了PHP以及其它一些技術。在本博客中我也記錄了很多日常使用Drupal中遇到的問題、解決的辦法，希望對其他使用Drupal的朋友有所幫助。
去年我們将EmojiAll網站接入了CloudFlare，這個網站是用Drupal來搭建的，也遇到一些清除緩存等小問題，都是同事們逐步發現、逐步解決。最近陸續接入了其它一些域名，我也多花了一些時間來了解，下面記錄一些要點。
先去網上搜了相關關鍵詞，發現Drupal有一個專門的CloudFlare模塊，其主要功能是：
我們EmojiAll.com這個網站算是做得很精細、邏輯有些複雜，各種數據庫調用很多，不過因為數據庫服務器采用阿裡雲RDS、負載不算很高，所以速度上還是可以的，前期主要注重功能，沒有太注意性能優化。
最近因為ECS服務器搬家，發現新服務器的内網帶寬比以前增加很多倍，然後打開Drupal的Devel模塊查看數據庫調用情況，發現sql語句非常多，一個典型頁面調用sql語句達到800條之多，内容很多的頁面sql語句超過4000條，雖說都還是可以在幾秒内打開，但對于有優化強迫症的人來說，顯然是無法忍受的。😖
以前其實想過要通過Memcache這種鍵值對緩存
Drupal搜索結果頁面中會出現一個搜索表單，與置頂的表單有重複的不好之處，另外，我也想在AMP頁面等特殊情況下去掉搜索結果頁中的表單。
以前好些在網上搜過有修改CSS的辦法來隐藏表單的顯示，今天又找到Drupal的hook_form_alter這個API調用辦法，測試有效，記錄如下：
function my_module_name_form_alter(&$form, &$form_state, $form_id) {
// We have to be careful to alter only the contact
Drupal中以前都是用node方式來呈現數據，content type設置好字段後，有現成的辦法來實現内容呈現和編輯。但後來比較多用到自建的數據表，呈現一般還是用Views來實現，也可以用SQL語句來實現，而修改數據表中内容最開始用阿裡雲RDS後台，後來改用自己寫的form展示和輸入修改提交。
昨天同事又說到另外一個類似的需求，我花了幾個小時來做，這次幹脆把以前呈現表單、提交結果兩個頁面合并為一個頁面，通過判斷這個頁面的$_GET和$_POST參數來做适當的操作，在Drupal的自定義模塊中的PHP程序代碼如下：
/** *
昨天同事說在查看Drupal官方網站的時候，發現挂出了因為COVID-19病毒🦠引起财務方面危機的消息：
我是從2010年開始使用Drupal的，這麼多年來還從來沒有見到Drupal官方向外求救的情況，于是上他們網站看了，可以捐款或者成為會員來支持，我選擇了會員方式，用PayPal繳納了50歐元。
今年總是接到來自Google Search Console這樣的提醒郵件：
在 https://example.com/ 上檢測到了 路徑 問題 緻：https://example.com/ 的所有者 Search Console 發現，您的網站受到了3 個 路徑 問題的影響： 出現次數最多的錯誤 錯誤可能會導緻您的網頁或功能無法顯示在Google 搜索結果中。我們在您的網站中發現了以下錯誤： 未填寫字段“position” 應指定“name”或“item.name”
我們2010年開始使用Drupal時，内容都是放在node裡面的，到2016年才開始在部分網站中使用直接建表的方式，當時的記錄《在Drupal中直接導入、使用數據庫》，後面從IP數據、2017年底的國語辭典系列等内容就使用了這種方式，再從2018年進行了《大數據量Drupal網站改造數據結構》，效果也是不錯的，所以新内容我們基本都是采取的這種方式。
但
Drupal的報錯日志裡面常常堆滿了這樣的報錯：
page not found 11/17/2019 - 11:26 apple-touch-icon.png 匿名使用者 (未驗證) page not found 11/17/2019 - 11:26 apple-touch-icon-precomposed.png 匿名使用者 (未驗證) page not found 11/17/2019 - 11:26 apple-touch-icon-120x120.png 匿名使用者 (未驗證) page not found 11/17/2019 - 11:2
我們選用Drupal的一個重要原因是其對多語言的支持，在實際使用中也發現多語言支持的一些問題，特别是對數據庫負載的影響很大，我們已經想過不少辦法了。例如：Drupal設置Memcache緩存、修改緩存翻譯詞的長度、減少翻譯相關數據表的尺寸等。
這兩天對一台阿裡雲RDS負載問題進行排查的時候，再次開啟Devel來查看IP Location系列典型頁面的SQL查詢語句，從幾個方面進行了優化：
以前在Drupal站中需要數據庫查詢的時候都是優先考慮使用Views而不是自己寫SQL語句，這确實方便了許多。但如果要跨站查詢非本站數據庫的時候就沒法調用其它站的Views了。以前曾經把需要的表複制到當前站再用Views，不過這樣可能造成大量冗餘的數據表。
前一段時間在網上搜了一下，Drupal的API中本來就準備了這站外數據庫查詢的接口，下面是一個例子：
function hanzi_emojis($input) {
// 原始 sql語句的辦法
$database_info = array(
'host'
2002-2023 v11.7 a-j-e-0