您的Drupal 7多站点实例在共享基础设施上运行着23个特许经营地点，自2025年2月以来就没有收到过安全补丁。您正面临着一次D7到D10的迁移，实际上是23次独立重建——每个位置的自定义模块、主题覆盖、内容类型都需要手工重建。Drupal 9团队在从D7升级到D9时遇到过完全相同的重建痛苦。现在D10到D11又带来了新一波的破坏性更改，您的网络会将每个兼容性问题乘以您管理的站点数。我们已在90天内将多站点网络从Drupal迁移到Next.js + Supabase。架构差异解释了为什么团队在做这个永久性转变——以及一旦您看到规模化部署的优势，为什么再回到Drupal就变得不可思议。

我必须坦诚地说：Drupal不是坏软件。它曾为——现在仍然为——互联网上一些最重要的网站提供支持。但2026年的多站点Drupal与2015年的情况从根本上不同。生态系统已经转变，经济学已经改变，开发者人才库已经迁移到JavaScript。如果您是一个为大学、医疗系统、政府机构或多位置企业管理Drupal多站点网络的IT团队或代理机构，本文就是为您而写的。

目录

Drupal多站点已死：多位置企业转用的新方案

为什么Drupal多站点正在衰落

Drupal多站点在2010年是个优雅的想法。一个代码库、一个服务器、多个站点共享模块和主题。对于拥有50个部门站点的大学或拥有30个诊所位置的医疗系统来说，这是逻辑上的选择。您可以从单个管理面板管理所有内容，推送一次更新，并在整个网络中保持一致性。

该模式在Drupal自身进化的重压下已经出现了裂缝。

核心问题不是任何单一问题——而是五个同时发生的压力的复合效应：升级成本、模块兼容性、人才稀缺、性能期望和托管经济学。每一个问题单独出现都是可以管理的。但它们加在一起，使得多站点Drupal对大多数组织来说变得不可行。

打破预算的升级税

Drupal 7在2025年1月到达生命终期。这不是温和的弃用——这意味着没有更多的安全补丁、没有社区支持，以及您网络中每个站点都面临主动漏洞风险。如果您仍在运行D7多站点，您正在承载真实风险。

但这里令人烦恼的部分是：从Drupal 7升级到Drupal 10或11不是升级。这是一次重建。Drupal 8重写了整个架构，从程序化PHP模型转变为基于Symfony的面向对象PHP。您的D7主题？没了。您的自定义模块？重新编写。您的模板文件？用Twig从头开始。

在单个站点上，这是一个痛苦但可管理的项目。在一个20站点的多站点网络上，这是20次重建。即使站点共享基础主题，每个位置可能也有自定义——自定义内容类型、Views配置、块和Paragraph类型布局，所有这些都需要个别关注。

数字说明了一切：

  • 单个站点的D7到D10迁移：$30,000–$80,000，取决于复杂性
  • 20站点网络的D7到D10迁移：$200,000–$600,000+（不是简单的乘法，因为有共享代码，但远不是单站点成本）
  • D10到D11升级：不那么戏剧性，但仍然涉及围绕Symfony 7组件、PHP 8.3要求和已弃用API移除的破坏性更改

而且周期不会停止。Drupal已承诺年度主要版本发布，这意味着年度破坏性更改。每个版本都会提高最小PHP版本、弃用API，并要求模块作者更新其代码。对于多站点网络，这创建了永久升级跑步机。

我谈过一些IT主管，他们将Drupal升级预算描述为"保持现状的成本"。他们花费六位数只是为了维持功能奇偶性——而不是添加任何新功能。

模块兼容性陷阱

Drupal的威力来自其贡献模块生态系统。典型的多站点安装可能使用40-80个贡献模块——Views、Paragraphs、Webform、Pathauto、Metatag、Media、Layout Builder和许多其他。

这里有个麻烦：在多站点设置中，所有站点共享同一个代码库。这意味着每个模块必须同时与每个站点兼容。当模块作者放弃对Drupal 9的支持（该版本已在2023年11月到达生命终期）并仅支持D10/D11时，您无法选择性地为一个站点升级模块。您要为所有站点升级模块，要么都不升级。

这创建了依赖关系死锁。您想升级模块A因为它有关键安全补丁，但模块A的新版本需要Drupal 10.3+，而您的代码库在10.1上，因为模块B还没发布10.3兼容版本。将此乘以60个模块和20个站点，您会花费整个冲刺周期在兼容性测试上。

贡献模块生态系统也在萎缩。根据Drupal.org统计，积极维护的模块数量自2020年以来一直在下降。许多模块维护者已迁移到其他平台或只是停止更新其模块。Drupal社区比五年前更小，这个趋势在加速。

Drupal多站点已死：多位置企业转用的新方案-架构

Drupal人才短缺是真实存在的

这是代理所有者和IT主管感受最深刻的一个。在2026年找到Drupal开发者确实很困难。

Drupal需要特定的技能集：PHP（高级）、Symfony、Twig模板、Drupal的实体/字段系统、插件API、配置管理（基于YAML）和渲染管道。这些不是坏技能——它们只是越来越罕见。从训练营和CS课程毕业的开发者正在学习React、Next.js和TypeScript。他们不是在学Drupal。

市场率反映了这一点：

| 角色 | Drupal开发者 | Next.js开发者 | |------|-----------------|-------------------|n| 初级 | $80–$120/小时 | $60–$90/小时 | | 中级 | $120–$170/小时 | $80–$130/小时 | | 高级 | $170–$220/小时 | $120–$170/小时 | | 可用人才库 | 萎缩 | 快速增长 | | 平均招聘时间 | 6-12周 | 2-4周 |

您为更难找到的开发者支付更多费用，在生态系统中工作时社区资源更少。这对任何组织来说都不是一个可持续的位置。

我们专门建立了我们的Next.js开发实践，因为这是人才和需求汇聚的地方。

性能：PHP渲染与边缘交付

Drupal通过PHP渲染提供页面。每个请求都会命中服务器、引导Drupal、查询数据库、运行渲染管道并返回HTML。即使有缓存层（Varnish、Redis、Drupal的内部页面缓存），该架构也有性能上限。

生产多站点安装上典型的Drupal Lighthouse分数：

  • 性能：55–70
  • LCP（最大内容绘制）：2.5–4.5秒
  • CLS（累积布局转移）：0.1–0.3
  • TTFB（首字节时间）：800ms–2.5s（取决于托管）

具有ISR（增量静态再生成）或SSG（静态站点生成）的Vercel上的Next.js：

  • 性能：90–100
  • LCP：0.8–1.5秒
  • CLS：0–0.05
  • TTFB：50–200ms（边缘缓存）

这不是边际差异。这是代际差异。Google的Core Web Vitals是排名因素，Drupal和现代前端框架在边缘基础设施上之间的性能差异可在搜索排名中测量。

对于多位置企业，这更重要。每个位置页面都是本地SEO登陆页面。如果您的Dallas诊所页面在4秒内加载，而竞争对手的在1.2秒内加载，Google会注意到。

成本对比：Drupal托管与现代堆栈

Drupal多站点需要托管的Drupal托管。您需要PHP、MySQL/MariaDB、服务器级缓存，理想情况下是了解Drupal文件结构和多站点配置的平台。主要选项：

  • Acquia Cloud：$800–$3,000/月用于多站点
  • Pantheon：$300–$1,500/月（取决于计划和站点数）
  • Platform.sh：$500–$2,000/月
  • AWS/GCP上自管理：基础设施$200–$800/月，加上$2,000–$5,000/月用于系统管理员管理

我们为多位置站点推荐的现代堆栈：

  • Vercel Pro：$20/月
  • Supabase Pro：$25/月
  • 总计：$45/月

这是$540/年对比$3,600–$36,000/年。即使您添加媒体CDN（$20/月）和监控工具（$30/月），您也只需$1,140/年。仅托管节省就经常在第一年内支付迁移成本。

公平地说：Vercel和Supabase定价随使用情况扩展。高流量多站点可能会看到Vercel账单为$100–$300/月，Supabase为$50–$100/月。即使在高端，您也只需$4,800/年——仍然只是托管Drupal托管成本的一小部分。

对比分析：Drupal多站点 vs. Next.js + Supabase

| 因素 | Drupal多站点 | Next.js + Supabase | |--------|------------------|--------------------|n| 升级成本（每个主要版本） | 20个站点$200K–$600K | $0–$5K（小型依赖更新） | | 年度托管成本 | $3,600–$36,000 | $540–$4,800 | | 开发者小时费率 | $120–$220/小时 | $80–$170/小时 | | 添加新位置的时间 | 2–4周 | 1–3天 | | 安全态势 | 需要持续补丁，共享代码库 = 共享风险 | 静态生成的页面，无服务器可利用 | | Lighthouse性能分数 | 55–70 | 90–100 | | i18n支持 | Drupal i18n模块（复杂配置） | next-intl +语言环境列（直接） | | 内容编辑 | Drupal管理UI | Supabase仪表板、自定义管理或无头CMS | | 部署 | SSH/Git部署到单个服务器 | Git推送→Vercel自动部署与预览URL |

迁移路径：从Drupal到Next.js + Supabase

这是我们在迁移Drupal多站点网络时遵循的实际过程。这不是周末项目，但它是定义明确和可预测的。

第1步：从Drupal导出内容

该方法取决于您的Drupal版本。

Drupal 10/11：使用JSON:API模块（包含在核心中）以编程方式导出内容：

# 导出所有"location"类型的节点
curl https://your-drupal-site.com/jsonapi/node/location?page[limit]=50 \
  -H "Authorization: Basic BASE64_CREDENTIALS" \
  > locations.json

Drupal 7：内置没有REST API。您需要直接查询数据库。Drupal 7跨多个表存储内容——node、field_data_*、field_revision_*和分类表。

-- 导出D7位置节点与字段数据
SELECT 
  n.nid,
  n.title,
  n.created,
  n.changed,
  fdb.body_value AS body,
  fda.field_address_value AS address,
  fdp.field_phone_value AS phone,
  fdl.field_latitude_value AS latitude,
  fdl.field_longitude_value AS longitude
FROM node n
LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
LEFT JOIN field_data_field_address fda ON n.nid = fda.entity_id
LEFT JOIN field_data_field_phone fdp ON n.nid = fdp.entity_id
LEFT JOIN field_data_field_location fdl ON n.nid = fdl.entity_id
WHERE n.type = 'location'
AND n.status = 1;

这很混乱——Drupal 7的EAV（实体-属性-值）字段存储意味着您为每个字段加入一个单独的表。但它有效。

第2步：将Drupal数据转换为Supabase架构

Drupal的数据模型不映射1:1到清晰的关系架构。这是我们如何处理关键转换：

段落类型→JSONB字段

Drupal Paragraphs将灵活的内容布局存储为引用的实体。在Supabase中，我们使用JSONB列：

CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  site_id TEXT NOT NULL, -- 标识哪个位置/站点
  title TEXT NOT NULL,
  body TEXT,
  address JSONB, -- {street, city, state, zip, country}
  phone TEXT,
  coordinates GEOGRAPHY(POINT, 4326),
  page_sections JSONB, -- 替代段落类型
  meta JSONB, -- SEO元数据
  locale TEXT DEFAULT 'en',
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

page_sections JSONB字段存储Drupal段落曾经处理的内容：

[
  {
    "type": "hero",
    "heading": "欢迎来到我们的Dallas位置",
    "image": "/images/dallas-hero.webp",
    "cta": {"text": "预约", "url": "/dallas/book"}
  },
  {
    "type": "text_block",
    "body": "<p>我们的Dallas诊所自2008年以来为社区服务...</p>"
  },
  {
    "type": "staff_grid",
    "staff_ids": ["uuid-1", "uuid-2", "uuid-3"]
  }
]

Drupal Views→Supabase查询+服务器组件

Drupal Views基本上是一个可视化查询构建器。在新堆栈中，这些变成从Next.js Server Components调用的Supabase查询：

// app/[location]/page.tsx -- 替代Drupal View
import { createClient } from '@/lib/supabase/server'

export default async function LocationPage({ 
  params 
}: { 
  params: { location: string } 
}) {
  const supabase = await createClient()
  
  const { data: location } = await supabase
    .from('locations')
    .select('*')
    .eq('slug', params.location)
    .eq('published', true)
    .single()

  if (!location) notFound()

  const { data: nearbyLocations } = await supabase
    .rpc('nearby_locations', {
      lat: location.coordinates.coordinates[1],
      lng: location.coordinates.coordinates[0],
      limit_count: 3
    })

  return (
    <main>
      <LocationHero location={location} />
      <SectionRenderer sections={location.page_sections} />
      <NearbyLocations locations={nearbyLocations} />
    </main>
  )
}

Drupal用户→Supabase Auth

如果您的Drupal站点有用户认证（患者门户、学生登录等），Supabase Auth用内置支持处理电子邮件/密码、魔术链接、OAuth提供商和行级安全：

-- 行级安全：用户只能看到自己的数据
ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;

CREATE POLICY "用户看到自己的记录" ON patient_records
  FOR SELECT USING (auth.uid() = user_id);

Drupal i18n→next-intl +语言环境列

Drupal的多语言系统功能强大但复杂——内容翻译、界面翻译、配置翻译和语言检测都通过单独的子系统运行。使用next-intl和Supabase，它更简单：

// 查询本地化内容
const { data } = await supabase
  .from('locations')
  .select('*')
  .eq('slug', params.location)
  .eq('locale', params.locale)
  .single()

分类→Supabase中的标签/类别

Drupal的分类词汇表变成简单的查找表，具有许多对许多关系的接合表：

CREATE TABLE categories (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  vocabulary TEXT NOT NULL, -- 'service_type', 'specialty', 等。
  name TEXT NOT NULL,
  slug TEXT NOT NULL
);

CREATE TABLE location_categories (
  location_id UUID REFERENCES locations(id),
  category_id UUID REFERENCES categories(id),
  PRIMARY KEY (location_id, category_id)
);

第3步：在Next.js + Tailwind中重建模板

这是实际前端工作所在。我们创建一个组件库，动态呈现JSONB页面部分。每个Drupal模板变成一个React组件。我们使用Tailwind CSS进行样式设置，这意味着您的设计师可以使用实用程序类而不是与Drupal的主题层搏斗。

第4步：为每个URL进行301重定向

这是关键。Drupal URL遵循模式如/node/123、/location/dallas-tx或任何Pathauto生成的内容。每个单一URL都需要301重定向到其新的Next.js等价物。我们从Drupal数据库生成这些：

// next.config.js
module.exports = {
  async redirects() {
    return [
      // 从Drupal url_alias表生成
      { source: '/node/1234', destination: '/locations/dallas', permanent: true },
      { source: '/locations/dallas-tx-clinic', destination: '/locations/dallas', permanent: true },
      // ... 数百个更多
    ]
  }
}

第5步：部署并停用

部署到Vercel，验证所有重定向，确认SEO指标稳定（预期2-4周的波动），然后停用Drupal服务器。保留数据库备份——您永远不会需要它，但这样您会睡得更好。

离开Drupal的行业（及其迁移到何处）

大学

高等教育是Drupal的据点。大学喜欢多站点，因为每个系、学院和课程都可以在同一个保护伞下拥有自己的站点。但升级成本对拥有50-200个子站点的机构来说是残酷的。我们看到大学迁移到Next.js与内容编辑的无头CMS选项如Sanity或Contentful，或对想要完全控制其数据的机构迁移到我们首选的Next.js + Supabase堆栈。我们的无头CMS开发工作涵盖这些确切的迁移。

医院系统

医疗组织需要HIPAA合规，而共享托管上的Drupal是一个合规噩梦。具有Supabase的现代堆栈（提供SOC 2 Type II合规，可为HIPAA要求自托管）提供更好的安全态势，运营开销更少。每个诊所位置页面变成一个静态生成的页面，没有服务器端攻击表面。

政府机构

政府站点是早期Drupal采用者——WhiteHouse.gov曾著名地运行在Drupal上。但FedRAMP合规要求和ATO（操作权限）过程用于服务器基础Drupal托管很昂贵。静态站点生成器和JAMstack架构大幅减少了合规表面积。多个机构已迁移到Next.js与静态导出或Astro用于内容丰富的信息站点。

媒体组织

发布商需要速度——既在页面加载中也在编辑工作流中。Drupal的编辑体验，虽然通过Layout Builder改进，也无法与现代无头CMS平台可用的现代编辑体验相匹配。Drupal渲染和边缘交付静态页面之间的性能差异是读者停留和反弹之间的区别。

迁移后的架构样式

多位置企业的最终状态如下所示：

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐    │
│  │ /dallas  │ │ /austin  │ │ /houston │    │
│  │ (SSG)    │ │ (SSG)    │ │ (SSG)    │    │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘    │
│       └─────────────┼─────────────┘          │
│                     │                        │
│            Next.js App Router                │
│            (共享组件)               │
└─────────────────────┬───────────────────────┘
                      │
              ┌───────┴───────┐
              │   Supabase    │
              │  ┌──────────┐ │
              │  │locations │ │
              │  │staff     │ │
              │  │services  │ │
              │  │reviews   │ │
              │  │media     │ │
              │  └──────────┘ │
              │  + Auth       │
              │  + Storage    │
              │  + Edge Funcs │
              └───────────────┘

添加新位置？在locations表中插入一行，添加页面部分内容，站点通过ISR重建。没有新的Drupal站点配置、没有DNS配置、没有Apache vhost设置。只是数据。

如果这个架构引起您的兴趣，我们已在我们的定价页面记录了我们的方法和这些类型迁移的定价。有关您特定Drupal网络的对话，联系我们。

常见问题

Drupal 7在2026年仍然安全使用吗？ 不。Drupal 7在2025年1月到达生命终期。它不再从Drupal安全团队接收安全补丁。有第三方扩展支持供应商，但它们很昂贵（$500–$2,000/月），只覆盖核心——不是贡献模块。如果您仍在D7上，您应该将迁移视为紧急，而不是可选。

Drupal到Next.js迁移需要多长时间？ 对于单个站点，预期4–8周。对于拥有10–20个站点的多站点网络，计划3–6个月的分阶段方法——分批迁移站点，从最高流量位置开始。共享组件库意味着每个后续站点迁移比前一个更快。

迁移到Next.js时我会失去SEO排名吗？ 您会看到临时波动——通常2–4周——因为Google重新爬取并重新索引您的页面。正确的301重定向是不可谈判的。我们看到大多数站点在30天内恢复到迁移前排名，许多在60天内超过它们，因为Core Web Vitals分数改进。

Drupal的内容编辑体验呢？非技术编辑需要CMS。 这是一个有效的关注。Supabase的仪表板对技术团队有效，但非技术编辑通常需要更友好的界面。选项包括：使用Next.js建立自定义管理面板（2–3周额外工作）、使用无头CMS如Sanity或Contentful作为编辑层，Supabase作为数据存储，或使用Supabase的自动生成的API与工具如Retool或Appsmith用于快速管理界面。

Supabase能处理医疗组织的HIPAA合规吗？ Supabase Cloud是SOC 2 Type II合规。对于HIPAA，您需要要么与Supabase的业务伙伴协议（BAA）——联系他们的销售团队——要么在您自己的HIPAA合规基础设施（AWS GovCloud、Azure Government等）上自托管Supabase。自托管Supabase增加运营复杂性但给您完全控制数据驻留和合规。

Drupal多站点和Next.js + Supabase之间的真实成本差异是什么？ Acquia或Pantheon上的20站点网络，您通常花费$12,000–$36,000/年仅在托管上。Next.js在Vercel + Supabase用于同一网络运行$540–$4,800/年。考虑Drupal升级周期（每2–3年$200K–$600K）与Next.js的接近零升级成本，五年TCO差异通常是$500K+。

我能增量迁移，还是必须全部一次？ 增量迁移工作良好。使用Vercel的重写来代理特定路由到您的旧Drupal站点，同时从Next.js服务迁移的页面。一次迁移一个位置。这种方法风险更低，让您在完全提交前验证新堆栈。我们已经用30多个站点的网络完成了这个，其中大爆炸迁移不可行。

我的Drupal贡献模块功能会发生什么？ 每个模块映射到新堆栈中的某些东西。Webform变成React Hook Form + Supabase插入。Pathauto变成Next.js动态路由。Metatag变成Next.js Metadata API。Views变成Supabase查询。Search API变成Supabase全文搜索或Meilisearch等服务。功能不消失——它只是转移到更可维护的实现。我们已为50个最常见的Drupal模块编写迁移映射，作为我们无头CMS迁移实践的一部分。