>>123
signed

>>209

>> More information on the all threads page, date of the last post? file size?

Well, I had already proposed the filesize indicator in >>208, but optimally I would actually prefer that subback resemble the one in 0ch (ie, same as the main page thread list, but without CSS).

And single-post links don't include the thread's first post anyway, so there's no need for >>n. Quoting an entire post is not wise either.

>>211

>Isn't this essentially the same as saying "Please don't talk so much?"

In a sense, yes. Just like the postcount limit could be interpreted as "Please don't talk so long".

>what

main page -- 161 Name：◆WAHa.06x36：2005/10/21(Fri) 14:44 ID:Heaven
subpage -- 4 ：◆WAHa.06x36：2005/10/21 14:44 ID:Heaven

Question: does Kareha have a 1001th post message like "Name: 1001:Over 1000 Thread" for when a thread exceeds its postcount limit?

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

I notice some weirdness with the CSS changes sometimes. For example, the first post on a -100 page will sometimes have the first character of the post enlarged. >>2 looks something like
\
/>2 until it is mouse-overed or you change the CSS, but then it goes back to large again on refresh. Also can happen with lowercase letters. Some of the field labels also change size from refreshing in a certain CSS versus just switching to it.

>It's all a design & layout question. I'd like to have the interface reduced to what is absolutely neccessary, esp. since I do not think many people really want to even bother or bother very often with the whole markup question.

Why have a name field or link field? For the majority of posts they are not used, or only used for sage. As stated earlier, they are not even needed for the bare minimum of usage. You want to prove it is you posting? Use a gpg signature or something and a third-party extension, it is just fluff that is not needed at all!

I'm all for having a system that is easy to modify to the end-user's wants and needs. However, there are going to be plenty of users that are not hardcore enough to make or use such options. Therefore, the normal functionality should be pretty usable.

People seem to pop-up whenever something that would change the interface to shout it down. They seem to fear any change and normally give no reason other than it would clutter things up or some nonsense. Does the CSS selector -really- get in your way? It is probably a whole ten pixels! Is having the More options thing really ruining your experience, or are you just against it on some principle? Personally, I would move it below the comment text-area or something, as now the tab amounts between the main fields has changed.

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.

>>157
So the functions need to be hardcoded to a post element one way or another? If I wanted to, let's say, create a template for gazo-box or Shiichan (both use checkboxes for sage), I'd need to slightly modify kareha.pl to check that new checkbox input instead of the Link string input?

An interesting limitation. Thanks for explaining.

About permasaging/deleting after a certain thread filesize is reached: would this be the same as a limit on the total number of characters in a thread? Or would we also include WakabaMark formatting, hyperlinks (including navigation), name/date/title headers, reply boxes, and non-Unicode characters in the formula?

>>158
Chances are that most if not all major/fundamental changes made to Kareha's core scripts will clash with the philosophy of most people here (including WAHa), and they won't care for them anyway. There really aren't all that many big-bang end-user features left to be implemented in Kareha before it loses its minimalist charm.

P.S. Reminder for >>85

And this:

だってよ。

231 ：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★：04/02/05 14:13 ID:???
ハンマー投げゲーム機能つけてみました。
名前の欄に『murofusianasan』と書き込めば
【６０ｍ】とか【７５ｍ】とか記録が出ます。
数値はランダムで０～１００くらいまでありますよ。。。
お暇なら遊んでください。

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

First thought: It would eliminate the concept of sageing as a protest entirely.

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

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.

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

>>16

Yes, it's throwing Javascript errors for me if I use that character. Gonna look into that some more.

> It would eliminate the concept of sageing as a protest entirely.

Except that nobody knows what's going on back-end.

I like the idea though.

"page top" is better imho

Funky, works... I am pretty sure the error has something to do with the characters preceeding the "¦" in the unprocessed tripcode. It begins with a "`"

>>259

Fixed.

>>260-261

The test script doesn't try to handle charsets at all at the moment.

>>153

http://en.wikipedia.org/wiki/Public_Domain

It means anyone can do whatever they want with it. They can't claim copyright, though, since they didn't create it in the first place. They can modify it an claim copyright on their modifications, at least as long as they're significant enough, but that doesn't affect existing works in the public domain.

> This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.

There's no obvious way to do this, since there has to be code that specifically checks a field and takes certain actions long before the template comes into play. It'd take some sort of plugin system to implement it, and I don't think that's quite called for.

Also >>154 is Kami.

> The error page in mode_message should more closely resemble that of 0ch (complete with "ERROR!" title).

Signed. And the style selector on the error page is pretty useless.

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?

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

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!

Forgot this one:
The general functions of imageboards do not seem to be clear to most people that eventually come around, the influx of total newbies is still big. Many neither know what sage is, how to properly reply to threads, what tripcodes are, etc.
Because of that, I believe it would be good to include a default link at the bottom of the unordered list at the bottom of the new thread form that links to http://wakaba.c3.cx/docs/docs.html#UsersGuide

Relevant:
http://dis.iichan.net/idc/kareha.pl/1128824710/12-

> Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess.

Why? Let people figure out things themselves, if they are so keen on changing their keywords. They can get together in their own webmaster threads and figure this out. I don't see why this should be solved here.
Of course I think this is a dumb idea in the first place. Nobody needs to know what fusianasan and sage are. Write a FAQ with two sentences about it and/or let your oldtime users tell newbies. Two frickin' words, and you people talk about it as if it were something like making up a new system of romanization!

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

That's a bit too much. You want to talk about sage and fusianasan in the comment field, not trigger it with it.
I suspect you are joking here, though. Design is about what you can take away and still remain optimal conveniency/efficiency on the user part, not about taking as much away as you are technically capable of.

>>9
I mentioned the option because on highly active boards it's helpful to know which threads will be gone in the next few minutes.

You could add entire thread links to either the "num" or "posts" column in subback.

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?