elementor

Elementor編輯器裡已經看得到新內容，別人打開網址卻沒有看到，先分清楚你看的是編輯畫布、登入預覽，還是公開頁面。Preview可以讓有權限的人看草稿，Save Draft保存內容，而Publish才處理公開狀態。這三個動作不能互相當作已完成的證據。 下面在隔離本地測試頁放一個容易辨認的Heading。保存草稿後，登入預覽確實顯示文字，但匿名開啟正式網址看不到它。透過編輯器Publish後，同一正式網址才對匿名請求顯示該文字。這個例子只說明頁面狀態與可見內容，不表示已完成搜尋索引、排程或正式部署。 先辨認手上的網址 官方Elementor說明Preview連結和實際頁面連結不同。預覽網址可能包含預覽參數，也可能需要目前登入權限。把它貼給沒有權限的人，對方可能看到錯誤或沒有草稿內容，不能因此直接認定頁面儲存失敗。 本例使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，操作獨立本地頁面11，放入傳統Heading，文字是Framework75 saved draft marker。這段測試字串是為了辨認同一版本，正式頁面應換成適合讀者的文案。 檢查時記下頁面名稱、頁面ID和正式網址，再另外保存預覽入口。不要只看瀏覽器分頁標題相同，就以為兩個網址都代表匿名公開頁。也不要將含登入預覽權限的連結當作正式宣傳網址，先確認分享對象需要什麼入口。 Save Draft先保存，不直接表示公開 在本例編輯器的Save Options選擇Save Draft後，WordPress頁面狀態仍是draft。開啟登入預覽，可以看見Framework75 saved draft marker。這證明該權限下的預覽已讀到保存內容，還不能證明一般訪客也看得到。 草稿儲存後的登入預覽可見測試文字，頁面仍是draft。 WordPress官方Post Status把draft和publish列成不同狀態：草稿提供有相應角色的人處理，公開內容則可供一般訪客閱讀。具體按鈕名稱和可用操作，還受你目前的權限與編輯器影響；不能在沒有發布權限時，因為看不到Publish就推定插件壞了。 先確認保存動作有完成，再重開預覽核對實際文字。如果只是畫布上看到剛輸入的內容，頁面還沒保存，另一個預覽分頁可能仍顯示之前的版本。此時先核對保存狀態與版本，不要急著修改網址或重新建立一張頁面。 匿名核對要和登入預覽分開 草稿階段，本例匿名開啟正式網址得到404，而且沒有測試文字；匿名開啟登入預覽網址則得到403，也沒有該文字。兩者都和登入預覽不同。這些狀態碼是本地測試環境的觀察，不是所有網站草稿都必須回應相同代碼的規則。 重要的是匿名使用者是否收到預期內容，以及你測的是哪個網址。404可能是未公開草稿的結果，也可能來自錯誤路徑；403可能代表預覽權限不足，也可能受其他存取控制影響。不能只看一個代碼，就跳過頁面狀態和網址核對。 用沒有登入該網站的瀏覽器情境測試，確認真的沒有沿用管理者權限。若同一個瀏覽器仍保留登入，畫面看起來像一般前台，也不表示它是匿名結果。尤其在交接時，要清楚說明測試者是否登入。 Publish後再讀正式網址 接著在這張獨立本地頁面透過Elementor介面的Publish發布。讀回WordPress狀態變成publish，匿名正式網址回應200，頁面也確實包含Framework75 saved draft marker。狀態與內容兩項都對上，才足以確認本例的文字已出現在匿名頁面。 Publish後以匿名正式網址核對同一段文字；只限這張本地測試頁。 不要只拿200當作內容已更新的證據。它可能回到其他頁面，或仍是一份舊版本。應一起核對網址、頁面名稱及一段具體的新內容，也查看圖片和主要連結是否符合本次修改，避免把伺服器有回應當成全部完成。 本例是本地公開狀態的教學，沒有把127.0.0.1頁面當成已部署到網際網路。你在正式網站操作前，仍應確認該頁已準備好讓訪客閱讀；不能為了排查草稿預覽，就直接把尚未確認的內容公開。 已發布頁面的修改要另外核對 新草稿首次發布，和修改一張原本已發布的頁面，不是完全相同的起點。官方Elementor提到可以保存草稿版本或模板，但實際保留和公開哪個版本，應依目前頁面的狀態與操作確認，不能只因為按鈕寫Save Draft就推定原公開內容完全沒有影響。 修改前先記下目前公開內容，修改後保存，再比較登入預覽與匿名正式頁。若你要讓新版本公開，完成相應的Update或Publish後再讀正式網址。不要把預覽裡的新文字當成一般訪客已收到的版本。 存成Template則是另一個用途，方便後續重用內容，不等於已發布成一張可供訪客打開的頁面。交接時應說明你保存的是草稿、模板還是公開頁，讓下一個維護者不用從畫布畫面猜。 確認版本後，才排查快取或其他因素 如果頁面狀態已公開、網址正確，匿名正式頁卻仍顯示舊內容，才繼續查前台是否使用快取或其他模板。先核對是否改錯另一張相似頁面，以及是否有桌面和手機兩份內容，不要一開始就清掉所有站點設定。 本例沒有測排程、角色變更或快取清理，也沒有證明搜尋引擎已索引頁面。這些需求需要各自的核對方式。公開狀態解決的是訪客是否能取得這份頁面，後續導覽、搜尋與追蹤並不會因為Publish一次就自動完成。 最後把正式網址交給需要檢查的人，同時說明目前狀態和要看的內容。別用「我這裡看得到」代替對方的入口驗收；從預覽、保存、公開到匿名內容逐步核對，才能避免把不同版本混在一起。 多人修改時，也要先確認目前開啟的是同一張頁面。頁名相似或複製草稿很容易看錯；可以用正式路徑和一段具體內容辨認，避免把另一張測試頁的成功公開，當成目標頁面已完成發布。 參考資料Elementor：Preview、Save Draft與PublishElementor：頂部列的發布與儲存入口Elementor：頁面狀態WordPress：Post StatusWordPress：Status與Visibility

Elementor圖片看起來一樣大，卻選了不同的Image Resolution，並不奇怪。這個選項和Style裡的圖片寬度不是同一件事：前者選擇可用圖片尺寸，後者影響畫面上的排版大小。前台若另外輸出srcset，瀏覽器還可能從多個候選檔選擇實際使用的圖片。 要判斷圖片是否合適，應分開看選項、畫面尺寸、currentSrc及圖片檔本身。不能只因為下拉選單選了Full，就認定所有裝置一定下載原圖；也不能只看naturalWidth，就直接把它當成檔案的編碼像素寬度。 同一張圖，先比較編輯器尺寸選項 本例在隔離本地WordPress 7.1.2、Elementor Free 4.3.3與Twenty Twenty-Five使用傳統Image，選的是同一個1800×1200測試附件。新版有Atomic Elements，本文不把不同元件的圖片控制混在一起。 在Content的Image Resolution依次選Thumbnail、Medium、Large與Full。這個附件的編輯器讀值分別是150×150、300×200、1024×683與1800×1200。Thumbnail是正方形裁切版本，和原圖的比例不同；尺寸選項不僅影響細節，也可能影響構圖。 Large對應本例1024×683版本，但畫布顯示寬度約625px。 本例Large與Full在編輯畫布的顯示寬度都約625px，並沒有因為Full檔案像素較多，就把頁面圖片撐成1800px寬。這是來源尺寸與排版尺寸分開作用的結果。正式頁面仍應核對Style、容器寬度和圖片比例，而不是只盯著來源數字。 編輯畫布沒有srcset，不代表前台也沒有 這次編輯器中的Image沒有讀到srcset與sizes，選Full時currentSrc直接使用原圖。儲存草稿後的前台則輸出多個寬度候選與sizes，瀏覽器會依那份前台HTML選擇圖片。兩者不能混為同一次量測。 WordPress官方Responsive Images說明，系統可為圖片提供srcset與sizes支援。實際有沒有輸出，仍要看使用的元件、圖片資料和網站設定。不能只因為網站是WordPress，就跳過檢查，假定每張手寫圖片都已具備同樣的候選尺寸。 所以應先儲存頁面，再重新開啟前台。若是在草稿階段，需要有相應權限才能看預覽；測量本地登入預覽與公開網站是不同情境，不要把登入頁的結果當成已確認所有匿名訪客的載入方式。 currentSrc指出瀏覽器選中的檔案 在本例1280px、DPR 1的儲存前台預覽，Image的src仍指向1800×1200原圖，但currentSrc選中1536×1024版本。圖片的實際版面盒子約645×430px。這三項數值各有用途，不能只看src的原圖網址就說瀏覽器正在使用原圖。 將預覽改為390px、DPR 1後，currentSrc改為768×512版本，版面盒子約330×220px。這是本例當下的候選選擇，不是保證所有手機都會選768px。不同DPR、sizes、版面和瀏覽器條件，可能得到其他結果。 390px前台測試使用768×512候選檔；版面盒子約330×220px。 MDN對currentSrc的說明是瀏覽器目前選中的圖片URL，它本身不證明圖片已成功載入。檢查時還應確認圖片確實有內容、載入完成，必要時查看網路回應或直接核對該檔案，不把一個非空網址當成所有條件都通過。 naturalWidth不是未校正的檔案像素 本例桌面currentSrc選中1536×1024檔，但naturalWidth讀到1280；手機選中768×512檔，naturalWidth則為390。這不表示檔案已被改成1280或390像素。直接讀取選中檔案的尺寸，仍分別是1536×1024與768×512。 MDN說明naturalWidth是以CSS像素表示、經密度校正的固有寬度。它和圖片檔內編碼的像素尺寸，可能不是相同數字。因此診斷時應把currentSrc、naturalWidth與檔案尺寸分開記錄；不要拿其中一個值代替另外兩個。 本例只測DPR 1，沒有把它說成高密度裝置的完整驗證。若網站圖片在高DPR螢幕顯得模糊，可以在自己的裝置另行測試候選選擇與清晰度，再決定來源尺寸，而不是用這組桌面數字直接推導所有裝置。 像素較少，不保證檔案較小 這張測試圖是適合壓縮的規律圖案，原始1800×1200 PNG只有13,158bytes，而1536×1024衍生PNG為53,872bytes。這個例子明確顯示：較小的像素尺寸，不必然在每一個檔案上得到較少bytes。 不能把這個特殊圖案推成「原圖永遠比較省」。不同圖片內容、格式、壓縮和衍生處理，會影響檔案大小。選尺寸時應看實際下載檔，而不是只用寬高猜載入成本，也不要在沒有量測下承諾改一個選項就一定加速。 若目的是減少下載量，可以先核對目前currentSrc對應的bytes，再評估格式、壓縮和必要尺寸。畫面品質也要一起看；只追求最小檔案，卻讓文字或產品細節模糊，未必符合頁面用途。 儲存後用同一組條件比較 比較前後時記下視窗寬度、DPR、Image Resolution、版面盒子尺寸和currentSrc。先保留同一張圖和同一版面，再改一個相關控制，結果才容易解釋。若同時換圖、改容器、改格式和字級，就不能只把變化歸因於Resolution。 也應重新載入前台後確認候選結果，不把尚未更新的編輯畫布當成正式圖片。不同瀏覽器快取或已載入候選可能影響測量方式，應清楚保存本次觀察條件，而不是先假設每次縮小視窗都會立即換成另一個檔。 最後依圖片用途判斷清晰度與載入量。Image Resolution提供尺寸選擇，Style控制呈現，瀏覽器依前台候選選檔；把三者分開核對，才能找到圖片太糊、來源過大或版面尺寸不符的真正原因。 先保留需要的構圖和細節 Thumbnail裁切後可能只剩圖片中央，這對某些縮圖很合適，卻可能切掉產品名稱、人物或重要標示。選小尺寸之前先查看實際版本，不要只因為它是清單裡最小的選項，就拿來顯示需要完整內容的圖。 若圖片包含細小文字，應在它最後顯示的大小下確認可讀性。把來源選成Full可以提供較多細節，但版面仍很窄時，文字不會因此自動容易閱讀。必要說明可放在正文，避免要求所有訪客放大圖片才知道重要資訊。 Style裡若另外固定高度或使用裁切呈現，也應和來源尺寸分開檢查。檔案本來的比例正確，不表示版面上沒有被裁切或拉伸。先核對來源版本，再看它放進容器後的比例與可見區域，才能找到構圖變掉的原因。 替代文字與圖說也要跟著圖片用途維護。換了裁切或換了素材後，舊描述可能已不符合現在可見內容；選好尺寸只是圖片交付的一部分，不能取代內容核對。 參考資料Elementor：Image Resolution與Style尺寸WordPress：Responsive ImagesMDN：currentSrcMDN：naturalWidthMDN：響應式圖片候選

Elementor標題看起來太小，應先查Typography，而不是為了變大就把HTML Tag改成H1。標籤表示內容層級，字級控制視覺大小；兩者可以互相受到樣式影響，但不應為了追求外觀而亂改頁面結構。 下面用一個傳統Heading比較：設定字級48px後，先輸出h2，再把HTML Tag換成h3。儲存後的兩次前台預覽都讀到48px。這個例子讓你看清楚：標題層級變了，視覺大小仍可以保持；若你的主題另有標籤樣式，則還需要核對實際前台。 先確認你要改的是內容層級還是外觀 本例使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，選中傳統Container裡的Heading。這個版本也有Atomic Elements，本文只說明傳統Heading的Content與Style欄位，不把兩套元件的預設樣式機制混在一起。 如果標題在文章裡是某一節的小題，應先依內容關係選層級。如果只是覺得字看起來不夠明顯，先處理字級、字重或間距。不能因為H1通常看起來比較大，就把所有卡片標題都設成H1；這會讓頁面的內容組織難以辨認。 也要確認那個標題是否由主題輸出。有些頁面同時有主題的頁面標題和你放進內容的Heading。選中其中一個修改，不表示另一個也會一起改。先辨認標題來源，才不會在元件裡調了半天，畫面上方的主題標題仍維持原樣。 HTML Tag在Content，字級在Style 選中本例Heading後，Content的HTML Tag可選H1至H6等標籤。先使用H2。接著到Style的Typography設定Size為48px，儲存草稿並開啟前台預覽。讀到的元素是h2，文字為Author Heading Case A，計算字級是48px。 第一個儲存前台狀態是h2，計算字級48px。 這裡的48px只是讓差異容易比較的測試值，不是所有網站標題都應使用的標準。正式頁面還要考慮文字長度、容器寬度、字型和閱讀距離。尤其手機上，桌面可放下一行的標題，可能會變成三行，應另外核對響應式控制。 也不要漏看單位。48px與4.8rem是不同設定，不能因為欄位都是數字就直接對照。先確認你設定的Size、單位與目前裝置，再讀前台的計算字級，才知道它實際使用了什麼結果。 換成H3後，字級仍可以保持 接著只把本例的HTML Tag從H2改成H3，保留字級設定，再次儲存並開啟前台。元素確實改成h3，文字仍為Author Heading Case A，計算字級也仍為48px。這不是只看選單變了，而是實際核對儲存後HTML和樣式。 第二個狀態是h3，字級仍48px；標籤和字級分別處理。 官方Heading說明也提醒，改標籤通常不直接改大小或樣式，但若主題或Site Settings對該標籤有定義，則可能受影響。因此不能把本例寫成「H2換H3永遠不變」。應保存局部設定，再看你的站點實際套用哪些樣式。 如果改成H3後真的變小，不要為了恢復大小就立即換回不合適的內容層級。先查局部Typography、全域字型和主題樣式，找出哪個值影響它。正確結構和想要的視覺大小通常可以分別安排。 用章節關係安排層級 W3C說明標題用來傳達內容組織，瀏覽器和輔助技術可以利用它們導覽頁面。主要內容下面的一節可使用次一層標題，再往下的子節繼續依關係安排。相同層級的標題應代表相似的內容位置，而不是只是看起來同樣大。 例如頁面主要題目下面有「服務項目」與「聯絡方式」兩節，它們可以是同一層；服務項目裡的三個方案則是下一層。這只是示意，實際頁面還要核對主題已輸出的標題，不是只從你目前選中的元件開始計算。 W3C建議盡量避免在往下建立子節時跳過層級，例如H2下面直接建立H4；但結束較深子節後回到H2，是回到新章節，不是同一種問題。不要把「避免跳級」簡化成整頁標題必須一直從H1遞增到H6。 不要用假標題取代真正的標題 把一段普通文字加粗放大，視覺上可以像標題，但HTML可能仍是段落或span。若它確實用來開啟一個內容章節，應選合適的Heading標籤，而不是只靠字體外觀讓讀者猜內容關係。 反過來，純粹需要一段醒目的促銷短句，也不一定要使用新的章節標題。先看它的作用：是組織後方內容，還是同一段資訊中的強調。不要為了套用某種樣式，把每句醒目文字都變成H2。 如果模板中的Heading預設層級不適合目前頁面，應依內容關係調整。複製元件會帶入原設定，不代表原層級在新位置也正確。新增一張卡片或插入一個區塊後，也應回頭看整頁章節順序。 改完儲存，再查實際輸出 儲存後用前台檢查目標元素的tagName與計算font-size，兩項都要符合目的。只看截圖，無法知道它是h2還是h3；只看HTML，則不能知道它最後看起來是否太大或太小。 再核對窄視窗下文字換行、行高和前後留白。本例只證明這個本地Heading兩次儲存結果，不把48px當成已完成所有裝置的字級設計。要調手機字級時，先確認該控制的裝置範圍，避免把桌面設定也一起改掉。 最後看整頁標題是否能清楚描述各節內容。把標籤與視覺分開處理，是為了同時保留可理解的結構與合適的外觀，不是為了承諾只改一個H標籤就能提高搜尋排名。 把層級決策留給內容，而非字型預設 網站使用同一套字型樣式，可以讓不同頁面看起來一致；但某個樣式名稱叫「主要標題」，也不一定表示每個套用它的元件都應使用H1。樣式名稱、視覺大小和HTML標籤仍應分別核對，不能只因名稱相似就視為同一個設定。 如果設計要求某個子節標題很大，可以保留它正確的層級，再安排字級。若主要標題需要較小的視覺外觀，也可以在保持內容結構的前提下調整樣式。這樣內容編輯和視覺設計都能清楚交接，不需要用錯誤標籤來補外觀。 交接時也可說明這個標題屬於哪一節、文字用途和局部字級，而不只留下「換成H3」這個操作。下一位維護者增加新章節時，便較容易判斷原本的層級是否仍合適。 參考資料Elementor：Heading標籤與樣式Elementor：Typography字級控制Elementor：Content與StyleW3C：標題層級MDN：h1至h6

卡片之間太擠，和卡片內容貼著邊框，是兩種不同問題。在Elementor裡，父容器的gap控制子項目之間的間距，padding處理容器內部邊緣到內容的留白。如果兩個都一起加大，畫面可能變鬆，卻不容易知道到底是哪一層造成空白。 下面分兩次比較：先把gap由20px改為40px，再固定gap為40px，把四方向padding由10px改為30px。兩組都儲存後看前台，觀察的目標不同：gap看項目彼此的位置，padding看內容與容器邊緣的關係。 先選中共同父容器 本例使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，頁面是Canvas，選的是傳統Container，裡面有標題、圖片和按鈕等六個子項目。先從Structure選中共同父容器，再看Layout與Advanced，不把個別Heading的margin當作整組項目的gap。 如果你做的是多張卡片，每張卡片內部也可能有自己的容器。外層gap安排卡片之間的距離，卡片自己的padding則控制文字與背景邊緣的空間。先辨認是哪個區域太擠，再決定調外層還是卡片內層。 畫面上看到一段空白時，也不能直接認定是padding。它可能來自gap、margin、Spacer、最小高度或主題外框。先在元件層級找到負責這段空間的控制，避免把其他正常設定一起取消。 gap改變項目之間的距離 本例父容器是Row並允許Wrap，內容寬度1140px。先把間距控制設為20px，再改為40px。此時欄位保持連動，前台讀到的row-gap與column-gap都一起變更，不能把這次結果說成只改了垂直間距。 gap由20px改為40px；本例連動控制同時影響兩個方向的間距。 第一個Heading頂端仍在y=72px，第二個同列Heading的x位置由約588.53px改為608.53px。下一行副本的y位置由140px改為160px；後面圖片由約191.77px改為231.77px。越往後累積的行間距，會讓下方項目移動更多。 這些數字只是本例的位置，不是你應照填的值。它們用來說明gap不會替每個項目加一圈相同內距，也不一定把第一個項目從容器邊緣推開。若第一張卡片貼著外框，但卡片彼此距離已經合適，繼續加gap通常不是主要解法。 padding處理容器裡面的留白 接著保留gap為40px，在同一Container的Advanced找到Padding，把四方向先設為10px，再改為30px。這次沒有把gap一起調整，前台兩次都維持40px。第一個Heading的y位置由52px改為72px，表示上方內容留白增加了20px。 四方向padding由10px改為30px，gap保持40px，分開觀察邊緣留白。 本例的Boxed內容寬度仍維持1140px，第一個Heading的x位置也仍為70px。這不是padding沒有保存，而是內容最大寬度與置中關係仍在作用。增加內距不代表每個版面都會立刻縮小相同數量的內容寬度。 開發者工具裡還能看到，外層容器主要呈現左右padding，內層e-con-inner呈現上下padding。控制值是四方向30px，但不能只讀外層的padding-top=0，就斷定上內距失效。檢查時應沿實際包覆層級看內容所在的盒子。 不要把gap和margin重複堆在一起 若父容器已有gap，子卡片又各自加左右margin，項目之間可能比預期更寬。換行後，每一行的首尾項目也可能留下多餘空間。先看目前哪個設定負責間距，再決定是否保留個別margin，不要只把新值加到原有值上。 margin仍有自己的用途，例如特定元件和附近內容需要不同距離；但它與padding的內部留白不同。官方說明把margin描述為元素外部空間、padding描述為內部空間，容器gap則是排列項目的間距控制。知道它們的作用範圍，才容易找到應改的欄位。 也不必為了每一段空白都新增Spacer。如果空白本來應由容器內距或項目間距表達，先使用相應控制，會比在多個位置插入額外空白元件更容易維護。只有確實需要獨立空間元件時，再評估其用途。 連動圖示與裝置控制要一起確認 Padding四方向可透過連動圖示一起或分別調整。修改前先看目前是否連動，避免只想增加上方留白，卻把左右也設成相同值。本例為了清楚比較，刻意把四方向設成相同數字；正式版面不必照這個安排。 間距控制也可能有響應式值。先確認正在修改桌面、平板或手機，以及其他裝置是否有自己的覆寫。手機空間較窄時，大的左右padding會占去可用寬度；但不能只看一張桌面截圖，就決定所有裝置都使用同一數字。 單位也要保持清楚。20px和20%不是同一種空間；百分比及其他相對單位會依相關尺寸計算。從別的模板複製設定時，應一起核對數字和單位，不要只把值填對而漏看旁邊的單位選項。 用兩次比較找到真正造成空白的控制 先固定padding，比較gap；再固定gap，比較padding。這樣你能看清楚項目之間和容器邊緣各自發生什麼變化。如果一次把gap、padding、margin和最小高度全部改掉，結果很難回頭解釋，也不容易安全復原。 本例只核對1280px儲存前台，不把坐標說成所有主題與手機的結果。你在自己的頁面應再看窄視窗，確認卡片換行、內容寬度與按鈕都仍適合使用。間距數值沒有一組放到所有網站都正確的答案，應依內容與閱讀需求選擇。 最後儲存並重新載入前台，確認空白落在你原本要調整的位置。若整區仍有不明留白，就沿父容器向外看主題或頁面版型，而不是繼續加負margin來抵消它。 間距變大也可能改變換行位置 同一行需要同時容納項目寬度和gap，所以增加gap後，原本能放在同一排的卡片可能改排到下一行。這不一定是設定錯誤，而是可用空間不再足夠。若欄數需要固定，應一起重新評估卡片尺寸與容器寬度，不能只把gap關掉掩蓋需求。 本例採用的測試文字、圖片與按鈕尺寸固定，便於比較兩次設定。如果你同時換了文案或圖片，行高和項目寬度也可能變化，便無法只用間距數字解釋位置差異。比較時保留其他內容，確定問題來源後再加入正式素材。 也不要把頁面上的所有間距都追求同一個數字。卡片之間的距離、標題與內文的距離、整區和下一區的距離，各自有閱讀用途。先找到負責那個範圍的容器，再安排一致而清楚的層次。 參考資料Elementor：容器gap與LayoutElementor：padding與marginElementor：容器Advanced內距MDN：gapMDN：padding

Elementor裡幾張卡片擠在同一排，先查它們共同父容器的Direction與Wrap。Direction決定排列方向，Wrap決定項目是否能另起一行。只把每張卡片的寬度改小，可能暫時放得下，卻沒有處理原本應該換行的需求。 下面比較同一容器的No Wrap與Wrap。實際前台在No Wrap時把六個子項目放到同一排，部分項目會縮小；開啟Wrap後，項目保留較大的尺寸並分到多行。這不是「No Wrap一定超出邊界」的保證，因為結果還受項目寬度、收縮與內容限制影響。 選共同父容器，先看Direction 本例使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，頁面版型為Canvas，選的是傳統Container。新版另有Atomic Elements，本文不把它們的控制面板混在一起。先從Structure確認標題、圖片與按鈕都屬於同一個父容器，再進入它的Layout。 Direction的Row讓項目沿水平方向排列，Column則沿垂直方向排列。你若只是想讓每張卡片各占一列，可以先評估Column；若桌面想排成多欄、空間不足時另起一行，才需要一起看Row與Wrap。方向與換行是兩個不同選擇。 不要只選中卡片裡的Heading，然後在它的Advanced加大左右margin，期待整組卡片自動換行。個別元件的留白和父容器的排列規則不同，改錯層級容易讓一個位置看似正常，另一個寬度卻出現新的擠壓。 No Wrap可能讓項目收縮 本例父容器內容寬度為1140px，Direction是Row，gap保持40px。No Wrap時，六個子項目的頂端都在同一個y位置。第一個Heading寬度約168.19px，圖片約345.47px，按鈕約58.17px；它們在同一排參與分配可用空間。 同一個1140px內容容器使用No Wrap；子項目寬度受到單排空間分配影響。 因此，畫面沒有水平捲軸，不代表排版已經適合閱讀。標題被壓得很窄、按鈕文字換成好幾行，也可能是單排安排的結果。檢查時應看內容是否仍清楚，而不是只把「沒有溢出」當作完成標準。 反過來，如果項目有無法再縮小的最小尺寸，No Wrap也可能產生溢出。這是應依實際內容核對的條件，不能把本例的收縮數字直接套到另一張圖片、另一套字型或固定寬度卡片。 Wrap允許另起一行，不指定每行幾張 接著在同一個父容器把Wrap改為允許換行，其他比較條件保持不變。儲存後前台仍是1140px、Row與40px gap，但六個子項目不再全部擠在同一排。第一個Heading寬度約498.53px，第二個約329.20px；後方項目陸續排到下一行。 Wrap允許項目換行；每一行放哪些項目，仍取決於各項目尺寸與間距。 這次圖片本身約1024px寬，所以它占了獨立一行。這提醒我們，Wrap不是自動建立三欄卡片的開關。如果希望三張卡片各有自己的標題、圖片與按鈕，應先把每張卡片內容分組到各自的子容器，再規劃子容器的寬度。 換行允許的是更多列，不會自動替你把所有項目變成相同寬度。要每行兩張或三張，需要一起考慮項目寬度與gap。不能只填兩張各50%寬，再另外加一段gap，卻仍期待它們一定放在同一行。 先算項目寬度，再留出gap 官方容器Layout說明以47.5%項目寬度加5% gap示範兩項安排。這是同一行要同時容納項目和間距的概念，不是所有版面的固定設定值。你若用像素gap，或卡片還有邊框與其他寬度條件，應依實際可用空間重新核對。 也要分清Container的Content Width和整個頁面的寬度。本例1280px預覽中，容器內部內容只有1140px；換行要依這個容器的可用空間判斷。不能拿整個視窗寬度除以三，就認定每張卡片可以使用那個結果。 如果你的卡片需要固定比例，可以先選合適的寬度安排，再在窄視窗改成較少欄。不要單靠內容剛好比較短，讓目前這一組看起來能放下；增加標題或換一張圖後，版面可能立刻變得不同。 窄視窗再核對裝置控制 容器的Direction與Wrap可能有響應式控制。修改前先看目前編輯的是桌面、平板還是手機，確認沒有把只想在手機使用的Column寫到桌面。沒有另行覆寫的裝置也可能沿用較大裝置的值，應以實際控制與前台樣式判斷。 本例比較的是1280px前台的兩個狀態，不把它說成已驗證所有手機。你在自己的頁面應儲存後再看窄視窗，確認每張卡片完整、按鈕仍容易操作、長文字沒有把卡片撐出邊界，且排列順序仍符合閱讀流程。 不要為了讓視覺順序好看，隨意使用反向排列後就忽略內容順序。Direction的Reverse選項會改視覺呈現，維護者仍要核對實際頁面和操作流程。若目的是修改資訊順序，先確認是否應直接整理內容結構。 每次只改一個排版條件 排查時先記下父容器、Direction、Wrap、gap與主要項目寬度。先確認方向，再比較換行，最後處理尺寸；不要同時改五個值，因為結果變好了，也不容易知道是哪個條件真正起作用。 儲存後重新開啟前台，確認不是只看編輯畫布的暫時結果。若卡片仍擠壓，沿父容器查看寬度限制及子元件的最小尺寸，再決定是否調整分組。先整理排列規則，比用負margin硬把項目拉回畫面更容易長期維護。 先分組卡片，再安排整排 如果一張卡片有標題、圖片與按鈕，應讓這三個元件屬於同一個子容器，再把多個卡片容器放到共同父容器。如此父層換行的是整張卡片，卡片裡的按鈕不會因為自己成為父層的獨立項目，而跑到另一排。 本例故意把不同元件放在同一父容器，便於看清Wrap依實際項目尺寸分行的結果；它不是完整服務卡片模板。如果照著數字做卡片，卻沒有建立相同分組，視覺結果當然可能不同。先理解哪個元素是一個排列單位，再決定方向和尺寸。 這種分組也方便之後修改單張卡片背景或內距，不必逐個元件重複補留白。父層負責卡片之間的排列，子層負責卡片內部內容，維護時較容易找到應調整的位置。 參考資料Elementor：容器Layout與Direction／WrapElementor：容器內元素排列Elementor：容器尺寸與行為MDN：flex-wrapMDN：flex-direction

Elementor頁面上方多出一個標題，或切換版型後頁首與頁尾一起消失，先查Page Settings裡的Hide Title與Page Layout。它們處理不同範圍：隱藏頁面標題，不代表移除整個網站頁首；Canvas移除頁首與頁尾，也不是單純把內容拉寬。 下面用Twenty Twenty-Five做一個具體比較。預設版型保留主題的頁首、頁尾與頁面標題；開啟Hide Title後，這個主題的標題仍可見。改用Elementor Canvas後，頁首、頁尾與主題標題都不再出現在同一份預覽，而Elementor內容仍保留。這個結果用來分清控制範圍，不表示所有主題都會和本例完全相同。 先找到頁面設定，不要改錯標題元件 本例使用WordPress 7.1.2、Elementor Free 4.3.3和Twenty Twenty-Five。從編輯器頂部的Page Settings按鈕開啟頁面設定，可找到Hide Title與Page Layout。這和選中畫布中的Heading元件不同：Heading是你放進內容的標題，Page Settings控制的是頁面本身的設定。 先辨認你要移除的是哪個標題。如果是主題輸出的頁面標題，可能需要處理頁面設定與主題的標題選擇器；如果是你自己放在內容中的Heading，應直接選那個元件修改。不要把Page Settings的Title名稱改空，就以為畫布裡所有標題都已隱藏。 也不要先刪掉文章或頁面的正式名稱來整理外觀。名稱可能還會用於管理清單、導覽或其他輸出。想改訪客看到的標題呈現，先找負責該輸出的控制，保留網站管理需要的資訊。 Hide Title需要對上主題的標題 在本例預設版型中，前台有一個主題輸出的h1，類別為wp-block-post-title。開啟Hide Title並儲存草稿後，重新預覽，這個h1仍是display:block；頁首和頁尾也都保留。這確認在目前主題與設定下，單切這個開關沒有把該標題收起來。 Hide Title開關需要配合實際主題輸出判斷，不能只憑開關狀態認定前台已隱藏。 官方Global Layout Settings說明，Page title selector必須對應主題使用的標題選擇器，預設例子是h1.entry-title；主題若使用不同選擇器，就需要另外核對。本例沒有修改全域選擇器，因此不把開關未生效寫成Elementor在所有網站都無法隱藏標題。 如果準備調整選擇器，應先在自有測試頁用開發者工具確認真正的標題元素，並評估全域設定影響範圍。不要把本例的wp-block-post-title直接套到另一個主題，也不要用過寬的h1選擇器，意外把內容裡的重要主標題一起藏起來。 Canvas會改變整個頁面的外框 接著把同一頁的Page Layout改為Elementor Canvas，儲存後再次開啟前台草稿預覽。本例頁首數量從一個變成零，頁尾也從一個變成零；主題h1不再出現，但頁面原本的Elementor測試內容仍在。 本例Canvas前台保留編輯內容，移除主題的頁首、頁尾與頁面標題。 這和只隱藏一個標題是不同動作。官方Canvas說明，它會移除網站頁首、頁尾及側欄，適合某些不需要這些元素的獨立頁面。若你的目標只是讓內容較寬，同時保留網站導覽，就不要先切Canvas再另外複製整套頁首回來。 切換後也要確認原來由主題提供的必要入口是否消失，例如聯絡方式、返回主要頁面的導覽或頁尾資訊。頁面看起來比較乾淨，不表示訪客已經知道如何完成下一步；要依頁面用途決定是否保留這些內容。 Full Width與Canvas不要混用 官方Page Settings把Elementor Full Width描述為保留頁首與頁尾的全寬版面。Canvas則著重只呈現Elementor建立的內容。本例實際比較的是Default與Canvas，沒有把Full Width當成已操作過的第三組量測結果。 如果你需要保留主題頁首與頁尾，可以依官方說明在自有頁面試Full Width，再確認前台結果。若需要完全獨立的登陸頁，才評估Canvas。選擇的依據是哪些網站外框要保留，不是只看下拉選單裡哪個名字聽起來最寬。 此外，Page Layout與Container的Content Width是兩層控制。前者決定頁面模板，後者影響內容容器的寬度。如果容器仍是固定或受限寬度，換版型後內容也未必立刻填滿你預期的空間。先查是哪一層限制，再調整相應設定。 只改這一頁，先不要動全站預設 Page Settings是核對單頁行為的起點。官方另提供在Site Settings把Canvas設為預設版型的方式，但那是更大的範圍。只是想讓一張活動頁獨立呈現時，不必先把整站新頁面的預設一起改成Canvas。 如果網站用了Theme Builder或其他模板條件，還要查目前頁面實際套用哪個模板。官方Canvas與Full Width說明有Single Post Template的適用條件，不能只看文章內容在編輯器可見，就推定同一套網站外框一定仍會套用。 調整前可以先記下原Page Layout與Hide Title值，儲存後對照正式前台。若效果不符合用途，回到原版型再查標題或容器，不要連續疊加隱藏規則，把頁首、主題標題和內容Heading一起弄得難以辨認。 最後以訪客頁面核對 本例使用有權限的隔離本地草稿預覽，沒有把版型改到正式網站。你在自有網站操作時，應在儲存後重新載入相應頁面，確認導覽、頁尾、頁面標題與內容都符合目的。 如果頁首仍在，先看是否真的使用Canvas，或是否另有內容元件自行做了一份頁首。如果標題仍在，查它究竟來自主題還是Heading。把輸出來源分清，再修改負責它的控制，會比為了讓畫面空白而到處加隱藏設定更穩妥。 版型切換後也要看小螢幕 頁首與頁尾移除後，內容所在的寬度可能改變。原來依主題外框設定的卡片、圖片或按鈕，應在桌面與窄視窗再看一次。不要只確認沒有頁首，就忽略內容是否超出邊界或留下過大的空白。 如果這張頁面需要獨立導覽，可以在頁面內容裡安排清楚的返回入口和必要資訊；但不要在沒有需求時再複製一整份全站頁首。複製後的電話、地址和連結需要自己維護，不能假定它們會和主題頁尾同步更新。 同時確認頁面的主要標題仍能傳達用途。隱藏主題標題後，可以使用合適的內容標題，而不是只留下圖片與沒有說明的按鈕。乾淨的Canvas應服務頁面任務，不能讓訪客反而不知道目前在哪一頁。 參考資料Elementor：Page SettingsElementor：Page title selector與全域版型Elementor：Canvas版型Elementor：Canvas與Full WidthElementor：Full Width與主題頁首頁尾

在Elementor畫布上點一段文字，側欄卻一直選到外層容器；或圖片和按鈕疊在一起，滑鼠找不到要改的元件，這時可以先打開Structure。它把頁面列成階層樹，讓你從結構選項目，不必反覆在畫布邊緣尋找小小的操作把手。 這篇處理的是「選對層級」。先找到要修改的項目，再確認側欄名稱與內容，才進行設定。不要因為目前選不到元件，就先刪掉外層容器、解除定位或加大空白；那些改動可能讓原本正常的版面也一起受影響。 打開Structure並展開容器 官方目前把這個工具稱為Structure，網址仍保留navigator名稱。較早教學若寫Navigator，可能說的是同類結構工具，但操作入口應以你現在的編輯器為準。可以用編輯器的Structure按鈕開啟，也可以依官方說明從元素的操作選單進入。 本例使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five。頁面有一個外層Atomic Flexbox，裡面放傳統Container，再由這個Container放多個傳統元件。本文只用Structure選中項目，不把Atomic與傳統元件的設定欄位當成完全相同。 打開後若只看到一個容器，不代表頁面沒有其他內容。先展開它左邊的折疊控制，繼續找內層項目。若結構較深，可以使用介面提供的展開全部功能，但仍要留意縮排：展開所有項目，是讓它們可見，不是把原本的父子關係攤平成同一層。 用縮排找出父容器和子元件 本例選中內層Container後，側欄顯示Edit Container。它下面有六個子元件，依序是Heading、Heading、Heading、Image、Button和Heading。相同名稱出現多次是正常的；類型名稱告訴你它是標題，但不足以辨認是哪一段文字。 先展開父容器，沿縮排辨認它的子元件；側欄此時是Edit Container。 外層容器常負責整區寬度、方向或留白，子元件則負責各自的文字與圖片。當你要改標題內容時，應選Heading；要調整整排卡片的排列，才回到它們共同的父容器。選對層級後再改值，比改完才猜是哪一層生效更容易維護。 不要只看畫布上的藍色框就斷定選對了。巢狀容器可能有相似的範圍，尤其外層和內層都沒有背景時，邊界看起來很接近。Structure縮排、側欄名稱與實際內容一起核對，才能確定你現在修改的對象。 選子項目後，確認它的內容 接著在Structure選中本例第二個Heading，側欄改為Edit Heading，文字欄位顯示Author Heading Case B。這是我們要找到的元件。前後比較，父容器顯示容器控制，子Heading顯示標題內容，兩者沒有因為位置相近就變成同一組設定。 選中子Heading後，用側欄名稱和文字確認對象，再進行修改。 這些測試文字只是讓項目容易辨認，不是網站必須使用的名稱。你可以先選各個Heading，看Content欄位對應哪段文案；若準備修改的文字與欄位不同，就先停下來重新找項目，不要把錯誤欄位改成你想看的文字，掩蓋選錯元件的問題。 同樣的方法也適用於Image和Button。選圖片時看目前縮圖和附件，選按鈕時看文字與連結。若只是想改其中一顆按鈕，選外層容器後調整整區設定，通常不能替你改正那顆按鈕的目的地。 結構面板的眼睛不等於手機隱藏 官方Structure indicators說明，眼睛控制可在編輯器內顯示或隱藏項目，這個狀態不直接影響前台。它是協助你整理編輯畫布的工具，不應當成Responsive裡Hide On Mobile的替代方式。 若你要讓訪客看不到某個裝置的區塊，應使用實際元件的響應式控制並在儲存後前台核對。如果只是暫時把重疊元素從編輯畫面藏起來，好選到下面的元件，則先確認使用的是編輯器顯示控制，操作完成後再恢復便於維護的狀態。 這篇的實際案例沒有切換眼睛、重新命名或拖曳排序；只比較父容器與子Heading的選取結果。其他結構工具的行為應依官方說明及你自己的版本再確認，不把選中成功擴成所有功能都已操作完成。 找到元件後再處理真正的版面問題 選對層級只是診斷起點。如果元件被絕對定位、負margin或其他區塊遮住，Structure可以幫你找到它，卻不會自動修正造成重疊的設定。先保留原值，再查看該元件與父容器的定位和間距，才能知道哪個控制需要調整。 若一個元件的位置受父容器Direction或Wrap影響，應回到正確父容器查看Layout。不要為了讓它在畫布上移動，就在子元件塞入很大的margin；那可能只在目前寬度有效，換到手機又跑出邊界。 多層結構也不表示一定要把所有容器合併。某些內層容器用來分組文字與按鈕，具有實際排版用途。先理解每一層負責什麼，再決定是否精簡；避免只因為樹狀面板看起來很長，就刪掉仍在控制必要排版的層級。 改完回到前台核對 修改前先記下選中的元件與父層位置，修改後儲存並重新開啟前台。確認改的是預期標題或按鈕，附近內容也沒有被連帶影響。編輯器的選取框不會出現在訪客頁面，最後仍要看真實內容與版面。 如果交接給其他維護者，應描述元件所在層級與內容，不要只說「改下面第二個Container」。當頁面再插入一個區塊，位置就可能不同。清楚指出父區塊與目標內容，能讓下一個人更容易在Structure找到正確項目。 不要把選取和搬動混在一起 從結構列選中項目，是為了編輯它；拖動項目則可能改變順序或父容器。滑鼠操作時先點清楚列上的選取位置，不要在還沒核對對象時開始拖曳。若畫布內容突然改了順序，應先查看結構是否也改變，再決定是否復原。 頁面內容很多時，可以一次只展開正在處理的區塊，把其他不相關分支收起來。這樣較容易辨認目前的父容器和子項目，也避免同名Heading散落整張樹而選錯。折疊只整理操作視線，不能當成內容已從頁面刪除的證據。 參考資料Elementor：使用Structure導覽頁面Elementor：Structure狀態圖示Elementor：編輯器與容器／元件控制Elementor：建立容器與父子結構Elementor：容器Layout控制

Elementor的Image元件已經顯示圖片，卻沒有替代文字時，先到媒體庫核對它選用的附件。圖片標題、檔名、圖說與Alt Text不是同一個欄位；把圖片名稱寫得很完整，也不代表前台img已經輸出alt。 下面用免費版的傳統Image示範：在媒體選擇視窗填寫Alt Text，再儲存頁面並開啟前台預覽。真正要確認的是預覽頁的img元素，不只是媒體庫裡看起來已保存的欄位。這樣才能分清附件資料、編輯畫布與訪客收到的HTML。 從元件找到正確的圖片附件 本例環境是WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，使用傳統Container裡的Image。先選中該Image，在Content裡點圖片縮圖，開啟媒體選擇視窗。這個版本也有Atomic Elements，本文不把兩種元件的控制介面混在一起。 媒體庫裡可能有多張外觀看起來相同的圖，例如原圖、重新上傳的副本或另一個檔名的版本。先看選中項目的檔名和附件資料，確認就是頁面使用的那張圖。若你改的是另一個附件，即使Alt Text儲存成功，目前Image也不一定會讀到它。 這次使用獨立測試附件40，來源是一張尺寸測試圖，沒有改其他測試頁使用的附件。附件編號只用來追蹤本例，並不是你網站要照填的值。實際操作時，應以自己元件選中的媒體為準，不要照著文章的編號去找圖片。 替代文字描述用途，不是替檔案取名 在媒體視窗的附件資料找到Alt Text欄位，填入適合這張圖用途的描述。本例為了清楚辨認輸出，使用Author isolated resolution test pattern。這是測試圖的辨識文字；正式頁面應改成讀者需要知道的內容，而不是保留測試字串。 先確認選中附件，再在Alt Text欄位填寫描述。 不要把Title、Caption或Description當成Alt Text的代替品。圖說可以顯示在圖片下方，附件標題可用來整理素材，但它們不會因為文字相同，就自動變成img的alt屬性。也不要用一長串服務名稱或地區關鍵字，取代圖片本來要傳達的資訊。 同一張圖在不同文章裡可能有不同用途。圖片若提供重要資訊，替代文字應能傳達那份資訊；若只是裝飾，則要依頁面情境評估空alt。不能只因為所有圖片都能填Alt Text，就對每張圖貼上同一句宣傳文案。 儲存後看前台，不只看編輯畫布 填好資料並選回圖片後，本例編輯畫布中的img仍讀到alt空值。這個即時結果不能直接證明正式輸出失敗，也不能因為媒體欄位有字就直接認定完成。我們接著用Save Draft儲存，再重新開啟具有登入權限的本地草稿預覽。 在儲存後預覽裡，同一個Image的img輸出alt="Author isolated resolution test pattern"。它的圖片網址使用1024×683尺寸版本，而編輯畫布先前使用原圖網址；兩者都要靠選中的元件與附件關係辨認，不能只拿圖片網址是否完全相同判斷是不是同一張圖。 本例的title屬性仍是空值。這不妨礙alt已正確輸出，也說明Alt Text不等於滑鼠停留時一定出現提示文字。若你要放可見的圖片說明，應另外處理圖說，不要把讀者應直接看見的重要資訊藏在預期的懸停提示裡。 缺少alt與空alt要分開看 檢查HTML時，沒有alt屬性與明確的alt=""是不同狀態。MDN說明alt提供圖片的替代文字；空字串可用於不需要額外替代描述的裝飾情境。但是否裝飾，取決於圖片在這個頁面裡的用途，不能只看檔案本身。 W3C的Images Tutorial區分資訊圖片、功能圖片和裝飾圖片。按鈕或連結中的圖片，需要讓使用者知道操作目的；資訊圖片需要說明重要內容。圖片旁邊若已經有完整的相同文字，也要考慮避免重複朗讀，依實際結構選擇合適描述。 例如服務流程圖若只有圖中寫了步驟，單填「流程圖」可能不夠；純背景紋理則不必用一段文字逐項描述顏色。遇到內容較多的圖表，可以在正文提供可閱讀的完整說明，讓替代文字幫讀者辨認圖片與相關內容，而不是把整篇說明塞進一個屬性。 改完媒體庫，不代表所有位置都已同步 這個例子只確認選中的傳統Image，在本地儲存預覽輸出正確alt。它不證明網站上所有曾用過該素材的元件都已更新。不同元件、手寫HTML、另一份附件或已儲存的局部設定，都可能使用不同來源。 若要修整站的替代文字，應先列出實際使用位置，再逐個核對前台img。不能只改媒體庫一次，就把所有頁面都標成完成；也不要為了讓一個元件顯示正確，而直接刪掉大家共用的附件再重新上傳，造成其他頁面的引用失效。 遇到仍沒有alt的Image，先確認附件是否選對、頁面是否真的儲存、前台是否讀到最新版本，再查看這個元件有沒有另行保存自己的替代文字設定。排查順序應從實際輸出往來源追，避免只在不同欄位反覆貼同一句話。 最後核對圖片和描述是否仍對得上 換圖後也要回頭看Alt Text。舊圖片的描述可能還留在媒體或元件設定裡，畫面已換成團隊照片，描述卻仍是產品圖。這種情況即使HTML有alt，也沒有正確表達現在的內容。 儲存完成後重新開啟前台，確認圖片可載入、替代文字符合用途，圖說也與現在的圖片一致。替代文字能改善資訊取得方式，但不應承諾只填完一個欄位就一定提高搜尋排名。先把圖片對讀者的意義寫清楚，比堆砌關鍵字更有用。 把描述交接給維護者 多人一起維護頁面時，可以把圖片用途與目前使用位置記在素材紀錄裡。維護者換圖時，便知道哪些描述需要一起改；不要只留下檔名，讓下一個人猜這張圖原本是裝飾還是重要資訊。 如果素材被重複使用，則在交接時說明各頁用途可能不同。首頁的裝飾照片，放到人物介紹頁後可能變成有意義的內容。先理解使用情境，再決定替代文字，能避免把一個曾經合適的空alt直接沿用到所有地方。 參考資料Elementor：Image widget與媒體庫Alt TextElementor：加入圖片與附件資料MDN：img與altW3C：圖片替代文字教學W3C：裝飾圖片

在Elementor替按鈕填好網址後，點擊卻離開原頁，通常先看Link旁邊的選項。要保留原頁並開啟另一個頁面，需要設定連結的開啟方式，也要在儲存後的前台實際點擊。只看編輯器裡的按鈕外觀，無法知道訪客最後會去哪裡。 下面以免費版傳統Button連到https://example.com/為例。開啟Open in new window並儲存草稿後，前台連結具有target="_blank"；實際點擊會開出example.com的新頁，原預覽頁仍保留。這裡的網址是示範目的地，不代表你應把正式按鈕連到它。 先把目的地寫完整 本例使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，選中傳統Container裡的Button。先在Content找到按鈕文字和Link欄位，確認選的是你要改的那顆按鈕，尤其同一頁有好幾個相似按鈕時，不要只憑畫面位置猜。 外部網站可以先填完整的https網址，再核對域名、路徑與必要參數。漏掉路徑、貼到測試站地址或多貼空白，都可能讓按鈕開啟錯誤頁。開新視窗只能改開啟位置，不能修復目的地網址；不應為了讓按鈕有反應，隨便先填一個看起來相似的首頁。 同頁錨點、電話、電子郵件與檔案連結是不同用途。它們都可能放在Link欄位，但點擊後的結果不同。如果目標是讓訪客繼續完成本站流程，先確認是否真的需要開新頁，而不是一律對所有按鈕使用相同開啟方式。 從Link旁的齒輪開啟選項 填好Link後，點它旁邊的齒輪圖示。本例的連結選項裡有Open in new window，將它開啟。這個設定通常對應連結輸出的target屬性，不能只用按鈕顏色或游標樣式判斷。不同版本、不同種類的元件，欄位位置或名稱可能改變，應看目前側欄實際提供的控制。 傳統Button的連結選項；設定後還要儲存並到前台核對。 不要把同一區裡的其他選項也一起打開。nofollow處理的是連結關係，不是開新頁；Custom Attributes則是另一種輸出屬性控制。只想保留原頁時，先處理Open in new window，再依實際需求另外核對其他屬性，會比較容易找到問題來源。 如果你是在Text Editor裡替一段文字加連結，操作入口可能不是這個Button的Link欄位。官方對自訂連結屬性也有適用元件範圍，不能把Button的選單套到所有文字連結。先辨認元件與連結來源，避免在錯誤的側欄找設定。 儲存後，核對真正的前台連結 本例使用Save Draft儲存隔離本地頁面，再開啟具有登入權限的草稿預覽。編輯畫布中的按鈕連結已是https://example.com/，但當時DOM讀到的target和rel都是空值。儲存後前台的同一個按鈕，href保持相同，target則是_blank。 這個差異說明，不能拿編輯畫布的DOM直接代替前台輸出。編輯器為了方便選中與修改元件，可能使用不同的互動方式。你應在重新載入的前台找到真正的a元素，確認href指向正確目的地，再看target是否符合設定。 即使前台已經有_blank，仍要實際點一次。本例確實開出example.com的新頁，原草稿預覽仍留在原網址。瀏覽器可依自己的設定把新瀏覽內容放在分頁或視窗，所以「Open in new window」不是保證一定出現另一個獨立桌面視窗。 開新頁與rel屬性分開看 本例前台的rel讀值仍是空值，因此這個操作結果只證明開新頁，不把它寫成已自動加入noopener、noreferrer或nofollow。若網站對外部連結有特定規則，應查看實際輸出的屬性，再依官方提供的欄位與自己的版本功能處理。 MDN說明現代瀏覽器對target="_blank"有隱含noopener行為；但這不表示HTML必定會明寫rel="noopener"。行為、原始屬性和你的站點規範是不同層次。本例沒有另外量測window.opener，不把官方通則冒充這顆按鈕的額外實測。 官方Custom Link Attributes說明可使用key|value格式加入連結屬性，並以空白分開同一rel裡的多個值。如果你要使用這種方式，先確認元件提供該欄位，儲存後再讀前台結果。不要把HTML語法直接貼進網址欄，也不要為了加入一個屬性而覆蓋原有必要值。 點擊沒有照設定開啟時，先查儲存版本 先重新載入前台，確認測的是最新儲存頁，而不是還留著舊內容的分頁。再找到正確按鈕，比對文字、href和target。如果頁面有桌面與手機兩份按鈕，可能只改了其中一份；另一份外觀看起來一樣，卻仍使用舊設定。 如果a元素的屬性已正確，但點擊仍走到不同位置，要查看是否有其他腳本攔截點擊、整張卡片另外包了連結，或上層元素擋住按鈕。本篇的普通Button例子不包含這些額外互動，不能只靠一個成功例子排除你網站的所有插件影響。 不要先連續改網址、關開新頁選項、加自訂腳本又清理全部設定。先保存目前值，逐項核對輸出和點擊結果。每次只調整一個相關控制，比把多個選項一起更動，更容易知道是哪一個設定解決了問題。 也替訪客確認這個選擇是否合適 外部文件或另一個服務平台，可能適合保留目前頁面；本站的下一步表單則可能更適合沿原流程進行。按鈕文字應清楚表達目的地或動作，必要時提示會開新頁，讓訪客知道點擊後會發生什麼。 最後使用滑鼠及鍵盤各核對一次，確認按鈕可聚焦、可啟動，目的地也正確。開新頁不是連結品質的全部：錯誤網址、過時內容或含糊的按鈕文字，即使成功出現另一個分頁，仍會讓訪客無法完成原本的事情。 複製按鈕後再查一次目的地 從另一張卡片複製按鈕，可以保留樣式，但通常也會保留當時的網址與開啟選項。把文字從「了解方案」改成「聯絡我們」之後，Link未必跟著換成聯絡頁。修改按鈕文字時，應同時查看實際網址，不能把文案變更當作目的地已更新的證據。 若網址含有查詢參數，也要確認那些參數是否仍屬於新按鈕的用途。不要把另一項服務的識別值一併帶過來，造成表單預選或追蹤對象錯誤。這些檢查不需要先增加新程式，只要逐項看清楚原有連結內容，便能避免許多複製後遺留的問題。 參考資料Elementor：Button widgetElementor：自訂連結屬性Elementor：Link齒輪與開新視窗選項MDN：a連結元素與targetMDN：noopener

做好第一張服務卡片後，複製它再改標題，是Elementor很常見的操作。第二張看起來和第一張一樣，並不表示兩張共用同一份文字。如果你修改副本後，原件沒有跟著更新，先確認使用的是普通Duplicate，還是特別建立的共用元件；這兩種做法的維護方式不同。 下面用免費版的傳統Heading示範普通複製。原件和副本一開始顯示相同文字，改副本後，原件仍保留原文字。這種獨立性適合做不同服務或不同方案的卡片；要讓所有頁面的聯絡資訊一起更新，則需要另外規劃共用內容，不能只靠複製。 先確認你複製的是哪一層 這個例子使用WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，選的是傳統Container裡的一個Heading。新版介面也有Atomic Elements，操作入口可能不同。先看側欄的元件名稱與Structure位置，確定你要複製的是標題、整張卡片，還是包含多張卡片的外層容器。 只複製Heading，不會順便建立它旁邊的圖片和按鈕。複製整個容器，則會帶出裡面的多個子元件。你若只看到兩個相同標題，卻沒有第二個按鈕，先回到Structure看實際層級，不要再連續複製幾次，讓畫面裡出現更多不知道屬於哪張卡片的元件。 在本例，對Heading開啟操作選單並選Duplicate，Structure出現另一個Heading。兩個項目都有各自的元素識別值；這些識別值用來找到目前選中的元件，不是讀者應照填的內容，也不表示兩個元件建立了同步關係。 改副本的文字，再回頭看原件 複製之前，原Heading的文字是Author Heading Case B。複製後，原件與副本都顯示這段文字。接著只選副本，在Content裡把文字改成Author Independent Duplicate；編輯完成後，原件仍是Author Heading Case B，副本則顯示新文字。 普通Duplicate建立獨立副本；選中副本改字後，原件保留原內容。 這裡用容易辨認的測試文字，是為了排除兩個標題很相似而看錯的情況。你在自有測試頁可以先用兩段明顯不同的短文字做同樣核對，再換回正式文案。若原件也變了，先查是否選錯項目、是否使用了其他共用功能，或是否其實在修改整個頁面套用的設定。 不要只看側欄文字欄位就認定完成。修改後先看畫布中的副本，再選回原件看它的Content欄位。儲存頁面後重新開啟前台，也要確認兩個位置各自顯示正確文字；編輯器裡的即時畫面與訪客最後收到的儲存版本，需要分別核對。 一開始樣式相同，不等於永遠同步 普通複製通常會保留當時的內容與設定，所以字級、顏色和間距起初可能完全一樣。後來你只改副本的一個局部欄位，另一個元件不跟著改，是合理的行為。這也是為什麼複製可以當作製作下一張卡片的起點，卻不能當作持續同步的方案。 另一方面，兩個元件若都使用同一個Global Color或Global Font，修改那個全域樣式來源，可能影響兩者。這不表示兩份文字變成同一份，也不表示Duplicate突然建立內容連結。診斷時要分清：你正在改元件本身的文字或局部樣式，還是在改它們共同使用的全域樣式值。 例如第一張卡片是網站架設、第二張是網站維護，內容應分開；品牌色可以共用。若把品牌色直接改成兩種不同的局部顏色，之後調整品牌時就需要逐張查。反過來，為了讓兩張卡片使用相同顏色，也不需要讓它們的服務名稱和說明全部共用。 Global Widget是另一個功能 Elementor官方另外介紹Global Widget，用來在多個位置使用同一個元件，並集中修改。這是與普通Duplicate不同的功能，而且屬於Pro範圍。免費版看不到相同入口時，不應把它當成複製失敗，也不應照著另一個版本的選單硬找。 這篇的操作例子只驗證免費版普通Heading的獨立副本，不把Pro的集中修改當作本例已操作過的結果。如果你有Pro並準備使用Global Widget，應先讀官方目前的建立、編輯與解除連結方式，在自己的測試頁確認哪些位置會一起變，再拿來放價格或聯絡資訊。 也不要把儲存為Template、複製貼上、全域樣式和Global Widget當成同一件事。它們可能都能減少重複工作，但複製出來的內容是否仍有連結，要依實際功能判斷。不能只因為第二個元件是從第一個做出來，就推定未來會同步。 副本要核對的不只標題 把一張服務卡片複製成另一張時，標題只是第一個要改的地方。圖片替代文字、按鈕文字、連結目的地、價格與補充說明都要逐一確認。畫面看起來已經是新服務，但按鈕仍連到舊服務，是比副本沒有同步更容易被忽略的問題。 如果元件填過CSS ID，也應檢查複製後是否出現重複識別值。需要由錨點、腳本或樣式精確找到的元素，不能只看外觀相同就保留同一個ID。這不代表每個元件都必須自己設定ID，而是你原本有依賴它時，要把識別值也列入副本核對範圍。 最後，儲存後重新開啟前台，確認兩張卡片內容、順序與連結都正確。普通副本的好處是可以獨立調整；代價是共通資訊變更時，你要知道哪些地方有副本。如果常常需要在很多頁更新同一句話，應先整理共用內容的需求，再選合適的功能。 讓後續維護找得到每個副本 如果頁面有好幾張相似卡片，可以在Structure使用容易辨認的名稱，並把共通資訊的出現位置記下來。名稱是幫你選對項目，不能取代內容核對。尤其是複製整區時，裡面的標題、圖片和按鈕都可能保留原設定；不要只替外層改名稱，就認為子元件已完成修改。 準備更新價格或電話前，先決定這些資訊應該每張卡片不同，還是所有位置相同。需要各自不同的內容，普通副本很方便；需要一致的資訊，則應評估共用功能與自己的版本權限。不要等到多個頁面出現不同舊電話，才回頭猜哪些元件原本是複製出來的。 參考資料Elementor：元素操作選單與DuplicateElementor：Global WidgetElementor：全域顏色Elementor：全域字型MDN：HTML id

桌面需要一段說明，手機卻想把它收起來，Elementor的Hide On Mobile常能處理這種需求。不過，編輯器裡還看得到元件、手機前台留下空白、或HTML仍有那段文字，分別代表不同事情。先確認你希望改的是顯示、版面空間，還是內容是否送到瀏覽器，才不會用錯設定。 下面以一個傳統Heading為例，儲存後用390像素的前台草稿預覽核對。開啟手機隱藏後，該元件的計算樣式變成display:none，高度歸零，下面的按鈕往上移；但元件仍存在HTML中。這個結果可以證明它已收起版面，不能證明資料已從頁面移除。 本地Free 4.3.3傳統Heading的手機隱藏設定；效果另在儲存後的前台預覽核對。 先選到要收起的元件 本例環境是WordPress 7.1.2、Elementor Free 4.3.3及Twenty Twenty-Five，使用傳統Container裡的Heading。這個版本也有Atomic Elements，本例不把兩種元件的介面混在一起。你應先選中真正要隱藏的標題或卡片，再看側欄目前顯示的元件名稱。 如果你選的是外層容器，隱藏它可能連同裡面的標題、圖片與按鈕一起消失。只想收起一段補充文字時，應先核對Structure裡的層級，確認選中的是那段文字。不要為了把一個標題藏起來，把整區容器設成手機隱藏，再另外複製按鈕到另一個區塊。 選中本例的Heading後，進入Advanced，展開Responsive，可看到Hide On Desktop、Hide On Tablet Portrait與Hide On Mobile Portrait。本例只開啟手機選項，另外兩項保持原狀。欄位名稱依裝置與版本可能不同，先看你的實際控制，不要把平板與手機當成同一個開關。 編輯器看得到，不代表設定失效 這個介面有提示：響應式顯示效果應在預覽或實際頁面核對，不能只看編輯模式。編輯器保留操作入口，是為了讓你還能找到元件、改字或關閉隱藏設定。因此開關打開後，畫布仍出現該元件時，先儲存並開啟前台預覽，再判斷是否真的沒有生效。 在本例，我們使用Save Draft保留頁面，再重新開啟有登入權限的草稿預覽。這仍是隔離本地頁面，沒有部署到正式網站。將預覽視窗設成390像素後，找到同一個Heading與它下面的按鈕，才能前後比較同一組元素。 也別把編輯器裡的眼睛圖示、元件透明化或拖曳時的淡色狀態，直接當成正式顯示結果。這些可能只是編輯工具的呈現。要確認訪客是否看得到，應以儲存後前台對應寬度的實際元素與計算樣式為準。 本例的空間確實收起來了 隱藏前，390像素預覽中的Heading是display:block，高度約84.84px，下面按鈕的頂端位置約679.66px。隱藏後，Heading變成display:none，高度為0，按鈕頂端改為約554.81px。元件高度和它參與排版時的間距不再把後方內容往下推。 這些數字只是本例版面的位置，不是你網站應照填的間距。標題文字、容器gap、字級、行高與頁首都會改變座標。真正有用的比較，是同一個元素在同一寬度下，隱藏前後是否還生成版面盒子，以及後方內容是否回到合理的位置。 切回1280像素預覽時，本例Heading仍是display:block。這確認我們只修改手機顯示，沒有把桌面也收起來。但如果你的站點改過斷點，應依實際斷點再核對，不能只憑裝置名稱或螢幕外觀，斷定某個視窗一定使用手機設定。 還有空白時，查外層容器與其他留白 如果標題已經display:none，頁面卻仍留下大段空白，先看外層容器是否有固定高度或min-height。隱藏內部文字，不會自動移除外層明確設定的高度。也要查看padding、margin、其他Spacer與容器裡是否還有另一個可見元素。 此時不要先加負margin把下面內容拉上去。負值可能只在目前文字長度下看似正常，換成別的語言或增加一行內容，便和前一區重疊。先確認是哪個盒子真的占空間，再調那個盒子的設定，會比較容易保留桌面原來的版面。 用瀏覽器開發者工具檢查時，可以先選Heading，再沿父元素向上看。辨認是哪一層仍有高度、背景或邊框，而不是只看文字是否消失。如果父容器還要保留其他內容，就應保留它，只移除不再需要的最小高度或多餘留白。 透明、不可見與不排版要分清 把opacity設為0，通常只是讓內容透明，它仍可能占空間；visibility:hidden也與display:none的排版結果不同。手機隱藏的目標若是把整段收起來，應核對實際display，而不是只追求截圖中看不到文字。本例的opacity一直是1，真正改變的是display。 反過來，如果你需要保留原本空間，只暫時不顯示內容，也應先確認選用的方式與目的相符。不要在同一元件疊加透明度、手機隱藏和負margin後，再猜哪個開關造成目前效果。一次處理一個控制，前後對照才清楚。 本例隱藏後仍能在DOM找到原文字，因此這不是移除內容或權限控制。敏感資料不應先送出再靠CSS藏住，也不能只靠手機隱藏就保證圖片或相關程式不會載入。本次沒有量測資源請求與效能，若目的是降低載入量，還要另外檢查實際網路請求。 先決定手機上是否仍需要這段內容 隱藏前先問這段資訊的用途。如果它是付款條件、服務範圍或聯絡方式，手機訪客可能和桌面訪客一樣需要閱讀。這種情況可以先縮短文案、調整字級或改變排版，而不是直接收起。若它只是桌面上的重複裝飾文字，收起後則應確認手機仍有主要標題和清楚的操作入口。 若頁面原本就有兩份不同裝置的內容，也要分別檢查維護範圍。修改桌面那一份，不表示手機另一份會跟著更新。不要把本次成功隱藏元件，當成兩份內容已同步的證據；下次改價格、地址或活動日期，仍要找到每個實際顯示的副本。 最後，儲存後重新載入手機與桌面前台，確認隱藏對象正確、必要按鈕還在、空間沒有異常，也確認手機使用者仍能取得完成任務需要的資訊。只因為手機版比較短就把重要說明收起來，可能讓訪客反而不知道下一步如何操作。 參考資料Elementor：Advanced與Responsive控制Elementor：手機與平板響應式編輯MDN：displayMDN：opacityMDN：visibility

在手機預覽把標題縮小，回到桌面卻發現文字也變小，先不要補一段CSS把它壓回去。要先確認剛才修改的欄位支援裝置分別設定，以及欄位旁當時選的是哪個裝置。編輯器上方切到手機，和每個屬性都有手機專用值，是兩件需要分開核對的事。 下面用傳統Heading元件的Typography Size示範：桌面48px、平板36px、手機28px。接著清空手機值，觀察它重新使用平板36px，而桌面仍維持48px。這個對照能幫你找出值來自哪一層，避免在三個裝置之間來回改到失去原先設定。 本地Elementor Free 4.3.3的傳統Heading：清空手機字級後，欄位以繼承值提示36，畫布也使用36px。 先分清元件版本與控制範圍 本例使用隔離的WordPress 7.1.2、Elementor Free 4.3.3與Twenty Twenty-Five主題。頁面放了傳統Container及Heading；同一版本也能看到Atomic Elements，但這裡沒有用Atomic Heading。若你的側欄、控制名稱或樣式系統不同，先辨認元件類型，不要只按產品版本號尋找完全相同的畫面。 選中標題後，進入Style，展開Typography，找到Size。確認數值旁有裝置控制，再看上方目前選中Desktop、Tablet Portrait或Mobile Portrait。遇到沒有裝置控制的欄位，不應假設它會因為畫布變窄，就自動儲存一份手機專用設定。 標題文字、HTML標籤與字體大小也要分開。你只是要調手機顯示大小時，應修改Size，不必把H2改成H3，更不必複製三份標題再用隱藏開關切換。這種複製方式會增加內容維護，也容易讓同一段文字在不同位置逐漸不一致。 從桌面開始，留下可比較的值 先選Desktop，把Size設為48，單位使用px。記住原值和所選元件，接著切到平板，先不要輸入。觀察欄位是否已有明確覆寫，或只是提示較大裝置的值。本例平板尚未填值時，輸入欄位的實際值是空的，但標題仍以48px顯示。 這一步很有用：空欄位不等於字級零，也不等於完全沒有樣式。實際效果可能來自較大裝置的設定、元件樣式或主題。若只看到空欄就填入一個猜測值，雖然暫時能讓畫面變小，卻把原來的繼承關係改成了獨立覆寫。 本例接著在平板填入36px，畫布字級成為36px，再切到手機。手機還沒有獨立值時，畫布也顯示36px。此時不要以為桌面48已失效；回到Desktop，它仍是原來的48。你看到的是不同寬度下，各自適用的設定。 手機覆寫與清空是兩種操作 在Mobile Portrait輸入28px，本例標題立即以28px顯示。這是手機自己的覆寫值；平板36與桌面48並沒有跟著改變。若手機需要特別緊湊的版面，可以保留這個值，但應順便檢查標題換行、行高與下面內容的距離，不能只看數字有沒有變小。 接著清空手機Size欄位並離開欄位，本例畫布回到36px。這個36來自已設定的平板值，因此清空不代表還原到桌面48。若你想讓手機直接使用48，也要先檢查中間的平板設定；不能只清手機，便期待它跳過仍存在的平板覆寫。 同樣地，清空與填入0不同。填入0可能仍是一個明確的值；清空是在這個控制上移除本例的手機數值覆寫。不要用0模擬繼承，也不要為了測試單一標題，重設整份Typography或全站樣式。先處理Size這個欄位，才容易確認改動的原因。 用儲存後的前台重新驗一次 編輯器畫布方便比較，但文章完成前仍應儲存，再開前台預覽。本例先Save Draft，重新開啟有登入權限的草稿預覽，分別使用1280、900與390像素視窗。手機覆寫已清空，所以測得的字級依序是48px、36px與36px，與編輯器最後狀態一致。 這裡的預覽仍是本地草稿，沒有公開部署。數據也只證明這個Heading及目前控制設定的結果，不能推論所有元件、所有主題或額外斷點都遵循同一份數字。真正要修的網站仍要在儲存後，重新核對自己的前台與實際使用的斷點。 若前台與編輯器不一致，先確認是否儲存了這次變更、預覽是不是同一頁，以及樣式檔是否正常載入。再查看是否有主題樣式或自訂CSS覆蓋字級。不要只在編輯器連續加大數字，因為樣式檔未更新時，這樣可能只是累積更多互相矛盾的設定。 若改手機卻影響桌面，沿同一欄位回查 先回Desktop查看Size的實際數值，再回Mobile查看手機欄位。如果桌面數值已變，先還原你記下的原值，再重新選手機裝置，確認是在同一個Heading的Size輸入。不要一邊換元件、一邊換裝置，否則很容易把另一個標題的設定誤認成同一份資料。 如果桌面值沒變，但畫面看起來變了，也可能是標題換行造成高度不同。將文字內容、字級、行高與容器寬度逐項比較，先找出真正不同的項目。把容器縮窄會改變一行能容納的文字，不代表字級本身已改；只憑標題占了幾行，不能判斷哪個裝置值被覆寫。 還要確認單位一致。本例全程使用px，方便對照48、36及28；若你使用相對單位，就需要連同它參照的條件一起看。不要把不同單位的數字直接比較大小，也不要在追查問題時同時更換單位，否則前後的差異便不只來自裝置覆寫。 不要把裝置名稱當成實體設備保證 本例介面標示平板上限1024px、手機上限767px，但網站可以自訂斷點，裝置名稱本身不能保證某一台手機一定套用哪個設定。判斷時要看瀏覽器的視窗寬度與站點斷點，而不是只憑手機型號、截圖縮放比例或螢幕像素數推測。 Elementor的開發者文件也把響應式值視為不同裝置的設定資料，並由響應式控制產生相應CSS。這有助於理解為何同一個元件會保存多份數值，但一般編輯時不需要手動改資料庫中的裝置鍵名。直接使用目前元件提供的控制，會比較容易保留正確格式和單位。 修好後留下三項記錄即可：桌面值、平板是否覆寫、手機是否覆寫。下一次調桌面字級時，就知道哪些較小裝置還會跟隨，哪些需要另外檢查。對有多人維護的網站，這比只記一句「手機已修好」更能避免後續改版再次把字級弄亂。 參考資料Elementor：響應式編輯與斷點Elementor：傳統Heading控制Elementor Developers：響應式控制Elementor Developers：響應式資料MDN：媒體查詢與視窗條件