How about appending an estimated (at the time of thread creation) time of pruning to the first post's header, if pruning-by-age is enabled?

GDLib for thumbnails: http://wakaba.c3.cx/sup/kareha.pl/1113869490/5

Thanks. I did it the hard way and put in the proper transformations everywhere so filenames can be kept intact, though.

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

Hmm, looks like my ISP fails at keeping my IP secret.

Okay then, for starters, how about the closing message to exactly look like a post (although it's sad it won't be accesable with >>1001)?

The test thread seems to be broken too.

> Better to have a tick-box and explain to people why it is useful. Or an option for it.

Yes, an option. Because I think a tickbox is horrible.

This is a widely used system. There is a very low learning curve here. sage = does not bump thread when replying, that's all there is to know. People can then figure out why it is useful on their own.

And personally, I think sageing should be encouraged more (since the perceptions on it have been pretty much ruined by 4chan). So it helps that it stays in the E-Mail/Link field instead of being purged from the tickbox each time like Shiichan does (interestingly, 4chan's Futallaby does also purge "sage" if written in all minor letters).

>>16

What browser are you using? I think I've tracked down the problem, and it's most likely a browser bug. The ancient Firebird (not fox, even) version I tested at work had the same bug (character set issues in the escape() and unescape() functions). It looks like your browser also doesn't follow the spec for how they are supposed to work.

Gah, I am totally confused about what to do about the admin interface. Separate script? Built-in? Javascript? How do I display the data? I have no idea!

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.

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

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.

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

I fixed the Javascript a bit, and uploaded it for these boards. Try shift-reloading to get the new code, and see if cookies work better now that I'm not using cargo-cult code.

Oops, forgot to link the first point to my original thread: http://wakaba.c3.cx/sup/kareha.pl/1127326007

Oh, and see if dmpk2k is willing to port over the proxy detection and load-balancing/distributed server cluster functions to Kareha. Those would be neat.

A 1001th post would be a bother.

>>244

Er, that's a feature, not a bug. That's how most GUIs act.

>>313 Like lots of people use them anyway </sarcasm>. Yes, security is a good idea. What are the holes, anyway?

I meant Remote host adress instead of IP.

durr hurr

>>152
What does that even mean? Does that mean nobody can come along and claim some sort of authorshop/copyright on Kareha or a slightly modified version of Kareha?

What wakaba needs is that SILLY_ANONYMOUS too! :D

I had a number of good old threads from this board bookmarked so I could read them later and wrap my head around their ideas, but then I lost them all in a hard drive crash (strike two, Western Digital!). I also had a number of Japanese BBS's linked from this board bookmarked so I could take a look at their software's functionality and get some other ideas.

Anyway, these are all non-template suggestions:

• Topical category metadata in new thread creation so only one instance is necessary per site (further fine-grained behavior with PATH_INFO would let you nest one category inside another and view multiple categories of threads at once).

• Thorough search functionality a-la notchan, using PATH_INFO. This might not be possible without implementing a per-post metadata system though.

• Elaborating on the above, per-post metadata for "sage" status, for future-proofing in case someone wants to remove the functionality from the e-mail field (onto a checkbox, for example).

• config.pl parameter for a generic image that takes the place of a deleted image (ie, Hello Kitty)

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

• Replace HTML error pages with dialog box equivalents using JavaScript.

• Kill user deletion. I can't see any case for when it'd have constructive uses.

• Conversion to mod_perl?

I also have an early idea swimming around in my head about only bumping threads a few positions up, instead of to the top. Another idea is actively bumping threads down, either by a few positions or to the bottom. I'm not exactly sure yet what good it'd be for.

Also...

>* I'll add thread closing to Kareha, but I was thinking of setting the default behaviour to never permasage or close threads.

I think this is ideal for the time, until we have enough statistical data to derive thorough auto-permasage and auto-delete/archive algorithms. Just add the functionality for mods to manually set these statuses, but remove the "permasage at 1000" behavior.

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?

RENZOKU are the flood detection things... even if they are useless MAX_POSTS_PER_MINUTE makes a lot more sense than RENZOKU2

3) was about a string to trigger ID:Heaven, not a constant for the Heaven part (which is already configurable)

Re: email/link field

Just because it works one way on 2ch/whatever does not mean it is the best way. Having 'fusianasan' as the only way to trigger the effect is just narrow-minded. Functions should have descriptive names to the people using them; should we keep the field names in Japanese because the Japanese have them in Japanese? Having all of the applicable things configurable is something that makes sense, and you can easily have both 'fusianasan' and 'show_ip' that work at the same time. Frankly, the combinations of many things into unrelated fields is a design flaw. What if you want to use a name/trip and fusianasan? What if your email address contains the string 'sage'? What if you want to sage a thread, but have an ID still?
I think the confusion of existing users is worth reducing the learning curve and improving the intuitiveness.

I'm not saying that the default behaviour needs to change, but being able to easily configure the strings used allows for easier localization.

I probably misspelled fusianasan too, why should I have to remember something so foreign?

> You still end up with no way to link the fusianasan post with the name/trip one without IDs enabled (unless the ID method is known and no secret data is used).

You'd figure that people who know what fusianasan is will also know how to trigger IDs.

> You spelled it fusiansan once.

So I misspelled one word once.

Sue me!

> Also, how is Kahera unrivaled when there are still large sites that are not running it? Shiichan is still on world4ch, Thorn on parts of wakachan for example.

Neither world4ch nor Pichan are by any means "large". Also, yes, as Shii said, their webmasters are stubborn.

I have always found that it's more difficult than one would think to implement features that will measure "popularity" in a satisfying way that isn't open to abuse in one way or another.