This is a Lemmy Community for perchance.org, a platform for sharing and creating random text generators.
Feel free to ask for help, share your generators, and start friendly discussions at your leisure :)
This community is mainly for discussions between those who are building generators. For discussions about using generators, especially the popular AI ones, the community-led Casual Perchance forum is likely a more appropriate venue.
See this post for the Complete Guide to Posting Here on the Community!
1. Please follow the Lemmy.World instance rules.
2. Be kind and friendly.
3. Be thankful to those who try to help you.
4. Only post about stuff related to perchance.
5. Refrain from requesting Prompts for the AI Tools.
text-to-image-plugin and ai-text-plugin) e.g. "What is the good prompt for X?", "How to achieve X with Y generator?"6. Search through the Community Before Posting.
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.
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).
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.
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.
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.
@perchance@lemmy.world thank you
tldr:
Proof complete. Here's the full evidence chain — the reason is the 6 hidden posts, and I can show each link.
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.
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.
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.
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.
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.