Repository navigation
New: Improve Scraper Search - #7259
Merged
Merged
Conversation
Gykes
requested changes
Oct 1, 2026
Gykes
left a comment
Gykes
left a comment
Collaborator
There was a problem hiding this comment.
Just a quick static lookover. No testing was done yet.
Gykes
approved these changes
Oct 1, 2026
Gykes
left a comment
Gykes
left a comment
Collaborator
There was a problem hiding this comment.
LGTM, thanks for the quick changes
1 task done
8ullyMaguire
pushed a commit
to 8ullyMaguire/stash
that referenced
this pull request
Oct 3, 2026
Keeps the fork current with upstream. The drift was measured with docs/fork-drift.sh rather than eyeballed -- and the first reading of `git rev-list --left-right --count` was misread, which made 434 commits look like 434 commits of BEHIND when they are 434 AHEAD. This fork is a soft fork carrying a large local programme (StashForge governance, the mesh, ed2k transfer), so "ahead" being large is expected; what matters is the merge-base age. Upstream work taken in: stashapp#7235 Safari layout, stashapp#7248 VR player colour, stashapp#7259 scraper search, stashapp#7249 portrait video height, stashapp#7254 organized-button contrast, stashapp#7264 patchable create endpoints, stashapp#7267 duration-match checkmark. Merge, not rebase: the ledger cites commits by SHA and the local tags point at them, so a rebase would rewrite every citation. Three conflicts, all in files this fork had also touched. ## en-GB.json -- kept ours, spliced in upstream's one key Upstream's only SEMANTIC change to this file is `package_manager.matched_via`. Every other difference between the two sides is key ORDER, which git reports as a conflict because both sides rewrote the same run of lines. So this is a keep-both, not a coin toss: take our side, then add the one key -- via docs/add-3530-locale.py, the same splice tool, precisely because a JSON round-trip cannot be byte-identical here. Verified after: the file parses, all six media_info range keys and all four validation range keys and both action range keys survive, and matched_via is present. ## Scenes/styles.scss -- took upstream's deletion This fork set `&.organized { color: #ffffff }` (stash#7160); upstream deleted the whole `&.organized` block instead (stash#7254). Both fix the same 1.35:1 contrast failure, and deleting the rule lets the button inherit the default colour rather than restating it. Took upstream's version and kept a comment recording WHY the rule is absent, since the reason is invisible in the CSS -- which is what would otherwise invite a well-meaning "tidying" back in. ## utils/apple.ts -- kept ours Upstream shipped the same ua-parser-js v2 fix (`"macOS"` where v1 said `"Mac OS"`, stash#7234), terser. Ours takes one UAParser() parse instead of two and names the booleans, which matters because the two reads were being taken from separate parser instances. Same behaviour, more legible, and the reasoning is written down. Verification after the merge: go build ./... exit 0 go test -count=1 ./... 61 packages green go test -tags integration ./... 61 packages green pnpm run check 1 error, the pre-existing Scene.tsx:756 vite build exit 0 ScenePlayer/styles.scss upstream's max-height added, this fork's CSS intact (git diff HEAD on that file is empty)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This lets the "Filter" bar for Available Scrapers find scrapers by the studios they scrape or their URL patterns in addition to the literal scraper names. This is a fully backwards-compatible change to the frontend because it uses additional metadata in the package index which is optional and (as far as I know) has only been implemented for the CommunityScrapers repository.
Related Issue
Resolves #7258
Testing
Since I've already added this metadata to the Community scraper feed this can be tested by searching for scrapers by either a non-obvious studio name or a full URL pattern as seen in the screenshots below.
Screenshots
This is what the search behaved like before this change: a literal search for the scraper name succeeds, but only finds the scrapers who happen to contain that studio name in the scraper name.
Searching for something like "Brit" would return no results at all.
And here's how the search behaves once this new functionality is added: searching for something like
Britfinds several studios that users would not otherwise know belonged to those scrapers.And searching with a full URL finds the scraper whose URL pattern would match
Checklist