其實Wordpress 的iOS app 我用得不多，但偶爾會用一下，有時候想到什麼先寫下來，整理了再發出來，但是最近iOS app 更新後我發現登錄不上。

經過我和AI 對source code 的分析，最終定位到問題所在，去github 提了個issue，很快就被合併提交，既然他們動作這麼快，為什麼之前都沒人提？

因為這是一個老用戶才會卡到的bug， 新用戶不存在，我直接修改了database 來匹配新版的app。

以下為AI 整理：

---

問題

WordPress iOS app (26.8) 登入自架站 時，瀏覽器 2FA 認證成功、產生 Application Password 也成功，但最後顯示「Site details cannot be loaded」。

根本原因

WordPress iOS app 新的 Rust-based HTTP client (wordpress-rs 0.1.0) 在 wp_api/src/users.rs 裡，把 extra_capabilities 宣告成：

pub extra_capabilities: Option<HashMap<String, bool>>,

值必須是 boolean。但 2011 年建立的老 admin 帳號，資料庫 wp_usermeta.wp_capabilities 裡存的是：

array('administrator' => '1')  // string

Rust serde deserializer 遇到 string "1" 無法轉成 bool，整個 User 物件 parse 失敗 → iOS app 回報「Site details cannot be loaded」。

新註冊的使用者沒問題，因為 WordPress 核心 set_role() 寫入的是 true（boolean）。

解法

直接改資料庫：

update_user_meta(1, 'wp_capabilities', array('administrator' => true));

Debug 過程的收穫

1. 證實不是 server 設定問題：Nginx、CloudFront、REST API、Application Password 全部正常
2. 排除了 Two Factor / WP-WebAuthn / Jetpack 404 等假設
3. PHP-FPM 的 php_admin_value[error_log] 會強制覆蓋 WP_DEBUG_LOG，導致 WordPress debug log 無法運作
4. systemd PrivateTmp 會讓 /tmp 變成 service 專屬，外部看不到
5. Android app 能過但 iOS 不行 是因為 iOS 改用 wordpress-rs，Android 還在用舊 client（type 較寬鬆）
6. 當 server 端所有回應看起來都正常，而錯誤發生在 client 端時，直接看 client 的原始碼是最直接的 debug 方式（最後一步靠 clone wordpress-rs 找出答案）

建議

這是 wordpress-rs 的 bug，應該寬容處理 "1" → true。可以到 https://github.com/Automattic/wordpress-rs/issues 報告，幫其他老站使用者。

今年不知不覺已經過了一半了。回頭看這上半年，公司的整體工作量其實沒有很大，處於一種相對清閒的狀態。人一閒下來，大家都在七七八八地找些無關緊要的事情來折騰。AI 的高速發展像一場停不下來的科技風暴，逼得很多人心慌意亂、無所適從，生怕一眨眼就被時代拋下；但也正因如此，不少人開始頭腦發熱，冒出各種不切實際的突發奇想，試圖在這波浪潮裡抓到一根翻身的稻草。

五月底的時候，因為腸胃持續不太舒服，我終於下定決心去醫院做了一次徹底的檢查。當然，去醫院檢查這個腸子不太舒服的症狀，名義上是看消化科，內心深處主要也是為了排查四月份那場莫名其妙的發燒究竟是為何，只可惜，折騰完畢，各項報告數據出來後，醫生搖搖頭，還是沒有發現到底是什麼原因導致了當初的發燒。醫學有時候就是這樣，留下一堆未解之謎，讓你只能當作是身體的一次抗議。

在大腸鏡的畫面裡，發現了大腸裡面有一顆息肉，做內視鏡的醫生手腳很快，當場就用工具把它給剪除掉了。回頭看報告上的照片，那顆息肉的表面看起來很不規則，在黏膜上扭曲著，似乎正憋著一股勁，想要在身體的隱密角落裡暗自孵化，變成一個面目可憎的怪物。幸好，在它真正興風作浪之前，就被醫生給攔截了。

相較之下，胃鏡檢查的結果倒還讓人鬆了一口氣，沒有什麼大問題。只是胃食道那邊稍微有一點點逆流，醫生安慰說這在現代人身上太常見了，屬於非常非常輕微的 A 級別。話雖如此，他還是給我開了整整三個月的胃酸抑制劑。因為我自覺平常根本沒什麼胃酸發作的症狀，那藥便一直被擱在桌角，我自己是一粒也沒有吃。反而是 Miley，每每吃到快要吐出來的時候、或者吃太多晚上睡不著覺的時候，會摸索著去拆開一粒來吃，這藥倒也算是沒有浪費健保。

轉瞬之間，打包行李離開帝都的生活，算一算居然也快要十年，偶爾在手機上蹦出關於北京的新聞，心頭竟然會湧起一絲難以言喻的陌生感。曾經無比熟悉的街道和生活節奏，如今都漸漸退化成了記憶裡的幾格剪影。

我覺得我的脾氣真的變了很多，少了很多不必要的憤怒與挑剔。現在深夜走在台北街頭，看到那些從下水道口爬進爬出、在柏油路上滿地亂竄的蟑螂時，我竟然不再感到噁心或厭惡，反而心平氣和地覺得，在這個悶熱潮濕的盆地裡，牠們其實也是這個城市不可或缺的一員，大家各自在黑夜與白晝裡討生活罷了。

這個有些過度溫暖的社會，包容度大得不可思議。它既溫柔地照顧著那些真正無助的弱小群體，同時，也極具耐心地包容、養育著那些在網絡上或現實中四處蹦跳的智障。這種無差別的善意，有時讓人啼笑皆非，卻也是這個地方最真實的底色。

不管上半年過得如何荒謬或清閒，下半年就這樣揭開了序幕。

七月你好。

七月又不認識你，憑什麼要對你好。

早年曾經買過一些手環，Jawbone up，misfit shine，然後他們都破產了，用到app消失也是醉了啊。

Fitbit 當時的設計很醜，不想買他，不過他被Google 併購後，最近出的Fitbit air 看起來不錯，USD$99， 立刻下單。

使用幾天之後發現他有明顯的問題：血氧數據不準確。

Fitbit air 記錄我的血氧最低到80%，這僅僅是因為配戴得不夠緊，但問題是他的設計本意就是不要太緊。

Apple Watch 的血氧數據大約30分鐘採集一次，我覺得最終結果可能是經過平均的，或是他會丟棄採樣不好的數據。

從Google health 的數據展示來看，Fitbit 很明顯知道每分鐘採集的數據不準確，所以他只有每日平均值而沒有單次數據展示。你無法看到單次數據，但是將數據導入Apple Health 後你就會發現那些不準確的數字。

我想，這就是Google Health 遲遲不開放將數據從官方app 同步到Apple Health 的原因，因為這樣大家都會發現，80%的血氧是什麼雞掰玩意兒？

至於心率，準確度和Apple Watch 相差無幾，而睡眠分析，則更多的是臆測，畢竟我也不知道我到底在床上掙扎了多久是什麼時候入睡的。

而且他的睡眠數據不能由Apple Health 的Vitals app 生成過夜統計，缺乏提示。

在佩戴的舒適性上確實比Apple Watch S8 好很多，因為他很輕。

準備兩個都戴上一段時間試試，等九月份的Apple Watch S12。