> He meant saging a thread just because a part of the actual e-mail address contains the word "sage."
> You know, like [email protected].
Well, then you are out of luck, aren't you? So you want to enter your E-Mail but cannot because then the post wouldn't bump then? Solution: Write it in the comment field, problem fixed.
There is no reason to change well-known keywords for this or even turn this into a frustratingly unconvenient tickbox/checkbox.
No, that's just plain wrong. It is very much the job of the programmer to decide on such issues, and make sure they work consistently across boards.
You can't document easter eggs! That's crazy talk!
Also, I find it insanely more annoying to write text in five-line tunnel vision than whatever annoyance might be caused by a comment box that expands.
> metadata
Not sure, that would require a database redesign and I don't want to force people with a current install to do that. Also, it seems something like that would work better for a whole new script, properly designed around the idea.
> config.pl parameter for a generic image that takes the place of a deleted image (ie, Hello Kitty)
Ah, good, been meaning to do, forgot about.
> Fine-grained banning options that let you choose whether or not the user is blocked from reading a board, posting to a board, or both. Another parameter defines the duration of his ban ('0' for permaban), and another defines a reason/message displayed when the user tries to access a board.
None of those seem useful to me, because I'm of the opinion that bans are to prevent abuse, not to punish users.
> Replace HTML error pages with dialog box equivalents using JavaScript.
Would require a bunch of hidden-iframing and such. I'd like to do a complete re-design full of javascript trickery, and this idea would fit better in such a context... That is to say, I'm lazy and the current version is robust, and I'm loathe to go around changing it, since it would introduce new problems.
> Kill user deletion. I can't see any case for when it'd have constructive uses.
On image boards, it has a very definite use - people do fuck up and post in the wrong thread, or create new threads. It's better if they can clean up after themselves. In Kareha, you can already disable deletion.
> Conversion to mod_perl?
As far as I know, it should work in mod_perl already, modulo some prototype bugs. I'll try to get those fixed.
> The standalone thumbnailer project is a great idea too. As a suggestion, how about adding functionality to also read and thumbnail document files like TXT, PDF, and DOC?
That would require a LOT of code, especially when you don't want external dependencies, so it's a bit iffy.
Yes, it's throwing Javascript errors for me if I use that character. Gonna look into that some more.
> It's not worth comparing until it doesn't break regularly.
The only problem with it is that it doesn't do paranoid file writes. The fact that the entire server occasionally breaks isn't related to how broken the script itself is.
>Let people figure out things themselves, if they are so keen on changing their keywords.
If you really want to use your own custom trigger strings, you can easily search kareha.pl for instances where "sage" and "fusianasan" are used in that context and either replace them with those custom strings or append them as secondary strings. It's not something that warrants additional config.pl parameters.
Oops, here's the screenshot. orz
>>321
Wait, why should l50 links be indexed/cached? IMO the only links that should be on Google at all are main pages and "entire thread" links.
Some final points (I hope) before the whole thing is wrapped up:
> metadata
Not sure, that would require a database redesign and I don't want to force people with a current install to do that. Also, it seems something like that would work better for a whole new script, properly designed around the idea.
> config.pl parameter for a generic image that takes the place of a deleted image (ie, Hello Kitty)
Ah, good, been meaning to do, forgot about.
> Fine-grained banning options that let you choose whether or not the user is blocked from reading a board, posting to a board, or both. Another parameter defines the duration of his ban ('0' for permaban), and another defines a reason/message displayed when the user tries to access a board.
None of those seem useful to me, because I'm of the opinion that bans are to prevent abuse, not to punish users.
> Replace HTML error pages with dialog box equivalents using JavaScript.
Would require a bunch of hidden-iframing and such. I'd like to do a complete re-design full of javascript trickery, and this idea would fit better in such a context... That is to say, I'm lazy and the current version is robust, and I'm loathe to go around changing it, since it would introduce new problems.
> Kill user deletion. I can't see any case for when it'd have constructive uses.
On image boards, it has a very definite use - people do fuck up and post in the wrong thread, or create new threads. It's better if they can clean up after themselves. In Kareha, you can already disable deletion.
> Conversion to mod_perl?
As far as I know, it should work in mod_perl already, modulo some prototype bugs. I'll try to get those fixed.
> The standalone thumbnailer project is a great idea too. As a suggestion, how about adding functionality to also read and thumbnail document files like TXT, PDF, and DOC?
That would require a LOT of code, especially when you don't want external dependencies, so it's a bit iffy.
> how about having a third party create extensions for those browsers and freeing up the real estate on the actual page?
What's with this obsession on removing the CSS options? It's a single line, and some of us find it useful.
Real estate? Scroll down.
> Huh?
You know, like [email protected].
Shiichan 2000 let you enter "down" to sage and "showip" for fusianasan, but it was mainly just a curiosity and was not used. There's no one English word that does the job of the pseudo-Japanese "sage". Better to have a tick-box and explain to people why it is useful. Or an option for it.
> Then the board has to be configurated to just do that (it already can).
No, 148 is referring to a user-end problem, not a server-end problem.
>Most admins probably don't get point of the secret string anyway, and asking them to put in several is just too annoying. In retrospect, I'd like to add a second layer of hashing to these, but that'd mean breaking secure trips AGAIN.
You could take the route that MrVB (I think?) did and generate the strings on first run? openssl, /dev/random, perl's random as last resort. In almost every case you are going to get a better random string than most people will supply, and if they want to change it they can. Or only have them generated if they are not supplied.
Honestly, when people care so much about anonymity they can put up with the changes required to ensure it.
This is the obligatory encoding test ... in <code>
㋋㏡
ゔ〲〰 ゔ〲〲〰〰 ゔ〲〰 ゔ〲〰 ゔ〲〰ゔ 〲〰ゔ 〲〰ゔ〲〲〰ゔゔ
〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰
(♛ฺД)(*゜∀゜)~♡ℳฺℴฺℯฺ❤ℒฺℴฺνℯฺ..._〆(゜▽゜*)㌰㌰ ㍉㍍㌧㌔㌶㍊㌣㌦
㌀㌁㌂㌃㌄㌅㌆㌇㌈㌉㌊㌋㌌☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ
☼♭♬♫♨♩♧♦♥♤♣♢♠♡♐ฺ♑ฺ♒ฺ♓ฺ ♔ฺ♕ฺ ♖ฺ ♗ฺ♘ฺ♙ฺ♚ฺ♛ฺ♜ฺ♝(・∀・)/ヾ~~╋┓!㋦㋸㋭°
|壁|」゜ρ゜)」 ノ ヽ``~ 力㋦㋸㋭°
/ ⌒ヽ
/ ´_ゝ`) I am sorry、 the β α κ α kopipe couldn't be carried out・・・
| /
| /| |
// | |
U .U > Red, bold thread filesizes displayed near the bottom of subpages?
I support this, especially if thread-closing by filesize should be implemented.
On second thought, the whole search idea was pretty poor...but could you implement saging in a way that's independent of any particular post element, and is instead assigned in the individual templates?
About the etyomology of "fusianasan":
http://4-ch.net/nihongo/kareha.pl/1102656968/224-
>>313 Like lots of people use them anyway </sarcasm>. Yes, security is a good idea. What are the holes, anyway?
> It's a link, it screams "Click me!".
There's something to be said about obsessive-compulsive... >.>;