Should be fixed now.

> Right, I guess it was dumb to mention 0ch/Futaba in the first place. The point is, as you said yourself, tripcodes are a gimmick, and if someone wants to maintain a persistent identity across multiple boards and sites (ie, everyone here with a tripcode), they have no choice but to use ordinary tripcodes. Secure tripcodes are useless because they limit your identity to a single board, supposing each board/site's cipher key is different -- which it should be, since that's the point of having a secure tripcode in the first place. No one should be so paranoid about a tripcode that they'd need to have a different one per board/site.

True, they're of limited usefulness, but people like admins might prefer to use them. And there are certain cases were you might use them temporarily for various purposes. I wrote the code already, so I might as well leave it in. It has some uses at least.

> Shouldn't we sacrifice some backwards compatibility for a more robust and scalable design? It might even be possible to provide an upgrade.pl for old threads.

I think I'm too lazy to do it. It's kind of hairy. Besides, as I said, you can remove a lot of the drawbacks of seprate installations by using symlinks.

>>145

>does that mean you approve of removing the style selector on subpages?

I was referring to the entire board, but as you later explained, it seems it can never be removed completely. Though removing it from subpages wouldn't be a bad idea I guess.

>Kareha has no "No File" check in the first place

That's what I thought, but then why is it in the Reply pages?

Other: Have you considered multi-page links with intervals of 100 posts at the top of subpages (ie, 1-, 101-, 201-)? Red, bold thread filesizes displayed near the bottom of subpages?

Something else to consider: separating the board description/rules template from the board- or site-wide announcements. Check out http://0ch.mine.nu/test/read.cgi/jikken/1120050851 to see what I mean.

The "Entire thread" link in the top navigation bar of the thread page is still broken.

>>18
Firefox 1.0.7, WindowsXP Pro.

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.

The "Entire thread" link in the top navigation bar of the thread page is still broken.

> Also, I couldn't be arsed to fix Amber, since it was just a joke in the first place.

Booo!

> who here finds enough use in the auto-expanding comment box to justify the annoyances when you click in or out of it?

I love that feature. Please don't remove it!

> I think the drop-in Style capability is fantastic-- but it just doesn't seem to play nice with the current 2ch page design.

plz 2 be keeping that feature too

>>98

Well, that's what I've said from the start, but people keep requesting them.

FUDGE_BLOCKQUOTES is used by the Futaba style, and I guess I just want to keep it there to make it compatible with Futallaby-style CSS files.

>>161

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

That's what I was referring to also in >>154 (S_NOID being the theoretical trigger string for ID:Heaven).

Concerning localization: there are certain compromises with input triggers that must be made in order to maintain interoperability with Japanese users coming from 2ch/Futaba. They're not going to care about a system where "sage" and "fusianasan" (in Roman too I'm guessing, can someone confirm this?) don't work in their respective fields. In effect, 2ch set a standard of usability that we need to follow if we want to build a bridge between both communities.

On the flipside, I think there should also be a secondary set of trigger strings that would be more coherent to Western users and universal to all Western boards. Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess. With Shiichan's death, Kareha stands unrivaled, and setting these strings in stone would ingrain them in the culture like "sage" and "fusianasan" have been in Japan. Thinking very optimistically, if a Western BBS site should grow into something large enough for 2channers to strongly take notice of, they would pick up on these triggers and possibly make their own concessions to implement them in 0ch.

What they should be is yet to be determined. Unfortunately, they'll probably have to be pretty dull in comparison to the witty botanical references and word puns in 2ch and Futaba.

>>163

>I don't think so, not in these cases. What's the alternative? Having a different field for fusianasan, a new checkbox for sage, etc.? That's just cluttering up the interface.

Then why not simply boil it all down to the comment field, with trigger strings for inputting the name, e-mail, sage, ID:Heaven, and fusianasan? You can get a lot more minimal with the current interface.

>Huh?

He meant saging a thread just because a part of the actual e-mail address contains the word "sage."

> Why?

I am not the user who initiated this parition but I find them to be triggered far too often.

> On another note, why have I seen partition instead of petition multiple times?

An old imageboard meme. Don't ask!

>>226
(´・ω・`）

...and admin posts that override all board/thread restrictions (ie, bumping a permasaged thread and possibly even posting in closed threads).

>>151 It's all public domain, I believe.

> 2channel does not do this either by default. It can make browsing a bit more convenient (and I suspect dedicated 2channel browsers to insert & read these in some kind of standardized way) but I don't think that's reason enough to impose it on users by default.

whoops, I misread "postcount" as "posticon". Nevermind!

http://wakaba.c3.cx/sup/kareha.pl/1099697376/101-101
(First "Next 100" link) does not include >>1 in that thread

There's also some weird bug where the entire browser windowd content goes black, dunno what that is about...

>>69
The sage seems a bit off...

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.

>>210

monospace font? like this?

test1

Currently, pruning by age is measured from the time of the newest post in the thread, so it wouldn't really work. I'm not sure if this is the best behaviour or not, but it seems it makes more sense to kill threads nobody cares about than to kill slow-moving threads just because they get old.

This my just be me, but I'd like a link to the entire thread in karaha at the top of threads.

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?

>>184
If people are going to decide to use custom names for paramaters, then there isn't much you can do about it anyway, or is there?

Anyway, test with |

> Also, I couldn't be arsed to fix Amber, since it was just a joke in the first place.

Booo!

> who here finds enough use in the auto-expanding comment box to justify the annoyances when you click in or out of it?

I love that feature. Please don't remove it!

> I think the drop-in Style capability is fantastic-- but it just doesn't seem to play nice with the current 2ch page design.

plz 2 be keeping that feature too

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

Some semantical nitpicking: "replies" should probably be changed to "posts", since >>1 is not really a reply, which makes >>100 the 99th reply to a thread, thus contradicting the "First 100 replies" thing. Same goes for "Next 100 replies" and "Last 50 replies".

0ch-PHP had this nifty feature where if it was a certain "high bandwidth" time of day, then you couldn't view the whole thread.

Hm... that is kind of useless on a worldwide forum, huh?

But there should still be an option to keep people from viewing more than 100-200 posts, as an emergency way of saving bandwidth.