求助：Drupal站点源码中CloudFlare脚本的来源排查及问题解决

遇到这种莫名冒出来的脚本确实头疼，我帮你梳理几个实用的排查方向，一步步来定位根源，顺便解决旧d3.js引发的问题：

1. 先从页面渲染的源头追踪脚本位置 #

• 开启Drupal的主题调试模式：在settings.php里加一行$settings['theme_debug'] = TRUE;，之后看页面源码时，能看到每个模板片段的注释标记，这样就能知道脚本是从哪个模板区域插进来的，缩小排查范围。
• 用Hook调试抓脚本来源：可以在自定义模块里临时加个调试代码，打印所有附加到页面的脚本资源，看看这个CloudFlare脚本是被哪个模块/主题加进来的。比如：

function mymodule_page_attachments_alter(array &$attachments) {
  foreach ($attachments['#attached']['library'] as $key => $library) {
    if (strpos($library, 'd3') !== FALSE || strpos($library, 'cloudflare') !== FALSE) {
      dpm($library); // 记得先装Devel模块才能用dpm打印
    }
  }
}

• 检查手动添加的内容：别忽略后台的自定义HTML区块、视图的页眉/页脚，还有内容节点里的WYSIWYG编辑器，有时候脚本是被手动插进去的。

2. 再深挖Superfish模块的可能性 #

虽然你暂时没找到线索，但可以再确认这几点：

• 看Superfish的配置页：有些模块会在设置里藏着加载第三方脚本的开关，比如是否默认关联了d3.js或CloudFlare资源，去模块配置里翻一遍。
• 检查它的库文件：到modules/superfish/libraries目录下，看看Superfish的库包有没有被篡改，或者自带了旧版d3.js相关的脚本——第三方压缩库有时候会悄悄带附加脚本。
• 查模块更新记录：看看Superfish最近的更新有没有引入这类脚本，或者有没有已知的恶意篡改漏洞（概率不高，但值得确认）。

3. 其他容易被忽略的来源 #

• 排查其他模块/主题：除了Superfish，那些带前端交互的模块（比如图表、动画类），还有当前用的主题，都可能默认加载旧版d3.js或CloudFlare脚本。可以用drush pm:list列出所有启用的模块，逐个排查它们的库依赖。
• 服务器和缓存层面：
  • 先清掉Drupal所有缓存（页面缓存、动态缓存、CSS/JS聚合缓存），有时候脚本是缓存里的旧残留。
  • 检查服务器的.htaccess或Nginx配置，有没有被加过自动插脚本的规则——有些服务器层面的篡改会在页面输出时偷偷附加脚本。
  • 排查恶意模块/主题：如果最近装过新模块或换过主题，先禁用它们，看脚本会不会消失，逐个排除。
• 检查CloudFlare自身配置：如果站点用了CloudFlare的CDN，去它后台看看页面规则或Workers，有没有自动注入脚本的设置——CDN端的配置也可能导致这种情况。

4. 临时解决旧d3.js的问题 #

如果暂时找不到脚本来源，可以先通过Drupal的hook_js_alter来替换或移除旧版d3.js，先解决当前的问题：

function mymodule_js_alter(&$javascript) {
  foreach ($javascript as $key => $item) {
    // 匹配旧版d3.js的路径，这里以版本低于3.0为例，你可以根据实际情况调整
    if (strpos($key, 'd3.v') !== FALSE && version_compare(substr($key, strpos($key, 'd3.v')+3, 3), '3.0', '<')) {
      // 移除旧版脚本
      unset($javascript[$key]);
      // 可选：添加新版d3.js替换
      $javascript['https://cdn.jsdelivr.net/npm/d3@7/dist/d3.min.js'] = [
        'type' => 'external',
        'scope' => 'footer',
      ];
    }
  }
}

内容的提问来源于stack exchange，提问作者PatriciaW