Partition for renaming "WakabaMark" to "WAHaMARk"!

>>201

Yeah, no, maybe. Using secure trips for capcodes also adds extra protections against accidentially misspellingyour capcode and leaving it open to attack.

Oh, and the navigation bar on the error page should probably look like the one on the thread page.

>>182
That's not what I meant. What I meant was: If people want to change keywords to something, let them figure out at appropriate places what this something should be. Whether it should be "down", "stay_down" or "stay_put" is not really a discussion belongs here, not at this point anyway.

/-100 shows the first post two times.

(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!

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

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

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

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

Weird, ¦ now stays ¦.
Testing #¦ now.

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

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.

Also, wouldn't making capcodes even more prevalent be considered A Bad Thing®? If anything, the role of capcodes should be minimized or altogether eradicated, in favor of ninja moderation.

Another question: would FUDGE_BLOCKQUOTES be considered deprecated by now, or are there still CSS styles out there that require it?

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

testing #`¦

I was browsing through some old threads and now they're all gone. :(

>>220
I meant only using the extra post for autoclose situations where the thread has exceeded the defined postcount limit in config.pl. As for the implementation, couldn't you just have Kareha use post_stuff() and (somehow) replace the timestamp with "Over XXXX Thread"?

>>342
Well, for example, in both forms the text labels are bolded when they shouldn't be, in Futaba and Blue Moon. If you take a look at Blue Moon, the text labels in Create new thread are larger than those in the Reply box.

Some minor things
1) rename the RENZOKU constants to something that makes sense
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
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?
5) Seperation of sage et al from the email field to something else...
I think a checkbox works better than putting something in the link field, but that can always be left as working too. It would be nice to know if the name is underlined that it has something other than sage rather than putting the cursor over it and reading the status bar. Strip things from the email field, append (sage) to the Name line?

> I don't understand the argument for OH NO ANOTHER BUTTON MY WHOLE LIFE IS RUINNED crowd

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.

> The replacement will be an option to select the default markup for a board, which makes much more sense overall.

I agree, this seems to make the most sense. I understand the "More options..." will not be showing up on boards with fixed settings, so I'll shut my mouth from now on. Apologies to all who I've been bothering.

Well, a lot of machines run on x86 these days, so that covers a lot of it. And you could pre-compile for a couple of other architectures, and have it pretty much covered. Linux and unixes in general make it ridiculously hard to distribute binaries, as opposed to Windows or Mac OS, but it's still possible with a bit of trickery. Avoiding dynamic libraries helps a lot.

>>66-67

Noted and fixed in development version.