[3.0] Limits a print page to one page of posts - #9672
Open
albertlast wants to merge 1 commit into
Open
albertlast wants to merge 1 commit into
albertlast wants to merge 1 commit into
Conversation
Every other view that shows a lot of a topic at once is capped. The "All" view refuses a topic longer than enableAllMessages, and a feed takes at most 255 items. The print view took the lot: one query for every message in the topic, each one parsed and held in memory, for anyone who could read the board. It now shows the same number of posts the admin is willing to show in the "All" view, and pages through the rest with a page index of its own. Forums that never show "All" get a limit of 250 rather than none, since 0 there means the link is off and not that a request may render anything it likes. The rest follows from paging: the page index and the text/images links carry the current start, the poll prints once with the first page rather than on top of every page, and an out of range start redirects the way a topic page does. The page links are plain text because the print page loads neither the theme's icon CSS nor its JavaScript, so the usual arrows and the expanding page list would both be dead there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: albertlast <mathiaspapealbert@hotmail.com>
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
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
?action=printpagerenders a whole topic in one request: one query for every message in it, each one parsed and held in memory at once, available to anyone who can read the board. Every other view that shows a lot of a topic at once is capped — the "All" view refuses a topic longer thanenableAllMessages, a feed takes at most 255 items — and the print view was the exception.This gives it the same treatment. A print page now shows as many posts as the admin is willing to show in the "All" view and pages through the rest, so a long topic is still printable in full but no single request builds all of it. Forums that never show "All" get a limit of 250 rather than none, since
0in that setting means the link is off, not that a request may render anything it likes.The rest follows from paging:
@media printalready hides.print_options, so paper output is unchanged.This came out of a request on the community forum, reporting that the print view is a favourite target for scrapers, residential proxy botnets and aggressive crawlers, which use it to pull entire threads past pagination and exhaust FastCGI slots on shared hosting.
Other ways this could be done
The limit is not the only answer, and it is not exclusive with any of these. It was picked first because it bounds what one request costs no matter who sends it, while the rest gate who may ask — and a scraper that registers an account, or rides a residential proxy, walks past a gate.
print_topicboard permission. What the report asked for first, and the one that fits SMF's existing machinery best: per board, per membergroup, and the only wayspider_groupcould be made to restrict the print view, since today there is no permission there to deny. It is a much wider change — an entry inPermission.php, rows inSources/Db/Schema/v3_0/BoardPermissions.php, language strings,Topic::$permissions['can_print'], and a migration granting it to existing groups or every upgraded forum silently loses its print button. Note also that keeping upgrades non-breaking means granting it to guests, so "off for guests by default" would only ever be true of new installs.disable_print_topic. Cheapest of the lot, but it is a second ad-hoc setting covering a slice of what the permission system already models, and it leaves the request itself unbounded for everyone else.disable_print_topic, which exists today and turns the feature off for everybody. It is the only lever an admin has right now, which is rather the point of this PR.robot_no_indexon the page and disallows?action=printpagein the robots.txt it generates, so a well behaved crawler is handled; the rest is an.htaccessor WAF matter. That is what the report was doing already, and what it asked not to have to do.Testing
tests/Integration/Http/TopicPrintTest.phpis the regression test. Before the change it fails with "the print page rendered the whole topic instead of one page of it — Failed asserting that 5 is identical to 2", and again on the missing page links.tests/Unit/TopicPrintTest.phpcovers where the limit comes from, including the0fallback..docker/test.sh..0,.3and.6;;imagessurvives the page links;.2redirects to.0,.999to.6,.msg1to.0; nothing logged insmf_log_errors.Issues References (Fixes|Related|Closes)
🤖 Generated with Claude Code