Conversation
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if (!res.ok) { | ||
| throw Object.assign(new Error('Request failed: ' + res.status), { | ||
| status: res.status, | ||
| }); |
There was a problem hiding this comment.
When Cloudflare blocks a request, fetchSite shows only Request failed: 403. Users need to open the site in WebView to pass the challenge, but this error gives them no way to tell what to do. Please give them that hint when the site blocks a request.
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!
There was a problem hiding this comment.
Fixed in ec9fb99. A 403 or 503 response now throws the same message other plugins in this repo use (novel543, truyendich): "Cloudflare protection detected (HTTP error). Please try opening the plugin in WebView first to solve the challenge." Other HTTP errors still throw Request failed: <status>. The error still carries status, so the live checker keeps classifying a block as INCONCLUSIVE. I checked it with mocked 403, 503 and 500 responses, and the normal requests still work against the live site through a browser session that had passed the challenge.
| // search-live returns every match at once. | ||
| if (pageNo > 1) return []; |
There was a problem hiding this comment.
After a search finds matches, the page enables Next Page. Clicking it calls searchNovels for page 2, which always returns []. The page then replaces the matches with “No results found.” Since this site returns every match on page 1, the search page needs a way to avoid offering a next page for this source.
There was a problem hiding this comment.
I've kept this as it is. searchNovels returns only Promise<NovelItem[]> (src/types/plugin.ts), and docs/docs.md describes no other way to say "no more pages". Returning [] past the last page is how plugins in this repo mark the end of results: about 46 of them return [] when pageNo > 1 or past the end, for example daotekno, novel543, konkon, kakuyomu and lightnovelworld. The Next Page button you mention is in the repo's playground (src/components/search-novels.tsx). It's a manual pager that replaces the results and is enabled whenever the current page has results, so every one of those plugins shows "No results found" on the page after its last one. That's playground behaviour, not something this plugin can change. This site's /search-live endpoint returns every match in one response, so page 1 is complete.
There was a problem hiding this comment.
You're right. searchNovels has no pagination metadata or end-of-results signal, and returning [] for pageNo > 1 is consistent with the repository's existing plugin convention. The “No results found” state is a playground pager limitation, not a defect this plugin can address through the PluginBase API. I'll withdraw this finding; no change is needed in empirenovel.ts.
Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.
This branch has not been deployed
1 participant
Closes #2498
Adds a standalone plugin for Empire Novel (English). It's a custom Laravel site, not one of the multisrc themes.
What it supports
/novels-list, paged, with Category and Status (Ongoing / Completed / Abandoned) filters. The site has no popularity ranking, and it ignores sort parameters on GET, so this list is alphabetical, the same as the site's own catalog./?page=N)./search-live?q=, the JSON endpoint behind the site's search box. It returns every match in one response, so page 2 and later return an empty list./select-partial/<slug>/<chapter>) in a single request. Chapters are listed oldest first. The site doesn't show chapter titles in its lists, so chapters are named "Chapter N".#read-novel. Script, iframe, object, embed and form elements are removed, along with allon*attributes andjavascript:URLs.Cloudflare
Every URL on the site, including
robots.txt, returns a Cloudflare managed challenge (cf-mitigated: challenge) to plain HTTP clients and to headless Chromium. So whennpm run check:pluginruns from Node, it can only report:The CI Plugin Live Check will likely report INCONCLUSIVE for the same reason. The plugin doesn't override the User-Agent, so it should work with the cookie the app gets when the challenge is solved in its WebView. I haven't tested that in the app. When a request gets a 403 or 503, the plugin shows the same message other plugins here use (
novel543,truyendich), asking the user to open the plugin in WebView to solve the challenge. Other HTTP errors still showRequest failed: <status>.How it was tested
scripts/live-check-plugin.js, and ran it in Node withfetchsending each request from inside that browser tab (same cookies). Against the live site:popularNovels: page 1 and page 2 (30 novels each, different novels),category=romance+status=2, and latest pages 1 and 2 (18 each)searchNovels('innkeeper')returns The Innkeeper; page 2 returns[]parseNovel('novel/the-innkeeper'): all metadata filled; 2456 chapters, Chapter 1 through Chapter 2456 in order.novel/princehas 11 chapters and status Completed.parseChapter: The Innkeeper chapters 1 and 2456 and ½ Prince chapters 1 and 11 returned full text with noon*attributes orjavascript:URLs.onclick,onerror,<script>,<iframe>and an obfuscatedjava\tscript:href. All of them were removed.eslintandprettier --checkpass on the new file, andnpm run build:compilepasses. (npm run lintstill reports errors, but they are pre-existing ones inrewayatfans.tsandwetriedtls.ts.)This PR was written by an AI agent (Claude). No human has reviewed it yet, so please review it with that in mind.