Tag: php

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

用 Fly.io 跑 RSS-Bridge，再把現有的 twitter2facebook 與 twitter2plurk 改寫

Twitter 把我本來 read-only 的兩個應用程式停用掉了，加上這陣子的新聞，就改用其他方式來處理。

用的是先前在「用 RSS-Bridge 接服務」提到的 RSS-Bridge，可以將 Twitter 的資料轉成 JSON Feed。

其中 RSS-Bridge 是 PHP 寫的，剛好就拿先前在「在 Fly.io 上面跑 PHP」這邊提到的方法丟上 Fly.io，不需要自己架主機跑了。

然後把 twitter2facebook 與 twitter2plurk 這兩個專案裡面本來抓 Twitter API 的程式碼改成抓 JSON Feed。

先這樣子弄，之後再看看要不要搬...

在 Fly.io 上面跑 PHP

在 Heroku 把 free tier 拔的差不多後 (「Heroku 公佈了廢止免費方案的時間表」、「Heroku 的替代方案」)，大家手上的小專案都往其他的服務跑，目前看起來做的比較有規模的就是 Fly.io 了，一個人可以建很多個 organization，而每個 organization 都有 free quota 可以用...

Fly.io 官方的文件 FLy.io Docs 裡面可以看到說明，介紹怎麼把 Laravel 站台跑起來，不過沒介紹怎麼跑純 PHP 站台，所以就看了文件研究看看，發現可以用 Docker container 跑，那就簡單了。

專案放在 GitHub 的 gslin/fly-vanilla-php 上面。

一開始我的 Fly App 用的是 V1 的版本，是跑起來了，但後來還是換到 V2 跑，雖然兩者用起來沒有太大區別 (參考「Fly Apps」這邊的說明)，但畢竟官方打算都把 V1 掛上 legacy 了，新的專案就儘量別用了...

另外一開始用 buildpacks 編 Docker image，但發現太慢了，就還是去 Docker Hub 上找個大戶人家包好的 image 來用。

首先是 fly.toml 這個檔案，這邊就直接指定用 Dockerfile 來編。

然後是 Dockerfile 這個檔案，這邊用的 image 是 richarvey/nginx-php-fpm 這包，預設會開在 port 80，所以 fly.toml 裡面就把 internal_port 指定在 80。

另外就是指定了 WEBROOT，我把 root 放在 public/ 下面。

跑起來以後就可以用他提供的網址測試了，我這個專案在 https://hidden-river-325.fly.dev/ 這邊可以看到，另外我有設定自己的 domain，在 https://test-fly.gslin.com/ 也可以看到一樣的 phpinfo(); 資訊。

這邊有個小插曲，我想要掛自己的 domain 上去跑 HTTPS，但如果機器沒有掛 IPv6 address 的話，Fly.io 的系統不會認定設定已經完成，也就不會往下去申請 Let's Encrypt 的憑證，我放了一天覺得奇怪，摸了辦天才發現這個 "feature"。

用 RSS-Bridge 接服務

查資料的時候發現 RSS-Bridge 這個用 PHP 寫的專案，直接找個 PHP hosting 架起來就可以用了，沒有什麼其他的需求。

簡單架起來測了一輪，看起來不賴啊，如果一般人要用的話可以考慮就用這個專案就好，量很少的人可以用官方列出來的 Public instances 玩一下，量多的人可以自己架，PHP hosting 還蠻好找的，官方要求要 7.4+，注意一下 PHP hosting 提供的版本應該不會有太多問題。

自己寫的 feedgen 比較偏順便練 Python，不過當時的確是還不知道有這樣的專案，看了一下 GitHub 上的 tag 記錄，2013 就有的專案...

Laravel 將不會有 LTS 版本

查資料的時候發現，在 Laravel 9 剛發佈的時候是有掛 LTS 版本的資訊 (從「Laravel 9 (LTS) 出了」這邊的截圖可以看到)，但在發佈後沒多就就被拿掉了，在 Taylor Otwell 的 Twitter 上有提到這件事情：

從幾個 forum 討論的態度上看起來以後不會出新的 LTS 版本了，之後的版本都是提供一年的 bug fix + security fix，再加上另外一年的 security fix，基本上有兩年的 support，算是半強迫開發者時間到了就要升級版本...

另外一個有看到的問題是，現在的 Laravel 9 支援的 PHP 版本因為底層 Symfony 要 PHP 8.0+ 關係也一起被拉上來，連 PHP 7.4 都不支援了：

這個靠「***** The main PPA for supported PHP versions with many PECL extensions *****」這類 3rd-party repository 來補是還能解，但感覺 Symfony 對這些問題的態度...

PHP 8.2 預計要將一些字串內指定變數的方法標為 Deprecated，在 9.0 移除

Twitter 上看到這個蠻大的改變：

裡面的連結是「PHP RFC: Deprecate ${} string interpolation」，在文件中提到了 PHP 語言支援的四種字串內指定變數的方式：

  1. Directly embedding variables (“$foo”)
  2. Braces outside the variable (“{$foo}”)
  3. Braces after the dollar sign (“${foo}”)
  4. Variable variables (“${expr}”, equivalent to (string) ${expr})

提案在 PHP 8.2 裡將 3 與 4 兩種方式標為 deprecated，並且在 PHP 9.0 移除，目前看起來是 31:1 通過了...

PHP (以及 Laravel) 下使用 DynamoDB 的 ORM 工具

在 Twitter 上看到「Laravel DynamoDB Eloquent Models and Query Builder」這篇文章，裡面講「Laravel DynamoDB」這個套件，可以在 PHP (以及 Laravel) 下存取 DynamoDB。

雖然套件提到了 Laravel，但文件裡面也有提到支援非 Laravel 的 PHP 環境下使用，單獨拿出來用也沒問題，比較重要的反倒是 DynamoDB 對各種 key 的概念。

如果是從零開始設計，但又不想要自己管資料庫，我會偏好先用 RDS 設計，無論是 MySQL 或是 PostgreSQL 的版本都行，畢竟 RDBMS 上面能做的事情比較多，對開發者比較友善，除非是第一天上線你就預期量會大到連 db.m5.24xlarge 都擋不住之類的情況...

Laravel 9 (LTS) 出了

剛剛看到 Laravel 9 (LTS) 出的消息：「Laravel 9 is Now Released!」，對應的 release notes 在「Release Notes」這邊可以看。

相隔兩年半的 LTS 版本，另外也要求到 PHP 8.0+：

不過 Lavavel 的 LTS 設計上，沒有與一般 release 差太多，LTS 版本是 24/36 個月支援 (功能/安全)，但一般版本是 18/24 個月支援：

For LTS releases, such as Laravel 9, bug fixes are provided for 2 years and security fixes are provided for 3 years. These releases provide the longest window of support and maintenance. For general releases, bug fixes are provided for 18 months and security fixes are provided for 2 years.

如果看隔壁 Ubuntu 的 LTS 是 60 個月，但一般版本是 9 個月；Node.js 的 LTS 是 36 個月，以及一般版本的 9 個月，這樣看起來就有很明顯的差異...

這樣看起來跟一般版本好像也還好？

PHP: The Right Way

在 Hacker News 上面意外看到「PHP – The Right Way (phptherightway.com)」，官網在「PHP: The Right Way」這邊，另外我在 2012 年的時候也有提過這個站台：「PHP 康莊大道」。

看了一下，應該不完全是給初學者看的，反而對於回鍋的人比較有用，無論是很舊的歷史 (像是裡面提到的 PEAR)，還是比較新的東西 (像是 test case 那邊的介紹)，他都有花一些篇幅介紹，而且除了開發以外也包含了 deployment 與 hosting provider 的部份...

沒想到這個網站過了十年繼續維護啊，而且內容豐富不少...

PHP 的 Git Server 被打穿，決定把整個 Git 系統搬到 GitHub 上

就如同標題說的：「Changes to Git commit workflow」，Hacker News 上的討論也可以看一下：「PHP's Git server compromised, moving to GitHub (php.net)」。

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our
own git infrastructure is an unnecessary security risk, and that we will
discontinue the git.php.net server. Instead, the repositories on GitHub,
which were previously only mirrors, will become canonical. This means that
changes should be pushed directly to GitHub rather than to git.php.net.

不知道發生什麼事情，要等事後的報告出來...