【Drupal 教學 2026】大型機構為何選 Drupal？一文看懂角色權限、多級審批與 SSO 單一登入整合分工 【Drupal 教學 2026】大型機構為何選 Drupal？一文看懂角色權限、多級審批與 SSO 單一登入整合分工

內容管理系統的用途與適用網站

內容管理系統解決的是「多人、多內容、持續更新」的管理問題。內容與外觀分離，改設計不必重寫內容；用戶按角色取得權限，編輯、審批、管理各司其職；新頁面沿用同一套結構，內容增加時不必每次重新規劃。

Drupal 的強項在結構化內容：課程、活動、會員服務這類欄位多、分類細、審批要求高的內容，用內容類型與欄位建模，再以 Views 排出各種列表，院校與會員組織常用它。五頁靜態官網或簡單網店，輕量工具通常夠用，為它付上學習成本未必值得。

判斷可先問三條問題：內容會否持續增加？是否多人分工？是否需要多語或嚴格審批？答案指向的需求愈複雜，愈需要結構化系統；三條都是否，輕量工具通常更合適。

Drupal core 與 Drupal CMS 的分別

Drupal core 是底層框架加核心模組：Views、Media、Layout Builder、JSON:API 都在內，安裝後啟用即可用。Drupal CMS 則是官方在 core 之上整理出的產品，預裝視覺化建頁的 Drupal Canvas 與一系列預設，Drupal 官方產品頁目前標示 2.0 版；它不是 Drupal core 12，也不等於新核心的代號。

看網上教學時，留意對方用的是哪一種：core 的教學從結構講起，Drupal CMS 的教學偏向快速建站，介面與預裝功能都有差異。本篇用 Drupal 11 core 的 Standard 安裝配置，它會預先建立 Basic page 與 Article 兩個內容類型。

練習環境與後台導覽

Drupal 要在網頁伺服器、PHP 與資料庫齊備的環境運行。學習階段用本機開發環境或測試主機皆可，安裝時選 Standard；官方用戶指南目前以 Drupal 11 為主要版本，卡住時可以對照。

裝好登入後，先認識管理選單的五個常用入口：Content 管內容、Structure 管結構（內容類型、分類、Views）、Appearance 管主題、People 管用戶與角色、Configuration 管全站設定。官方指南另列 Extend、Reports、Help 等項目，實際顯示與排列會隨版面設定不同；把五個常用入口各開一次，見到列表就回來。

Basic page 與 Article 的分別

Standard 安裝預建兩個內容類型：Basic page 適合「關於我們」這類靜態頁；Article 適合消息與文章，設有圖片與標籤欄位，發佈日期一項則屬節點的作者與建立時間資訊，不是自訂欄位。

建立第一頁：Content → Add content → Basic page，填標題與內文。按 Preview 可先看前台效果，看完按 Back to content editing 返回編輯畫面；儲存前確認 Published 已勾選，儲存後頁面才會公開。檢查時用未登入的瀏覽器開啟該頁網址，內容完整、網址由系統自動產生，這步就完成。示範學院先建三頁：學院簡介、課程總覽說明、聯絡我們。

內容類型、欄位與分類

內容類型是同一類內容的模板，欄位是模板內的資料格。課程要有開課日期、導師、名額、費用與報名截止這些固定欄位，Basic page 一樣可以加；本教學另建「課程」類型，是為了把課程資料的結構與用途分清楚，之後的列表、權限與審批都以它為準。

次序：Structure → Content types → Add content type，名稱填「課程」；儲存後進 Manage fields 逐個加欄位，日期選 Date、導師選 Text、名額選 Number。欄位的顯示有兩個位置要分別設定：Manage form display 管編輯表單的輸入方式，Manage display 管前台顯示的次序與格式。分類交給 Taxonomy：新增詞彙表「課程分類」，加入數碼生活、手工藝、語言、親子四個術語，再在課程類型加指向它的參照欄位。

Media 媒體庫負責圖片與影片：它與 Media Library 都要啟用並設好權限，編輯介面才有媒體庫可用，不是 Standard 裝好即有。課程須配置媒體參照欄位及 Media Library 輸入元件，內文插入媒體則另配編輯器。同一張導師照片入庫一次，可以跨課程重用。

驗證：新增課程「長者智能手機實戰班」，填齊欄位儲存；前台欄位次序與 Manage display 的一致、分類顯示為連結，這節的結構就成立。

用 Views 排出課程列表

Views 把符合條件的內容排成列表頁、區塊或資料來源，屬核心模組，使用前先啟用它與 Views UI。學院要一頁 /courses 顯示即將開課的課程，就用它做。

次序：Structure → Views → Add view，名稱「課程列表」；在建立精靈先選 Show Content、內容類型「課程」，勾選建立頁面，路徑 /courses，每頁 10 筆並啟用分頁，然後按 Save and edit 進入編輯畫面。在編輯畫面加三項篩選：已發佈、內容類型等於課程、開課日期大於或等於今天；排序按開課日期由近至遠，最後儲存。日期條件屬相對日期設定，要確認日期欄位類型、相對日期與時區設定，再用昨天、今天、明天的課程各建一篇核對。精靈與配置畫面的欄位位置，可對照 Drupal 用戶指南的建立內容列表 View一節。

開 /courses，課程應按日期排列；新增一篇更早開課的課程，重新整理後次序自動更新。列表不是逐篇人手排列，而是條件篩選的結果。

課程內容與 Views 列表：篩選、排序與分頁的設定位置示意。

模組三層與主題、區塊、選單

Drupal 的功能分三層。核心模組隨安裝已有，Views、Media、Layout Builder、JSON:API 都在內；社群模組從 drupal.org 下載安裝，常用的 Metatag、Pathauto、Webform 全屬這層；定製模組則按機構需要自行開發。想加新功能，按「核心 → 社群 → 定製」的次序找。

外觀與擺位由另外三樣東西管：主題（themes）決定網站外觀與版面區域；區塊（blocks）是小塊內容，放在側欄、頁尾等區域；選單（menus）管理導航結構。

Layout Builder：預設版面與單頁覆寫

Layout Builder 是核心模組，官方Layout Builder 文件列明兩種版面控制：在內容類型上設預設版面，同類內容共用排版；也可以在個別頁面覆寫，讓單頁用不同的區塊組合。學院的例子：課程頁預設兩欄，左欄內文與導師介紹，右欄日期、費用與報名按鈕；大型活動課程要全闊橫額，就用單頁覆寫。

多語網站有一條限制：官方文件明示 Layout Builder 目前不支援 translated layouts。各語言的版面表現，要在測試環境逐頁核對，不要假設覆寫會跟語言一起切換。

Paragraphs 與 Layout Paragraphs 組件編排

Paragraphs 是社群模組，讓編輯在文章內逐段插入預先定義的組件；它不附預設組件，要先配置 Paragraph types 才有東西可插。學院定義四種：圖文卡片、影片區塊、按鈕組、FAQ 問答組，編輯按需要插入、調動次序。

Layout Paragraphs 是另一個社群模組，為 Paragraphs 欄位加上拖拉排版，組件可直接放入兩欄、三欄的版面位。它與核心 Layout Builder 是兩套工具，不要混稱。

繁簡英三語內容管理

先啟用三個核心模組：Language、Interface Translation、Content Translation；加入繁體中文（預設）、簡體中文與英文，再把「課程」內容類型設為可翻譯，並逐欄位選可否翻譯。

介面語言與內容翻譯是兩回事：後台選單換了語言，網站內容不會自動跟着翻。翻譯逐篇做，路徑是 Content → 找到課程 → 操作列的 Translate → 英文旁按 Add → 填英文標題與內文 → 儲存；標題與內文逐語言維護，日期、費用、圖片通常共用原文欄位，不必重填。

訪客切換語言，用 Language 模組的 Language switcher 區塊加入版面。翻譯分三個位置：介面文字交給 Interface Translation；選單本身的名稱與區塊標題屬配置，啟用 Configuration Translation 後逐項翻譯；自訂選單連結是內容，跟課程一樣用 Content Translation 做。

翻譯品質有三點要機構安排：

• 譯名一致：分類術語（數碼生活／Digital Living）逐個翻譯，統一譯名靠機構自備的術語表，指定譯詞不改寫、指定內容要保留。
• 版本對齊：原文送審後，翻譯以哪一版為準、誰可解鎖、對不上怎樣處理，寫進流程文件。
• 校對與審批：術語與內容由誰校對、審批責任怎樣分配。

審批與語言之間的關係，官方Content Moderation 概覽寫明：每個語言版本分開審批，改一個語言的狀態不會同時更改其他語言；新翻譯以來源的已發佈版本為基礎，不是最新的未發佈修訂。驗證：把英文版標為待審，回頭看繁體版，狀態不變才是正常。配 Layout Builder 覆寫時，記住 translated layouts 的限制，多語版面逐頁核對。

角色權限與部門分工

People → Roles 先建角色，再按 Edit permissions 逐項設定；可用的權限項目會隨安裝的模組增加，啟用審批模組後才會出現狀態轉換的權限。示範學院用三個角色，對應矩陣如下。

兩條紀律。權限設完必須開測試帳戶、以該角色登入實試，只看勾選清單不算數。部門隔離更不是角色自動做到：想「手工藝組只改手工藝課程」，要配合按分類限制存取的模組或定製邏輯，並逐部門驗證，角色名叫「手工藝組」，不代表隔離已生效。

從草稿到發佈的工作流設定

審批用兩個核心模組：Content Moderation 擴展內容狀態（草稿、已發佈），Workflows 管狀態之間的轉換。設定次序：建工作流（草稿→待審→已發佈），套用到「課程」內容類型，再逐角色設定可做的轉換；「待審」這類中間狀態是自訂的，不是預設。工作流不止往前走：審批人可把內容退回草稿，編輯修改後重新送審，這條轉換同樣要在 Workflows 設定，並指明哪個角色可用。

編輯草稿可與已發佈版本並存：線上頁面照常顯示，修改留在草稿，審批通過才取代；每次儲存都是修訂版本，出錯可回退。

通知與定時屬延伸功能。待審時通知誰、審批人缺勤怎樣轉派，核心不內建，要配通知模組或定製，「通知去哪、轉派規則」寫進流程文件。定時發佈用 Scheduler 模組，按指定時間發佈或取消發佈，依賴網站排程；與 Content Moderation 合用，要另裝 Scheduler Content Moderation Integration。它解決「何時上線」，不會替你完成審批。

檢查：確認 Cron 執行頻率後，安排一篇測試課程；到期且排程執行後，核對前台與後台發佈狀態。

ADFS、Entra ID 與 SAML 登入

機構已有中央帳戶系統（例如 ADFS 或 Microsoft Entra ID）的話，Drupal 不必再設一套密碼：以 SAML Authentication（社群模組）把 Drupal 作為服務提供者，連接身份提供者。用戶在中央登入頁輸入一次帳密，回到網站已經登入。

屬性對應是設定重點。登入時身份提供者傳來電郵、姓名、部門等屬性，每項要對應到 Drupal 用戶的哪個欄位；對應錯了，登入會失敗，或資料放錯位置。多重驗證通常由身份提供者處理，Drupal 端不必重複要求；但網站若同時保留本地帳戶，就要另定這批帳戶的登入保護，以及是否容許繞過中央的安全策略。

登入成功只解決身份，用戶登入後見到與可做的操作，由 Drupal 的角色與權限決定，兩件事分開規劃。異常追蹤也要預先定義：記錄每次登入的時間、用戶與結果，屬性缺漏、對應失敗誰收通知、到哪裏查記錄，先寫下來再上線。

JSON:API 與外部資料交換

JSON:API 是核心模組，以實體與欄位提供資料操作，官方JSON:API 文件說明它沿用 Drupal 的認證、存取權限與快取機制：讀課程清單、更新欄位，都圍繞內容實體進行。想經接口建立報名一類記錄，前提是該資料已建模為支援的內容實體、開放寫入並完成授權；Webform 提交記錄或外部系統的報名資料，不會自動可寫。登入、重設密碼、帳戶建立等業務功能不在此範圍，對外開放的接口要另定授權方式與可讀寫的欄位。

兩個規劃動作不可省。資料主導權：每類資料定一個主導系統，課程內容由 Drupal 主導，手機應用經接口讀取；會籍資料由會員系統主導，Drupal 只讀取顯示。同步衝突：名額在 Drupal 改了、報名系統又寫回舊值，要預先定規則，以主導系統為準，衝突時擱置並標記待人工處理；沒有這條規則，對不上的資料會在接口上線後逐漸累積。

驗證方法：以沒有權限的測試帳戶，經接口讀會員專區內容，讀不到才是正常。

會員及校友門戶整合

一個典型場景：會員或校友名單在舊系統，網站要提供報名記錄、會員專區、校友通訊這類登入後的服務。帳戶啟用屬業務層：名單核對後，用戶首次以 SSO 登入，才建立與啟用 Drupal 帳戶；啟用前核不核對會籍有效期、由誰執行，要寫清楚。JSON:API 不會自動完成 SSO，也不會自動啟用帳戶，這裏的分層最易被誤會。

登入後見到什麼，由角色與存取權限控制；規劃時把「哪個角色見哪個入口」列成矩陣，開發與驗收用同一份。舊系統過渡期仍要用的服務，可在門戶頁提供連結；連結是否帶着登入狀態，視舊系統是否接受同一套 SSO，不接受就要另想方法。

敏感資料從最少收集做起：身份證號碼、付款資料預設不同步進 Drupal；門戶頁確實要顯示時，即場向主導系統查詢，按權限遮罩，查詢與存取留有記錄。「不同步」與「即場查詢」本身不是安全保證，授權、遮罩與記錄保護都要做到位，經手的資料越少，風險範圍越小。

SSO 確認身份、JSON:API 讀寫內容、業務規則由主導系統負責的分工示意。

Search API 搜尋、分類篩選與同義詞

Search API 屬搜尋框架：先設定搜尋索引（哪些內容類型、哪些欄位入索引）與搜尋後端，再做搜尋頁；分類篩選搭配 Facets 模組；同義詞、附件解析與結果相關度，視後端與整合而定。

搜尋結果的存取權限，不會自動與內容權限完全一致，要實際檢查索引與輸出；測試方法是以未登入身份搜會員專區文件的關鍵詞，結果不應出現。索引要照顧時效：完結或取消的課程，仍有參考價值的可留在搜尋結果，但要清楚標明已完結或取消，避免訪客誤以為仍可報名；是否保留在搜尋結果，按頁面的實際用途決定。結果頁的分頁與「沒有結果」提示同屬設定，搜不到時至少給訪客一條出路，例如熱門課程連結。

同義詞是設定工作，不是內建智慧：想搜「長者班」也找到「長者課程」，要在後端配置同義詞表，並按實際搜尋字定期補充。

Webform 報名、問卷與投票

報名、問卷與投票，都用 Webform 這個社群模組做：它支援多步驟表單、條件邏輯、提交次數限制、提交記錄與匯出，以及電郵通知。學院的報名表用四個欄位起步：姓名、聯絡電話、報名課程（連動課程清單）、同意條款；問卷加評分題，投票限制每帳戶一次，都是同一模組換設定。

提交記錄可在後台查看與匯出。誰可看結果、誰可匯出，用權限逐項控制；報名資料含個人資料，存取要隨角色收緊。需要問卷或投票的圖表統計，屬附加模組或報表整合的範圍。分工要講清：Webform 管收集，報名後的確認、收款、候補遞補屬業務流程，做在另一系統就經接口走，不要期望表單模組包辦。

AI 對話與網站知識庫

本篇的網站知識庫對話方案可採用 RAG（檢索增強生成）：先從你的資料檢索相關內容，再交給模型組織答案。文件要先處理、分段、索引。學院的例子：課程手冊 PDF 與常見問題頁入知識庫，訪客問「長者智能手機班何時開課」，系統先檢索相關段落再作答。

設計上有四項要求：答案要列出來源；資料權限跟內容權限一致，會員專屬文件不答給公眾；內容更新要同步，課程改期後知識庫跟着更新；答不出時要有出路，轉表單或真人接手。

送進模型之前，訪客問題與檢索內容的個人資料要先過濾或遮蔽，模型服務怎樣處理資料也要一併評估；資料一離開網站，就不再是 Drupal 權限管得到的範圍。

AI 對話屬網站方案的功能設計與整合，不是 Drupal 預裝。上線前準備一組「不該答」的問題（未公佈課程、會員專屬資料），按公眾與會員身份分別試，確認不該看到的內容不會被回答。

品牌吉祥物、Lottie 動畫與節日排程

吉祥物動畫常用 Lottie 格式：設計工具輸出的向量動畫，檔案細、可縮放，主題或區塊加入播放組件即可顯示。這是前端工具整合，不是 Drupal 功能。

節日排程（聖誕換帽、農曆新年換版頭）沒有裝了就生效的開關：排程顯示的區塊與 Scheduler 定時發佈，各自管自己那層，吉祥物何時換造型，要按所用的內容實體與前端組件另作整合，屬定製邏輯。素材管理一樣要規劃：每個節日版本的檔案狀態、上線前預覽、由誰審批定稿，列成日曆，設計與內容兩邊都有依據。

頁面 SEO 與多語網址

Metatag（社群模組）在全站、內容類型、單篇三個層級設定標題、描述、canonical 與分享卡資料；Pathauto 以 token 模式自動產生易讀網址，例如 /courses/digital-class。內容檢查可用 Real-time SEO for Drupal，它結合 Metatag 在編輯頁提示內容與焦點詞狀態，不是排名保證。

有網址變更時，舊網址要逐一轉到新址；Redirect 可用來設定轉址。多語站用 Simple XML Sitemap 產生 sitemap，支援 hreflang、圖片與自訂連結；hreflang 標明語言與地區版本的對應，驗證時逐頁檢查：各版本標對語言代碼、互相指向對方、返回標記齊全，標記不完整，搜尋引擎未必能正確辨識版本關係。收錄與排名，最終由搜尋引擎決定。

GA4、GTM 與表單轉化追蹤

Google Tag Manager 的容器放進主題，GA4 經 GTM 載入。報名完成與問卷提交要分開設定事件，各設一個；確認 Webform 成功提交後，把事件推送進 dataLayer，經 GTM 送到 GA4，再在 GA4 將該事件標記為重要事件（key event）。做法見 Google Analytics 的建議事件說明。若要用於 Google Ads，需另建相應轉化，可經 Google Ads，或在支援此功能的 Google Analytics 介面設定，Google 的標記重要事件說明列出兩種入口。

課程手冊一類 PDF 連結，GA4 的 Enhanced measurement 啟用相應選項即可收集 file_download 事件，不必自建；它量度的是連結點擊，不等於檔案完整下載。特殊下載流程才另設追蹤，並避免兩邊重複計。驗證用 DebugView 與即時報告，先確認事件有送出、參數正確，再查報表有沒有記錄。網站跨多個網域時，跨網域量度要另行設定：同一資料串流使用相同的 Google tag／tag ID，並實際走一次跳轉流程，核對連結參數。

報表存取在 GA4 內按同事逐個授權，不會隨 Drupal 角色自動同步。追蹤配置要符合私隱要求，包括告知與同意機制；改版或表單更動後，事件要重新驗證。事件都驗證好之後，想把數據整理成月報或一頁式儀表板，可看GA4 報表與儀表板的呈現方法。

模組更新、輸入保護與安全測試

核心與模組的安全更新要跟進，公告見 drupal.org 安全頁，Composer 管理的依賴同樣要更新，更新先在測試環境做完才上線。輸入保護收緊文字格式權限，full HTML 只給完全信任的角色，防止惡意腳本經內容進入網站；對外收集檔案的表單，要限制附件類型與大小，上載權限只向需要的角色開放。全站強制 HTTPS，登入資料與表單提交才不會明文傳送。

上線前的安全檢查至少三件事：權限矩陣逐格審視；以低權限帳戶嘗試不該做的操作；逐一核對已裝模組的來源與維護狀態。深度檢測各有分工：SAST 掃描程式碼找漏洞，DAST 對運行中的網站發測試請求，程式審查補機器掃不到的邏輯問題，業務流程測試驗證報名與審批有沒有可被繞過的位置。

快取、CDN、負載測試與 WCAG 2.2

快取用核心的頁面快取與 Dynamic Page Cache：前者主要服務匿名訪客，後者連已登入用戶也生效，按快取上下文隔離個人化部分，被隔離的內容不會跨用戶共享；定製組件要提供正確的快取中繼資料，並開啟快取做跨帳戶驗證。靜態圖檔與程式檔經 CDN 派發。圖片壓縮與合適尺寸、前端資源的合併與載入次序，同樣影響速度，量度基準用 Core Web Vitals 的指標。

負載測試按預計尖峰做：報名開放首小時的同時請求，先在測試環境模擬，覆蓋登入、資料修改與表單提交，觀察回應時間與錯誤率，超出可接受水平就回頭調整。

無障礙以 Web Content Accessibility Guidelines (WCAG) 2.2（W3C 建議標準）做準則，落實在替代文字、標題層級、表單標籤、鍵盤操作與讀屏測試。只靠模組或自動掃描不能聲稱合規；最基本的人工檢查兩項：只用鍵盤走完一次報名流程，用讀屏軟件聽一次課程頁。想逐項核對鍵盤操作與表單標籤，可看無障礙網頁指南的實際檢查方法。

版本相容、內容遷移與上線回退

升級前查兩件事：核心版本的支援時間表，以及每個模組與主題對新版本的支援。同一份官方時間表顯示，Drupal 10 將於 2026 年 12 月 9 日停止支援，仍在 Drupal 10 的網站，升級規劃要在到期前完成。

由舊版或舊系統遷移內容，先在測試環境完整演練一次：欄位對應、分類對應、多語版本、附件，逐項核對數量與抽樣內容，並整理內容、附件、舊新網址三份對照清單，驗收與日後排查都靠它們。切換前請實際使用的同事做一輪用戶驗收測試（UAT），按日常流程操作，問題在測試環境解決，不要留到上線當日。

備份包括四樣：資料庫、上載檔案、sites 設定、自訂程式，另地保存多個版本、按更新頻率排程，並定期實際測試還原。版本管理與自動化部署讓每次改動有記錄、可重複執行，出錯時知道退回哪個版本。上線回退的清單，要連切換期間的新增資料一併考慮：訪客在切換後提交的報名怎樣補回，先有答案才上線。

後台教學影片、操作手冊與知識庫

網站交給日常同事管理，交接資料要能協助日常操作。形式按角色和操作複雜度取捨，例如操作影片、可下載的 PDF 手冊、可搜尋的知識庫或後台教學入口；規模較小的，不必每類都齊。支援渠道也要講明：出問題找誰、非辦公時間怎樣處理。交接資料與功能一起驗收，不要上線後補。

需求梳理與網站架構規劃

BINGO 拿到功能清單，第一步是分層：哪些用現成模組與設定做到，哪些在模組上加調整，哪些要定製開發；三類方案同樣要評估配置、整合、測試與長期維護。第二步定骨架：內容模型、角色權限矩陣、多語策略、接口清單，骨架定了才開始做版面。

與開發商開會，先問兩句：「這項用現成模組還是定製？」「這類資料的主導系統是哪個？」答案直接影響成本與工期的評估。

定製組件、業務功能與系統接口

Drupal 項目可按需要規劃 Layout Builder 預設版面，以及 Paragraphs 組件類型（圖文卡片、影片、按鈕、FAQ）的配置與樣式整合。業務功能同樣承接：Webform 報名與審批工作流、會員門戶、多語內容管理、站內搜尋與知識庫方案設計。

接口方面，公司設有自研 CMS 與系統開發團隊，有 ERP、CRM 與大型學習管理系統的開發經驗；SSO（SAML 連 ADFS／Entra ID）、JSON:API 資料同步、舊系統串接這類項目，規劃時會先定資料主導權與衝突規則，再寫接口文件。想先了解系統及接口開發涵蓋的範圍，可看網站系統開發的服務範圍，頁內列出 ERP、CRM、LMS 及應用程式 API 連接的服務。AI 對話與知識庫屬方案的設計與整合範圍。

開發團隊、品質驗證與持續支援

團隊方面，BINGO 是全球百人團隊，每個項目由 3 至 8 人小組負責，設計、開發、項目管理分工跟進；公司持 ISO 9001、ISO 20000、ISO 27001 認證，程式碼經雙重檢查，無障礙設計累積 20+ 嘉許獎項。

支援是長期的：永久保用與終身維護保證，不會因時間久遠而不提供跟進。可以先整理需要的功能和實際用途，再與開發團隊一起評估做法。