这是 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