網頁教學

WooCommerce 的商品頁通常載入得還算可以。商店頁、分類清單和搜尋結果往往就不是了，而店主常常對此感到意外，因為單一商品看起來都沒問題。差別在於算術。商品頁顯示一張主圖。一個呈現二十四件商品的分類頁至少顯示二十四張，一旦把滑鼠移入效果與相簿預覽算進去，經常是兩倍。 正是這個乘法，讓目錄頁通常成為整間商店裡最慢的部分，也讓它們成為商業上最重要的頁面。它們恰好卡在訪客抵達與訪客找到可買之物這兩件事之間。 多數緩慢目錄背後的固定模式： 佈景主題請求了一個 WordPress 從未產生過的縮圖尺寸，於是瀏覽器下載完整尺寸的原圖，再在頁面裡縮小。二十四件商品，每件都送出一張兩百萬位元組的照片只為在三百像素上顯示，就是一個五千萬位元組的...

每個 WordPress 網站最終都會撞上同一個問題。圖片是頁面上最重的東西，編輯上傳的是相機直接輸出的檔案，而行動端分數為此付出代價。慣常的答案是裝一個圖片最佳化外掛，慣常的候選是 Smush、ShortPixel 和 Imagify。 還有第二種做法，它的運作方式完全不同，而這個比較很少被公平地做出來，因為它並不是同類產品。Cloudflare Image Transformations 不會壓縮你的圖片再把結果存起來，而是在圖片被請求的那一刻重寫它。理解這個差別，決策就完成了一大半。 真正決定選擇的區別： 外掛處理並儲存你圖片的最佳化副本。Cloudflare 按請求轉換，並把結果快取在邊緣。外掛按你擁有多少張圖片計...

如果你照著 2026 年以前寫的 Cloudflare 教學操作過，安裝過名稱裡帶有 “resizing” 的外掛，或者接手過一個重寫圖片 URL 的 Worker，你多半已經遇到令人困惑的狀況：Cloudflare 控制台裡再也沒有名為 Image Resizing 的功能，說明文件也不再提到它。你的設定並沒有壞掉，只是你要找的那個名稱悄悄消失了。 這項功能現在叫做 Image Transformations。它做的是同一件事，走同一套 URL 結構，使用同一批參數。改變的是名稱、它在控制台裡的位置，以及計費方式。最後一點值得仔細閱讀，因為計費模式和多數舊指南所描述的確實不同。 一句話總結： 你現有的 URL 與 Worker 照...

網站遷移大概是唯一一種能在一個下午就抹掉多年搜尋能見度的例行專案。重做前端、更換平台、更換網域，甚至只是順手整理一下網址結構，都帶著同樣的風險，而損失很少在上線當天現形。它通常在兩週後才浮出來，表現為一條安靜而持續的下滑曲線，沒有人會把它和那次發布聯想在一起。 好消息是，成因早就被研究得很清楚，而且幾乎全部可以預防。在實際專案裡，遷移造成的流量損失幾乎都能追到同一件事上：一份不完整的重新導向對照表。這篇文章裡的其他所有內容，重要性都排在把這件事做對之後。 只有一條規則： 每一個目前存在且仍有價值的網址，都必須透過一次永久重新導向，落到新站上最接近的對應頁面。這裡說的價值，指的是它有流量、有外部連結，或者僅僅是已被索引。不是首頁。不是...

幾乎每一次 WooCommerce 效能排查都從同一個場景開始。店主已經換了更快的主機，裝了快取外掛，還買了圖片最佳化工具，網站卻依然慢。於是他們得出結論：WooCommerce 本來就重，然後就此放棄。 WooCommerce 確實比一個型錄式網站重，這在每個頁面都可能帶著購物車的前提下無法避免。但一個要六秒才打得開的商店，承受的並不是這份開銷。它承受的是某個具體的東西，而以我的經驗，幾乎總是四件事之一。 一句話版本： 商店慢，是因為購物車和結帳頁無法進入頁面快取，因為 options 資料表被自動載入的垃圾資料撐到臃腫，因為商品查詢在掃描一張沒有索引的中繼資料表，也因為三十個外掛各自往每個頁面塞自己的指令碼。主機是最後才該換的東...

Drupal 遷移屬於那種能安穩待在下一季計畫裡的專案，直到某個日期讓它變得急迫。眼前正有兩個日期在做這件事，而其中只有一個還沒到來。 Drupal 7 已於 2025 年 1 月 5 日失去官方支援。任何還在跑它的網站，已經一年多沒有任何資安保障了。Drupal 10 將在 2026 年 12 月 9 日走到生命週期終點，正好是 Drupal 12 推出的同一週，此後它不會再收到任何形式的釋出版本。如果你正處在這兩個版本之一，問題已經不是要不要動，而是走哪一條路、要花多少錢。 你現在的位置： 從 Drupal 10 到 Drupal 11 是一次真正的升級，同一個網站原地更新，通常兩到六週。從 Drupal 7 到 Drupal...

需要招聘 Drupal 開發者的組織，通常在營運體量不小的東西：有四十個院系的大學網站、帶有無障礙義務的公部門入口網站、權限真正重要的會員平台。Drupal 很少被選來做型錄式的網站。它被選中，是因為內容模型複雜，而這意味著你招的人必須理解模型，而不只是佈景主題。 這個市場也比 WordPress 更小、更成熟。開發者更少，其中資深比例更高，招聘流程獎勵的是具體。本文說清這個職位在 2026 年要花多少錢、哪些能力把 Drupal 工程師和只裝過一次 Drupal 的 PHP 開發者區分開，以及現在就該左右你決策的那個期限。 有時間壓力： Drupal 10 將於 2026 年 12 月 9 日結束生命週期，同一週 Drupal...

「WordPress 開發者」這個說法涵蓋了極為寬廣的能力區間，價格區間也一樣寬。你可以用每小時四十英鎊聘一位 WordPress 開發者，也可以用每天六百英鎊聘一位，而這兩個人會在同一個接案平台上用完全相同的措辭描述自己。一個人負責裝外掛。另一個人寫的 PHP，在接下來三次核心更新之後依然能跑。 弄清楚你需要哪一種，就解決了問題的大半。本文梳理四類截然不同的 WordPress 工作，說明它們在 2026 年各自要花多少錢，以及那幾個能可靠告訴你對面是誰的問題。 一句話版本： 如果你的需求靠一個挑選得當的外掛加上細緻設定就能滿足，你需要的是一位稱職的實作者，不該按開發者價位付費。如果牽涉到自訂功能、...

CRM 與 ERP 整合幾乎總是被說成一個連線問題，而它幾乎從來都不是連線問題。兩套系統都有文件齊全的介面，也都有現成的連接器。真正的難處在於，業務和財務花了很多年，用兩套不同的詞彙去描述同一門生意，而整合正是這兩套詞彙被迫達成一致的地方。 當有人問起，一條被轉換過兩次的商機到底該產生一個客戶還是兩個，這個專案就不再是技術問題了。這樣的對話，在三十個欄位上重複一遍，才是真正的工作量。 先做這件事: 在挑選連接器或平台之前，先寫下每一個共用欄位由哪套系統擁有，以及兩邊同時被編輯時會發生什麼。跳過這一步的整合建得很快，然後用好幾年時間不斷產出重複紀錄、對不上的合計數，以及沒人敢信的報表。 為什麼 CRM 與 ERP 的資料始終對不齊兩套...

大多數公司決定招聘 Symfony 開發者的時機，恰好是最糟的時機。主力工程師剛遞出辭呈，一次版本升級卡在半路，或者結帳頁面在高負載下開始逾時。找人忽然變得緊急，候選名單很薄，第一份看起來靠譜的履歷就顯得格外誘人。昂貴的錯誤正是這樣造成的。 這篇文章講清楚這個職位在 2026 年實際要花多少錢、如何分辨真正的 Symfony 專家與剛讀完文件的 PHP 通才，以及哪一種合作形式適合你的處境。它是從以接手別人留下的 Symfony 程式碼庫為生的角度寫的。 簡短答案： 英國的 Symfony 約聘人員中階通常每天收費 350 到 500 英鎊，資深級別每天 500 到 750 英鎊；正職年薪則依年資與地區大致落在 45,000...