Dear dev:

the age old bug where having a certain adminPasswordHash will cause [load more] gone happened again, which was solved before.

in this gen all default channel except General lost [load more]. but if switched to another Hash or just comment it out load more will appear again. The bug exists confirmed by refresh, switching to incognito and different users reports.

  • RudBoOPEnglish
    1·
    2 months ago

    Here are 3 fixes for the comments-plugin dev. All reference the embed source (I saved the full embed page to scratch/comments-embed.html for line numbers).

    1. Ask the server “are there older messages?”, don’t infer it from the page count (root-cause fix) The button and noMoreMessages are computed purely from how many messages got embedded: if(messageDataArr.length < maxMessagesPerPage) noMoreMessages = true; (line 2536) and the button only renders when messageDataArr.length >= 200 (line 2564). But when adminPasswordHash is in the query, the server excludes hidden/flagged messages before embedding, so a channel with 329 real messages ships only 194 → button never renders. Fix: have the server include an authoritative flag in the embedded data (e.g. hasMoreMessages, or a total count) computed from the full pre-exclusion message list, and gate the button + noMoreCommentsBeforeThis on that flag instead of length >= 200.

    2. Make the exclusion count-preserving: embed “most recent 200 non-hidden”, not “most recent 200 minus hidden” (smallest, surgical fix) The hashed feed is currently: take newest 200 → drop hidden ones → 194. Change the server query to WHERE hidden=0 ORDER BY time DESC LIMIT 200 so the array always reaches 200 whenever 200 non-hidden messages exist. Then the existing client logic (button at length >= 200) works unchanged for both hashed and un-hashed feeds.

    3. The same flaw exists in the load-more API path AND the availability signal is DOM-based (needed for the button to survive partial pages)

    loadMoreMessages also sets noMoreMessages = true when a fetched page has <200 items (line 2671) — so even with the button shown, one short page kills it. Use the same server hasMore flag there. noMoreCommentsBeforeThis is computed via a DOM hack: if(!#loadMoreMessagesBtn || offsetHeight===0) noMoreCommentsBeforeThis = true; (line 2492) — this reports “no more messages” whenever the container is hidden or zero-height (exactly the announcement ticker case). Compute it from server data, not geometry. Host-side, ctx.loadMoreButton only activates when opts.onLoad is set (imports/comments-plugin/main.pjs:344) — hosts who don’t pass onLoad can never get a button even when older messages exist. Want this written up as a ready-to-paste bug report file? Meanwhile, the immediate workaround on your side: delete the 6 hidden messages via admin (or ~6 new posts will push them out of the window) and the button returns with the hash intact.

      • RudBoOPEnglish
        1·
        2 months ago

        tldr:

        • the bug: has admin hash = no [load more] button
        • cause: mod deleted(hidden) some comments, so comment count never reach 200, no [load more]
        • fix: might be as above
    • RudBoOPEnglish
      1·
      2 months ago

      Proof complete. Here’s the full evidence chain — the reason is the 6 hidden posts, and I can show each link.

      1. Same channel, same moment, one variable. Fresh cache-busted fetch of Submit’s message list, two ways:

      with the admin hash → 194 messages without the hash → 200 messages Same newest message, same instant, reproducible. The only thing that changed is whether the 6 hidden posts are in the list.

      1. The 6 posts are identifiable — and they’re not deleted, they’re excluded. The 200-msg list contains exactly 6 that the 194-msg list omits (publicId 518f2597… ×4: “Ale Pina is a pre-adolescent girl…”, “Leo is an eighteen-year-old…”, “Elena is a firebrand…”, plus the SUBMISSION_column spam and “is there any mod that can help me”). They still exist in the DB (the public feed shows them) — the hashed/mod feed is the one that drops them. So: hashed feed = most-recent-200 − 6 hidden = 194.

      2. The plugin’s own code turns 194 into “no button”. In the embed: maxMessagesPerPage = 200 (line 2457); if(messageDataArr.length < maxMessagesPerPage) noMoreMessages = true (line 2536); button only rendered when !noMoreMessages && length >= 200 (line 2564). I ran that exact condition on the real arrays: 194 → no button, 200 → button.

      3. You can run the reversible A/B yourself in 10 seconds. Comment line 284 back in (hash on) → reload → Submit loses “load more”. Comment it out → reload → it returns. You’ve already seen both states. The switch is literally whether those 6 posts are counted.

      4. Corroboration: General & 18+ General show the button with the hash because their recent-200 contain zero hidden posts (200 ≥ 200). Submit/Feedback sit under the line.

      So the hash isn’t the cause by itself — it’s what makes the server exclude those 6 posts, dropping 200→194, below the plugin’s hard 200 threshold. Fix: mods delete the 6 (or ~6 new posts arrive) and the button returns with the hash intact.