ISEmega (v8.0) is built and deployed. Andrew is consolidating the live server's current state into a v8.0 master, then starting v8.1 fresh from there. This session was almost entirely QA/bugfixing on top of the v8.0 build from the prior session, plus two real infrastructure discoveries.
Andrew runs two separate SMF installs on the same box:
/var/www/html/The_ISE_Project — the original/live install ("Live v7.4.2")/var/www/html/smf20/The_ISE_Project — a newer test install ("smf20 v8.0")These have separate databases and separate copies of the Board-Icons-and-colours mod's data. A board-color mismatch between them (General Discussion showing black on one, unstyled on the other) turned out to be smf20 simply never having had that board's color set — not a code bug. Any "before vs after" comparison Andrew makes going forward may be comparing these two installs rather than two points in time — worth checking which install a screenshot/report is actually from before diagnosing.
PDFsearch.py's _parse_php_dir_array() (now v7.4.1#5, in this session's outputs) — only handled SMF's PHP-serialized attachmentUploadDir format (a:N:{i:K;s:LEN:"value";...}); a plain path string (/var/www/html/smf20/attachments, no serialize syntax at all — some installs store it this way) matched zero times and raised RuntimeError. Fixed with a plain-string fallback, tested against the real failing value plus both single- and multi-directory serialized forms — all pass. Shared by MiscIndexer.py too (imports the same function), so this one fix covers both indexers' directory resolution.
ise_post_download.php deployed on Live was v1.0 — the very first version, predating both the Formatted/Raw mode split AND the generic-bracket-tag BBCode-stripping fix (still had the narrow color/b/i/u/size/url/quote/img whitelist bug). Checkpoint notes from an earlier session described v1.2 as having both fixes, but that version apparently never actually got uploaded to Live — a real example of the "AI builds it in chat, human doesn't always deploy it" gap. Rebuilt as v1.1 with both fixes combined, delivered and confirmed deployed this session.
ResultFormatter.py's _render_cluster_item() only had one generic Download button — no ?mode= parameter existed at all on either side (PHP or Python) despite earlier notes describing a Formatted/Raw split. Same "never actually deployed" pattern as above. Patched live via small, safety-checked find-and-replace Python scripts run directly over SSH (not full-file rewrites) — this pattern worked well and is worth reusing: write a script that verifies its anchor text matches exactly once before touching anything, backs up the original first, refuses to guess on a mismatch.
Originally MegaSearch.py had a hand-copied, parallel version of posts-card rendering, separate from ResultFormatter.py's real _render_cluster_item(). This is exactly how the Formatted/Raw buttons silently went missing from ISEmega even after being fixed in ResultFormatter.py — there were two copies to keep in sync, and only one got updated.
Fixed by deleting the parallel copy entirely. MegaSearch.py's _render_posts_card() now wraps each flat scored post result as a fake single-item cluster ({"representative": r, "matching_replies": []}) and calls the real _render_cluster_item() directly. This means:
cluster_lines[0] and shown outside the Minimal/Full tier wrapper (matching PDF/Misc cards, which always show their title) — this was a real bug in the first delegation attempt (minimal mode showed nothing but the source badge for posts cards specifically)._render_cluster_item()'s first returned line is always the title div. True as of this session's version, but if that function's internal structure changes later, this breaks silently. Worth a comment flag in the code (already added) and worth re-checking if posts cards ever look wrong after a future ResultFormatter.py change.PDF and Misc cards were NOT delegated this way (no equivalent shared function exists in PDFsearch.py/MiscSearch.py to delegate to) — they still have their own hand-written renderers in MegaSearch.py. Same drift risk exists for those two, just not hit yet.
Originally built Minimal/Standard/Full. Andrew asked to drop Standard — collapsed to Minimal (badge + title only) and Full (everything else). ise_mega_detail.js now v1.1, same localStorage-backed pattern as the shell theme picker.
Agreed rule: anything that navigates away from a results page into the live forum (board, topic, message, post, Misc's file viewer) opens in a new tab (target="_blank"). Downloads never get a target at all (they don't navigate anywhere). Whether a download prompts "Save As" vs. auto-saves is a browser setting, not something the code controls — not something to chase as a bug.
Applied so far via the same small-patch-script pattern:
PDFsearch.py's Board link — confirmed fixedResultFormatter.py's title/Best-matching-post/Match-evidence links (posts page) — confirmed fixedResultFormatter.py's Board link (posts page) — patch delivered, confirm it was actually run before assuming doneSeveral "regressions" this session (missing buttons, wrong colors) turned out to be stale browser cache, not real bugs — hit at least three times across different browsers. Worth remembering as the first thing to rule out (hard refresh / incognito window) before deep-diving a reported regression, especially right after a patch script reports success.
patch_posts_board_new_tab.py (posts page Board link → new tab) was actually run and confirmed working — last message before this checkpoint was delivering that script, not confirming resultsResultFormatter.py and PDFsearch.py from the actual live server, NOT from any file in a prior chat's outputs folder — several small live patches this session were never round-tripped back into a saved file, so the server is the current source of truth for those two files