Drupal 的 AI 已經不再是一堆按廠商拆開、誰需要誰自己掛上去的貢獻模組。它現在是一個有抽象層托底的統一專案,有安全團隊涵蓋的發布週期,並且在 Drupal CMS 裡被包裝成產品,在安裝過程中主動問你要不要把其中一部分打開。值得問的問題已經從 Drupal 能不能做 AI,變成了哪些部分值得打開,以及當四位編輯每個工作日都在用它時,每一項功能到底要花多少錢。 多數文章講到示範就停了。有人敲一段提示詞,頁面出現了;你看著聊天機器人建出一個內容類型。示範本身是真的。它沒有告訴你的是,編輯按下那個按鈕的瞬間有什麼離開了你的基礎架構,清單上的模組裡哪些從來沒有發布過穩定版,以及哪一條預算真的會漲。 Drupal AI 給企業帶來了什...
文章
在同一頁面瀏覽所有文章。找到關於人工智慧、程式設計、資安、基礎設施與網站開發的教學、深度解析、指南與更新。
「Drupal 很慢」這個名聲，絕大部分來自主機代管，而它幾乎總是一個採購決定，不是軟體問題。網站被認真地做了出來，然後上線在一個以「幾個 PHP 檔案的形象網站」定價的方案上。結果就是：一套帶著正經算繪管線的內容管理系統，跑在一個自己改不了的記憶體上限裡，跑在一個自己控制不了的作業碼快取上，還沒有一個能執行自身工具的命令列。 人們心裡拿來對比的是 WordPress，而這個對比是錯的。WordPress 幾乎在任何環境下都能勉強跑得動，是因為它的市占率逼著主機商把它做成幾乎在任何環境下都能勉強跑得動。Drupal 的前提不同：它假定你有較新的 PHP、較新的資料庫、真正的快取後端、一個命令列，以及一套把程式碼庫當成建置產物、而不是...
在開源 CMS 的世界裡，Drupal 安全是少數幾個公開流程優於平台名聲的領域之一。Drupal 安全團隊按固定的揭露時程運作，用一套有據可查的數值標準為每一份公告評分，並在核心與數以萬計的貢獻專案之間協調修復。 現實中的紀錄配不上這套流程。Drupal 網站確實會被攻破，而原因幾乎從來不是沒有人知道。公告準時發布了，就在某個星期三。修補程式則是隔週才進到正式環境。這篇文章要談的正是那段空檔，而安全強化、防火牆與檔案權限的存在，都是為了讓這段空檔變得撐得過去，或者把它縮短。 決定風險的是你修補的速度，而不是你剛好裝了哪些模組。 核心公告落在每月一次的星期三時段，貢獻專案公告則是每週三，兩者都依據一套公開的標準評為 0 到 25 ...
Drupal SEO 的名聲並不完全配得上它的實力。隨便問一圈，總有人會告訴你 Drupal 開箱即用就很適合搜尋，而說這話的人往往是拿十五年前對另一個平台的記憶在做比較。一套原裝的 Drupal 11 安裝，既沒有中繼描述欄位，也沒有 XML 網站地圖，URL 變更時沒有自動轉址，而且在編輯手動輸入別名之前，內容一直在 /node/123 上回應。 這不是在批評這個專案。核心刻意把自己的範圍維持得很小，把一切帶有立場的東西推給貢獻模組，而這正是大型 Drupal 網站能比多數平台調得更精細的原因。但這也表示開箱即用這個說法承擔了非常多的分量，也表示一個 Drupal 網站的搜尋表現，幾乎完全取決於第一天裝了哪些模組，以及有誰把它們...
CMS 遷移屬於少數幾類專案：技術面可以做得毫無差錯，結果卻仍然是一場災難。網站按期上線，外觀更好看，載入也更快，流量卻掉了一半，原因是幾百條網址換了形狀，而沒有人去做那張對照表。技術驗收一項項全過，商業結果卻是負的。 掉掉的流量並不是新平台造成的，而是斷裂造成的：以前能回應的網址現在不再回應，以前認得出來的頁面現在看起來像全新的，多年累積在舊網址上的歷史也失去了去處。而且排名往往不是上線當天就掉下去，而是在接下來的幾週裡慢慢往下沉，所以上線當天看起來一切正常，並不能說明任何事情。 決定結果的只有一個判斷：你要保留 URL 結構嗎？ 如果保留，遷移基本上就是一件內容與範本的工作，風險有限。如果不保留，每一條變動過的網址都需要一條指向...
事故檢討很容易召開，卻很難做得有用。會開了，文件寫了，四條改善事項記下來了，六個月後同一個故障又發生一次，而某個人正好在找別的東西時翻出那份舊文件。 談到這件事時，注意力幾乎都落在「不究責」這個詞上。這條原則確實重要，但失效的地方並不在那裡。有大量組織把不究責執行得一絲不苟，檢討卻什麼也沒有改變，原因很簡單：他們把檢討本身當成了交付物，而不是當成產出交付物的手段。 判斷你們的檢討是否有效，有一個簡單到令人難堪的測試：過去六個月記錄下來的改善事項，實際完成的比例是多少？ 如果答案是「大部分」，那麼無論流程長什麼樣，它都在發揮作用。如果低於一半，你們是在開會而不是在運行一個流程，換更漂亮的範本也救不了。少數幾條帶負責人與期限的事項，勝過...
密碼儲存是軟體領域裡少數幾個真正存在標準答案的題目之一。答案早就公開了，一直有人維護，而且免費。但它同時也是最常被做錯的題目之一，原因很單純：那些現在被視為錯誤的做法，在某個年代確實是正確的，而後來沒有人再回頭看過一眼。 失敗的樣子很少稀奇。通常就是一套 2016 年依照 2012 年的建議搭起來的系統，到今天還在跑，還在接受登入請求，而自從當初寫下那段雜湊程式碼的人離職之後，就再也沒有人打開過那個函式。它沒出過事故，也沒被稽核過，所以從來不在任何人的待辦清單上。 如果只帶走一句話：用 Argon2id，真的不行就用 bcrypt。 本文其餘部分都是細節。像 SHA-256 這樣的通用雜湊函式，無論你套用多少次，都不會變成密碼雜湊。...
軟體供應鏈安全聽起來像是設有專職資安部門的大型組織才需要煩惱的事，而正是這種定位讓人判斷失準。一個只維運少數幾項服務的小型團隊，通常同樣相依於數百個套件，而其中沒有任何一個是團隊裡有人真正讀過的。這些套件會在建置時從團隊無法掌控的套件庫抓下來，接著在存放部署認證資訊的機器上執行安裝腳本。 暴露程度並不跟著公司規模等比例放大。它跟著相依套件的數量與建置自動化的程度放大，而小型團隊往往是前者更多、後者更少人盯著，處境比那些公開談論這件事的大型組織還要吃緊一些。 令人不舒服的算術： 你的應用程式大概有十來個直接相依套件，以及數百個間接相依套件。那十來個是你自己挑的。其餘的不是，你一個也沒讀過，而其中任何一個只要執行安裝腳本，拿到的權限就跟...
多語言 SEO 通常被講成一個翻譯問題，外加一點技術標記。但把這個網站用十二種語言營運下來，也就是英語、阿拉伯語、德語、法語、匈牙利語、義大利語、日語、韓語、羅馬尼亞語、越南語，再加上中文的兩種書寫形式，我們很清楚地看到：翻譯才是簡單的那一半。 難的那一半在於，你在英語裡習以為常的每一條規則，都有一個依文字系統而變的版本，而你原本並不知道它存在。長度上限不一樣。結構會跑掉。數字會被一個想幫忙的譯者寫成國字，從那一刻起就不再和原文對得上。這些問題在有東西去檢查之前，一律看不見。 真正讓它跑得起來的是自動化，不是努力。 在任何內容上線之前，有十一項獨立檢查會從頭到尾掃一遍：語言涵蓋率、原文與各譯文之間的結構一致、數字一致性、標題層級順...
在多數已經經營了一段時間的網站上，內容更新是報酬率最高的一項工作，而它之所以不受歡迎，正是因為做完之後沒有任何東西可以拿出來宣布。修改一篇已經有排名的文章，感覺像是在做維護。發布一篇新文章，感覺像是在往前走。數字通常不同意這種感覺。 原因在於，一個已經存在的頁面早就累積了那些昂貴的東西：外部連結、檢索紀錄，以及與一組搜尋字詞之間被驗證過的關係。新頁面從零開始，什麼都沒有，要花上好幾個月才能掙到舊頁面早已擁有的東西。而改進舊頁面，是直接疊加在這份累積之上。 會讓整件事白做的錯誤，是只改日期，別的什麼都不改。 這種做法夠常見，值得把話講明白。一個把新鮮度納入考量的檢索系統，比較的是內容而不是時間戳記，一個日期動了、實質卻原封不動的頁面，...