Skip to content
Articles

【1招解決】WordPress 6.6 更新導致連結被加上底線 underline

WordPress 6.6 更新? WordPress 6.6 於 2024 年 7 月 16 日正式發布,帶來了多項改進和新功能。然而,這次更新也帶來了一些意外問題,其中一個最明顯的問題就是所有頁面上的連結都被加上了下劃線(text-decoration)。 為什麼連結都加了下劃線? 這個問題的根本原因在於 WordPress 6.6 引入了一個新的 CSS 規則,優先級比現有的主題樣式更高,從而覆蓋了所有主題的設置。具體來說,WordPress 6.6 注入了以下 CSS: 這一行 CSS 導致了所有頁面上的連結都被強制加上了下劃線。 社區關注及討論 問題報告 這個問題已經在 WordPress 社區中引起了廣泛關注,並且有多個相關的支持話題和問題單被提交和討論。例如: 官方回應 根據官方的回應,這個問題會在 6.6.1 版本中得到修復。因此,無論你是選擇暫時不更新、等待修補版本,還是手動修改 CSS,都有相應的解決方案。 解決方法 先不要更新⋯ 如果你還沒有更新到 WordPress 6.6,那麼最簡單的方法就是暫時不要更新。等待官方發布 6.6.1 修補版本後再進行更新,這樣可以避免受到這個問題的影響。 等待修補 如果你已經更新到了 WordPress 6.6,可以選擇等待官方的修補版本。根據官方的說法,這個問題會在 6.6.1 版本中得到修復。因此,耐心等待幾天,等到新版本發布。 6.6.1 預計會 7 月 23 號發佈。 修改主題文件 如果你能夠修改代碼,則可以通過修改主題文件來解決這個問題。在 wp-content/themes/YOUR-THEME/theme/theme.json 文件中添加以下內容: 這樣可以覆蓋掉 WordPress 6.6 引入的 CSS 規則。 添加自定義 CSS 如果以上方法仍然無法解決問題,可以通過添加更具優先級的 CSS 來強制覆蓋樣式。在你的主題的自定義 CSS 中添加以下代碼: 這樣可以確保連結不再被強制加上下劃線。 總結 希望通過本文提供的解決方案,能夠幫助你快速解決連結加下劃線的問題,並繼續順利使用 WordPress。

分享我常用的 Command

我的日常工作通常都在 MacOS 上處理,也有時需要透過zsh登入 SSH 管理主機,絕大多數也是 Linux based. Sum with awk:懶得按再計數機,直接給我總和吧! 經常需要上載下載備份/傳送 zip 檔,必然是用 tar 檔吧!有時會記不起 cvzf… Create tar file: Create tar.gz with folder Extract tar file to current directory: Search content in file:這句應該不用告訴你吧?太常用了! Find files that changed in the last 24 hours:方便找回最後被改動過甚麼檔案 Find files with ≥ 500MB:

AWS RDS – CreateDBInstance Operation in AWS Cost and Usage Reports 成本和用量報告

最近的工作是減少現有 AWS 資源成本,目標是減少 40% 的總開支。需要研究每種 Resources,以至每個 Operation 相關的支出成本。 剛好在處理 RDS 部份,見到有一項 CreateDBInstance:xxxx,因為同一地區內有很多使用中的 RDS,無辦法猜到 Database 源頭是哪裡。AWS 官方文件好像也未有明確列出所有項目,所以在此記錄一下,方便大家時,也方便自己之後有需要時回來看。 Operation Name Description CreateDBInstance:0002 MySQL CreateDBInstance:0003 Oracle Standard Edition 1 (Bring Your Own License) CreateDBInstance:0004 Oracle Standard Edition (Bring Your Own License) CreateDBInstance:0005 Oracle Enterprise Edition (Bring Your Own License) CreateDBInstance:0006 Oracle Standard Edition 1 CreateDBInstance:0008 SQL Standard Edition (Bring Your Own License) CreateDBInstance:0009 SQL Enterprise Edition (Bring Your Own License) CreateDBInstance:0010 SQL Express Edition CreateDBInstance:0011 SQL Web Server CreateDBInstance:0012 SQL Standard Edition CreateDBInstance:0014 PostgreSQL CreateDBInstance:0015 SQL Enterprise Edition CreateDBInstance:0016 Aurora MySQL CreateDBInstance:0018 MariaDB CreateDBInstance:0019 Oracle Standard Edition 2 (Bring Your Own License) CreateDBInstance:0020 Oracle Standard Edition 2 CreateDBInstance:0021 Aurora PostgreSQL CreateDBInstance:0022 Amazon Neptunen CreateDBInstance:0023 Amazon DocumentDB CreateDBInstance:0028 IBM Db2 (Bring Your Own License) CreateDBInstance:0402 SQL Server SE (AWS-provided media) CreateDBInstance:0403 SQL Server Ent (AWS-provided) AWS API Reference: https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html

JavaScript Framework 最新動態 (2024 May)

隨著 JavaScript 框架的持續發展,跟上所有最新動態可能會非常困難。Google I/O 2024 有提到現時各大 JavaScript 框架的發展趨勢,這篇文章是個濃縮版,總括過去一年 JavaScript 框架生態系統中的一些重要事件。若想深入了解這些主題,可以參考今年 Google I/O 活動中的 Navigating the JavaScript Frameworks Ecosystem 相關演講 (片長 42分34秒)。 Framework 趨勢及功能 Common Features Angular Astro Next.js Remix Nuxt SolidStart SvelteKit Component-based ● ● ● ● ● ● ● Virtual or Incremental DOM ● ● ● ● ● ● SSR Support ● ● ● ● ● ● ● Static Site Gen ● ● ● ● ● ● ● File-based Routing ● ● ● ● ● ● TypeScript Support ● ● ● ● ● ● ● Reactive ● ● ● ● ● ● Recent Trends Fine-grained Reactivity ●(Signals) ●(Forget) ●(Forget) ●(shallowRef) ●(Signals) ●(Runes) Partial Hydration ● ● ●(partial prerendering) ● Server Components ● ● Image Component ● ● ● ● ● 從圖表中可以看出,JavaScript 框架在許多相似的特性和架構上趨於融合。這些特性包括基於組件的架構、基於文件的路由和現代伺服器端渲染(SSR)支持。這種融合展示了生態系統的成熟和演變,各框架相互學習並採用最佳實踐。 與此同時,一些最近的趨勢(e.g. server components and fine-grained reactivity methods)繼續使各個框架有所不同。為了更好地理解這些趨勢,我們將逐個框架深入探討。 Angular Angular 最近的版本包含了多種重要的變化,包括信號、可延遲視圖、NgOptimizedImage、無損水合和部分水合。以下是一些亮點: Astro Astro 是一個現代靜態網站生成器,憑藉其創新的 Web 開發方法引起了廣泛關注。Astro 注重性能和開發者體驗,推出了多項令人興奮的功能和更新: React 去年,React 伺服器組件的發布引入了一種新的 React 組件方法。此後,React 團隊一直致力於各種新功能,包括 React 編譯器和伺服器操作功能,以及: Remix Remix 是一個全棧 Web 框架,正迅速在開發者社區中獲得認可。Remix 注重 Web 基礎和增強的開發者體驗,推出了多項顯著更新: Next.js 2023 年 5 月發布的 Next.js 13.4 尤其值得注意,因為它帶來了對 React 伺服器組件、流式傳輸和 Suspense 的穩定支持。此後,Next.js 繼續建立對新 React API(例如 Server Actions)的支持,並通過像 Turbopack 這樣的項目來改進開發者體驗。其他亮點包括: Vue Vue 最近的版本 Vue 3.4 包含了多種性能改進。Vue 目前也在開發 Vue Vapor,一種以性能為導向的模式。以下是一些亮點: Nuxt Nuxt 即將發布 Nuxt 4。除了 Nuxt 過去一年的頻繁框架發布,Nuxt 模塊生態系統已增長到近 220 個模塊。這一領域的一些最新發展包括: Solid Solid 一直在努力向其元框架 stable 1.0 release 版本邁進。SolidStart 具有細粒度反應性、同構路由以及支持多種渲染模式。亮點包括: Svelte 過去一年中,Svelte 團隊一直專注於即將發布的 Svelte 5,這將是一個重要的版本。其他亮點包括: Chrome Aurora Chrome Aurora 是 Google 的一個團隊,與各種開源 Web 框架合作,以改進用戶體驗——特別是性能。以下是我們過去一年貢獻的一些項目: 結論 JavaScript 框架生態系統繼續以快速的速度發展,每個框架都帶來了一套創新和改進。無論您對成熟框架(如 Angular、React 和 Vue)的最新功能感興趣,還是探索較新的選擇(如 Astro、Remix 和 Solid),都有很多令人興奮的發展值得關注。 作為開發者,了解這些進展有助於我們在選擇項目框架時做出明智的決定。通過了解每個框架的優勢和獨特特性,我們可以選擇最符合項目需求和開發偏好的框架。 希望這篇文章能夠為讀者提供 JavaScript 框架當前狀況的一瞥。同時亦建議查看 Google I/O 的相關演講,深入了解這個主題。謝謝!

Text Fragments 使用「:~:」分隔竟然是這個原因?!

相信大家 highlight 網頁文字並點擊右擊時,都會用過「Copy Link to Highlight」。複製出來的是一抽很長的 URL。例如: 會見到 :~: 這個符號作分隔。今日我深入研究這個符號時,竟然發現原來當初草擬是這樣決定⋯ Text Fragments 的背景 為了讓使用者能夠輕鬆地鏈接到網頁中的特定內容,WICG 提議增加支持在URL中指定文本片段的功能。當導航到這樣的URL時,瀏覽器能更精確地理解用戶對目標頁面感興趣的內容。這可能提供更好的體驗,例如:視覺上要強調、自動將其滾動到視圖中或允許用戶直接跳轉到該文本。 當前的Web標準已經支持滾動到帶有name屬性的錨元素和帶有id的DOM元素,當導航到一個Fragment時。雖然命名的錨點和帶有id的元素能夠支持滾動到網頁的特定部分,但不是所有文件都使用這些元素,也不是所有頁面的部分都可以通過命名錨點或帶有id的元素來定位。 目前 Text Fragments 這個功能已在Chrome M80穩定版本中推出。 實際情境 在跟隨鏈結閱讀網頁的特定部分時,導航後找到相關文檔部分可能很麻煩。在 mobile 上,這尤其困難,因為在長頁面滾動或使用瀏覽器的“頁面內查找”功能時,找到特定內容可能很困難。少於1%的客戶在Android上的Chrome使用“頁面內查找”功能。 為了讓用戶更快地找到他們感興趣的內容,所以才有提議將現有的基於片段標識符滾動到元素的支持推廣。若好好利用在搜索引擎結果頁面、分享維基百科參考鏈結時,會有很好的 UX 體驗。 Syntax 定案 [括號] 是 optional 而這個 Syntax 需要考慮到 針對以上第2點,就有人提議用 ##符號作分隔,但不符合 URL spec 而且造成 invalid code point,所以反快被駁回: On navigating to https://example.com/#hash##targetText=test, the UA would process the targetText and change the document’s URL to https://example.com/#hash. We’d want to avoid modifying the session history in this case. I think we’d also want to avoid firing hashchange as well (moot at this point as we only process targetText on full navigations for now; this would happen before author JS has a chance to run). 而且 Use counters we added to Chrome in M77 showed that, on Windows, about 0.08% of page loads already have a # character in the fragment. While small, that’s a non trivial percentage. 儘管現有的HTML支持直接在片段中指定目標元素的id和name屬性,但大多數其他mime類型都在片段中使用這種x=y模式,例如媒體片段(例如#track=audio&t=10,20)、PDF(例如#page=12)或CSV(例如#row=4)。似乎用 id 或 name 作定位雖然可行,但 WICG 並沒有採納這方案,似乎想更 standardize 這事情。 考慮過的方案 事實上,WICG 就有考慮過以下選項: 以下更 verbose 的也被曾納入考慮: WICG 根據過去 5 年的 Google Search Crawler 記錄,按照網址使用率剔除了部份選擇。而 verbose 的選項未曾在互聯網使用,其實是可以用。不過由於希望更短、更簡潔有效的方式,所以按優先度選擇純符號的選擇。 根據統計所得: While this doesn’t guarantee compatibility, it did give us some confidence. We chose :~: from this list somewhat arbitrarily. However, we’ve also added Chrome use-counters to M78 for all these delimiters. :~: is seen on fewer than 0.0000039% of page loads (or about 1 in 25 million) so we currently believe this is a safe choice. 可以見到,最終結論選擇 :~: 有考慮了很多因素,但其實又有一點隨意。在只有 0.0000038% 下,相信已經是很安全的分隔號。 Opt-out 若你的網站不想支援這個功能,你可以在 HTTP header 加上這句: Feature: Document-Policy: force-load-at-top

2024 年最新 AWS EC2 + Web Server 建立【逐步圖文教學】

這篇文章記錄了我在 AWS 建立一個新的 EC2 instance + Web Server,提供最簡單直接的步驟流程,避開中伏位,分享經驗小 tips,讓大家可以有個參考。 目標:Amazon Linux 2023 + Apache + PHP 若是想找 Amazon Linux 2 (AL2) 的教學,可以瀏覽這篇 How To Install PHP 8.0 on Amazon Linux 2。 建立 AWS EC2 名字隨便填一個就可以,主要方便與其他 instance 辨別。 AMI 選擇 Amazon Linux 2023 AMI,已經是目前最新,沒有 2024 這回事。 今天 2024-03-22 用的是 Amazon Linux 2023 AMI 2023.4.20240319.1 arm64 HVM kernel-6.1。 Architecture 選擇 64-bit (Arm),架構比較省電,而下一步可以選擇 t4g 系統。 要想了解t4g 這些是甚麼意思,可以瀏覽這篇 Amazon EC2 names explained。 Instance type 選擇 t4g.small,如果測試用可以考慮 t4g.nano 或者 t4g.micro,可以注意一下 vCPU、Memory、價錢分別。後續需要安裝 Web Server,所以我選擇 2 GiB Memory 的 t4g.small。 然後,建立一個新 Key pair (best practice 不要重用其他的 key),用於之後 SSH 登入。 Key pair name 輸入一個 file name。 Key pair type 按你個人喜好。一般來說,ED25519 的 algorithm 會比較安全,key size 比較少。 Private key file format 我用 .pem,如果是 windows 用 Putty 的話,用 .ppk 會比較方便。而 .pem 與 .ppk 也是有方法去轉換的。 ED25519 is based on elliptic curve cryptography, which is considered more secure than RSA. The security of RSA is based on the difficulty of factoring large prime numbers, while the security of ED25519 is based on the difficulty of solving the elliptic curve discrete logarithm problem. The latter is generally believed to be harder than factoring large prime numbers, making ED25519 a more secure choice. 先把 key 保存到自己電腦,安全的保管好。同時也可以先把 key 設置 SSH 能用的權限: 400 只限指定讀取,不能改動。 繼續下一步,Network Settings。選擇 Create security group 建立新的 rule。 同時剔選 這個 EC2 暫時不用 Load Balancer,所以用 Web Server 的概念,需要打開 HTTP & HTTPS,剔選: 背後會是以下這些 Rules: 然後下一歩, Storage 預設 8 GB 太少了,我會改為 30 GB,方便之後存放 files。當然之後不夠也是可以向上 resize。 File System 用預設的 EFS 就 ok。其他都用預設值。 IP 可以留意一下選擇 IPv4 或者 IPv6。 可以參考這篇關於 AWS 對 IPv4 收費的文章。 檢查一下 configuration 沒有錯的話,點擊「Launch instance」。 以前要等幾十秒,現在幾秒鐘就已經成功建立 instance 了⋯ 可以見到 Instance 已經上線了,同時也可以登入 SSH。這個時候,AWS 也會正式開始對你計算收費。 經驗小提示!! 我會建議這個時候先 associate 一個 Elastic IP 給這個 Ec2。因為這 EC2 一旦重新開機,關機後 AWS 就會回收這個沒有在用的 IP,到開機時,AWS會再分配另一個 IP 給 EC2。這樣可能對你 DNS 設置 / SSH 登入不太方便。 在左邊選單選擇 Network & Security > Elastic IPs 頁面。 Allocate Elastic IP address 用預設值就足夠。 然後選剛剛新建立的 IP,右鍵打開選擇 Assoicate Resource type 選擇 Instance,並揀選 ec2,其他可以留空。 這時候跳回 EC2…

2024年 SASS 已經過時? 原生 CSS vs SASS

SASS 作為一個強大的本地安裝的預處理器,十多年來一直是我的項目重要開發工具之一。它讓我能夠高效地組織可擴展和穩定的 CSS packages。即使在今天,我仍然認為 Sass 是一個非常強大的工具。然而,當我們走進 2024 年,不可否認 CSS 已經快速發展。曾經是 Sass 獨有的功能,現在已經原生集成到 CSS 中了,包括 Variables 和最新亮點:CSS Nesting。 Variables 長期以來,定義 Variables 被視為 SCSS 的一項獨特強項,它允許集中管理許多屬性,這是 CSS 長期以來非常缺失的功能。今天,然而,Variables 也可以在 CSS 中以類似 Sass 的方式定義。然而,一個顯著的差異是,Sass Variables 僅存在於 pre-processor 上下文中,而 CSS Variables 可以在瀏覽器中使用,甚至可以通過 JavaScript 動態覆蓋。 CSS Nesting 能夠在另一個元素內定義 style,直接簡化了 CSS。不必重複使用相同的 Selector 來選擇子元素或 Pseudo-Class,CSS Nesting 允許在 parent 內組合這些 selectors。這種技術導致了一個清晰的、層次結構化的,因此更高效的代碼庫。 隨著 CSS Nesting 和 Nesting Selector 的瀏覽器支持分別超過 84% 和 86%,這種技術變得越來越可普遍。 :is Pseudo-Class The :is() CSS pseudo-class function takes a selector list as its argument, and selects any element that can be selected by one of the selectors in that list. This is useful for writing large selectors in a more compact form. :is() – CSS: Cascading Style Sheets | MDN :is Pseudo-Class 徹底革新了選擇器概念,這大大方便了在 DOM & selector 的工作。 代替以過很長的 CSS Selectors,現在可以使用 :is() 來提高可讀性。 :has Pseudo-Class CSS Pseudo-Class :has() 提供了一種強大的方式,能夠更容易處理以往無法存取到的條件情境。 Container queries Container Queries 被認為是自 CSS3 以來網頁設計中最重大的創新。它通過允許元素根據其容器的大小進行調整,擴展了響應式設計的概念。這項技術使得元素的設計可以根據上下文動態變化,從而導致更靈活和適應性的設計。 如果 container fancy 有變量 --theme: dark,就應用段內的 CSS。 Cascade layers Cascade Layers 避免為了 higher specificity 而所添加的 nesting of classes、ID 等。使用 @layer at-rule 和分層的 @imports,我們可以建立自己的 Cascade Layers – 從低優先級樣式(例如重置預設樣式),到主題、框架和設計系統,再到最高優先級樣式(如組件、工具和覆蓋)。Cascade Layers 容許更多控制權。 Sass 的未來 這是否意味著 Sass 已經過時了?一點也不。Mixins 和 functions,例如可以方便地將像素轉換為 rem 的函數,仍然是 Sass 不可替代的優勢。不過,我決定逐步放棄 Sass 作為我大多數項目的一部分,改用 Native CSS 寫法。相反,我會在 editor 中使用更多 pre-defined snippets 去簡化我的開發工序,提高了我的工作速度。 Sass 真的再見了嗎? 我深信在 2024 年,現在 SASS 的好處,包括安裝、使用和編譯問題,會逐步被 Native CSS 所取替,因為透過 Native CSS 不需要額外工具也能做到這些事情,而 SASS 的使用價值必然會下降。

Amazon EC2 升級為 IMDSv2

從2024年中起,AWS將對其新推出的Amazon EC2實例類型標準化使用最新版本的元數據服務(IMDSv2)。這項轉變旨在進一步加強安全措施,因為相比於先前版本的IMDSv1,IMDSv2引入了加強的安全功能來抵抗潛在的惡意攻擊,封堵可能的安全漏洞。 IMDSv1 安全問題 舊有 v1 中,可以直接問 IMDS 獲取 EC2 的相關資訊 若 EC2 instance 有綁定 IAM Role 的話,更可以獲取到機密級的 AWS Credential!! 然後就可以用這組 Credential 來登入 AWS CLI!! IMDSv2 新要求 EC2實例提供了一個從固定IP地址訪問IMDS的途徑,允許用戶檢索包括啟動實例所需的AMI ID、網絡設置以及臨時IAM憑據等一系列靜態和動態信息。IMDSv2與其前身的一大差異在於其使用了基於會話的溝通方式,這要求客戶端和服務端在交換數據前建立一個安全會話,這一過程中生成的令牌將用於後續的數據請求和回應。 AWS指出,雖然IMDSv1本身安全性已經很高,IMDSv2進一步增強了對四種主要安全風險的防護——這包括不當配置的開放式網站應用防火牆、反向代理漏洞、伺服器端請求偽造以及網絡層的配置錯誤——從而大大減少了未授權訪問EC2元數據的可能性。 自2019年推出IMDSv2以來,AWS於2023年3月發佈的Amazon Linux 2023已預設啟用IMDSv2。目前,通過控制台啟動的Quick Start以及所有Amazon及其合作夥伴的Quick Start AMI均已支持IMDSv2。 為了促進用戶轉向使用更安全的IMDSv2,AWS計畫於2024年2月推出新的API功能,使得用戶可以在賬戶級別控制IMDSv1的默認使用情況。當IMDSv2成為AWS管理控制台和其他接口的默認選項時,這些新API將使用戶能夠輕鬆地在賬戶級別禁用IMDSv1,進而輕鬆切換至IMDSv2,以提高安全性。 隨著2024年中期新EC2實例類型的推出,IMDSv2將成為預設的元數據服務版本,顯示AWS對於加強其雲平台安全性的持續承諾。即使如此,AWS仍提供靈活性給予用戶選擇,即在不需要重新啟動實例的情況下,於實例啟動期間或之後選擇啟用IMDSv1的選項,這確保了向後兼容性與過渡期的順暢性。 IMDSv2 實際用法 v2 與 v1 最大的不同之處,就是 v2 需要先生成一個 token,然後在後續的請求中傳送這個值作為認證,防止未經授權的訪問。 這項策略旨在鼓勵並促進用戶轉向更安全的IMDSv2,同時也為那些需要時間來適應新系統的用戶提供了足夠的彈性。通過這樣的漸進式轉變,AWS期望其用戶能在保證安全的前提下,充分利用雲計算資源。