Paste this whole file into a fresh chat to resume. Project: SMF mod (PDFBBCode class, PDFBBC.php) that adds a [pdf] BBCode tag rendering PDFs via a self-hosted, client-side Mozilla PDF.js viewer in an iframe — plain URL form, attachment-ID form, and per-post autodisplay toggle. Zero core-file edits; everything goes through SMF's own integration hooks (2.1.x) or an install-time hook-registration script (2.0.x, which has no hook auto-loading).
| File | Status | Use it? |
|---|---|---|
PDFBBC.php |
v2.22 — single validatePDF() entry point dispatching to validateUrl/validateAttachment by is_array($data). Debug scaffolding (unconditional error_log, [PDFBBC DEBUG: ...] messages) was flagged for removal but never confirmed stripped — check before calling this clean. |
Yes — current live file |
package-info.xml |
v2.22 — 2.1 block now includes pdf_display_patch_21.xml; 2.0.x block untouched |
Yes |
pdf_display_patch_21.xml |
New this session. Patches Subs-Attachments.php's loadAttachmentContext() (adds is_pdf) + Display.template.php (echoes the iframe when shouldAutoDisplay() is true) |
Yes — 2.1.x only |
pdf_display_patch.xml |
Original, 2.0.x-only. Patches Display.php directly (fork-specific anchor, doesn't exist on stock 2.1) |
Yes — 2.0.x only, unchanged |
pdf_register.php / pdf_unregister.php |
2.0.x hook registration via install-time code action | Yes, unchanged |
pdf.gif / pdf.png |
Toolbar icons — .png required on 2.1 (SCEditor CSS hardcodes it), .gif for 2.0.x |
Yes, unchanged |
pdfjs/ dir |
Bundled PDF.js viewer + its own .htaccess for .mjs/.wasm/.map MIME types |
Yes, unchanged |
pdf_bbcode.english.php |
Language strings | Yes, unchanged |
readme.txt |
Rewritten this session — fixed a stray ] typo, documents the "2.1.x needs filler content between tags" quirk |
Yes — current |
test_harness.php |
Standalone CLI script, calls validatePDF() directly bypassing SMF's parser entirely. Diagnostic only — not part of the shipped package |
Keep for future debugging, don't ship |
Duncan85:PDF_Tag (old mod line) |
Dead, abandoned, unrelated lineage — checked and ruled out as a suspect this session | No — ignore entirely |
[pdf] forms (unparsed_content URL form, unparsed_equals_content attachment/toggle form) register correctly via add() → integrate_bbc_codes on both branches; confirmed by grepping the actual tagged v2.1.7 SMF source (cloned from GitHub), not from memory or assumption.unparsed_equals_content (or unparsed_content) when there is zero characters of content between the opening and closing tags. [pdf=attach-01][/pdf] and [pdf=autodisplay][/pdf] never reach validatePDF at all on 2.1.x. Workaround (permanent, documented in readme): always put filler content between the tags on 2.1.x — [pdf=attach-01]x[/pdf]. Not needed on 2.0.19, which has never shown this quirk.pdf_display_patch.xml was never wired into the 2.1 install block in package-info.xml at all (only ever in 1.0 - 2.0.99). Even if it had been, its search anchor ('is_approved' => $attachment['approved'],) only exists in the customized 2.0.19 fork's Display.php — stock 2.1.7 builds that array in Subs-Attachments.php's loadAttachmentContext() instead, a different file. Fixed via the new pdf_display_patch_21.xml.autodisplay/noautodisplay flag-setting logic (self::$autoDisplay[$msgId], read via shouldAutoDisplay()) is internally correct in isolation, independent of the parser-matching question above — these were two separate, stacked bugs, not one.currentMsgId() works on both branches: $context['ila']['msg'] (set by the already-installed ILA mod, 2.0.19-fork-only mechanism) tried first, falls back to self::$capturedMsgId (populated via a genuine integrate_pre_parsebbc hook, confirmed to exist on stock SMF 2.1, registered in the 2.1 install block)..pdf attachments and confirmed rendering both, after the display-patch fix).attach-NN is a 0-indexed position among the current post's own .pdf attachments (not a global attachment ID, deliberately scoped to the post it's posted in — no cross-post/cross-topic lookup, explicitly rejected as having no value in earlier iterations).error_log() line and [PDFBBC DEBUG: ...] messages out of validateAttachment in PDFBBC.php, and bump the version string off 2.21-debug-merged to a clean 2.22 — flagged, not confirmed done.attach-NN form on 2.1.7 were not independently retested after the pdf_display_patch_21.xml fix went in — only autodisplay was explicitly reconfirmed live. Worth a quick pass if a regression ever shows up on those two specifically.autodisplay opt-in vs opt-out) — currently opt-in/default-off, a live, easily-revisited decision from earlier in the project, not touched this session.None outstanding — v2.22 is confirmed working on both live branches; this checkpoint is being archived to the forum post to close out the thread. If resuming, start with: confirm whether the debug-scaffolding strip (above) was done, and if not, do that before calling this build genuinely "clean."