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.
>>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). :)
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.
http://wakaba.c3.cx/sup/kareha.pl/1114201493/l50
Or use some sort of filter to replace them characters with underscores on upload.
This offcourse for files that keep their original filename.
>>n74,76
It's good for referencing replies, too.
The "always show the first post" behaviour is sort of confusing at first. It seems more intrusive than useful.
>>152
What does that even mean? Does that mean nobody can come along and claim some sort of authorshop/copyright on Kareha or a slightly modified version of Kareha?
PS: I just tested fusianasan + tripcode on 2ch, it works fine.
> 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.
Well, I don't want to have to read posts without highlighting. It's annoying. Just for that, I don't want leave it off.
On another topic, a vote: I could make the secure tripcodes and other parts of the script that use the SECRET more secure by some small changes, but this would make secure trips change when you install the new version.
Good idea, y/n?
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.
>>137
I also noticed that you removed the CSS selector in individual thread views. Personally, it seems both the Admin options and Style selector are a bit of a hindrance to the overall layout. Don't get me wrong -- I think the drop-in Style capability is fantastic-- but it just doesn't seem to play nice with the current 2ch page design.
The thing is, don't most or all major browsers these days allow users to change CSS styles from within the application itself? I know Firefox does, at least. Maybe the selector isn't really necessary.
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:
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?
I thought fusianasan was supposed to be a mod-only function to weed out bad posters. And what would be the difference between revealing the persons's IP and his ISP's domain?
>>99
I didn't mean to include Forcenick in there, sorry.
Adding to that, however, how about forced sage for specificed IPs? It'd make for a great slogan: Remember kids, tripcodes and aging are privileges, not rights!
> change the no-ID-on-email option to no-ID-on-sage
> multi-page links (1-, 101-, 201-, etc) at the top of subpages
Already implemented.
> config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached
Isn't this essentially the same as saying "Please don't talk so much?"
> no EMAIL_ID parameter (most if not everyone uses "Heaven" anyway, and if they really want to change it they can easily find the string in kareha.pl)
The choice of this string is so weird and arbitary, I feel better keeping it as an option so that I can disclaim responsibility!
> better configuration of date and time (with optional timezone offsets), parsing certain characters for individual elements (ie, yyyy/MM/dd(D) hh:mm:ss -5:00:00) and also accepting numerical inputs for fixed dates and times (Eternal September)
> red, bold thread filesize indicator near the bottom of subpages
Pretty useless. I'd rather not waste work and code on something that has no actual use. (Timezone offsets would be useful, but this is such an incredibly hairy issue to get right, I don't want to even try. Just handling Daylight Savings Time would make my head explode, and I can't just leave it out, because then either the admin has to keep changing the offset, or the time will be wrong half the year anyway.)
> non-bolded post numbers
> colons before dates
> colons before names (thread subpages only)
what
Your browser momentarily regressed to an old bug and then got better? Who can tell?
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.
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.
> 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.
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 "`"
>>151 It's all public domain, I believe.
Apparently it's not Japanese, because it's supposed to be pronounced as an English word. I have no clue, though.
>>n74,76
It's good for referencing replies, too.
The "always show the first post" behaviour is sort of confusing at first. It seems more intrusive than useful.
You may want to consider releasing Kareha & Wakaba under some sort of license at this point, just to make sure that the scripts always stay free for people to use.
http://en.wikipedia.org/wiki/Free_software_license
http://en.wikipedia.org/wiki/Software_License_Types#Free_software_licenses
http://en.wikipedia.org/wiki/Copyleft
I think you're a bit nutty, >>350...
How about a function to replace an inappropriate image with a standard image? (aka HelloKitty.gif)