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? Should there be a consideration to make these pages as static as the front page?

Also, let's put out a partition to kill secure tripcodes (unless they originated from 0ch/Futaba) and captcha (until we find a way to implement similar functionality without requiring it in the form of a GIF/PNG image), and add functionality for multiple uploads in one post.

And is there any practical way that Kareha can be modified to run multiple (even nested) boards in a single installation?

Partition for renaming "WakabaMark" to "WAHaMARk"!

> Wait, why should l50 links be indexed/cached?

Because the only way for the search engine to find the old threads is to go through the l50 links. I'm taking the advice of >>322 though.

> The CSS in the All threads page is unsightly. Is there a way to properly wrap the outer color border(s) around the table of threads?

You need to explain what you're talking about before I can do anything about that. What style, and what does "wrap the outer color border(s) around" mean?

> I still say that the "Navigation: " text is extraneous when people can clearly see what the links do. Also still partitioning for 0ch-style error pages (with displayed user host and all).

It's there because freefloating unlabelled links look weird.

> Now that we do have filesize indicators in the backlog page of mode_message, do you still find it useless to have the red bold filesizes near the bottom of thread subpages?

They're there, but only if you enable pruning by size.

> Does mode_message now work in PAGE_GENERATION => 'paged'?

No. I'm too lazy to figure what that's supposed to do, and I don't think anybody actually wants to use that in the first place.

> Idea: forced anonymous/sage/ID/fusianasan by IP/thread/board/whole site (some of these combinations already exist, I know)?

There's no database to keep IP data in, and I'd prefer to keep the script completely agnostic to IP addresses.

> Finally, I imagine that the permasage/close/delete functions in kareha.pl will be easily interchangeable among the conditions in post_stuff(). Can you confirm this?

No, because I don't know what you mean.

And maybe this: http://wakaba.c3.cx/sup/kareha.pl/1126586277/5

A trigger for turning wakabamark off and one for forcing a monospace font

I don't know if this is a bug or not, but could you change the Futaba template so that hovering over/clicking on a post header doesn't count as doing the same to the deletion checkbox next to it? Same goes for the "[File Only]" area at the bottom with its checkbox.

So, I made the All threads page a lot fancier. Might need some shift-reloading to get the proper CSS.

Is this about done, besides the admin bit? I'm getting a bit tired and distractions are looming to the left and right.

Oh, and the navigation bar on the error page should probably look like the one on the thread page.

> Red, bold thread filesizes displayed near the bottom of subpages?

I support this, especially if thread-closing by filesize should be implemented.

PS: I always wanted to say this: The # anchors on the TiddlyWiki automatically scroll me (FF, 1.0.7) just below the actual text box of the entry. Is that a bug, a feature or... ?

Recapping, here are the things I'd like to see in the final release:

• better configuration of date and time (with optional timezone offsets), parsing certain characters for individual elements (ie, yyyy/MM/dd(D) hh:mm:ss -5:00:00) and also accepting numerical inputs for fixed dates and times (Eternal September)
• config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached
• change the no-ID-on-email option to no-ID-on-sage
• no EMAIL_ID parameter (most if not everyone uses "Heaven" anyway, and if they really want to change it they can easily find the string in kareha.pl)

Some nitpicky template adjustments to mode_message in order to more closely resemble 0ch (see http://f17.aaa.livedoor.jp/~zerotest/jikken and http://0ch.mine.nu/jikken):

• multi-page links (1-, 101-, 201-, etc) at the top of subpages
• red, bold thread filesize indicator near the bottom of subpages
• "read all later posts" link just below the filesize indicator
• non-bolded post numbers
• colons before dates
• colons before names (thread subpages only)
• colons after thread position number in main page thread list
• smaller and (at least for Pseud0ch) black and bolded title in "Create new thread" box

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?

"page top" is better imho

And maybe this: http://wakaba.c3.cx/sup/kareha.pl/1126586277/5

Kareha can't use different layouts for posts on different pages, except by CSS trickery. I could add the second colon, though.

Also, I've implemented optional thread closing now, but there's no extra post. That would just be a total mess to implement, and would make re-opening threads annoying, if such a feature was requested. It replaces the posting form with a notice that the thread has been closed, instead.

>>19

I can't reproduce this on Firefox 1.0.4 nor Safari on the Mac, but that ancient Firebird had a similar problem (but even worse).

Anyone else? Try post with a | in your name.

>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.

About the etyomology of "fusianasan":
http://4-ch.net/nihongo/kareha.pl/1102656968/224-

> Can't this be somewhere else but the post form?

No, because that would be immensely useless and annoying, because nobody would know it's there, and even if they did, they'd have to go somewhere else every time they wanted to post something using a different markup.

>> 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.

The "Entire thread" link on the thread page is missing a "/" at the end.

n is implemented, but not for >> yet.

Also, >>1 is, as it is, only added to URLs of the form xx-yy and lxx. 2ch doesn't add >>1 for single-reply URLs, and if you're using commas, I figure you can add >>1 yourself if you want it. I'm not sure if this is the best behaviour, but that's how it works at the moment.

Well, there are some issues to consider here:

• Hardly anybody needs to ever use fusianasan. It's a gimmick. Design decisions should not be made around it.
• The strings may be strange, and combining fields isn't the best design possible, but this is a 0ch clone, after all. If I were designing something from scratch, I'd do things differently, but as it is, people are expecting 0ch behaviour, and it would confuse them if the script worked like 0ch in some ways but not others.
• I might consider adding additional strings that trigger sage and fusianasan, but I'm not sure what they should be.

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.

>>236

mode_image copies the Futaba/Futallaby HTML style and uses the same CSS, so yeah, it should be, and no, it won't be.

>>238

This would need writing to yet another file, and it also makes it less obvious how to get the same secret on several boards.

> Pruning set to furthest-back instead of oldest.

I don't like this one. You just have to continually age a topic (until it hits the permasage treshold) in order for it so survive a long time. Normal users might have good reason to ignore simply it, though...

> Size limit instead of post number limit, maybe?

Sounds good.

> I was thinking of setting the default behaviour to never permasage or close threads.

I guess I don't have a strong opinion on this one. As long as the values will be customizable, I don't really care, I suppose.
Also: I just noticed that "¦" in tripcodes will work correctly but turn into "�U" through the cookie on /soc/ but not on the sandbox.

>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.

No, but that's not the point.

Oh, and I apologize for indirectly causing you too much trouble with this change.