Repository navigation
Conversation
…ation parseChapter removed whatever element followed the top navigation <hr>, assuming it was the author/translator credits table. On Worldgate Online chapter 1 onwards that element is div.ppw-restricted-content, which holds the whole chapter, so those chapters came back empty; on chapters with no credits table (e.g. Arifureta) the first paragraph was dropped. Only remove the credits table itself. Also report early access (password protected) chapters and refused responses with a clear error instead of returning the password form or an empty chapter, and strip event handlers and script URLs from the returned HTML. Closes lnreader#2688
Re:Library replaced the most-popular list with div.relibrary-novel-card cards, so popularNovels returned no novels, and the latest listing's title heading now wraps a whole novel card, so names came back with the card's text. Read the card title, link, and cover instead, and throw with the HTTP status when the listing request is refused.
 [Medium impact] The PR appears safe to merge; the remaining request for repeatable chapter tests is non-blocking. Findings
SummaryFixes Re:Library chapter loading and updates listings for the redesigned site.
Reviews (2) · Last reviewed commit: "no-mistakes(ci): The Plugin Live Check f..." · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const afterNav = pageLinkHr.next(); | ||
| if (afterNav.is('table')) afterNav.remove(); | ||
| else afterNav.children().first().filter('table').remove(); |
There was a problem hiding this comment.
The wrapper-preserving fix in parseChapter has no repeatable check. The existing live check opens only the first chapter, but the reported failure affects chapters after Chapter 0. A later cleanup change could therefore bring back blank chapters unnoticed.
Add saved HTML cases for a credits table inside div.ppw-restricted-content, a standalone credits table, and a chapter starting with a paragraph. Check that chapter text survives and credits are removed.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
…urning HTTP 403 to the CI runner. I changed the three `!result.ok` throws in `plugins/english/relibrary.ts` (`popularNovelsInner`, `lastestNovelsInner`, `parseChapter`) to throw `Object.assign(new Error(...), { status: result.status, response: result })`, as `ao3.ts` does. The error messages are unchanged. I haven't confirmed that `isNetworkOrBlockError()` in `scripts/live-check-plugin.js` now reports a 403/503 as INCONCLUSIVE, because I didn't reproduce a block locally. Prettier and eslint are clean. `npm run check:plugin` passes all four checks locally: 30 popular novels, 3 search results, 413 chapters, 17265 chars of chapter text. The CI job itself hasn't been re-run
This branch has not been deployed
1 participant
Summary
Closes #2688.
On Re:Library, Worldgate Online chapters after Chapter 0 opened empty. From Chapter 1 onward the site wraps the whole chapter, credits table included, in
div.ppw-restricted-content. The plugin always removed the element right after the top navigation<hr>, assuming it was the credits table, so it deleted the chapter. Chapter 0 worked because its credits table sits outside the wrapper. The same assumption also dropped the first paragraph of chapters with no credits table (for example Arifureta chapter 2).This PR also fixes the popular and latest listings, which were already broken on master by the site redesign: popular returned no novels, and latest names included the whole card text. That break made the Plugin Live Check fail at
popularNovelsbefore it could test chapter loading. It is kept as a separate commit.This PR was written by an AI agent (Claude Code) and checked against the live site; please weigh the review accordingly.
What Changed
parseChapterinplugins/english/relibrary.tsno longer removes the whole element after the top navigation<hr>. It now removes only the credits table, whether that table follows the<hr>directly or is the first child of a wrapper such asdiv.ppw-restricted-content. Previously the wrapper held the whole chapter, so removing it left chapters empty. This addresses Worldgate Online has no chapters except Ch. 0 #2688, where every chapter except Chapter 0 of Worldgate Online opened blank.parseChapternow throws a clear error instead of returning empty content in three cases:script,styleandnoscriptelements,on*attributes, andjavascript:,vbscript:and non-imagedata:URLs inhrefandsrc..relibrary-novel-card,.relibrary-titleandimg.relibrary-cover. Both now throw on a non-OK HTTP response.Risk Assessment
✅ Low: The change is a bounded fix to one scraper plugin: it stops removing the wrapper div that holds the chapter body and adds guards that throw on HTTP errors or empty output. I found no new defect.
Testing
I ran the live checker on the plugin, which passed popular, search, novel and chapter parsing. I then drove the real Worldgate Online novel: it lists 41 chapters, and the chapters wrapped in
ppw-restricted-content(volume 1, chapters 1 and 5) now return 13–14k characters of readable story text. The last chapter is early-access locked and throws an explicit password-protected error with its unlock date instead of returning empty HTML. Playground screenshots are in the section below.check:pluginall PASS; ch0 returned 15327 charscheck:plugin: 30 popular novels, 3 search results, 413 chapters for the sample novelEvidence: Worldgate chapter HTML samples
Playground screenshots
Captured in the repository's plugin playground (
npm run dev:start) at commit 9a3c3f0 (the later commit only attaches the HTTP status to thrown errors), driven in headless Chromium. Two test-harness adjustments: the browser sent a regular Chrome user agent, because re-library.com returns 403 toHeadlessChrome; and cover requests carried the plugin's declaredimageRequestInitReferer (https://re-library.com/), which the app applies but the playground's plain<img>tags do not.Re:Library popular novels (30, with covers)
Re:Library latest novels with clean names
search for Worldgate
Worldgate Online novel details
Worldgate Online chapter list (41 chapters)
Worldgate Online Chapter 1 text (13123 characters)
early-access Chapter 29 shows an unlock-date error
CI note
On the GitHub runner, re-library.com answers with HTTP 403 (Cloudflare), so the Plugin Live Check reports INCONCLUSIVE there. The listing and chapter request errors now carry the HTTP status, so a block like this shows as INCONCLUSIVE instead of FAIL. From a regular connection,
npm run check:plugin -- plugins/english/relibrary.tspasses all four checks.Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
✅ **Review** - passed
✅ No issues found.
✅ **Test** - passed
✅ No issues found.
check:pluginall PASS; ch0 returned 15327 charscheck:plugin: 30 popular novels, 3 search results, 413 chapters for the sample novelnpm cinpm run check:plugin -- plugins/english/relibrary.ts(all four checks passed)Bundled the plugin with esbuild and ranparseNovel('/translations/worldgate-online/')plusparseChapteron chapters 0, 1, 5 and the last chapter against the live site✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.
🤖 Generated with Claude Code