Tag: wordpress

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...

AWS 官方推出 WordPress 整合套件

AWS 自己推出了跟 WordPress 的整合套件：「Accelerating WordPress with CloudFront using the AWS for WordPress Plugin」、「AWS for WordPress plugin now available and with new Amazon CloudFront workflow」。

這次的套件主要是將 Amazon CloudFront 整合進 WordPress：

Amazon Web Services announces the general availability of the AWS for WordPress plugin. Previously known as the Amazon Polly and Amazon AI plugin, the new AWS for WordPress plugin now provides a workflow to configure an Amazon CloudFront distribution that is highly optimized for WordPress websites.

如果想要都控制在自己手上，AWS 算是提供了一個官方的方案，也應該有一定的支援。不過大多數人還是會拿 Cloudflare 的免費方案吧...

換到 PHP 7.3

上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」)，這次是在整理機器時發現 blog 這台機器還在跑 7.2，就更新一下系統把上面的站台都換到 7.3。

蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」)，目前看到的資料都會快一些，應該是沒有太大問題，之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB，但用 opcache-status 看起來只用了 65 MB 左右)，把記憶體空間讓給其他程式用...

不過 7.4 也快出了...

Automattic (WordPress.com 的公司) 買下 Tumblr

Verizon 一直在把 Yahoo! 手上比較有價值的資產賣掉，總算是輪到 Tumblr 了，這次是賣給了 Automattic，也就是 WordPress.com 營運的公司。

Verizon 已經發新聞稿了：「Verizon Media announces sale of Tumblr to Automattic」，Tumblr 的 staff blog 上也發表了：「Hello Tumblr ? Today, Tumblr’s owner, Verizon...」，但 Automattic 這邊還沒看到：「Features, news, and more: See what’s been going on in Automattic’s world.」。

金額不確定多少，但感覺應該算是好事？不知道之前的 porn content 會不會回流...

補上 WordPress 編輯器的 accesskey

在 WordPress 編輯文章時我還是習慣用傳統編輯界面自己修改主要的 html tag，像是這樣：

上面那些按鈕在很久以前的版本透過 accesskey 用鍵盤快速輸入各種連結與效果，但後來就被拿掉了... 不過可以在「Adding WordPress Custom QuickTags」這邊看到一些文章有提到過。

研究了一下 WordPress 的 minimal plugin 有哪些東西，看起來也不難寫，就花了些時間用 js 操作，這樣編輯起來方便多了... 程式包起來放到 gslin/wp-editor-accesskey 上，有需要的也可以拿去用，不過我猜現在還這樣寫文章的人不多了...