Andrew's forum (drugs-and-users.org, SMF 2.0.19 fork, CentOS 6.10) has two BBCode mods with a real, currently UNRESOLVED bug: their theme CSS is not visibly rendering on live posts, even though the underlying tag/content logic works.
[ltv=...]...[/ltv], Lightweight Text Viewer) — file /var/www/html/Sources/LTVBBC.php, confirmed const VERSION = '2.3' live.[lmv], Lightweight Markdown Viewer) — file /var/www/html/Sources/LMVBBC.php, confirmed const VERSION = '3.3.4' live (though see "Known messy state" below — this file's provenance today was via a direct WinSCP copy, not a tracked Package Manager install).A [ltv] box renders structurally correct — collapsible arrow, search bar, theme <select> dropdown showing the right option selected (e.g. "Dark Cyan") — but with zero visual styling: no card background, no colors, no rounded corners, default browser widget appearance throughout. The content and JS-driven parts (search, theme dropdown value) work; the CSS does not visibly apply.
Both LTV and LMV emit their <style>/<script> block inline, embedded directly inside the post body content (i.e. as part of what the BBC tag's validate() callback returns), NOT via the page <head>. Every other <style>/<script> tag visible in this forum's real page source (checked via grep -A 20 "<style>" lmvhtml on an actual saved page source) lives in the <head>, injected by other installed mods (BBCode-YouTube2.css, md_bbcode.css, a signature "blinkme" <style> block, etc.) — none of those are comparable, since they're head-level, not post-body-level.
Open, untested hypothesis at time of handoff: something in this fork's post-rendering pipeline may be stripping or sanitizing <style>/<script> tags specifically when they appear inside post body content, while leaving head-level injection untouched. This would explain the symptom exactly: structural HTML (div/select/input elements) survives, but the <style> tag and its contents get silently removed or neutered before reaching the browser.
Two direct checks that were about to be run, never completed:
grep -c "ltv-wrapper" lmvhtml(on a real saved page source of a post containing [ltv]) — if this comes back 0, the class name that the CSS block should have injected never made it into the rendered page at all, confirming something strips it upstream.
Also worth confirming: does an LMV card on a real live post currently show actual colors (rounded card, colored header) or is it also just plain unstyled text? This was never actually confirmed on production — every "LMV renders correctly" verification done today was against an isolated test file, never Andrew's actual live server output. If LMV is ALSO unstyled on production, this is a shared/systemic issue, not an LTV-specific bug — meaning the fix is not "something wrong in LTVBBC.php's CSS" but something in the render pipeline itself (SMF core, or a security/sanitizer mod, stripping inline <style> from post content).
LTVBBC.php output in a real Chromium instance: themes genuinely apply, switcher genuinely works, search highlighting genuinely works, autodisplay open/collapsed state genuinely works. All of this was screenshotted and visually confirmed correct in isolation (a standalone HTML file, not through SMF).<style> tag bug — a real bug of this class WAS found and fixed earlier today (themeColorsCss()'s heredoc had its own literal <style> tag nested inside getStyles()'s own <style>...</style> wrap, producing invalid <style><style> in output). That fix is confirmed correct via direct render inspection (exactly one <style> and one </style> tag now) and shipped as LTV v2.3. The screenshot Andrew provided of the still-broken live box was taken AFTER installing v2.3, so this particular bug is not the (or not the only) remaining cause.LTVBBCode::integrate is confirmed present in integrate_bbc_codes, and LTVBBC.php is confirmed present in integrate_pre_include, both verified via direct DB query against smf209_settings.Packages/ was checked and only contains the one correct ltv_bbcode_v2.2.zip; the live LTVBBC.php's own version constant reads 2.3, matching what was actually built and tested.Today involved a LOT of Package-Manager/file-mixup confusion (documented in full in the conversation history, not repeated here). The most relevant residue: LMV's live install state does not cleanly match what Package Manager's own bookkeeping believes is installed (a hybrid of an old v3.0 registration plus a manually WinSCP'd v3.3.4 LMVBBC.php). This was left deliberately alone once it was confirmed working for LMV's specific crash/autodisplay bugs — but it's relevant context if theming turns out to be connected to anything install/registration-related rather than pure CSS/output-sanitization.
ltv_bbcode_v2.3.zip — current, tested LTV package (the fix for the double-<style> bug described above).lmv_bbcode_v3.3.4.zip — current LMV package.lmv_display_patch-3.3.4.xml, lmv_display_patch_21-3.3.4.xml, listatt_display_patch.xml — reference-only <modification> copies, NOT used by either package's actual install path (both use self-healing <code>-action installers instead) — kept only as documentation.Rather than more theorizing: get a live view-source of an actual post containing [ltv], search specifically for ltv-wrapper (the class name the CSS block targets) and for the literal string <style> immediately around where the LTV box sits in the body — not in the <head>. That single piece of real evidence (present vs. stripped vs. present-but-something-else) will point directly at whether this is a CSS/output problem in the mod itself, or a sanitization/rendering-pipeline problem elsewhere in the stack.