TYPO3 至 Drupal 遷移：實用開發者指南
如果你曾經盯著 TYPO3 後台，心想「一定有更好的辦法」，相信我，你絕不是唯一的想法。TYPO3 的確有強大之處——我不會否認。它在超過二十年間一直是無數歐洲企業和政府網站的 CMS 寵兒。但是，老實說，開發者的生態系已經改變了很多。許多組織發現 Drupal 提供了更現代的架構、更強大的社群，以及更輕鬆的無頭/解耦架構路徑。
在過去幾年裡，我深入參與過幾次 TYPO3 遷移到 Drupal 的項目，那真是一段漫長的旅程，過程中要解開真實世界的內容模型。它們通常亂七八糟。這份指南是我希望在第一次遷移前有人交給我的東西。我會涵蓋所有技術細節的硬碰硬部分、規畫中必須做的事項，以及那些討厭的陷阱——如果不小心的話，這些陷阱會炸毀你的時程表。
目錄
- 為什麼組織放棄 TYPO3
- TYPO3 vs Drupal：誠實的比較
- 遷移前審計與規畫
- 內容建模：將 TYPO3 對應到 Drupal
- 遷移工具和技術方法
- 處理 TYPO3 TypoScript 和擴展
- URL 結構和 SEO 保留
- 遷移後改為無頭架構
- 時程、成本和人力估算
- 遷移後檢查清單
- 常見問題
為什麼組織放棄 TYPO3
直言不諱：TYPO3 不是一個壞的 CMS。它極其靈活，天生支援多站點和多語言設置，擁有特別是在 DACH 地區忠實的粉絲基礎。那麼為什麼人們會跳槽呢？
我每次都聽到差不多的理由：
開發人員的可用性。 在中歐以外，找到 TYPO3 開發人員猶如大海撈針。另一方面，Drupal 根據 Drupal.org 的 2024 年社群報告聲稱全球擁有約 130 萬開發人員。TYPO3？沒有那麼多。如果你的資深 TYPO3 開發人員決定另謀高就，填補空缺可能需要很長時間。
生態系的動力。 隨著 Drupal 11 在 2024 年末的發布，管理員 UI、新的食譜系統和絕佳的 API 優先功能都取得了巨大進展。當然，TYPO3 v13 也很穩定，但 Drupal 的創新速率，特別是在無頭設置方面，明顯更快。
無頭/解耦架構。 計畫將內容提供給時髦的 Next.js 或 Astro 前端？Drupal 的 JSON:API 和 GraphQL 外掛程式已經是老手了。TYPO3 有自己的無頭擴展，但它不太成熟，支持者較少。
總擁有成本。 託管 TYPO3 通常對錢包造成更大的衝擊。其專門化的基礎設施意味著你可能最後會花費更多。Drupal 在從 Pantheon 到 Acquia，甚至是基本的 LAMP 堆棧上都能運作良好。
TYPO3 vs Drupal：誠實的比較
在匆忙開始遷移之前，確保 Drupal 真的會解決你的痛點。以下是 2025 年的最新情況：
| 功能 | TYPO3 v13 | Drupal 11 |
|---|---|---|
| 內容建模 | 靈活但傾向於 TCA | Entity/Field 系統，具有欄位管理 UI |
| 多語言 | 出色的原生支援 | 同樣出色的原生支援 |
| 多站點 | 標準多站點，具有內容樹 | 可能，通常使用 Domain Access 或分開安裝會更好 |
| 無頭/API | 有無頭擴展 | JSON:API 核心，GraphQL 貢獻 |
| 模板化 | Fluid 模板 + TypoScript | Twig 模板 |
| 擴展/模組生態 | TER 上約 1,800 個擴展 | Drupal.org 上 50,000+ 個模組 |
| 管理員 UI | 強大但過時（v13 中已改進） | Drupal 11 中現代而華麗 |
| 開發者社群 | 約 500 名活躍貢獻者 | 8,000+ 名活躍貢獻者 |
| 託管選項 | 自託管或專家託管 | 自託管、Pantheon、Acquia、Platform.sh、Lagoon |
| PHP 需求 | PHP 8.2+ | PHP 8.3+ |
| 典型代理公司費率 | €100-180/小時（DACH 地區） | $80-200/小時（全球） |
TYPO3 的頁面樹模型是稀有的寶石。對在 TYPO3 中管理複雜頁面層級結構上癮的編輯可能會發現 Drupal 的風格——內容類型和分類的組合——需要一些調整。安排一些編輯培訓以緩解該過渡。
遷移前審計與規畫
這個階段決定了大多數遷移的命運。一切都在規畫中，不是技術時間。
內容盤點
首先審計你 TYPO3 設置中的一切：
- 頁面： 提取頁面樹，記錄你使用中的每個
doktype（頁面類型）。 - 內容元素： 每個
CType（內容類型）都需要關注——無論是文本、帶圖像的文本、HTML 還是通過mask或content_defender的自訂內容。 - 擴展： 記錄你擁有的每個擴展。找出是否有 Drupal 的等價物。
- 文件參考： TYPO3 的 FAL（文件抽象層）處理媒體。將這些對應到 Drupal 的媒體位置。
- 後台使用者和權限： TYPO3 的複雜後台使用者組，具有頁面和欄位級別的存取權限，應該整潔地翻譯為 Drupal 角色和權限。
以下是一個方便的 SQL 查詢，用於從你的 TYPO3 資料庫獲得內容元素的概況：
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
有了這個，你可以快速瞭解你處理的內容類型。在一個案例中，我發現一個 TYPO3 實例擁有 40+ 個自訂內容元素類型，其中只有十幾個被積極使用。不要將死代碼拖過去。
什麼要保留，什麼要刪除
這是你整理房屋的機會。使用內容審計工具如 Screaming Frog 或 Sitebulb 來查找：
- 過去一年沒有流量的頁面
- 重複或幾乎相同的內容
- 損壞的內部連結
- 孤立的媒體文件
通常，大型 TYPO3 遷移中內容削減 30-50%。頁面越少意味著遷移越快。
內容建模：將 TYPO3 對應到 Drupal
撸起袖子。這是繁重的智力勞動。TYPO3 和 Drupal 處理內容的方式非常不同。
TYPO3 的模型
TYPO3 圍繞頁面展開。一切都藏在頁面樹中。內容元素（tt_content 中的記錄）插入頁面的欄位（colPos）。通過 Extbase 模型或 TCA 定義的自訂記錄位於不同的表中，但通常是從頁面連結。
Drupal 的模型
Drupal 全是關於實體。你製作內容類型（節點束），每個都有專用欄位。頁面只是眾多內容類型之一。分類、段落（使用段落模組）和佈局生成器掌控著結構化內容組合。
對應
以下是我用作指南針的典型對應表：
| TYPO3 概念 | Drupal 等價物 |
|---|---|
| Page（doktype: standard） | Node（內容類型: Page） |
| Page（doktype: shortcut） | URL 重新導向 |
| Page（doktype: link） | 帶有連結欄位的節點或重新導向 |
| Content element（CType: text） | 段落類型或 Body 欄位 |
| Content element（CType: image） | 媒體實體參考 |
| Content element（CType: textpic） | 帶文本 + 媒體的段落類型 |
| Content element（CType: gridelements） | 佈局生成器部分 |
| FAL 文件參考 | 媒體實體 |
| sys_category | 分類術語 |
| fe_users | Drupal 使用者實體 |
| be_users | 具有管理員角色的 Drupal 使用者實體 |
| TypoScript 模板 | Twig 模板 |
| Extbase 外掛程式 | 自訂 Drupal 模組 |
| Mask/DCE 內容元素 | 段落類型 |
最大的轉變？將內容元素移至段落。TYPO3 在頁面欄中堆疊內容元素，這與 Drupal 的段落模組相映良好。編輯們從可重複使用的段落類型中堆疊頁面——這出乎意料地無縫。
遷移工具和技術方法
Drupal 的遷移 API 很棒。但要注意，它缺少原生 TYPO3 源外掛程式。你必須製作一些自訂源外掛程式來從 TYPO3 的資料庫提取。
方法 1：直接資料庫遷移
將 Drupal 的遷移 API 直接插入你的 TYPO3 MySQL/MariaDB 資料庫：
// TYPO3 頁面的遷移源外掛程式範例
namespace Drupal\typo3_migrate\Plugin\migrate\source;
use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;
/**
* @MigrateSource(id = "typo3_pages")
*/
class Typo3Pages extends SqlBase {
public function query() {
return $this->select('pages', 'p')
->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
->condition('p.deleted', 0)
->condition('p.hidden', 0)
->condition('p.doktype', [1, 4], 'IN');
}
public function fields() {
return [
'uid' => $this->t('Page ID'),
'title' => $this->t('Page title'),
'slug' => $this->t('URL slug'),
'abstract' => $this->t('Abstract/summary'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// 載入關聯的內容元素
$pid = $row->getSourceProperty('uid');
$content = $this->select('tt_content', 'tt')
->fields('tt')
->condition('tt.pid', $pid)
->condition('tt.deleted', 0)
->orderBy('tt.sorting')
->execute()
->fetchAll();
$row->setSourceProperty('content_elements', $content);
return parent::prepareRow($row);
}
}
我喜歡這種方法。它涉及完全的控制，並讓你在你的程式碼中處理 TYPO3 的特殊性（如軟刪除和工作區覆蓋）。
方法 2：通過 JSON 或 XML 導出/導入
一些團隊選擇將 TYPO3 內容導出為結構化格式（比如通過自訂 TYPO3 擴展或 CLI 命令），然後導入到 Drupal。當然，這增加了另一層，但如果你擔心在遷移期間維護直接資料庫連接，它會派上用場。
方法 3：混合與手動審查
你的網站較小（少於 500 頁）？自動進行結構化資料遷移，同時手工製作關鍵登陸頁面可以發揮得很好。這似乎很基礎，但當內容與 TYPO3 特定的渲染邏輯交織時，自動遷移通常會導致廢話。
處理 TYPO3 TypoScript 和擴展
TypoScript
直言不諱：TypoScript 無法遷移。它是一種 TYPO3 特定的配置語言，在其他地方沒有真正的對應。你的工作是用外行人的術語記錄每個 TypoScript 模板的作用，然後將其重建為 Twig 模板和 Drupal 配置。這很痛苦但必要。
擴展
以下是常見 TYPO3 擴展和它們的 Drupal 等價物的方便比較：
| TYPO3 擴展 | Drupal 等價物 |
|---|---|
| news | 核心內容類型 + Views |
| powermail | Webform 模組 |
| solr（ext:solr） | Search API + Solr |
| realurl / routing | Pathauto + 核心路由 |
| gridelements | 佈局生成器或段落 |
| mask | 段落 |
| tt_address | 自訂內容類型或 CiviCRM |
| ke_search | Search API |
| femanager | 使用者模組 + 自訂 |
| cal/events | 自訂內容類型 + Views |
自訂 Extbase 擴展需要重寫為 Drupal 模組。沒有捷徑——確保為此預算。
URL 結構和 SEO 保留
把這搞砸了，你會失去有機流量。我見過組織在遷移後由於不當處理重新導向而損失多達 40% 的搜尋流量。
步驟
- 從 TYPO3 導出所有 URL。 為每個已索引的 URL 使用 CLI 工具或爬蟲。
- 將這些對應到 Drupal URL。 使用 Drupal 的 Pathauto 進行 URL 別名生成，盡可能靠近現有 URL。
- 為所有更改的內容創建重新導向。 在 Drupal 中部署重新導向模組。對於大量重新導向，通過 CSV 導入。
- 處理語言前綴。 TYPO3 使用
/de/、/en/、/fr/- 確保 Drupal 的語言設置鏡像這個。 - 立即向 Google Search Console 提交更新的網站地圖。
# Drupal 重新導向模組的 CSV 導入格式範例
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de
專業提示：在遷移後最少保持舊 TYPO3 實例活躍（雖然唯讀）三個月。你會發現遺漏的 URL。
遷移後改為無頭架構
Drupal 在前往解耦前端的路上閃閃發光。在 Drupal 11 中，JSON:API 模組堅如磐石，無頭 Drupal 生態系正在蓬勃發展。
如果你在考慮無頭方法——在 2025 年，對於大多數內容驅動的網站，這值得考慮——我們已經在 /solutions/headless-cms-development 詳細涉及過。
將受歡迎的前端與 Drupal 配對：
- Next.js — 領頭羊。第三章的
next-drupal緩解了問題。我們在 /capabilities/nextjs-development 廣泛討論。 - Astro — 完美適合內容豐富但不太耗用客户端資源的網站。見 /capabilities/astro-development。
- Nuxt — 如果 Vue 是你的遊樂場。
首先遷移到 Drupal 再啟動 Drupal 預設 Twig 前端的妙處在於稍後你可以切換到解耦的。不要一次嘗試兩次移動——那是在要求項目混亂。
時程、成本和人力估算
來自我參與過的項目或擁有準確數據的項目的真實數字（2024-2025）：
| 網站大小 | 頁面 | 時程 | 預算範圍 | 團隊 |
|---|---|---|---|---|
| 小型 | <500 頁 | 2-3 個月 | $30,000-60,000 | 2-3 名開發人員 |
| 中型 | 500-5,000 頁 | 4-6 個月 | $60,000-150,000 | 3-5 名開發人員 |
| 大型 | 5,000-50,000 頁 | 6-12 個月 | $150,000-400,000 | 5-8 名開發人員 |
| 企業 | 50,000+ 頁 | 12-18 個月 | $400,000-1,000,000+ | 8-15 名開發人員 |
這些包括發現、內容建模、遷移、前端主題、質量保證和編輯培訓的一切。持續的維護不包括在這裡。
最大的成本因素不只是頁面計數——它是複雜性。一個具有 30 種自訂內容類型和 4 種語言的 2,000 頁網站將比一個簡單的 10,000 頁網站花費更多。
考慮你的案例的具體情況？查看 /pricing 或 直接聯繫。
遷移後檢查清單
不要跳過這份檢查清單。相信我。
- 驗證所有重新導向。確保它們是 301。
- 使用新網站地圖更新 Google Search Console。
- 測試所有表單：聯繫、新聞通訊、登入。
- 確保每種語言的多語言內容準確性。
- 準確遷移媒體文件及其替代文本和中繼資料。
- 檢查每個角色的編輯器權限。
- 捕獲效能指標（Core Web Vitals）。
- 驗證分析追蹤（GA4 事件、目標）。
- 配置和測試 CDN/快取。
- 啟用安全標頭（CSP、HSTS）。
- 測試備份和災難恢復系統。
- 完成編輯培訓並提供文檔。
- 將舊 TYPO3 實例保持為唯讀狀態。
常見問題
TYPO3 到 Drupal 的遷移通常需要多長時間？
對於中等網站（500-5,000 頁），從開始到啟動大約需要 4-6 個月。第一個月？純粹發現和內容建模。遷移編寫通常意味著 6-8 週的工作。質量保證和編輯培訓？預計再花一個月。如果它是複雜的多語言、多站點設置，具有自訂擴展，你在看 9-12 個月。
我可以自動遷移 TYPO3 內容，還是需要手動？
結構化內容（如頁面、新聞記錄或類別）？絕對是用 Drupal 遷移 API 自動進行。但 TYPO3 複雜的渲染邏輯內容可能需要一些手動護理。大多數遷移？大約 70-80% 自動，20-30% 手動。
在遷移期間我會失去 Google 排名嗎？
如果你對重新導向勤奮的話不會。為任何 URL 更改設置 301，盡可能貼近你的 URL 結構，立即提交那些更新的網站地圖。你可能會看到一個下降，比如 2-6 週。但反彈是典型的——網站通常在 4-8 週內反彈到遷移前的水平，並且通常在三個月內由於更好的效能而看到改進。
對於內容編輯器來說，Drupal 比 TYPO3 更難學嗎？
不同，不是更難。習慣於 TYPO3 頁面樹模型的人可能需要時間來適應 Drupal 的實體中心方法。段落模組確實提供了某種相似的內容構建體驗。記住為編輯器預算約 2-3 天的培訓，並為他們提供內容類型和工作流特定的文檔。
在遷移期間我的 TYPO3 擴展會發生什麼？
每個擴展都應該進行個別評估。許多都有直接的 Drupal 等價物（例如，powermail → Webform、ext:news → 自訂內容類型 + Views、ext:solr → Search API + Solr）。自訂 Extbase 擴展？它們需要完全重寫為 Drupal 模組。沒有轉換器——你需要自訂。
在從 TYPO3 遷移到 Drupal 時我應該改為無頭嗎？
這取決於你的目標和時程表。如果你的遷移動機來自開發人員或可維護性問題，就從簡單的 Drupal Twig 主題開始，稍後瞄準無頭。但如果你的前端團隊喜歡 React 或類似的設置，並且你渴望現代交付架構，考慮從一開始就計畫無頭。只要記住：同時進行兩次遷移和前端更改？那是高風險領土。
我如何在遷移中處理多語言內容？
TYPO3 的語言設置（sys_language_uid、l10n_parent）與 Drupal 的內容翻譯模組非常吻合。訣竅？在你的指令碼中敲定語言對語言的對應，並確保回退與你的期望相符。小心部分翻譯的內容——TYPO3 的語言覆蓋模式（自由、連接、嚴格）沒有精確的 Drupal 對應物。對於不完整的翻譯，編輯決定可能是必要的。
從 TYPO3 遷移到 Drupal 的投資回報率是什麼？
投資回報率在哪裡？主要來自於削減開發人員開支和加快功能推出。從歷史上看，我指導的團隊在第一年看到約 20-40% 的開發成本削減，主要歸因於更輕鬆的人才招聘和擁有更大的模組池，這減少了自訂開發的需要。初始遷移成本可能很高，但大多數應該在 18-24 個月內達到盈虧平衡。