Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

grunt patch fails for every ticket: Trac returns a bot challenge instead of the attachment list

オープン 初心者向け
  • 何か問題がありますか？
#210 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript
領域
cli

調査の方向性

tasks/patch_wordpress.js の getPatchFromTicket() と getPatch() から始めます。ここでは、200 以外のレスポンスが fileFail() に到達します。Issue にある curl コマンドで 403 のチャレンジレスポンスを再現し、その後、現在のメッセージがどのように組み立てられているかを追跡します。ボット保護のレスポンスが識別され、空のパッチや一般的な使用方法エラーとして扱われるのではなく、明確に報告されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Summary

grunt patch:<ticket> no longer works for any ticket. Trac now answers requests from non-browser clients with a proof-of-work bot interstitial instead of the page, so the attachment list can never be read and no patch is ever found.

This is a server-side change at WordPress.org, not a regression in this package — but the package cannot currently do its job, and the error it prints sends people looking in the wrong place.

Reproduction

Using the tool's own literal User-Agent against its own endpoint:

curl -s -o /dev/null -w '%{http_code}\n' \
  -A "grunt-patch-wordpress; https://github.com/WordPress/grunt-patch-wordpress" \
  "https://core.trac.wordpress.org/attachment/ticket/62281/"

Result: 403. The body is a Checking your browser… page — a SHA-256 hashcash challenge that sets an _hcc cookie and escalates to an "I am human" checkbox on repeat requests.

The same applies to /raw-attachment/ticket/<id>/<file>, so the download step in getPatch() is blocked as well as the listing step. Sending a browser User-Agent instead returns a bare nginx 403. Verified 2026-08-06 from an ordinary home connection, not a datacentre IP.

What the user sees

Both request sites treat any non-200 the same way:

  • tasks/patch_wordpress.js:238-244 — getPatchFromTicket() emits fileFail on a non-200
  • tasks/patch_wordpress.js:279-283 — getPatch() does the same

fileFail() then prints "Nothing to patch." followed by the four-point usage help — "enter a ticket number, enter a ticket url, enter a patch url". So a contributor whose ticket definitely has patches on it is told, in effect, that they typed the command wrong. The 403 is in the emitted message but is buried under generic usage advice, and nothing indicates the request was blocked rather than empty.

Suggested direction

The real fix is almost certainly not in this package. Two paths, neither of which this repo controls:

  • An allowlist for an identified client User-Agent, which would need Systems.
  • A structured read API. meta #8202 proposes JSON endpoints exposing ticket metadata and the attachment list (filename, author, date, size), which would remove the scraping dependency entirely rather than restoring it. It is assigned and has an implementation in progress.

What is in scope here, and worth doing regardless: say what actually happened. Detecting the challenge response and printing something like "Trac returned a bot-protection challenge (403); this tool cannot currently fetch attachments" would stop people debugging their own ticket number, and would make the scale of the problem visible instead of looking like scattered user error.

Related

  • #83 (list PRs along with patches) needs the same ticket data, and would be unblocked by the same API rather than by more scraping.
  • Worth noting for #70: whatever succeeds this tool will hit exactly this wall unless it consumes a real API, so the successor's data source may matter more than its build tooling.
主要言語
JavaScript
スター
51
フォーク
14
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WordPress/grunt-patch-wordpress のほかの issue

WordPress/grunt-patch-wordpress の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。