The "LMV - Liteweight Markdown Viewer" BBCode (with autodisplay and theming)

[Chip (OP)]

📎 Click on me to view the list of attachmentsTheme: Deep IndigoPink & PurpleSlate TechDark Cyan

#	File	Size	DL
1	MD_SYNTAX_MANUAL.md	7.8 KB	⬇️
2	Final CHECKPOINT.md	9.8 KB	⬇️
3	gfm_combined_spec.md	232.7 KB	⬇️
4	README-lmv_bbcode.md	5.8 KB	⬇️
5	chatlog-redacted.pdf	400.6 KB	⬇️
6	lmv_bbcode_v2.2.zip	26.4 KB	⬇️
7	lmv_bbcode_v2.7.zip	27 KB	⬇️
8	LMV BBC Updates.pdf	252.3 KB	⬇️
9	Conflicts between MDBBC.php and PDFVVC.php and LMVBBC.php as seen in the PDF and LMV conflcts -- there should be another PDF listing the workcound bbcodes the inpost in question.pdf	11.6 MB	⬇️

The LMV - Liteweight Markdown Viewer

Conflict testing

Display by URL to its webroot filename
[pdf]https://forum.drugs-and-users.org/PIHKAL-PEA.pdf[/pdf]

[b]Display by attachment id[b]
[pdf=attach-0]Display the first valid PDF attachment[/pdf]

Display by attachment id


APut PDF AUTO on aas the last PDF BBC tag

📎 Click on me to view the list of attachmentsTheme: Deep IndigoPink & PurpleSlate TechDark Cyan

#	File	Size	DL
1	MD_SYNTAX_MANUAL.md	7.8 KB	⬇️
2	Final CHECKPOINT.md	9.8 KB	⬇️
3	gfm_combined_spec.md	232.7 KB	⬇️
4	README-lmv_bbcode.md	5.8 KB	⬇️
5	chatlog-redacted.pdf	400.6 KB	⬇️
6	lmv_bbcode_v2.2.zip	26.4 KB	⬇️
7	lmv_bbcode_v2.7.zip	27 KB	⬇️
8	LMV BBC Updates.pdf	252.3 KB	⬇️
9	Conflicts between MDBBC.php and PDFVVC.php and LMVBBC.php as seen in the PDF and LMV conflcts -- there should be another PDF listing the workcound bbcodes the inpost in question.pdf	11.6 MB	⬇️

The LMV - Liteweight Markdown Viewer

Version 3.0+ makes the common code MDBBC.php publically callable

The stable version without auto-CSS installation is lmv_bbcode_v2.2.

The latest version with auto-CSS installation is lmv_bbcode_v2.7.

Both are compatible with SMF 2.0.x and 2.1.x

Examples

Remote URL check:

📝 DEMO2.mdTheme: Deep IndigoNo Theme (Plain)Pink & PurpleSlate TechDark Cyan

PDF BBCode v3.0

Fixed

• Black/404 viewer on [pdf=attach-NN] and [pdf]url[/pdf]: the inner PDF URL was being urlencode()'d before being passed to PDF.js's file= param. PDF.js 6.2.108 doesn't decode that value, so it tried to fetch a literal path containing %3F/%3D/%3B and got a 404.
• Same bug, same fix, in the autodisplay path (pdf_display_patch.xml and pdf_display_patch_21.xml) — urlencode($attachment['href']) removed.
• Removed schemeless() stripping on the inner PDF URL. PDF.js 6.2.108 needs an explicit http:/https: scheme to pick a fetch adapter — without it, "No available adapters." schemeless() is still used for the outer viewer.html iframe src, which was never broken.
• 2.0.x install block was missing <require-dir name="pdfjs" destination="$themedir" /> entirely — added, matching the 2.1.x block.

Install location

pdfjs/ installs to $themedir (e.g. Themes/default/pdfjs), not $boarddir.

Notes

• Live production was found running an unpatched, several-versions-behind PDFBBC.php despite package history showing v2.22 as reinstalled — several rounds of "the fix didn't work" were actually "the fix was never deployed." Worth checking the live file's VERSION const at the start of future debugging sessions.
• Treat this as a full Package Manager uninstall + reinstall, not a hot-swap — the 2.0.x block now installs a directory it didn't before.

-- remote URL
 
Attachment by DB ID 400.:

⚠️ Attachment #1 not found or pending save.

  -- attachment by DB ID

[lmv=0][/lmv] -- auto-detect (last .md attachment)

Attachment by id number 0:

📝 README-lmv_bbcode.mdTheme: Deep IndigoNo Theme (Plain)Pink & PurpleSlate TechDark Cyan

lmv_bbcode — Lightweight Markdown Viewer

Version: 2.0 Status: Live, fully tested Tag: [lmv]...[/lmv]

A standalone SMF BBCode mod that renders .md attachment or URL content inline in a post, using the existing MDParser.php engine from md_bbcode. No iframe, no external viewer — just clean inline Markdown rendering.

Architecturally mirrors pdf_bbcode (URL form, attach-NN position-based attachment form, autodisplay toggle, currentMsgId() pattern) but is a fully separate mod from both pdf_bbcode and md_bbcode, so neither is disturbed by changes here.

Commands (Tag Forms)

Command	Form	Behavior
URL	[lmv]https://example.com/path/to/file.md[/lmv]	Fetches and renders the Markdown file at the given URL
Attachment by ID	[lmv=ID][/lmv]	Renders a specific attachment by attachment ID
Auto-detect	[lmv=attach-01][/lmv]	Position-based reference to the Nth attachment on the post — no literal attachment ID needed
Force scroll	[lmv=scroll]...[/lmv] / [lmv=scroll-N][/lmv]	Forces the scroll class regardless of CSS default
Force no-scroll	[lmv=noscroll]...[/lmv] / [lmv=noscroll-N][/lmv]	Forces the .lmv-viewer-noscroll override class
No-scroll + attach-NN	[lmv=noscroll-attach-01][/lmv]	Combines auto-detect with the no-scroll override

All modifiers are composable with both the URL and attachment forms. With no modifier, scroll behavior falls through to the CSS default (tri-state: unset → CSS default, scroll → forced on, noscroll → forced off).

CSS

• .lmv-viewer-noscroll — override rule added to force the no-scroll viewer state when the noscroll modifier is used; lives in lmv's own stylesheet, not shared with md_bbc
• No shared CSS file with md_bbc currently exists — each mod ships its own stylesheet. A shared code/asset directory between md_bbc and lmv_bbc (mirroring how pdf_bbc uses a shared PDF.js library) was discussed as a future step but deliberately deferred to keep the initial build simple and portable
• Theming pass (to match the existing subtle theme set already built for the PDF search UI and listatt) is still on the to-do list, not yet done

Shared Code with md_bbc

lmv does not have its own Markdown parser. It calls MDParser.php from md_bbc directly as a standalone callable parse function — one engine, two consumers. This was a deliberate choice to avoid maintaining a second parser, while keeping lmv_bbc as a fully separate, independently installable mod so nothing here touches or destabilizes md_bbc's own [md] tag logic.

Where lmv Fits — the Document Management System

lmv is one of five components making up the forum's homegrown Document Management System:

Component	Role
md_bbc	[md] tag — renders Markdown directly in a post; owns MDParser.php, the shared rendering engine
pdf_bbc	[pdf] tag — renders PDF attachments inline via PDF.js; architectural template that lmv was deliberately built to mirror
lmv	[lmv] tag — renders .md attachment/URL files inline, reusing md_bbc's MDParser.php
ISE	"The ISE Project" (Intelligent Search Engine) — the custom Python post-search engine (search.py), replacing/augmenting native SMF search, with its own query logger, tokenizer, and ranking engine
ISEpdf	ISE's PDF-focused sibling — PDFIndexer.py/PDFsearch.py, indexing the PDF library (magic-byte discovery, pdftotext -layout extraction, page-level word index) and surfacing results through the "ISEpdf" search-engine dropdown option

Together: md_bbc, pdf_bbc, and lmv handle rendering documents inline in posts, while ISE and ISEpdf handle finding them — indexing and searching post content and the PDF library respectively. pdf_bbc's architecture (tag-form conventions, install-package pattern) was the template lmv copied; md_bbc's parser is the engine lmv runs on top of.

Architecture

• LMVBBC.php — tag registration and rendering, mirrors PDFBBC.php exactly in structure
• Rendering engine — reuses MDParser.php from md_bbcode via a standalone callable parse function (no duplicate parser)
• No shared library yet — a shared code directory between md_bbcode and lmv_bbcode (analogous to pdf_bbcode's shared PDF.js library) was considered but deferred; each mod is currently self-contained

Install Notes

• Core BBC-tag registration (URL form + attachment form) is the stable, confirmed-working install path.
• The original v1.2 install package also attempted a Display.php / Display.template.php autodisplay patch, mirrored from pdf_bbcode's own display patch. This caused install failures:
  • Display.php patch added key is_lmv, but Display.template.php checked is_md (mismatch)
  • lmv_unregister.php referenced a nonexistent method (capturePreParse vs the actual captureMsgId)
  • Modification test failures likely stemmed from pdf_bbcode already having patched nearby anchors in the same core files
  • This display patch is not required by any current lmv feature and was stripped from the package
• If rebuilding the install zip, build it on Windows, not on the server — PclZip on the server rejects zips containing streaming data-descriptors (same issue historically hit with pdf_bbcode).
• lmv_register.php does not register integrate_pre_parsebbc on this SMF 2.0.x fork (hook doesn't exist on this branch), so no equivalent fix was needed there.

Confirmed Working (Live)

• URL form
• Attachment form ([lmv=ID])
• attach-NN auto-detect form
• scroll / noscroll per-tag override, including the .lmv-viewer-noscroll CSS rule

Next Steps

• Theming pass to match the existing subtle theme set already built for the PDF search UI and listatt

nth .md attachment on the post starting from 0

Attachment by id number 1:

📝 Final CHECKPOINT.mdTheme: Deep IndigoNo Theme (Plain)Pink & PurpleSlate TechDark Cyan

Checkpoint: MD BBCode Mod — GFM Conformance Pass

Purpose: bring Andrew's SMF Markdown BBCode mod (MDParser.php/MDBBC.php) up to a level of GFM spec conformance good enough to satisfy SMF's lead dev, who recommended testing against the full GFM spec (https://github.github.com/gfm/) after reviewing the mod for possible official SMF inclusion.

Files / components

File	Status	Use it?
MDParser.php (this session's patched version, attached)	Patched: emphasis rewrite, loose/tight lists, indented-code blank-line merging, link destination fixes, code span fix, bare-URL/www/email autolinking	Yes — this is the current working version, supersedes the originally-uploaded copy
MDBBC.php (originally uploaded)	Untouched this session — no changes were needed	Yes, unchanged
MD_SYNTAX_MANUAL.md (attached)	Full table of every currently-supported syntax element + raw/rendered examples, generated from the actual current parser	Yes — hand this to anyone (including SM) who wants to see current scope
extract_spec.py (attached)	One-time script: pulls cmark-gfm's test/spec.txt and converts it to spec.json (672 examples, tagged by section/extension)	Only needed if spec.json (attached separately) is ever lost — otherwise skip straight to run_tests.php
spec.json (attached)	Already-extracted output of extract_spec.py — the 672-example test suite itself	Yes — drop it next to MDParser.php and run_tests.php, no re-fetch needed
run_tests.php (attached)	Runs MDParser.php against every example in spec.json, writes results.json	Re-run after every parser change
analyze.py (attached)	Reads results.json, applies a "cosmetic-diff-tolerant" normalizer (strips our own CSS classes, rel= attribute, self-closing-tag style, tag-per-line formatting) to separate real bugs from harmless serialization differences; writes real_failures.json and prints per-section pass rates	Re-run after every run_tests.php run

Verified facts — don't re-check

• The GFM spec's machine-readable test suite lives at test/spec.txt in github/cmark-gfm on GitHub (raw: raw.githubusercontent.com/github/cmark-gfm/master/test/spec.txt), in a literate format (fenced blocks marked `...`` example [extension-name] , input, a lone . line, expected HTML, closing fence). extract_spec.py parses this correctly — 672 examples extracted, matching the known canonical GFM spec size.
• PHP is not preinstalled in this environment; apt-get install -y php-cli works (no sudo needed, container runs as root) and pulls PHP 8.3.
• Raw pass rate (exact string match) is a bad metric here — many of the mod's own intentional additions (CSS classes md-code-block/md-table, the rel="noopener noreferrer nofollow" security hardening on links, HTML5-style non-self-closing tags) cosmetically differ from the reference renderer's output without being bugs. Always read the normalized pass rate from analyze.py, and treat real_failures.json (not raw results.json) as the list of genuine bugs.
• Confirmed baseline at session start: 138/672 raw, 282/672 (42%) normalized.
• Confirmed after this session's fixes: 213/672 raw, 424/672 (63.1%) normalized. This is the final number for now — no further enhancement work planned. Andrew explicitly instructed a stop after this round: debug what exists, sync the manual, produce the final gap report (GFM_CONFORMANCE_REPORT.md), and stop. Do not resume spec-conformance chasing in a future session without Andrew explicitly asking for it again.
• List parsing fixed further this session: bare markers with nothing after them (- alone on a line) are now recognized as empty list items, and the sibling-vs-nested-item decision now compares a new marker's indent against the current item's actual content column instead of a flat baseIndent+1 - this was causing lists like - foo\n - bar\n  - baz (each indented one more space than the last) to nest each item inside the previous one instead of staying siblings, which is what CommonMark actually specifies.
• Two more real bugs found and fixed in the final debugging pass: image alt text didn't handle nested brackets (same class of bug as the earlier link-text fix, just never applied to images) and now flattens nested markup to plain text per spec; and the emphasis delimiter algorithm had a real bug where ***text*** left stray unmatched asterisks outside the <strong> tag instead of nesting into <em><strong>text</strong></em> - found by systematically re-rendering every example in the manual against actual code output as part of syncing the two, not by chasing the spec suite further.
• The manual itself had a wrong example (***both*** was documented as rendering <strong><em> when the correct nesting is <em><strong>) and two other real-output mismatches (autolinks actually include rel="noopener noreferrer nofollow", GFM tables use style="text-align:X" not align="X") - all fixed during the sync pass.
• Confirmed ceiling: literal 672/672 is not a sensible goal. Reference-style links/link-reference-definitions and full raw-HTML-block parsing are deliberately out of scope (~100+ examples) — the latter because supporting it would conflict with the mod's "escape everything, selectively re-decode" security model, which the prior external security review specifically hardened. Realistic achievable ceiling is roughly 550–600/672 (~85-90%).
• Confirmed via direct testing against the npm commonmark reference package: one spec example (__foo, __bar__, baz__) has an expected output in cmark-gfm's own spec.txt that disagrees with what the reference implementation's actual delimiter-stack algorithm produces (nested vs. flat <strong>). Traced this to the algorithm level, not a wasted rabbit hole — treat as a known, accepted gray area, do not re-derive.
• Andrew's stated priority order (confirmed, his words): emphasis + list nesting first (highest-traffic, most complaint-prone), then links + blockquote laziness, then headings/tables (already solid), then fenced/indented code + thematic breaks/autolinks/escaping (lowest priority).
• Andrew has separately built a syntax reference manual for the [md] tag on his own and confirmed it renders well — this may or may not be the same document as MD_SYNTAX_MANUAL.md above; worth asking rather than assuming they're the same artifact.
• Forum BBC policy: all standard BBCode tags are disabled except [nobbc] (kept enabled/exempt as the literal-text escape hatch) and [md] itself. This is stated in MD_SYNTAX_MANUAL.md's header warning and in MDBBC.php's top doc-comment — check both stay in sync if the policy ever changes.

Open items (decisions, not blockers)

• Base angle-bracket autolink (<scheme://...>) only recognizes http/https/ftp/ftps/mailto. CommonMark's actual rule allows any scheme matching [a-zA-Z][a-zA-Z0-9+.-]{1,31}:. Decision needed: is broadening this worth it for a forum (real schemes people might paste: irc://, magnet:, steam://), or is the current allowlist a deliberate security stance worth keeping as-is?
• Link destinations don't yet balance parens ((foo(bar)) inside a bare URL) or do full percent-encoding of unsafe characters — only literal-space encoding is implemented. Decision needed: how much of this edge case is worth chasing given forum posts rarely paste raw unencoded URLs with parens.
• Blockquote laziness (continuation lines without a leading >) is now fixed for the common case (paragraph continuation only, not headings/lists/fences/thematic breaks/indented code, and not after a blank line). Remaining edge case: laziness tracking inside an already-open non-paragraph block within a quote (e.g. an unclosed fence) isn't precise - low priority.
• List "same list vs new list" rules fixed this session: a changed bullet character (-/*/+) or ordered delimiter style (. vs )) now correctly starts a new list; an ordered list can only interrupt a paragraph if it starts at 1.
• Link destinations now do real percent-encoding (HTML entity decode, then percent-encode any byte outside the URL-safe set while preserving existing valid %XX sequences) and correctly balance parentheses via a recursive regex ([link](foo(and(bar))) works). Caution for future edits: adding a named recursive group inside an existing capturing group shifts the numeric index of every group after it — this caused a real regression this session (title text silently became a duplicate of the URL) until the shifted indices were corrected. Double-check group numbering with a quick preg_match test whenever the link/image regex structure changes again.
• Link destinations still don't do full percent-encoding (backslash → %5C, HTML entities like ä → %C3%A4, non-ASCII chars, quotes in a titleless destination) — only literal-space encoding is implemented. This is the largest remaining Links gap (roughly a dozen of the remaining ~53 failures).
• Angle-bracket link destinations spanning a literal line break ([link](<foo\nbar>), which per spec should NOT be a valid link) aren't rejected, because paragraph-line-joining happens at the block level before this inline check ever sees the newline — a real but low-priority structural limitation.
• Whether to reconcile/merge with Andrew's own separately-built syntax manual, or keep MD_SYNTAX_MANUAL.md as this session's independent version.

Next actual action

Andrew has explicitly ended spec-conformance work as of 424/672. Do not resume it unprompted. If a fresh session picks this project back up, the correct default action is: read GFM_CONFORMANCE_REPORT.md for the full accounting, treat the current MDParser.php/MD_SYNTAX_MANUAL.md as final and in sync, and only touch the code again if Andrew explicitly asks for a specific fix - not "keep improving conformance" in general.

nth .md attachment on the post starting from 0

Turn on autodisplay and override the ID and id numbers:

[lmv=autodisplay] ON [/lmv] --  toggle  automatic attachment display on

 -- toggle automatic attachment display off

Display by attachment id

📝 Inline MarkdownTheme: Deep IndigoNo Theme (Plain)Pink & PurpleSlate TechDark Cyan

Session Checkpoint — 2026-08-07/08

1. PDFIndexer.py cron fix — DONE, confirmed working

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP

[smfadmin]

📎 Click on me to view the list of attachmentsTheme: Deep IndigoPink & PurpleSlate TechDark Cyan

#	File	Size	DL
1	LMV and PDF BBCode Conflict Workaround.txt	4.6 KB	⬇️
2	LMV and PDF BBCode Conflict Workaround_.pdf	1.4 MB	⬇️
3	Conflicts between MDBBC.php and PDFVVC.php and LMVBBC.php as seen in the PDF and LMV conflcts -- there should be another PDF listing the workcound bbcodes the inpost in question.pdf	11.6 MB	⬇️

The LMV - Liteweight Markdown Viewer

Topic bumped
Post Merged: Yesterday at 08:54:16 PM

Conflict testing

Display by URL to its webroot filename
[pdf]https://forum.drugs-and-users.org/PIHKAL-PEA.pdf[/pdf]

[b]Display by attachment id[b]
[pdf=attach-0]Display the first valid PDF attachment[/pdf]

Display by attachment id


APut PDF AUTO on aas the last PDF BBC tag

📎 Click on me to view the list of attachmentsTheme: Deep IndigoPink & PurpleSlate TechDark Cyan

#	File	Size	DL
1	LMV and PDF BBCode Conflict Workaround.txt	4.6 KB	⬇️
2	LMV and PDF BBCode Conflict Workaround_.pdf	1.4 MB	⬇️
3	Conflicts between MDBBC.php and PDFVVC.php and LMVBBC.php as seen in the PDF and LMV conflcts -- there should be another PDF listing the workcound bbcodes the inpost in question.pdf	11.6 MB	⬇️

The LMV - Liteweight Markdown Viewer

Version 3.0+ makes the common code MDBBC.php publically callable

The stable version without auto-CSS installation is lmv_bbcode_v2.2.

The latest version with auto-CSS installation is lmv_bbcode_v2.7.

Both are compatible with SMF 2.0.x and 2.1.x

Examples

Remote URL check:

📝 DEMO2.mdTheme: Deep IndigoNo Theme (Plain)Pink & PurpleSlate TechDark Cyan

PDF BBCode v3.0

Fixed

• Black/404 viewer on [pdf=attach-NN] and [pdf]url[/pdf]: the inner PDF URL was being urlencode()'d before being passed to PDF.js's file= param. PDF.js 6.2.108 doesn't decode that value, so it tried to fetch a literal path containing %3F/%3D/%3B and got a 404.
• Same bug, same fix, in the autodisplay path (pdf_display_patch.xml and pdf_display_patch_21.xml) — urlencode($attachment['href']) removed.
• Removed schemeless() stripping on the inner PDF URL. PDF.js 6.2.108 needs an explicit http:/https: scheme to pick a fetch adapter — without it, "No available adapters." schemeless() is still used for the outer viewer.html iframe src, which was never broken.
• 2.0.x install block was missing <require-dir name="pdfjs" destination="$themedir" /> entirely — added, matching the 2.1.x block.

Install location

pdfjs/ installs to $themedir (e.g. Themes/default/pdfjs), not $boarddir.

Notes

• Live production was found running an unpatched, several-versions-behind PDFBBC.php despite package history showing v2.22 as reinstalled — several rounds of "the fix didn't work" were actually "the fix was never deployed." Worth checking the live file's VERSION const at the start of future debugging sessions.
• Treat this as a full Package Manager uninstall + reinstall, not a hot-swap — the 2.0.x block now installs a directory it didn't before.

-- remote URL
 
Attachment by DB ID 400.:

⚠️ Attachment #1 not found or pending save.

  -- attachment by DB ID

[lmv=0][/lmv] -- auto-detect (last .md attachment)

Attachment by id number 0:
 unscrollablle 1st  nth .md attachment on the post starting from 0

Attachment by id number 1:

⚠️ No .md attachment at index 1 for message #49431 (currentMsgId() returned this value).

nth .md attachment on the post starting from 0

Turn on autodisplay and override the ID and id numbers:

[lmv=autodisplay] ON [/lmv] --  toggle  automatic attachment display on

 -- toggle automatic attachment display off

Display by attachment id

📝 Inline MarkdownTheme: Deep IndigoNo Theme (Plain)Pink & PurpleSlate TechDark Cyan

Session Checkpoint — 2026-08-07/08

1. PDFIndexer.py cron fix — DONE, confirmed working

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP (192.168.233.129).

• Root cause: LOG_PATH/WORD_INDEX_PATH/PDF_STORE_PATH were relative

  paths (ISE_Data/...), which broke under cron's CWD (apache's home   dir, not the script's directory) — PermissionError on   os.makedirs().

• Fix: anchored all three paths to ISE_ROOT, mirroring

  IndexBuilder.py's existing (working) convention exactly —   Path(__file__).resolve().parent.parent, overridable via an   ISE_ROOT env var (confirmed not set anywhere on this box).

• Tightened dev/live detection from a loose 192.168. prefix match to the exact dev IP