Tag: plugin

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

繞過 Web 上「防機器人」機制的資料

這兩天的 Hacker News 冒出一些討論在講 Web 上「防機器人」機制要怎麼繞過：

第一篇主要是從各種面向都一起討論，從大方向的分類討論 (「Where to begin building undetectable bot?」)，另外介紹目前有哪些產品 (在「List of anti-bot software providers」這邊)。

在文章裡有提到一個有意思的工具「puppeteer-extra-plugin-stealth」，主要是在 Node.js 類的環境，查了一下在 Python 上也有 pyppeteer-stealth，不過 Python 版本直接講了不完美 XDDD

Transplanted from puppeteer-extra-plugin-stealth, Not perfect.

第二篇文章在開頭就提到他不是很愛 Proxy，因為 Proxy 很容易偵測。在文章最後面則是提到了兩個方案，第一個是用大量便宜的 Android 手機加上 Data SIM 來跑，另外一個是直接用 Android 模擬器加上 4G 網卡跑。

依照這些想法，好像可以來改善一下手上的 RSS 工具...

把自己的 Trac 換到 1.4

八月底的時候就已經出 Trac 1.4 了 (參考當時寫的「Trac 1.4」)，不過當時升級一直失敗：

$ trac-admin ./ upgrade
Error: Unable to check for upgrade of trac.db.api.DatabaseManager: TracError: Unsupported database type "mysql"

後來在「TracError: Unsupported database type “mysql”」這邊找到解法，下面有人提到解法是裝系統的 python-pymysql，那麼對應到 pip 的套件安裝時，裝 PyMySQL 就可以了。

另外一個比較麻煩的就是 Trac 的 XmlRpcPlugin 套件，這個套件其實一直都很 hack，常常是自己硬幹底層的東西跳過現有機制 (於是像是透過他開 ticket 時，就不會發通知信之類的問題)，但目前暫時又不能不用他...

Anyway，這東西在升級後也爛掉了：「Plugin fails on Trac 1.4」，然後下面看到 Gasol 修了一版出來：「Gasol/trac-xmlrpcplugin」。

另外是我自己有掛 custom theme 的套件 ThemeEnginePlugin 也爛掉了，不過這個暫時移除就好，之後再排進去修...

最後就是把本來的 css/js 都依照「Customizing the Trac Interface」的說明，porting 到 Jinja2 下。

主要就是把本來的 site.html 裡面的片段搬到 site_head.html 與 site_footer.html 裡，然後 CSS 的部份照著建議拆到 style.css 裡 (因為 css selector 的 id selector # 在一行開頭的位置會被 Jinja2 當作命令處理)。

後續繼續看看還有什麼要修正的，另外 wiki 也得等摸索差不多後更新...

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 的免費方案吧...

用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時，會定義自己的 Message-ID，另外後續變更的通知信件會增加 References 欄位，讓 mail client 可以配對起來 (變成一個 thread)。

但 Amazon SES 會把原來的 Message-ID 改掉，使用自己的 Message-ID 欄位，可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來，只剩下後續的信件因為有相同的 References，所以 mail client 可以正確的配對起來。

所以我就決定生一個 workaround plugin，只要是沒有 References 的信件 (像是每張 ticket 的第一封信)，就從 Message-ID 複製一份到 References 裡，這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好，所以就不判斷是不是 ticket 的通知信了...

這就是 trac-references-mail-decorator 這個套件的由來...

Chrome 72+ (目前在 Beta 的版本) 對延伸套件的影響

我的桌機平常都是跑 beta channel 的 Chrome，所以前陣子已經升級到 72，然後發現兩個問題：

從 dev console 可以看到問題都是 Referer 沒被送出，導致有檢查 Referer 的網站拒絕存取，後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則，裡面提到了：

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Accept-Language
Accept-Encoding
Referer
Cookie

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

不確定這個設計的目的是什麼，但反正已經中獎了，總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一？)。

所以就先去 Tampermonkey 開 ticket，也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版)：「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。

另外跟 Referer Control 的開發者回報這個問題，也修正出新版上架了，更新就生效了：「refererControlDisqus.html」。

目前看起來還有「Spoofs Lang」得修，不過這個軟體好久沒更新了，不知道有沒有機會...

DefaultCcPlugin 改 Component 不會增加 Cc 列表的問題...

在 Trac 的 DefaultCcPlugin 裡有個很喜歡用的 feature：改 component 後會自動增加該 component 的 cc list。但這在 Changeset 13747 被「修正」掉了：

0.3dev: Only append to CC field when ticket is created. Fixes #11624.
Previously the CC field would be modified on Preview and during any ticket change, however these would often go undetected since the field is de-duplicated on save.

而這個 plugin 還是用 Subversion 管理，本來找了一堆 svn2git 的工具，後來發現 Git 所以靠 git-svn 拉下來再改，然後再丟出來：「gslin/defaultccplugin」。

Trac 的 DuplicateTicketSearchPlugin

DuplicateTicketSearchPlugin 是 Trac 的 plugin，在開新票時會搜尋系統內可能重複開過的票給出建議。

之前在寫 wiki 上的「Trac」條目時沒寫到，大概是最早的時候都沒裝，後來有人找出來要我裝的東西，所以印象沒那麼深刻。剛剛是在找 Trac + Elasticsearch 有沒有現成的方案可以搭，結果先看到這個...

產生的效果是這樣，在改變 summary 後會出現 (focus 從 summary 移開時)：

當然就算裝了還是難免會重複開 (尤其組織夠大的時候)，但算是有幫助的東西...

總算把手上的 Trac 1.0 升級到 1.2 了...

就如同上一篇提到的，Trac 在 1.1.1 後新增了 time 格式，所以本來的 DateFieldPlugin 有些資料要轉換。我這邊只有用在 Due Date，所以就是轉 due_date 的資料而已。

先把 due_date 都改成 due_date_bak：

UPDATE ticket_custom SET name = 'due_date_bak' WHERE name = 'due_date';

然後重新計算資料，這邊是因為所有的系統都是 UTC，所以直接轉就可以了：

INSERT INTO ticket_custom (ticket, name, value) SELECT ticket, 'due_date', LPAD(UNIX_TIMESTAMP(STR_TO_DATE(value, '%Y-%m-%d')) * 1000000, 18, '0') FROM ticket_custom WHERE name = 'due_date_bak';

而我的 Report 有用到 due_date 欄位的東西，本來是 c.value 直接輸出，現在要改成：

FROM_UNIXTIME(CONVERT(c.value / 1000000, UNSIGNED INTEGER), '%Y-%m-%d') AS due_date

Trac 1.2 相較於 1.0 最不習慣的地方應該是修改界面的位置改變了，現在 Add Comment 變成在 Modify 下面，有點不太習慣，但之後用久了應該就會習慣了。其他的修一修改一改都會動了...