升級到 WordPress 6.3 遇到的問題

WordPress 6.3 出了:「WordPress 6.3 “Lionel”」,順手按了升級就爛掉了,發現是 admin 介面爛掉,網站本身還能瀏覽,先翻出 PHP 的錯誤訊息:

2023/08/09 04:52:32 [error] 845702#845702: *1350433 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function W3TC\Util_Environment::is_dbcluster(), 0 passed in /srv/blog.gslin.org/public/wp-content/db.php on line 56 and exactly 1 expected in /srv/blog.gslin.org/public/wp-content/plugins/w3-total-cache/Util_Environment.php:176

順著這個訊息找到這個算新的討論:「Fatal error in Util_Environment」,看起來跟 W3 Total Cache 有關。

(話說這個錯誤訊息還比較新,Kagi 上面找不到,後來是在 DuckDuckGo 上找到)

解法就比較粗暴一點,先到 wp-content/plugins 下讓 W3 Total Cache 失效:

sudo chmod 000 w3-total-cache

跑完升級後會出現錯誤訊息提示 W3 Total Cache 沒有啟用,這時候再開回來:

sudo chmod 755 w3-total-cache

後續把 cache 都清掉就正常了。

拿許久沒用的 abpe.org 出來架 Mastodon

前幾天 Twitter 在搞事情,把未登入的存取方式都擋住了,所以本來透過 RSS-Bridge 的方式也被擋掉了,只好趕快研究 Mastodon 要怎麼架。

https://abpe.org/@gslin 這邊。

要先注意硬體需求,好像沒有文章特別獎,但實際測試後發現 2GB RAM 的 VPS 只是超級低標,光是跑起來就把 2GB 吃乾了,我測試的時候開 VPS (2GB RAM + 512MB swap) 才勉強撐住,swap 都已經吃到 400MB 左右。一開始開 1GB RAM 的時候直接 OOM 給你看...

現在是跑在家裡的機器上,8GB RAM 的機器上面跑個 Sentry + Mastodon 就差不多了。

文件的部分因為想要用 Docker Compose 跑,是參考「How to take advantage of Docker to install Mastodon」這篇跑起來的,把裡面 docker-compose.yml 使用的版本換新再跑,基本上沒有問題。

接下來就是找有誰已經在 Mastodon 上,要花時間訂起來...

WordPress 誕生 20 年

Matt Mullenweg 寫了一篇文章簡單提到 WordPress 誕生 20 年:「WP20 & Audrey Scholars」。

雖然 Matt Mullenweg 在文章裡都沒提到,但 WordPress 的興起其實跟當年 2004 年最大的 blog 軟體 Movable Type 自己出的包有很大的關係:

With the release of version 3.0 in 2004, there were marked changes in Movable Type's licensing, most notably placing greater restrictions on its use without paying a licensing fee. This sparked criticism from some users of the software, with some moving to the then-new open-source blogging tool WordPress. With the release of Movable Type 3.2, the ability to create an unlimited number of weblogs at all licensing levels was restored. In Movable Type 3.3, the product once again became completely free for personal users.

當年 hlb 在社團主機上用 Movable Type 架了服務讓大家寫,結果後來發生了 license 問題,大家就都順勢跑到 WordPress 上了;而等到 Movable Type 再次想放寬 license 的時候已經來不及了,大家都已經搬完了。

翻了一下最舊的文章 (在另外一個 WordPress 上) 是在 2004 年十月的時候寫的,就有提到當時從 Movable Type 換到 WordPress 的考量:「開場:為什麼用 WordPress」。

備份 Xuite Blog 的公開文章

中華的 Xuite 前陣子宣佈了服務中止的公告:「Xuite隨意窩平台服務終止公告」(這邊就先拉 Internet Archive 的連結了,看起來之後會消失...)。

Blog 的部份,除了作者本身可以拉資料下來放到其他平台以外,外人也可以把這些歷史遺跡保留下來,像是丟到 Internet Archive 的 Wayback Machine 上面。

所以用 Perl 寫了一隻 script,把 url 掃出來後,後續就可以用其他工具 submit 到 Wayback Machine 上面:「xuite-urldump」。

當年有不少 ACG 相關的 blog 在上面,先來備份起來...

改用 IFTTT 分享到 Twitter

前面兩個月發文比較少,所以沒注意到 Jetpack 分享功能變成限制一個月只能分享 30 則,超過的部份要另外購買。這應該是 Twitter 之前在搞事的時候順勢推出來的專案?

看了一下應該是 Social 功能,Basic 版本就夠,但然後那個價錢應該是不太可能買 (年繳要 US$12/mo):

替代方案是把先前買的 IFTTT 拿出來用,透過 RSS feed 同步到 Twitter、LinkedInTumblr

本來的 PlurkFacebook 則是從 Twitter 同步過去,應該是不用動,來看一下效果怎麼樣...

新版 WordPress 預設的佈景主體將不會使用 Google Fonts

新版 WordPress 的預設佈景主體 (Theme) 出於隱私考量,將不會使用 Google Fonts:「Google Fonts are included locally in bundled themes」。

這邊講的是年份系列的 Theme,從 Twenty Twelve (2012) 到 Twenty Seventeen (2017):

再更後新的版本,首先是沒有 Twelve Eighteen (2018) (可以從「Themes by WordPress.org | WordPress.org」這邊翻),而從 Twelve Nineteen (2019) 後都沒有使用 Google Fonts 了,在 GitHub 上的 WordPress/twentynineteen 這邊可以 clone 下來確認:

$ git grep google    
classes/class-twentynineteen-svg-icons.php:         'google-plus' => array(
classes/class-twentynineteen-svg-icons.php:                 'plus.google.com',
classes/class-twentynineteen-svg-icons.php:         'google-plus' => '
classes/class-twentynineteen-svg-icons.php:         'google'      => '

官方還是有給繼續使用 Google Fonts 的方法,在「Continuing to use Google Fonts」這段有提到設定的方式。

WordPress 打算要支援 SQLite 作為後端資料庫

目前 WordPress 只有支援 MySQL,而昨天在 Hacker News 上看到 WordPress 有打算要支援 SQLite 作為後端資料庫的消息:「WordPress testing official SQLite Support (github.com/wordpress)」,原文在 GitHub 上:「Implement new experimental SQLite integration module」。

理論上對使用者會更方便,但對 extension 開發者會麻煩一些 (或是直接標不支援?),尤其是用到 MySQL 特有的語法就要注意了。

實質上 PHP + MySQL hosting 其實蠻常見的,這個作法有多少幫助就不知道了。

但突然想到,如果做一個 read-only 版本的 WordPress 站台,然後把 SQLite 的讀取部份改用 sql.js 之類的計畫,再把一堆 server side rendering 的部份變成 client side rendering,好像有機會可以整包直接上 GitHub Pages 之類的服務?雖然這樣有點拖褲子放屁...

難得看到 John Resig 的 Blog 更新,在講 Mastodon

jQuery 的發明人 John Resig 已經超久沒更新 blog 了,雖然有訂起來但沒想到會看到他更新:「Twitter vs. Mastodon」。上次的更新是 2016 年初,快七年了。

基本上裡面就是解釋 TwitterMastodon 的差異,然後順便介紹他自己的 Mastodon 帳號。

不過目前看了一輪,ActivityPub 的各種實做還是離理想差了一截,可能會先繼續龜著...

用 DALL·E 2 的圖當作網誌文章的圖片

Hacker News 上看到「I replaced all our blog thumbnails using DALL·E 2 (deephaven.io)」這個點子,原文在「I replaced all our blog thumbnails using DALL·E 2 for $45: here’s what I learned」這邊。

網誌文章如果包含好的圖片時,曝光度與互動都會比較多。所以作者就想到用 OpenAIDALL·E 2 來搞事了:給個描述,請 DALL·E 2 生成圖片。

文章裡面有很多產生出來的圖都蠻有趣的,像是「a cute blue colored gopher with blue fur programming on multiple monitors displaying many spreadsheets, digital art」這個描述生出來的圖:

不過不算便宜,他花了 US$45 生成大約一百篇文章的圖:

I spent the weekend and $45 in OpenAi credits generating new thumbnails that better represent the content of all 100+ posts from our blog.

如果用先前「玩玩文字轉圖片的 min(DALL·E)」這邊提到的方法自己搞不知道可不可行?

實做 RSS/Atom feed 的最佳實踐

前陣子看到的文章,在講實做 RSS/Atom feed 的 best practice:「RSS Feed Best Practises」。

最簡單的當然還是丟個 Atom feed 就好,接下來就是一些延伸出來可以多做的事情。

首先有提到 discovery,可以讓 crawler 在抓到 HTML 頁面的時候知道 feed 在哪裡,這對於 user experience 來說蠻重要的,大多數的 feed reader 都可以透過這個方式抓到真正的 feed 位置。舉個例子來說,我丟 https://blog.gslin.org/ 進 feed reader,可以透過 discovery 的方式告訴 feed reader 我的 feed 位置在 https://blog.gslin.org/feed/

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />

另外是常見的 cache 問題,這個設起來不算太難,主要是細節很多 XD

後面提到的 WebSub,以前叫做 PubSubHubbub,是一個在 feed 更新後主動通知讓 crawler 來抓的機制。不做的話也還好,現在的 crawler 現在都還蠻聰明的,會針對更新比較頻繁的 feed 常常去確認,但這樣總是會有一些時間差。

不過裡面好像沒提到 Update Services,這是比較早期的方法,走 XML-RPC,雖然也不知道現在有什麼用途了,大概就是這樣所以沒提...