Repository navigation
Conversation
Adds a standalone English source for mizupanshoko.wordpress.com, a WordPress.com fan translation blog. Novels are the menu pages, chapters are the dated posts they link to, and search is the native WordPress search mapped back to novels through each post's category. Authored with AI assistance (Claude); verified with the live-check script and the plugin playground.
 [Medium impact] The PR appears safe to merge, with the existing non-blocking EPUB cover issue still open. Findings
SummaryAdds Mizupan's Archives as an English source, with browse, search, novel details, chapter text, and a source icon.
Reviews (2) · Last reviewed commit: "no-mistakes(review): Drop cheerio docume..." · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| return found.map(this.toNovelItem); | ||
| } | ||
|
|
||
| resolveUrl = (path: string) => this.site + this.toPath(path); |
There was a problem hiding this comment.
resolveUrl breaks absolute cover URLs. EPUB export calls it with sourceNovel.cover, including the external defaultCover used for novels without artwork. Since toPath preserves external URLs, this produces https://mizupanshoko.wordpress.comhttps://github.com/.... The request fails, and export silently leaves out the cover.
Return absolute URLs unchanged before joining site-relative paths.
| resolveUrl = (path: string) => this.site + this.toPath(path); | |
| resolveUrl = (path: string) => | |
| /^https?:\/\//i.test(path) ? path : this.site + this.toPath(path); |
This branch has not been deployed
1 participant
Intent
Work on #244 and include screenshots of the working fix in the PR.
Issue 244, "[Source Request] Mizupan's Archives" (opened four years ago, no linked PR): the requester wants the site added as a source. https://mizupanshoko.wordpress.com/ returns 200 and is a wordpress.com site; a chapter page such as https://mizupanshoko.wordpress.com/2022/01/26/former-yang-guifei-chapter-2-.../ returns 200 with about 11.8k characters of readable text. No plugin and no generated source covers the site today. Content is English.
Make sure the fix's pull request shows a photo of the plugin working correctly inside the plugin playground, and run that screenshot process headless if possible.
Screenshots
These come from this repo's plugin playground (run headless), not from the LNReader app. The Android toolchain is not installed on the machine that made this change, so the plugin has not been tested in the LNReader app.
1. Popular listing, with covers in the playground. The fallback cover is used for 99 Firemaking, which has no artwork.
2. Search for "Shisha", with this source's result on screen.
3. Parse Novel for
/shisha-sosei/: cover, summary and metadata.4. Parse Novel chapter list: 39 chapters.
5. Parse Chapter for Former Yang Guifei chapter 2: readable text.
What Changed
plugins/english/mizupanshoko.ts(idmizupanshoko, v1.0.0), for mizupanshoko.wordpress.com. Novels are discovered from the main-menu pages that list chapter posts, and chapters come from each novel page's chapter list./?s=queries and maps chapter hits back to their novel through the category slug. Chapter text drops script, style, sharing, and related-post blocks, plus Previous/TOC/Next navigation paragraphs.public/static/src/en/mizupanshoko/icon.png(96x96 PNG), referenced by the plugin'siconfield.Risk Assessment
✅ Low: The change is a single new standalone plugin with a valid 96x96 icon and no edits to shared code. The findings are parser and error-handling edge cases that depend on live site markup, which the review could not confirm, so the risk is limited to browse/search robustness rather than data loss.
Testing
npm run check:plugin -- plugins/english/mizupanshoko.ts: popularNovels PASS (3 novels), searchNovels PASS (1 result for "Shisha Sosei"), parseNovel PASS (39 chapters), parseChapter PASS (4023 chars).npm run build:full: exit 0. ESLint and Prettier are clean on the new file.Open items
AI disclosure
This PR was written with AI assistance (Claude) and validated by the no-mistakes pipeline. No human has reviewed the code or tested it in the app. Weight reviews accordingly.
Fixes #244
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
plugins/english/mizupanshoko.ts:179- fetchCatalogue loads every menu page with no per-page error handling, so one menu link that returns a non-OK status (e.g. a stale menu entry 404ing) makes fetchHtml throw and fails the whole catalogue. Both popularNovels (line 54) and searchNovels (line 120) call fetchCatalogue, so browse and search both break. Fix: catch errors per menu page in the loop and skip that page, keeping the others. Only the loop at lines 179-183 needs to change, since both callers share it.plugins/english/mizupanshoko.ts:92- Navigation-stripping in parseChapter only drops a paragraph when NAV_WORDS removes everything. A nav line such as "« Previous Chapter | TOC | Next Chapter »" leaves "« Chapter | | Chapter »" after replacement, so it is kept and the nav text leaks into chapter content. Same for "Previous Chapter" alone. The check at lines 92-97 must treat these leftover words as nav too. This is conditional on the live markup using such wording; the bracketed form in the comment is the only one the author verified.plugins/english/mizupanshoko.ts:217- chapterNumber is parsed with \d+, so decimal chapter titles collapse onto the integer part. "Chapter 5.5" gets chapterNumber 5, the same as "Chapter 5", and the two chapters become indistinguishable by number. Conditional on the site using decimal titles, which the review did not confirm against the live site.plugins/english/mizupanshoko.ts:164- fetchCatalogue re-fetches the homepage and then every novel page sequentially on each call. It runs on every popularNovels call and on every searchNovels call, including each paginated search page, so one search costs N+1 sequential requests. The smallest honest fix (parallel fetches or caching) adds machinery beyond the stated scope, so the remedy needs authorization. The defect itself is only a latency and load issue.plugins/english/mizupanshoko.ts:9- Simplification: NovelPage keeps the full cheerio document ($) for every catalogue entry. The catalogue consumers (toNovelItem, the searchNovels byPath lookup) need only path, name, and cover, and novelChapters is called on the document inside fetchCatalogue, so the stored $ is not needed. Removing the $ field from NovelPage (and the return on line 199) would drop the per-novel DOM retention and remove an unrequired component. This does not change behavior.🔧 Fix applied.
4 warnings still open:
plugins/english/mizupanshoko.ts:179- fetchCatalogue loads every menu page with no per-page error handling, so one menu link that returns a non-OK status (e.g. a stale menu entry 404ing) makes fetchHtml throw and fails the whole catalogue. Both popularNovels (line 54) and searchNovels (line 120) call fetchCatalogue, so browse and search both break. Fix: catch errors per menu page in the loop and skip that page, keeping the others. Only the loop at lines 179-183 needs to change, since both callers share it.plugins/english/mizupanshoko.ts:92- Navigation-stripping in parseChapter only drops a paragraph when NAV_WORDS removes everything. A nav line such as "« Previous Chapter | TOC | Next Chapter »" leaves "« Chapter | | Chapter »" after replacement, so it is kept and the nav text leaks into chapter content. Same for "Previous Chapter" alone. The check at lines 92-97 must treat these leftover words as nav too. This is conditional on the live markup using such wording; the bracketed form in the comment is the only one the author verified.plugins/english/mizupanshoko.ts:217- chapterNumber is parsed with \d+, so decimal chapter titles collapse onto the integer part. "Chapter 5.5" gets chapterNumber 5, the same as "Chapter 5", and the two chapters become indistinguishable by number. Conditional on the site using decimal titles, which the review did not confirm against the live site.plugins/english/mizupanshoko.ts:164- fetchCatalogue re-fetches the homepage and then every novel page sequentially on each call. It runs on every popularNovels call and on every searchNovels call, including each paginated search page, so one search costs N+1 sequential requests. The smallest honest fix (parallel fetches or caching) adds machinery beyond the stated scope, so the remedy needs authorization. The defect itself is only a latency and load issue.✅ **Test** - passed
✅ No issues found.
npm ci (dependencies installed, lockfile untouched)npm run check:plugin -- plugins/english/mizupanshoko.ts (live: popularNovels PASS 3 novels, searchNovels PASS 1 result, parseNovel PASS 39 chapters, parseChapter PASS 4023 chars)npm run dev:start (playground served from this worktree; port 3000 held by other sessions, so the playground was reached at localhost:3000 via a Chromium host-resolver mapping to this worktree's server on port 3001)Headless Chromium driven via chrome-devtools-axi: plugin filter 'Mizupan' selects Mizupan's ArchivesPopular tab: Fetch lists Shisha Sosei, Former Yang Guifei, 99 Firemaking with covers (99 Firemaking uses defaultCover); console error-freeSearch tab: 'Shisha Sosei' returns the novelSearch tab adversarial: 'zqxjvkwnomatch' shows 'No results found' with no console errorsParse Novel tab: '/shisha-sosei/' shows cover, summary, metadata (39 total chapters, first Jul 24 2020, last Jan 23 2022) and a 39-row chapter tableParse Novel tab adversarial: '/no-such-novel-zz/' surfaces 'HTTP 404 while fetching ...' as an errorParse Chapter tab: '/2020/07/24/shisha-sosei-chapter-1-execution-order/' renders 4030 characters of clean prose; text snapshot contains 0 occurrences of previous/next/tocScreenshots captured to evidence dir (01-popular-novels.png, 02-search-shisha-sosei.png, 03-parse-novel-shisha-sosei.png, 04-parse-chapter-1.png, 05-parse-novel-not-found.png)Teardown: stopped my Vite server (port 3001) and my headless Chromium (port 9622), removed the temp Chromium profile; git status clean✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.