>>294 Hey I like the new formatting bit. Should it collapse back down if you click away or if you click the "More options..." bit again, like the text box?
Just a thought. This setup is easier and more obvious than using the link field, with "AA" or "Wakabamark". BTW, I just realized that was a pun. Boo! Hiss! Not punny! :)
Tell me more about these pre-compiled binaries. I thought that was impractical...I mean, instruction set differences and so on.
>considering the default prune behaviour of imgboards
One of the parameters Kareha uses to determine pruning is MAX_POSTS, so even if you sage a thread under this new condition, you still add to the board's total postcount and speed up the process for pruning that thread, regardless of MAX_RES. The only flew is this assumes pruning is based on thread creation date, not popularity (because someone could easily bump a shitty thread and save it from deletion).
I also agree that enabling this functionality would further make threads vulnerable to intentional bumping by trolls. I was sorta envisioning it being used in a mature community where trolling is minimal and quickly weeded out by regulars.
Here's a new idea: how about trying this in reverse? Only "sage" posts are counted in MAX_RES, in which case saging can again be used either in protest or as a courtesy to others. The only problem is that people can then freely bump threads without consequence.
Well, there are some issues to consider here:
In the end, people actually enjoy the 0ch quirkiness. I know I do. I know about designing good interfaces, but there's something fun about an interface that is a little bit quirky, as long as it doesn't get in your way, and these things don't.
ugh "More options..."
too much clickable elements! and it doesn't even do anything (Firefox 1.0.7 here)!
out! out!
Well, there are some issues to consider here:
In the end, people actually enjoy the 0ch quirkiness. I know I do. I know about designing good interfaces, but there's something fun about an interface that is a little bit quirky, as long as it doesn't get in your way, and these things don't.
I've also had an idea swimming around: an option to only count actual thread bumps in MAX_RES (not "sage" posts). I think it would lead to making each bump more valuable so that people don't do so wastefully and unnecessarily.
The point is to make a portable file, so you do not /have/ to compile it on the host. Statically linked lets you use libraries that the host does not have.
Sure, doing it in perl is an option though.
>>333
The whole point of websites is to implement things without the external application. I don't understand the argument for OH NO ANOTHER BUTTON MY WHOLE LIFE IS RUINNED crowd. If you don't like the extra buttons why don't you remove them with an external application and/or preferences? When you are talking about formating options, a preview makes sense. Are you going to set up your thrid-party application for every configuration of tags supported for every board?
If a feature is of a wide enough audience, it should be included. I'm sure nearly everyone could use a preview every once in a while, whereas something like a Bible quotation functionality would not have wide use.
Also, wouldn't making capcodes even more prevalent be considered A Bad Thing®? If anything, the role of capcodes should be minimized or altogether eradicated, in favor of ninja moderation.
Another question: would FUDGE_BLOCKQUOTES be considered deprecated by now, or are there still CSS styles out there that require it?
>>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:
I've been meaning to change some of the defaults away from Futaba-style to saner behaviours. Any suggestions for what to change are welcome. So far:
I don't see what's so bad about >>330. The alternative is to force the table to be full width, which will make it uglier (because in HTML all columns will become wider, including the skinniest ones), and harder to read.
> No need for a database, just a text file. You're right about storing IPs, though, but then how can you implement a banning system? Do you use an encrypted IP like the algorithm to generate ID codes?
Banning is done through Apache, which really makes more sense than doing it in the script. I don't want to re-invent the wheel for that.
> I mean that (for example) if I wanted to replace the permasaging function under the MAX_POSTS condition (permasage after X posts) with the thread-closing function (close after X posts), all it would require is a simple replacement of the proper function references in post_stuff(), correct?
No, they're done at different different places, because they are essentially different functions. The permasage behaviour doesn't actually permasage a thread, it only refrains from bumping it. There's no permsage flag added to the thread. The closing, on the other hand, does add a flag to the thread.
> Making "More options..." an option in the configs.
> Seems sensible, when you already have the ability to turn off WakabaMark as a board admin.
No. And I actually removed the DISABLE_WAKABAMARK option since it's no longer really needed. The replacement will be an option to select the default markup for a board, which makes much more sense overall.
Again, the list of tags allowed on that page don't correspond to what would be allowed in Kareha. Of course <img> tags wouldn't be allowed, for instance. This is just for testing the actual cleanup engine.
That form just looks wrong with no title or clear separator, though. I might put in a title that is not the exact same as the button, though. Any suggestions?
The board title is inserted by template.pl, and rules.html is included after it.
The one with encoded Javascript that makes you post with fusianasan is cute.
> Another topic: since dynamic pages eat up CPU in order to rebuild pages according to URL parameters, what would be the likelihood of the current dynamic thread subpages having a significantly adverse effect in this aspect if a board were to grow to 2ch-sized proportions?
The effect would be miniscule in comparison to the huge increase in bandwidth that would result from sending the entire static thread pages.
The "entire thread" link can easily be changes to link to the files in /res/ instead of going through the script, but that would make it somewhat less convenient when you want to consturct custom URLs, so I haven't done it.
> Also, let's put out a partition to kill secure tripcodes (unless they originated from 0ch/Futaba)
Why? Even if 0ch or Futaba implemented secure tripcodes, you wouldn't get the same secure tripcode there as on another board. That's the nature of the security.
> captcha (until we find a way to implement similar functionality without requiring it in the form of a GIF/PNG image)
That's even more non-sensical. Nobody on the entire internet has figured out a reasonable way to implement captcha except by using images, and the only boards that use them are image boards where you have to load images anyway. And finally, they aren't just there to annoy you, people do actually try to flood boards, and they are stopped by the captcha.
> And is there any practical way that Kareha can be modified to run multiple (even nested) boards in a single installation?
Not without doing a lot of changes throughout the code, and not without breaking current installations.
>> config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached
> Isn't this essentially the same as saying "Please don't talk so much?"
I am not >>208 but the first who suggested this here (long ago). I think it may be vital for future, actually popular boards to limit the filesize of a thread so that the board won't get hammered by repeated loads of whole threads without having to limit the size of posts themselves something fierce.
How come this is now the by far biggest thread on this board?
Maybe it's because I'm posting useless replies like this one!