Re: Little things that bug you/me about the forum

Quote from: Cyrus on July 24, 2024, 05:00:01 PM

Something related to persistence: the Post a redirection topic checkbox from the Move Topic page should be disabled by default. Redirection topics left by members are seldom useful and mods leave them sporadically. Having the choice saved would be a small benefit.
Albeit it's more useful for mods when moving lots of threads (had a userscript long time ago disabling the checkbox to save some mouse travel and clicks Cheesy

I've been leaving this one until after theymos merges the header-persistence patch I did for dkbit98 (because I'd like to persist the checkbox using the same endpoint that that patch might restore).

But, I've got no idea when theymos will merge that patch, or even if he plans to do it at all. So, in the interest of keeping things moving along, here's a patch for your request (minus persistence):

Code:

--- baseline/Themes/default/MoveTopic.template.php 2006-09-02 14:24:47.000000000 +0000
+++ modified/Themes/default/MoveTopic.template.php 2024-12-25 08:27:26.000000000 +0000
@@ -26,18 +26,18 @@
<label for="reset_subject"><input type="checkbox" name="reset_subject" id="reset_subject" onclick="document.getElementById(\'subjectArea\').style.display = this.checked ? \'block\' : \'none\';" class="check" /> ', $txt['moveTopic2'], '.</label><br />
<div id="subjectArea" style="display: none; margin-top: 1ex; margin-bottom: 2ex;">
', $txt['moveTopic3'], ': <input type="text" name="custom_subject" size="30" value="', $context['subject'], '" /><br />
<label for="enforce_subject"><input type="checkbox" name="enforce_subject" id="enforce_subject" class="check" /> ', $txt['moveTopic4'], '.</label>
</div>';

// Disable the reason textarea when the postRedirect checkbox is unchecked...
echo '
- <label for="postRedirect"><input type="checkbox" name="postRedirect" id="postRedirect" checked="checked" onclick="document.getElementById(\'reasonArea\').style.display = this.checked ? \'block\' : \'none\';" class="check" /> ', $txt['moveTopic1'], '.</label><br />
- <div id="reasonArea" style="margin-top: 1ex;">
+ <label for="postRedirect"><input type="checkbox" name="postRedirect" id="postRedirect" onclick="document.getElementById(\'reasonArea\').style.display = this.checked ? \'block\' : \'none\';" class="check" /> ', $txt['moveTopic1'], '.</label><br />
+ <div id="reasonArea" style="display: none; margin-top: 1ex;">
', $txt['smf57'], '<br />
<textarea name="reason" rows="3" cols="40">', $txt['movetopic_default'], '</textarea><br />
</div>
<br />
<input type="submit" value="', $txt[132], '" onclick="return submitThisOnce(this);" accesskey="s" />
</td>
</tr>
</table>';

I had a little thought just now (after reading this post) that I'd appreciate some community feedback on...

When I did the 2FA patch, I came up with a really neat from-scratch PHP implementation of QR codes. Considering that that code is already written, tested, and present on the server, it would be really easy for me to wire it up to a new BBCode tag.

Something like:

Code:

[qrcode]https://www.youtube.com/watch?v=hvvjiE4AdUI[/qrcode]

Which would turn into:

Code:

And display like:

(As with the example above, I think I'd make it so that the payload would be duplicated in a tooltip. That way, you could hover over the QR code to see what's in there, before scanning it. Probably the wordfilter, which I hate and would remove if it were up to me, will prevent QR codes from linking to banned sites and whatnot.)

Do you guys think a [qrcode] tag (with a 134-byte payload limit) would be useful? I can't myself decide between "Yeah, that's useful!" and "Nah, it'll cause more problems than it'll solve." Undecided

There are requests for a "spoiler" tag going all the way back to 2011. I started work on this a few months ago, and am now finished with it.

I experimented with a lot of different approaches, but the one I eventually settled on is just a simple button that replaces itself (once you click/tap on it) with whatever content you'd like.

I've named the tag [hide] rather than [spoiler]. Basically, you can wrap anything you'd like in [hide]...[/hide] tags, and then rather than the content itself appearing, instead you just get this neat little "Show" button:

(That's obviously just an example image, so clicking on it won't do anything.)

Something that works particularly well with this approach is making quotes more compact:

Quote from: BinaryMage on August 24, 2012, 07:44:59 PM

(Seriously, stop clicking things.) Tongue

I can see this being a nice way (for the people who choose to start using it) to post more courteously, and to save others from having to scroll through huge images and big tables and whatnot. I think I've squared away every concern I've run into. For example, I worried about how this tag might negatively affect SEO, but worked around that by making the content rather than the button appear for guests (on the basis that that's the most reliable way I can think of to make sure that hidden content won't confuse web crawlers). I've also made it so that you can tack a ;unhide on the end of URLs, so that there's some way for people who are both logged-in and refuse to enable JavaScript to still be able to view everything (long term, I really can't see always trying to accommodate the no-JS crowd, but if it turns out to be a genuine sticking point, then I'll add a profile-setting that does the same thing as ;unhide, though I'd really prefer not to, because there are various things that I'd like to add to Bitcointalk that just have no way of working well without client-side scripting, so one or two final concessions to the no-JS peeps would be pretty pointless, all things considered).

And though I expect very few people use them, I've also made sure that the tag recursively auto-expands for the wap/wap2/imode and action=printpage features.

I'll post the patch sometime in January, but, in the meantime, if anyone has any concerns they'd like to raise, or believes that I haven't considered something deeply enough, then I'd be grateful for your thoughts.

I know I said here that I was hoping to finish the ICQ/AIM/MSN/YIM thing before 2024 was over. Not much chance of that happening now, I'm afraid. I'll try to finish this one soon (though, realistically, there are a bunch of things on my plate that I really should clear first, so June/July seems more likely to me than early 2025).

BTW, Merry Christmas! I wish everyone on this forum nothing but good fortune. See you in 2025!