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.
| 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. |
[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.//host/path).[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.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.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.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.dlattach URLs download correctly when hit directly — attachment integrity/permissions are not in question.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.[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.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.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.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."