component pages: show distributor part numbers as text, not constructed product links (DigiKey 403, Mouser serves a denial page with HTTP 200)

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 1mo ago ·closed by Colby Knox

Colby's ask (2026-09-17): on a component page, show the distributor PART NUMBER as text, the way the Adom number and LCSC number read, instead of linking out to the product page. The DigiKey and Mouser links on https://wiki.adom.inc/adonis/lw-a6sg-v2ba-fk0pn0 come back as "you're blocked from this page".

Three separate problems are stacked here. The first is the one to fix; the others explain why.

1. The constructed product URLs are not product URLs

partNumberRows (lib/templates.js, the entries array) builds the outbound href from the part number:

DigiKey  https://www.digikey.com/en/products/detail/<number>
Mouser   https://www.mouser.com/ProductDetail/<number>
LCSC     https://www.lcsc.com/search?q=<number>

DigiKey's real product path is /en/products/detail/<manufacturer>/<mpn>/<id> and Mouser's is /ProductDetail/<manufacturer>/<mpn>?qs=.... A bare distributor number in those paths cannot resolve to a product, no matter who is asking. LCSC is the odd one out because it links to a SEARCH, which is why it is also the only one that works.

Checked with a real number from adom/sn74ahc1g08dbvr (DigiKey 296-1091-2-ND, Mouser 595-SN74AHC1G08DBVR), browser UA, from this container:

URL the page builds	result
digikey.com/en/products/detail/296-1091-2-ND	403
mouser.com/ProductDetail/595-SN74AHC1G08DBVR	200, body is "Access to this page has been denied"
lcsc.com/search?q=C79401	200, real page

This is not one bad page: 208 component pages carry a DigiKey or Mouser number today, and every one of them renders a link of this shape.

2. Both distributors block us anyway

Even the correct search shapes (digikey.com/en/products?keywords=<n>, mouser.com/c/?q=<n>) answer 403 and a challenge page from here. Caveat so nobody chases a ghost: this is client and IP dependent, so a human on a home connection may well get through. Mouser's block is the nastier one, because it answers 200 with a denial body, so any link checker calls it healthy.

Showing the number as text sidesteps all of it: nothing to get wrong, nothing to block, nothing to rot when a distributor renumbers a product URL.

3. The reported page put URLs where numbers go

adonis/lw-a6sg-v2ba-fk0pn0 declares:

"distributor_links": {
  "mouser":  "https://www.mouser.com/en/ProductDetail/ams-OSRAM/LW-A6SG-V2BA-FK0PN0?qs=...",
  "digikey": "https://www.digikey.com/en/products/detail/ams-osram-ag/LW-A6SG-V2BA-FK0PN0-0-20-R33/13624925"
}

partNumberRows treats those values as numbers, so the page renders the whole URL as the part number, and concatenates it into its own base:

https://www.digikey.com/en/products/detail/https%3A%2F%2Fwww.digikey.com%2Fen%2Fproducts%2Fdetail%2F...
https://www.mouser.com/ProductDetail/https%3A%2F%2Fwww.mouser.com%2Fen%2FProductDetail%2F...

I audited every component page on prod (3001 checked: ray 2791, adom 203, barrett-land 5, tylerk 1, plus the two adonis pages). 275 carry a distributor block; exactly one, the reported page, has URLs in the number fields. So this is a single page to correct, not a migration. Worth noting the field is named distributor_links but wants numbers, which is what invites the mistake.

That page does have the real numbers, further down its own spec table: Mouser 720-LWA6SGA1198, DigiKey 475-LWA6SG-V2BA-FK0PN0-0-20-R33TR-ND.

Asks

Render DigiKey and Mouser part numbers as copyable text, like the Adom number, with no outbound product link. If a link is wanted at all, make it the distributor's search for that number (what LCSC already does), never a constructed product path.
Reject or ignore a value that starts with http:// or https:// in a distributor number field: refuse it at publish with the existing distributor hint, and never concatenate it into a URL.
Consider renaming the field, or accepting { "digikey": { "part": "..." } } as the documented shape (the picker already reads .part), so "links" stops inviting URLs.

Filed from the CLI thread. adom-wiki's own lint has the matching client-side check for #2 if you want it there too; say the word and I will add it.

1 Reply

Colby Knox · 1mo ago

Shipped (git-wiki be1f682, on prod).

1. Numbers as text. partNumberRows no longer builds a product URL from the number. Each DigiKey / Mouser / LCSC row is the part number as copyable text; the only link is a small "search" beside it that opens the distributor's own search for that number (digikey.com/en/products/result?keywords=, mouser.com/c/?q=, lcsc.com/search?q=), which is what LCSC already did. Nothing on any component page links to /en/products/detail/<number> or /ProductDetail/<number> any more; the 208 pages carrying numbers all changed at once, no republish needed.

2. URLs in number fields. A component.distributor_links value that starts with http:// or https:// (as a string, or as { "part": "https://..." }) is refused at create and on EVERY publish of a component, not just the first: 400 DISTRIBUTOR_NUMBER_IS_URL, errors[] naming the field, data.fields[], and a hint that says where the number is on the distributor's page. At render and in the indexer a URL is dropped rather than concatenated, so a page that already carries one shows no row for that distributor instead of the doubled URL.

3. The field's shape. { "digikey": { "part": "..." } } is accepted as the number everywhere the string is (hint, refusal, indexer, rows). I did not rename distributor_links: 275 manifests spell it that way and the CLI lint reads it; the refusal in 2 is what stops the URL mistake now. If you want the rename anyway, say so and I will alias both names.

The adonis page. I left adonis/lw-a6sg-v2ba-fk0pn0 alone (not my page). Its DigiKey and Mouser rows are absent now; the numbers it needs are in its own spec table (Mouser 720-LWA6SGA1198, DigiKey 475-LWA6SG-V2BA-FK0PN0-0-20-R33TR-ND) and the next publish with URLs in those fields is refused with the exact field names.

Tests: test/pages/part-number-rows.test.mjs (no product links, search link, URL dropped, { part } shape), test/packages/publish-distributor-json.test.mjs (the refusal, both shapes). Docs: api reference under POST /api/packages/:slug/publish, hint-codes row. The CLI-side lint you offered is welcome; the server refusal already carries the field list, so the CLI can print errors[] as is.