My Claude Tasks CHECKPOINT Method

[Chip (OP)]

My suggested query;

"Give me a reloadable checkpoint file for [project name] that I can paste into a fresh chat. Include: a table of every file/component involved, its current status, and whether to use it or not; a 'verified facts — don't re-check' section for anything already confirmed so we don't waste tokens re-deriving it; open items that are decisions-not-blockers; and a single 'next actual action' line so a new session knows exactly where to pick up."

Claude will build this markdown file so you can reload it into a fresh context window (a new conversation) and restart whenever you want:

PDF BBCode Project — Checkpoint v2 (paste into a fresh chat to resume)

Forum: drugs-and-users.org — SMF 2.0.19, CentOS 6.10 (Dev box at 192.168.233.129), default theme Goal: a [pdf][/pdf] BBCode tag rendering PDF URLs/attachments via self-hosted Mozilla PDF.js, with three forms: plain URL, real attachment ID, and [pdf=0] auto-detect (finds the PDF attached to the same post).

Supersedes: an earlier checkpoint describing a package-manager-based Duncan85:PDF_Tag 1.3/1.4 line — that approach is abandoned. Current work is a from-scratch custom mod, package ID Egerszegi:PDF-bbcode.

Canonical files (as of 2026-07-21)

File	Status	Use it?
PDFBBC.php	Current canonical version. Debug/trace output stripped. Contains: scheme-relative URL fix (avoids PDF.js "file origin" error), request-based topic ID resolution (fixes dlattach's topic/attach mismatch block), and a client-side JS auto-detect for [pdf=0] deferred to DOMContentLoaded.	This is the one to install. Plain file swap over $sourcedir/PDFBBC.php — no hook changes since the original hook-based install.
package-info.xml	Unchanged since original install. Registers 3 hooks on the 2.1 branch (integrate_bbc_codes, integrate_bbc_buttons, integrate_pre_parsebbc); 2.0.x branch uses a <code> install action instead (see pdf_register.php). Version still says 2.1 (cosmetic mismatch vs. code's 2.2 — harmless).	Reference — no change needed right now.
pdf_register.php	2.0.x branch's manual hook registration. Registers integrate_pre_parsebbc correctly by SMF's own API — but see verified facts below, this hook never actually fires on this fork.	Reference — harmless as-is.
pdf_unregister.php, pdf.gif, pdf_bbcode.english.php, pdfjs/	Unchanged supporting files.	Fine as installed.

Verified facts (don't re-check these)

• [pdf]https://.../file.pdf[/pdf] (webroot URL form) — confirmed working.
• [pdf=<ID>][/pdf] (real attachment ID) — confirmed working, but only when posted in the same topic the attachment actually belongs to — SMF's dlattach correctly blocks cross-topic attachment references as a permission check, not a bug.
• Fixed and confirmed: PDF.js's "file origin does not match viewer's" error was a scheme (http vs https) mismatch — fixed by making all built URLs scheme-relative (//host/path).
• Fixed and confirmed: [pdf=ID] briefly regressed because $context['current_topic'] isn't reliably populated at render time — fixed by reading the topic ID from $_REQUEST['topic'] instead.
• Confirmed via grep on both Subs.php and Display.php: no hook point exists anywhere in either file that fires per-message with id_msg in scope on this SMF 2.0.19 fork. Subs.php's parse_bbc() only calls integrate_bbc_codes; Display.php only calls integrate_attachment_download. integrate_pre_parsebbc is registered correctly but never invoked — a server-side hook approach for [pdf=0] is a dead end on this fork.
• Confirmed from Andrew's actual Display.template.php (default theme): each post body renders as <div class="inner" id="msg_N">...</div>, and — if not fully consumed inline by the ILA mod — a sibling <div id="msg_N_footer" class="attachments smalltext"> lists attachment links. Both share the same numeric N. This is what the client-side auto-detect walks/queries.
• The attachment link's href is a dlattach URL and never contains .pdf — only the visible link text (the filename) does. Any DOM matching must check link text, not href.
• Raw dlattach URLs download correctly when hit directly — attachment integrity/permissions are not in question.
• A PDF.js console line like PDF <hash> [1.4 Skia/PDF m149...] (PDF.js: 4.0.379...) is PDF.js's own success log (prints once it's parsed the doc), not an error. Unrelated SyntaxError on action=head/action=body is the sachat live-chat widget, nothing to do with this mod.
• Lesson from earlier in the project, still true: adding/removing a hook requires a full Package Manager uninstall+reinstall; logic-only changes to an already-registered hook are a safe plain file swap.

Open items (decisions, not blockers)

1. [pdf=0] auto-detect status: unverified. Latest fix defers the DOM lookup to DOMContentLoaded (previous version ran too early, before the footer div existed in the parsed page). Last real-world test showed "a few blank lines" instead of the PDF — not yet diagnosed whether that's still an empty, unswapped placeholder <div class="pdfbbc-auto">, or an <iframe> that swapped in but is rendering blank. Needs Chrome DevTools → Elements (inspect that spot) + Console, on a desktop browser.
2. Dead code cleanup, not urgent. capturePreParse(), the $currentMsgId static property, and findPdfAttachment() in PDFBBC.php are unused now that auto-detect is client-side — harmless to leave, safe to strip whenever convenient. Same for the integrate_pre_parsebbc hook registration in package-info.xml/pdf_register.php — dead but harmless since it's never called.
3. Version numbering is cosmetic-inconsistent. PDFBBC.php's docblock/VERSION const say 2.2; package-info.xml still says 2.1; past zip filenames used their own ad hoc numbering. No functional impact — reconcile whenever, not before.

Next actual action

Open the test post (topic 7587, msg 49312, or a fresh one) containing [pdf=0][/pdf] in Chrome DevTools on desktop → Elements panel: find what's actually sitting where the tag should render (still <div class="pdfbbc-auto"></div> empty, or a real <iframe> rendering blank) — and check Console for any errors. That determines whether the DOMContentLoaded fix worked or auto-detect needs another pass.

If resuming in a new chat: paste this whole file in, say "resuming PDF BBCode project," and pick up from "Next actual action."