Transcript — Andrew & Claude — 25–26/09/2026 (AEST)
User — attached listatt_bbcode_v6.12.zip
bug in ListAtt - stops at 50 attachments! WTF - it should be 200 atleast
Claude
Claude: [25/09/2026--23:49:31:654 AEST]
I checked v6.12 and there's no 50 limit anywhere in ListAtt. fetchAttachments() runs SELECT … WHERE a.id_msg = {int:msg} AND a.approved = 1 with no LIMIT. The render loop goes through every row, there's no array_slice, and no CSS max-height or overflow could hide rows. If the database has 200 approved attachments on the message, ListAtt shows 200.
So the cap is almost certainly happening before ListAtt runs, when the files are saved to the post. Three likely causes, in order:
attachmentNumPerPostLimit. If it's 50, SMF refuses anything beyond that, so only 50 are ever stored.approved = 1, so any attachment waiting for approval won't appear.max_file_uploads. This only matters if you upload in one batch. Its default is 20, though, so it's less likely to explain exactly 50.This query will tell you which it is (swap in your table prefix and the message ID):
SELECT attachment_type, approved, COUNT(*)
FROM smf_attachments
WHERE id_msg = 12345
GROUP BY attachment_type, approved;attachment_type=0, approved=1 is 50, the files were never stored, and cause 1 or 3 applies.approved=0, that's cause 2.A separate bug I found: the query doesn't filter on attachment_type = 0. SMF stores image thumbnails as their own rows (attachment_type = 3) with the same id_msg. So any post with images gets extra thumbnail entries listed, and they inflate the "Attachments (N)" count in the heading. The fix is one line: add AND a.attachment_type = 0 to the query. I can package that as v6.13 through Package Manager if you want it.
User — attached two screenshots (each attached twice)
User (sent while Claude was working)
... and fix the bug pls
Claude — delivered listatt_bbcode_v6.13.zip
Claude: [25/09/2026--23:53:10:261 AEST]
v6.13 is attached, and it installs through Package Manager as usual. There was never a limit of 50. The screenshots show the post has 56 attachments (0–55) but ListAtt only listed 00–50, and the five missing are the five most recently added: unclip_overflow.txt, Unclip_Overflow_JS_Fix.md and .pdf, and psw_process_monitor.md and .pdf.
Cause: SMF saves a copy of each rendered post (a cache) and finds that copy by the post's text. Adding attachments doesn't change the text, so SMF kept showing the [listatt] table as it was before the five were added. ListAtt's own query was never run again.
What v6.13 changes:
render() now puts invisible markers around its output. A new page-output hook (integrate_buffer, ListAttBBC::bufferFill) replaces each marked box with a fresh list from the database on every page view, so SMF's cache can't affect it. If the hook fails for any reason, the page shows the old cached copy exactly as now, so nothing gets worse.live HH:MM:SS when the fresh list is showing, or bbc HH:MM:SS if the hook isn't registered. You can see which one ran.AND a.attachment_type = 0, so image thumbnails no longer appear as extra attachments.package-info.xml and readme are updated, and the uninstall script removes the new hook.I tested it with a fake database: it rendered and cached 51 rows, then with 5 more added the page showed all 56. The custom title, surrounding page content and pages without a list all came through unchanged. It hasn't been tested on your forum yet.
If it still stops at 50: check the end of the banner.
live: the database really holds only 51 of the attachments. Run the GROUP BY query from my earlier message to see why.bbc: the hook didn't register.User
Build a MD and PDF transcript instructions: Transcribe the entire conversation, DO NOT EMBELLISH OR SUMMARISE UNLESS YOU FIRST HAVE IT VERBATIM, Expand all Query and Reply windows if applicable, Preserve formating, Embed any graphics, Do not lose a single word, Suggest a few names derived from a terse summary and pick the best but be as fast as possible.