>>259

Fixed.

>>260-261

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

Copyright only applies to the literal code, not to features, ideas, or algorithm. Patents do, to some extent, but that's not the issue here. Since I'm not going to write the exact same code, there's little they can do.

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

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

>>148

>5) Seperation of sage et al from the email field to something else...

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.

>2) Have the string to sage and fusianasan defined as a constant in config
>3) A specific string for ID:Heaven instead of anything in the email field

As I mentioned above, this would better work if they could be modified within each template in the list of string variable definitions.

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

I like this one, as far as saving name and e-mail inputs go. I occasionally browse 4-ch at school, and it'd be nice for just an option to clear cookies when you're done and don't want anyone else to use your name, e-mail, and deletion password.

What the hell is RENZOKU?

P.S. >>151 is RMS

What wakaba needs is that SILLY_ANONYMOUS too! :D

PS. What's "Raw HTML"?

> Maybe the thread title should be an l50 link?

That's what I've been saying in >>3!

> If anything, the role of capcodes should be minimized or altogether eradicated, in favor of ninja moderation.

It's up to the administration of the site how to use them. I am advocating that if they are used at all (and yes, there are useful instances for this and yes, these are and should be rare) then it would be helpful to be able to differentiate between site owner/admin/supermod/mod/maid/etc

Oops, here's the screenshot. orz

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.

sup

>>191

Thanks for reminding me that I need to fix the CSS for the captcha!

>>255
By replacing it with AN EVEN DUMBER PUN!

Getting back to inconsequential nitpicking: I find the "___ image replies omitted" phrase to be a bit redundant, and for one it confuses me as to whether or not those image replies are separate from text-only replies. How about simply calling it "images"?

>>255
By replacing it with AN EVEN DUMBER PUN!

>>74
The comma range separator is useful for anchoring a certain post range to the first post (ie, "1,-100"), but that's all I can really think of. Still, I appreciate such a degree of flexibility.

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?

(Lots of stuff in here, click "whole post"!)

> How about listing what dmpk2k or you have done already?

Truth be told, I haven't even looked over his contributions yet. I'm doing some work on Kareha first. He did bandwidth load balancing for Wakaba across several servers, and image file archiving, at least. Plus some proxy checking and other goodies.

> Split threads and posts into separate tables. You're repeating the lasthit and parent column over and over.

Bad idea. Adds a lot of code complexity without adding any new functionality. The current solution is simple and robust.

> Automatic closing and moving of threads that do not get any activity in a certain timeframe (based on average activity frequency of the board)

This is nearly impossible to get right, and I don't think I'm going to try unless someone can think up a reliable algorithm that uses the data that is availble (not much).

> Reintroduction of "Marked for deletion (old)" (it's just handy to have that)

I tried several times, and concluded it wasn't worth the code and database overhead it would take. This feature is relatively easy to implement for Futaba-style post number limited boards (and Futaba implements it really stupidly), but it gets tricky when you have different deletion modes and want to do it right.

> Prune-limit mode that is defined by number of files or size sum of files on a board

Size limit is already implemented. I might add file limit, but I'm not sure it's all that useful, when you already have the size limit.

The rest, I agree with, and I will try to get most of it done. I'm sure there's some more stuff hidden in old threads, though!

>>55
I'm not complaining about the current system, just throwing around some new ideas for a change (instead of blindly following whatever new thing comes along on 2ch).

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

It's also more markup when even the existing one isn't working as well as it should.

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

>>326

>You need to explain what you're talking about before I can do anything about that.?

See attached screenshot. It's in every style but Pseud0ch.

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

Well the functionality is already in kareha.pl, right? All you need is some modifications to the mode_message template. You can check out the 2ch-like boards on Futaba for reference, though I'm pretty sure I've seen other 2ch-like boards that implement multi-paged functionality with a different layout. Personally, it isn't all that big a deal if it's just a template issue though.

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

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?

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

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?

>>327

>(optional) preview page

Excessive, methinks.

>Is there a reason why the post box is so small and pushed to the side?

Because mode_message is modeled after the 0ch layout. To compensate for the smallness, it expands automatically when you click inside it.

>Forced fusianasan would be fine I think, if they had advanced warning.

This can be easily done manually with rules.html

>>336
IMO minimalist web applications like Kareha should only focus on core content/functionality and leave the inconsequential presentation options up to browser extensions so that each user can tweak them to his whim. That's why I was pushing to offload the CSS selector to an extension.

>>337
Here's a better example, I think. Even if we can't remove the excessive side borders, is there a way to at least have rounded corners?

On formatting options: I think >>338 fails to understand that leaving the formatting options up to each individual user is a good thing by all means. Besides, they are absolutely necessary to the interface and core functionality, just like the Name and URL fields are. Preview functionality, on the other hand, should be implemented in an extension.

I think the issue that people have with the formatting options is that we don't have a Japanese counterpart to blindly model it after. Since we're going at this on our own, nobody is quite sure how it should be done. I'd like to see how it turns out on mode_image (if you feel the need to include it at all). :)

PS. What's "Raw HTML"?

This is the obligatory encoding test ... in <code>

 ㋋㏡
 ゔ〲〰 ゔ〲〲〰〰 ゔ〲〰 ゔ〲〰 ゔ〲〰ゔ 〲〰ゔ 〲〰ゔ〲〲〰ゔゔ
〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰
(♛ฺД)(*゜∀゜)～♡ℳฺℴฺℯฺ❤ℒฺℴฺνℯฺ..._〆(゜▽゜*)㌰㌰ ㍉㍍㌧㌔㌶㍊㌣㌦
㌀㌁㌂㌃㌄㌅㌆㌇㌈㌉㌊㌋㌌☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ
☼♭♬♫♨♩♧♦♥♤♣♢♠♡♐ฺ♑ฺ♒ฺ♓ฺ ♔ฺ♕ฺ ♖

ฺ ♗ฺ♘ฺ♙ฺ♚ฺ♛ฺ♜ฺ♝(･∀･)/ヾ~~╋┓!㋦㋸㋭°

|壁|」゜ρ゜)」　ノ ヽ``～ 力㋦㋸㋭°
 　 　 ／ ⌒ヽ  
　 　/　´_ゝ`） I am sorry、 the β α κ α kopipe couldn't be carried out・・・
　　|　  　　/
 　　| /| 　|
　 //　|  |
　Ｕ 　 .Ｕ  

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

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

>>357
by "including," I mean "plus."

>>101
If that is legit, then fusianasan needs to display IPs just like tripcodes: not bold/strong.