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?

Plus if you were to allow those tags in HTML, you should do the same for WakabaMark (which actually takes its cue from Markdown, so I don't see why it has a different name).

>>32

Your browser momentarily regressed to an old bug and then got better? Who can tell?

>>22

Running in pure perl would be ideal, portability-wise, but in practice implementing a JPEG loader and saver from scratch in Perl is both a lot more work than anyone wants to do, and the result will also be too slow.

As was already stated, making a statically linked executable lets you distribute pre-compiled binaries that people can just upload along with the script.

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.

Hmmm, I just noticed you still allow <a> tags, which would let posters use inline links. Are you gonna keep that?

Here's a fun little game for you all!

I'm looking into adding support for using HTML markup in addition to WakabaMark, but since most boards use XHTML, I can't just let through any old HTML, and most people can't write well-formed XHTML. Also, I don't want any cross-site scripting going on. So I've tried to write a piece of code that takes any horribly written piece of HTML, sanitizes it by removing all tags and attributes that are not an approved list, checks the attribute values, and turns it into well-formed XML.

Now I'd like to see if anyone can break this. The objective is to get some Javascript onto the page, or making the page break in Firefox (or any other browser that parses XML strictly), or otherwise causing trouble. Have at it!

http://wakaba.c3.cx/test/sanitize.pl

>>63
Nevermind, the issues seem to have resolved themselves within the hour of the new version being uploaded.

More stuff:

To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?

And as suggested before, the navigation links on the bottom of individual thread pages should include "Previous 100" (ie, all posts before the first post in the URL) and "Next 100" (ie, all posts after the last post in the URL). Of course, this could get screwy if you're using reverse order and out-of-order posts in the URL, so I dunno how well it could be implemented.

The "First 100" link should also be removed from the bottom of individual thread pages, and there should be a link to to thread-list included below the reply box of each previewed thread on the front page.

Bonus:

Change "Del" links to widget buttons.

In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu? The same could be done with the Admin functions (appearing only after one correctly inputs the password), placing it on the right side of the board and thread title headers (this would also allow admins the convenience of deleting and permasaging threads from the front-page).

and would something like this work (given that all boards share the same root directory)?

>>>>sup/1129153864/1-100
>>>1129153864/1-100

P.S. When you mentioned serving dynamic pages in >>46, were you referring to individual thread pages? As I mentioned before, it'd be nice to make the front page as dynamic and flexible as thread pages when it comes to viewing options (via PATH_INFO).

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?

Removed it when redesigning the page head, haven't figured out quite what to do about it yet. It needs to be changed, but to what, I'm not yet sure.

Also, here's something that would be useful, but is a bit more work than I feel like doing right now:

A simple thumbnailing program, that has no external dependencies and can be compiled to a maximally compatible, statically linked executable, for those who have hosts that don't have any image processing software, and don't allow you to compile your own. Should be able to load GIF, JPEG and PNG images, and produce JPEG thumbnails. Should contain all the source code it needs without linking to external libraries (it's easy enough to just stuff libjpeg, libpng, and zlib into the distro).

If anyone is lacking a programming project, feel free to take up this one! If you do, I can provide some fairly fast and good-looking image scaling code (or just rip it out of mangariini yourself).

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

>>41

>database redesign

You mean requiring SQL software, or just making backwards-incompatible changes that would screw up old threads?

>prevent abuse

Are you only referring to flooding and spamming, or also trolls and flamewars?

Finally, out of curiosity: how much of the functionality in the .js file do you think could be properly implemented into a new or existing perl script?

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

> He meant saging a thread just because a part of the actual e-mail address contains the word "sage."
> You know, like [email protected].

Well, then you are out of luck, aren't you? So you want to enter your E-Mail but cannot because then the post wouldn't bump then? Solution: Write it in the comment field, problem fixed.
There is no reason to change well-known keywords for this or even turn this into a frustratingly unconvenient tickbox/checkbox.

>>112
We already have the ID function, so why do we need such an egregious compromise of anonymity (and security) like voluntarily exposing your own IP?

I hate that blue link next to the reply box! It looks ugly!

Also, there's no "Less options..."

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

About rel=nofollow: What links should have it? Obviously not the "entire thread" link, but the l50 links in the thread list sort of need it, otherwise the search engine will never find them in the first place. But that means the l50 links will end up in the index.

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

the text

c < d

causes a <d> tag to be opened, which is not on the list, and therefore all the text until the next tag will be deleted. a better behavior in this case would be to just convert that < to &lt;. you even ought to do this for

a < b

too, despite the fact that b is a valid tag, because who the hell leaves the closing angle bracket out of their HTML tag?

creating the correct regexes for this is an exercise left to the reader.

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

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

>>226
(´・ω・`）

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

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

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

Er, that's a bug I guess.

> 1) rename the RENZOKU constants to something that makes sense

I dunno, they're pretty useless anyway, as has been pointed out, so I don't know if I care enough to change them.

> 2) Have the string to sage and fusianasan defined as a constant in config

I dunno, if different boards use different strings, that will only make for immense confusion.

> 3) A specific string for ID:Heaven instead of anything in the email field

Well, the only string that makes sense is sage, but yes, I should implement the Heaven-on-sage behaviour.

> 4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?

Maybe, but I'm not sure it's worth the effort (I'd have to implement a preferences page for it, too).

I meant Remote host adress instead of IP.

durr hurr

>>183

No, that's just plain wrong. It is very much the job of the programmer to decide on such issues, and make sure they work consistently across boards.

>>89

>But the body text is even more important, and that goes at the bottom. So I dunno.

Yeah, I considered this too. I'm mainly suggesting for the sake of convention.

We definitely don't need a separate page for creating new threads (I get bad memories of Shiichan), mainly because it's inconvenient and requires a whole other page for something that really shouldn't. The fact that it'd be at the bottom of the board page already detracts bad posters with itchy trigger fingers. I think most of us have an "End" key on our keyboards, so we don't really have to scroll all the way down anyway. :) Really, the only issue I have with moving the post box to the bottom is that it ruins my personal visualization of new threads falling on top of the "stack of threads" and replies emerging from below the "stack of replies".

In reference to >>90, there's something I see on every 2ch board that is a lot less prevalent in Western counterparts (barring certain 4-ch boards): a rules/disclaimer block at the top, above the thread-list, with links to a newbie guide, site FAQ, and the like. Yes, it may be an annoyance to veterans, but being at the very top means it's most visible to newbies. That way, we don't get a constant influx of people wondering whether or not they need to fill in the Name and Link fields and what the hell sage and tripcodes are.

/-100 shows the first post two times.

>>108
I don't think that restricting specific users' posting priviliges is useful in any way except restricting them from posting.

>>108,113
"fusianasan" is for when a user wants to prove that he is posting from a certain place (like a school, a company's network or a military base).

>>112
A keyboard shortcut for "reply" in Kareha or "submit" in Wakaba would be nice to have.