> To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?
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.
> 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.
Personally, I find the reverse order listing, as well as the random order listing, to be a bit silly & useless. The only useful bonus feature here seems to be the comma range seperator, but it seems even in that case there is not much benefit to it (saves 1-3 links in the average case that it is needed, which is rare to begin with).
> 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.
signed
> In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu?
This was proposed before (long time ago) and it is hereby also signed.
> and would something like this work (given that all boards share the same root directory)?
That's a tricky bit and I think it was decided against because it would be too much work to properly maintain such a function at the time when 4chan implemented it.
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.
> the only boards that use them are image boards where you have to load images anyway.
Correction: http://www.akatsukimanga.com/kareha/
> To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?
I find the "1. Thread title (1000)" format much more readable in the post list. And for the main titles, I don't see any value is putting the position in there. That serves no discernable purpose.
> 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).
They already do, but only if there are enough posts in the thread for this to make sense. Or, try a short range like 23-27 to see it in action.
> 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.
I've been wondering about the justifications for which navigation links should go where. 2ch has it pretty much worked out, I'm sure, but I don't quite see why there should be a "First 100" at the top but not at the bottom.
> Change "Del" links to widget buttons.
Would be very ugly. Those buttons are big.
> In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu?
I was meaning to do that from the start, but there was some problem with gettting it right. I forget what exactly.
> 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).
Squeeks would prefer to have a separate script for admining. I'm not sure which is the best approach here.
> and would something like this work (given that all boards share the same root directory)?
> >>>>sup/1129153864/1-100
> >>>1129153864/1-100
Maybe, but I don't see the value in adding code for this, given that you can just paste the URL in there.
> 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).
The front page gets lots of hits. This would drive up CPU usage something fierce.
> Oh, and please bring back MAX_LINES.
I still don't think it serves any useful purpose.
> 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?
The effect would be miniscule in comparison to the huge increase in bandwidth that would result from sending the entire static thread pages.
The "entire thread" link can easily be changes to link to the files in /res/ instead of going through the script, but that would make it somewhat less convenient when you want to consturct custom URLs, so I haven't done it.
> Also, let's put out a partition to kill secure tripcodes (unless they originated from 0ch/Futaba)
Why? Even if 0ch or Futaba implemented secure tripcodes, you wouldn't get the same secure tripcode there as on another board. That's the nature of the security.
> captcha (until we find a way to implement similar functionality without requiring it in the form of a GIF/PNG image)
That's even more non-sensical. Nobody on the entire internet has figured out a reasonable way to implement captcha except by using images, and the only boards that use them are image boards where you have to load images anyway. And finally, they aren't just there to annoy you, people do actually try to flood boards, and they are stopped by the captcha.
> And is there any practical way that Kareha can be modified to run multiple (even nested) boards in a single installation?
Not without doing a lot of changes throughout the code, and not without breaking current installations.
∧∧
( ・ω・) It's late
_| ⊃/(___
/ └-(____/
∧∧
( ・ω・ ) Good night!
_| ⊃/(___
/ └-(____/
<⌒/ヽ-、___
/<_/____/
 ̄ ̄
What does Thorn have to do with Kareha? Thorn's counterpart is Wakaba.
Anyway, the version of Shiichan on world4ch is bust. It's not a case of feature versus feature here, Shiichan simply doesn't work. It's not worth comparing until it doesn't break regularly.
If Shii were still working on it might be different, but Shiichan is effectively a dead project which incidentally has a closed and broken version working on world4ch.
>>96
forgot to mention that maybe a parameter could be included in config.pl to define an XHTML file for the disclaimer/rules block. It could be used both in 2ch and Futaba (right under the posting area) modes.
I can't reproduce this on Firefox 1.0.4 nor Safari on the Mac, but that ancient Firebird had a similar problem (but even worse).
Anyone else? Try post with a | in your name.
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.
Oh, and I apologize for indirectly causing you too much trouble with this change.
Thanks. I did it the hard way and put in the proper transformations everywhere so filenames can be kept intact, though.
Text Art's description about auto-linking URLs and >> references is redundant. Not a bad solution with the layout, though (hiding the menu behind "More options..." still bugs me).
Also, I forgot to mention: fusianasan works now! Put it in as your name to test it!
rel=nofollow for internal links as discussed in http://wakaba.c3.cx/sup/kareha.pl/1127092367/
> but I don't quite see why there should be a "First 100" at the top but not at the bottom.
Probably to avoid clutter and because of the assumption that if you arrive at the bottom of a page, you can do without the "First 100" link. "First 100" seems to be a navigational aid for beginners who are new to the thread, so it makes sense to only have it at the top.
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!
Oh, and "AA mode" should be changed to "Text art mode" so we won't be incessantly quibbling about the difference between ASCII and SJIS art.
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!
Oops, forgot to link the first point to my original thread: http://wakaba.c3.cx/sup/kareha.pl/1127326007
Oh, and see if dmpk2k is willing to port over the proxy detection and load-balancing/distributed server cluster functions to Kareha. Those would be neat.
Yes, it's throwing Javascript errors for me if I use that character. Gonna look into that some more.
There are some inconsistencies in both the Blue Moon and Futaba styles, with regard to the size and formatting of text labels in the Create new thread and Reply form areas.
The spacing of the Create new thread title is off in Futaba, Headline, and Toothpaste.
None of the styles that utilize rounded corner borders have them in the Create new thread area.
>>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
> Can't this be somewhere else but the post form?
No, because that would be immensely useless and annoying, because nobody would know it's there, and even if they did, they'd have to go somewhere else every time they wanted to post something using a different markup.