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-200tasks/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
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:
Result:
403. The body is aChecking your browser…page — a SHA-256 hashcash challenge that sets an_hcccookie and escalates to an "I am human" checkbox on repeat requests.The same applies to
/raw-attachment/ticket/<id>/<file>, so the download step ingetPatch()is blocked as well as the listing step. Sending a browser User-Agent instead returns a bare nginx403. 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()emitsfileFailon a non-200tasks/patch_wordpress.js:279-283—getPatch()does the samefileFail()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:
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