Tag: wordpress

升級到 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 都清掉就正常了。

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」。

改用 IFTTT 分享到 Twitter

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

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

替代方案是把先前買的 IFTTT 拿出來用，透過 RSS feed 同步到 Twitter、LinkedIn 與 Tumblr。

本來的 Plurk 與 Facebook 則是從 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 之類的服務？雖然這樣有點拖褲子放屁...

WordPress 對 FLoC 的對抗計畫

Google 打算在 Google Chrome 裡面強推的 FLoC 最近有很多消息，但因為沒看完 spec 就一直丟著了... 可以先參考 iThome 的「繼Brave瀏覽器之後，DuckDuckGo、Vivaldi也要封鎖Google FLoC廣告投放技術」，雖然裡面提的很淺。

目前檯面上除了廣告產業以外，所有看到的人與組織都反對 FLoC。

從 EFF 的「Google’s FLoC Is a Terrible Idea」，之後 DuckDuckGo 也發表了「Use the DuckDuckGo Extension to Block FLoC, Google’s New Tracking Method in Chrome」，再來是 Brave 的「Why Brave Disables FLoC」與 Vivaldi 的「No, Google! Vivaldi users will not get FLoC’ed.」。

最新的進展是 WordPress 決定把 FLoC 當作 security concern 來看，打算直接推出 security hotfix 更新，預設關閉 FLoC：「Proposal: Treat FLoC as a security concern」，在 Hacker News 上也有討論：「Proposal: Treat FLoC as a security concern (make.wordpress.org)」。

主要的原因是正常的 WordPress 版本會在今年七月才出，會跟不上 FLoC 的進度：

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

我自己也因為 FLoC 而又再次跳到 Brave，還遇到 imgur Uploader 套件不見 (可以參考「What Happen to the imgur uploader extension?」)，以及有些套件無法運作的問題...

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量)，就把 blog 搬到 AWS 的 t4g.small (ARM) 上，理論上頁面的速度應該會快不少，過幾天等穩定性沒問題後就來買 RI...

從 x86-64 轉到 ARM 上面，主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository，所以就改用 MariaDB 了。

其他的倒是都差不多，目前的 Ubuntu + nginx + PHP 沒什麼問題，跑一陣子看看...

PHP 8.0 快要出了

看到 WordPress 的這篇「WordPress and PHP 8.0」，看起來 PHP 8.0 快要出了：

PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.

官網上已經有一些資料可以看了，不過記得畢竟還沒 release，裡面的資訊還有可能會修正：「Migrating from PHP 7.4.x to PHP 8.0.x」，最重要的應該還是「Backward Incompatible Changes」這邊，可以看到這次畢竟是主版號升級，精彩的不相容性應該會搞爆不少應用程式，像是開頭就提到的，對數字與文字之間的 == 行為改變：

比較好的作法是自己先轉型再用 === 比較，這個概念在各家程式語言都類似，loose comparison 只是方便而已...

這幾天 blog 被掃，用 nginx 的 limit_req_zone 擋...

Update：這個方法問題好像還是不少，目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面，結果 CPU loading 變超高，從後台可以看到常常滿載：

看了一下是都是從 Azure 上面打過來的，有好幾組都在打，IP address 每隔一段時間就會變，所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit，搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個，就設起來暫時用這個方式擋著，大概是這樣：

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable，但這邊用 429 應該更正確，從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明：

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來，目前比較困擾的是需要 copy & paste try_files 與 FastCGI 相關的設定：

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot，至少在現階段應該還是有用的...

如果之後有遇到其他手法的話，再見招拆招看看要怎麼再加強 :o

PHP 在 Amazon EC2 的 m5 (Intel) 與 m6g (ARM) 的效能差異

先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWS 在 Amazon EC2 上推出了以 ARM 為架構的 m6g 系列機器，剛剛看到有人拿 PHP 上的應用丟出測試的差異了：「Improving performance of PHP for Arm64 and impact on Amazon EC2 M6g instances」。

最先要注意的應該是這張：

在 PHP 7.3 的時候 Intel 平台的 m5 跑比較快，但到了 PHP 7.4 就變成 ARM 的 m6g 跑比較快了，不過這兩個版本的差異都不算太大，而到了還在開發的 PHP 8 則是出現了比較大的差距。

作者有提到主要的原因是在 PHP 7.4 之前 ARM 上不會啟用 Zend optimizer，而這個功能對效能的影響差很多，在 PHP 7.4 打開後就反轉了：

Zend optimizer is a component of the PHP runtime system that improves performance by up to 30% on a range of Zend micro-benchmarks. Before PHP 7.4 the Zend optimizer was not enabled for Arm.

而 PHP 8 的差距拉大，則是因為 PHP 有更多針對 ARM 平台的改善，像是這邊提到的 NEON 指令集：

PHP-8 plans to release in 2021 with more improvements for Arm64: an improved toupper/tolower function brings performance up by 16.5x. https://github.com/php/php-src/pull/4439

除此之外，AWS 也對 PCRE2 提供了使用 NEON 指令集的加速的 patch：

AWS has contributed changes to PCRE2 release 10.34. PCRE2 version 10.34 is used in PHP-8 to match regular expressions. PCRE2 accounted for about 8% of execution time in WordPress benchmark. The change contributed by AWS to PCRE2 vectorizes first character match and matching pairs of characters with NEON instructions: performance improves by up to 8x on M6g.

這樣可以看到 ARM 平常應該會愈來愈成熟，而更重要的是 m6g 系列機器比 m5 便宜不少：以作者測試的 {m5,m6g}.4xlarge 來看，分別是 USD$0.768/hr 與 USD$0.616/hr，大約是 20% 的差距，加上效能上的差距，C/P 值看起來是真的有到官方宣稱的 40%，這點在其他 Plurk 也測出了類似的結果：

未來除非是 binary-only 的東西，不然應該會朝著往 ARM 上面測過，再決定要怎麼選 instance type...