So, it's finally release time!
http://wakaba.c3.cx/releases/wakaba_3.0.0.zip
http://wakaba.c3.cx/releases/kareha_3.0.0.zip
I decided to bump the version number up to 3.0.0, partly because of a number of new features, and partly because there's been lots of messing around in the guts of the scripts, which means there are probably some new and interesting bugs. I do not recommend installing these scripts on any busy boards without doing some testing first, or waiting for others to test them for you. Conversely, testing is very welcome. Report those bugs!
Specific information will follow in the next posts.
First off, new features that are available in both scripts (either due to re-use of wakautils.pl
or kopipe magic):
wakautils.pl
now has a function named get_http()
which does HTTP downloads with caching. It can be used in header.html
and friends by putting in a <const get_http("http://domain.com/header.html")>
New Wakaba features:
Thanks to dmpk2k, there are now a bunch of new (somewhat experimental) features. Unfortunately, I don't know all that much about how all of them work, and I hope dmpk2k will fill us in with some details. Anyway, there is:
Kareha changes and features:
More changes that affect both scripts, because I forgot a bunch in >>2:
Also, Kareha now has an admin script. However, I was sort of tired of workin on this for now, so the design is pretty ugly and half-assed. It does work, though. It still needs some things, like the easy interfacing with a banning script I mentioned earlier (if you want to do this, you can edit the templates to include the approriate links, though). It also needs a better layout and some non-ugly CSS. Squeeks has indicated he might do some work on the latter, but if anyone wants to help out with this, go right ahead.
Well, that is about that. I'm sure I forgot a bunch of stuff, though. I'll post more as I remember it.
Now, report those bugs!
So...who is testing it?
http://img.6channel.org/sexy/wakaba.html
I got it installed here.
Wakaba also can also now archive posts and images once they're bumped off the board, for our dear packrat administrators.
I also (highly) recommend administrators of current boards run cleanup.pl in wakaba's root, since 2.1.4 doesn't always get rid of thumbnails like it should. Make sure to make a backup copy of thumb/ first.
Old data is never deleted, just moved.
Anyway, some explanation of the load balancer. Let's assume the board is shii/* (ie: shii/wakaba.pl, shii/config.pl, etc):
To enable this, do the following:
a) Copy shii/extras/load_balancing/sender.pl into shii/
b) Create shii/redir/
c) in shii/config.pl, set ENABLE_LOAD => 1
Other options: LOAD_LOCAL is a variable that gives a rough estimate how much bandwidth the local boards has per month.
LOAD_HOSTS lists other hosts to send to, their access passwords, and their bandwidth per month. See example below.
d) If you have an old board already set up, you need to convert to the balancer mode. Do this by copy shii/extras/load_balancing/redir-convert.pl into wakaba's root, and run it.
e) Refresh cache from management panel.
Before you do all the above, you'll first want to copy shii/extras/load_balancing/loader.pl to the other hosts that will be helping balance. Make sure they can execute, have permission, and that the PASSWORD in loader.pl has been changed from CHANGEME.
An example:
I have three hosts.
LOAD_HOSTS in config.pl is set up as follows: ([host 1, password, bandwidth], [host 2, password, bandwidth], ..., [host n, password, bandwidth]). So, for the above example the line would become:
use constant LOAD_LOCAL => 100;
use constant LOAD_HOSTS => (['http://www.zomg.com/shii/loader.pl', 'zOMG', 30], ['http://www.4chan.org/shii/loader.pl', 'mootykins', 50]);
The proxy detection in wakaba is a lot fancier than in futaba, for example. It has an age/refresh mechanism where it never scans recognized IPs, so a poster will only be scanned once, unless their IP changes or they don't post again before their entry in the proxy code is deleted (default of seven days). The proxy detection is also somewhat voodoo, for two reasons:
Most of the hard work has been done though, so to get a basic anti-proxy system running, do the following:
Download proxycheck from http://www.corpit.ru/mjt/proxycheck.html and compile it. Put it in wakaba's root (or in my case, below root, but you'll need to add ../'s to PROXY_COMMAND)
Change PROXY_COMMAND in config.pl.
The default line in config.pl is a good guideline of what to start with. Don't change much other than the CHANGEME (and the "CHANGEME ESMTP", which should also just be "CHANGEME"). In other words, leave the option switches the same. If you want a ready-made line, here's what I use:
use constant PROXY_COMMAND => '../proxycheck -s -d achaea.com:23 -c chat::"Multi-User License: 100-0000-000" -aaaa';
What this does is attempt to connect through a potential proxy to achaea.com, port 23. Achaea is a MUD, and one of the strings it always returns on its own line is "Multi-User License: 100-0000-000". What proxycheck will be looking for is that line. The reason I chose this is because it never changes. You can use other things too, like an SMTP server, but only if you're certain that the greeting string never changes.
If you get PROXY_COMMAND wrong, or the string it's looking for goes out of date, no blocking will occur at all.
One last comment: I recommend every board set this up if possible, but leave ENABLE_PROXY_CHECK => 0 (in other words, leave it off). It's only meant for use when a board is under active attack, because it also will lock out some legitimate traffic. Some of the board users seem to have a habit of using a proxy, and they won't be able to post while this is enabled, so it won't just block hostiles.
Uh... never mind?
Captcha overrides are a little feature put together that allows certain tripcodes to post without ever entering a captcha. This is handy for mass posters, since they don't like repeatedly entering tripcodes.
To add a tripcode, go to the Bans/Whitelist of the management panel, and add the person's tripcode in the bottom-right form (the one with "Tripcode", "Comment" in it). The tripcode it the person's encoded tripcode, with the leading !.
So, for example, in "dmpk2k!hinhT6kz2E", the tripcode to enter would be "!hinhT6kz2E". For the comment field I usually put the poster's name, since I don't usually remember tripcodes.
Once you click on "No Captcha", and entry should appear in the table belog that specifies the tripcode as "NoCap". For this point on the target person won't need to enter a captcha. Be aware that this does open you to abuse if the person turns hostile, or someone else finds out their tripcode and goes on a spamming spree.
Requesting Admin password and Remember me on this computer in the management panel be moved to the same line in a future update. It doesn't look nice the current way.
One last thing, for those who decide to use wakaba's load-balancer, please be aware that it still needs some bugs hammered out. The main one is that as of this writing I don't think it properly takes the bandwidth of each host into account.
In other words, even if you enter the 100, 30, 50 given in the example above (>>12), it seems that it's allocating redirects evenly between each one, not the 55%, 17%, 28% you'd expect.
If someone uses the load balancer extensively, please let me know so I can grab copies of what's in redir/. It'll help me confirm whether the ratios between board bandwidth is being considered or not.
Also, archiving is disabled by default. It can be enabled in config.pl
. It needs the arch/
directory, with src/
, thumb/
and res/
subdirectories.
You people are slow! I already found one bug: The RSS is kind of broken. Anything else before I package up a 3.0.1?
They're just stuffed in a directory. It's up to the admin what to do with the files later.
After login in Karehas admin.pl I always get an "Thread specified does not exist." error message if I call admin.pl without anything in PATH_INFO. Things like admin.pl/list or admin.pl/$thread do work.
That's weird, it works fine here... What Perl version?
Perl 5.8.7. It only happens if the total number of existing threads is less then THREADS_DISPLAYED in config.pl.
have you seen the new "newsticker" on 4chan? Worth emulation in an official release y/n?
> Anything else before I package up a 3.0.1?
I have several things I'd like to submit for Wakaba. Hopefully you only intend to keep major version number in sync between Kareha and Wakaba, not minor.
>>26
rules.html can be meant for board- or site-wide announcements.
>>20
Not a bug, but is there a reason you've consciously kept the image details italicized in both Futaba templates?
While we're on that topic, I got rid of a few moldy leftover interface strings in Kareha's mode_image and cleaned up the error strings for coherence and professionalism, on top of removing the <em> brackets in the file details header. Do what you wish with the changes.
plz2fix css
BAD:
body {
background-color: #6B7B8D;
}
GOOD:
html {
background-color: #6B7B8D;
}
Fix where? As far as I can recall, most of the CSS should use html, body
. Did I miss any?
I looked through all the CSS files, and all of them define styles for both html and and body. I can only conclude that you are COMPLETELY CRAZY.
http://wakaba.c3.cx/releases/kareha_3.0.1.zip
>>20,23,28 fixed. Some of >>31 copied (error messages should be friendly, not professional, though), and some other strings changed a little. admin.pl
can now edit spam.txt, too.
Also: Most of the translations are getting a bit out-of-date and are kind of full on English. They need updating, if anyone feels like doing some work.
Kareha 3.0.1, mode_message, perl 5.8.6.
I see the following warnings in my servers error.log:
kareha.pl: Warning: Use of "shift" without parentheses is ambiguous at /home/www/bbs/kareha.pl line 1145, <FILE> line 7.
The script works but the warnings are a bit annoying.
Find the line, and change shift
to (shift)
. Should fix it.
>>34-35
the problem is that 'background-color' is in body instead of in html.
also, mode_image templates.pl doesn't have any way to choose formatting
Kareha 3.0.1. The "permasage" link in admin.pl/$thread should be an "unpermasage" link for permasaged threads like in admin.pl/list.
The code to do that is there, but there was a typo that broke it. orz
There's at least one typo with regard to the DELETED_THUMBNAIL/DELETED_IMAGE parameters in futaba_style.pl.
Also, would it be possible to release a minor Kareha upgrade in the near future with a few tweaks (I've implemented most of them myself in a custom distribution, but it'd probably be good for the main version too)?
> There's at least one typo with regard to the DELETED_THUMBNAIL/DELETED_IMAGE parameters in futaba_style.pl.
Well, what is the typo?
> DELETED_THUMBNAIL/IMAGE parameters
Not possible to implement without regexp trickery that is not guaranteed to work on different templates.
> S_ANOTITLE and S_ANOTEXT parameters
Meh, I never liked those much.
> Removed capcode checks in kareha.pl and templates.pl (now that they're customizable, admins can easily add the <em> tags and append the name/cap string with '(Admin)')
For mode_image? I think I forgot to update that, will fix.
> PAGE_GENERATION checks at least for mode_image's templates.pl(ie, if I set a board to 'single' it won't display the page list at the bottom)
PAGE_GENERATION isn't really an option you're supposed to change for a given template. Why would you want to run mode_image in single-page mode? That makes no sense, as there's no way to access the older threads.
> Non-styled (ie, no h1, no center alignment, no extra line break) error template in mode_image, with designated headers above and below -- the markup should have its own div class to be styled in CSS
You can just style h1, can't you? The entire page should have its own class so you can do that (if it doesn't, that's a bug), but I haven't bothered to style it. Thing is, though, I'm not touching the CSS for the Futaba-style templates, because I prefer it to be compatible. I could make the HTML more like the original Futaba/Futallaby error page, but it's not really an issue that has very high priority.
> Is there a way to replace the <br clear> tags with something more sane in CSS? AFAIK the clear parameter has been deprecated in XHTML.
XHTML 1.0 is just HTML 4.0 in XML. Maybe it's deprecated in XHTML 2.0, but this isn't that.
> Well, what is the typo?
Unfortunately, this computer doesn't have anything better than Notepad, so I can't give you the exact line numbers. Just search for "DELETE_THUMBNAIL".
> For mode_image? I think I forgot to update that, will fix.
In kareha.pl too though, since admin functions are now independent of whether you input a capped trip or not.
> You can just style h1, can't you?
I don't know if this is sarcasm or not, but I assumed it's possible in CSS.
> The entire page should have its own class so you can do that (if it doesn't, that's a bug), but I haven't bothered to style it.
Indeed there is no body class for mode_image's error template.
> Thing is, though, I'm not touching the CSS for the Futaba-style templates, because I prefer it to be compatible. I could make the HTML more like the original Futaba/Futallaby error page, but it's not really an issue that has very high priority.
Futaba's error page doesn't use header tags in HTML, but it does center the text (then again, it also centers "postarea" and right-aligns "userdelete")
About <br clear>: I'm really just echoing the W3C spec for HTML 4.01 (http://www.w3.org/TR/REC-html40/present/graphics.html#h-15.1.3.2), which states it's deprecated.
> Using style sheets, you could specify that all line breaks should behave this way for objects (images, tables, etc.) floating against the left margin. With CSS, you could achieve this as follows:
> <STYLE type="text/css">
> BR { clear: left }
> </STYLE>
> In kareha.pl too though, since admin functions are now independent of whether you input a capped trip or not.
No. They never had anything to do with admin functions before, either. What they DO let you do is post on a board where posting is disabled.
> Indeed there is no body class for mode_image's error template.
I'll have to fix that, then.
> About <br clear>: I'm really just echoing the W3C spec for HTML 4.01
Ah, it's not listed as deprecated when you just look up the definition for the <br> tag. I don't think I'll be changing that, though, because the whole Futaba layout is heavily outdated in the first place. It's also nearly impossible to implement in proper modern XHTML/CSS, at least in such a way as to make it work in IE, too. I tried, but it was much more pain that it was worth.
> the whole Futaba layout is heavily outdated in the first place
You mean the actual Futaba software, or Kareha's Futaba mode template?
> It's also nearly impossible to implement in proper modern XHTML/CSS, at least in such a way as to make it work in IE, too. I tried, but it was much more pain that it was worth.
IE needs to die.
> You mean the actual Futaba software, or Kareha's Futaba mode template?
I mean the HTML code it uses. futaba_style.pl is an attempt to make it a bit more XHTML-like, and is at least in part based on thatdog's work of Futallaby, but there's only so much you can do with it.
> IE needs to die.
That it does, but it hasn't yet.
Well, here's the latest batch of bugfixes:
http://wakaba.c3.cx/releases/wakaba_3.0.1.zip
http://wakaba.c3.cx/releases/kareha_3.0.2.zip
Nothing terribly important, just getting these things uploaded so they'll be available.
>>50
I was under the impression that mode_image's template was 99% XHTML.
Sure, but you can write circa-1993 style HTML in XHTML too, just as long as you keep it well-formed.
>IE needs to be fixed or upgraded so it supports webstandards.
Fixed.
http://wakaba.c3.cx/releases/kareha_3.0.3.zip
Should implement the fixes in >>54 (although I was kind of sloppy with that, I might have missed some unused string), some fixes for the Japanese template, and there's now an option to turn off the ability of admins to edit include templates (since templates can execute code, that's a bit risky). It's off by default, so if you want editing, remember to turn it on.
I have to say that kareha has a much more professional feel to it now than it had before!
I installed a new copy of Kareha 3.0.0 (now upgraded to 3.0.2) and the tripcodes are acting funny. Each time I enter my name as "foo#bar" (with foo and bar being constants), the tripcode resulting from bar is different. I've gotten three tripcodes so far out of three posts, entering the same thing in the Name field each time. (Also, none of the three matches my tripcode on another, Kareha 2.0.4 forum.) Why might this happen?
That's strange... could you link to the board in question, or post the results here?
>>60
bar is equal to "super" and the results are hnaqdgEjIm, VT4sg21iYS, 8JCn9fwUsm, umVH01Gevu. The expected result (from Kareha 2.0.4) was oCplYpbPzw.
It does work as expected here. That's very strange. The only thing I can think of is that the crypt() function would for some reason be returning weird values, but that shouldn't just affect the one version. The code that generates the 2ch tripcodes hasn't changed at all between those versions, either. Do other tripcodes work as expected? Short ones? Long ones? Try posting in the test thread to compare.
Actually, this experiment is unscientific because one of the variables has changed. The 2.0.4 install is on a Linux server, while the 3.0.x is on a FreeBSD server. I will try installing 2.0.4 on the latter and see if it, too, produces ridiculous results. (Probably it will.)
If it doesn't work, then I suspect BSD has some weird-ass crypt() implementation that doesn't do what it's supposed to. I'm really not entirely sure what can be done about that, though.
Here is the FreeBSD crypt(3) manpage:
http://www.freebsd.org/cgi/man.cgi?query=crypt&sektion=3
It looks like the problem might be that the format defaults to something other than DES (probably Blowfish). Can you do crypt_set_format("des")
first? (I'm not familiar with how C functions are called from Perl.) Of course, you would only do this if (`uname` eq 'FreeBSD')
.
According to the manpages from NetBSD and OpenBSD, both of their crypt(3) implementations can be used in the traditional way, so no workarounds should be necessary for those.
> I'm not familiar with how C functions are called from Perl.
That's the problem, you can't, without an XS module in between. Searching for this on Google, I turn up lots of Japanese pages. I guess various tripcode-using programs would all have this problem. The only way out I see off hand is to use this suggestion from the man page:
> The global default format can be set using the /etc/auth.conf file using the crypt_default property.
Of course, if you're not allowed to do that, then you have a problem.
If you ask me, FreeBSD should not go around changing how well-established system calls work on a whim, but what the hell do I know.
Does anybody else see a little line above the style picker on the Society board?
That's a pretty useless question unless you specify what style you use and what you mean by a "little line".
Stardard futuba, a 2-3 pixel this <> background-color line where the board into text and the style selector are.
In firefox, too.
A picture alright?
Ordered HTML lists in WakabaMark ("1. foobar..") seem to cause infinite loops in the wakautils.pl version included in Kareha 3.0.3.
http://wakaba.c3.cx/releases/wakaba_3.0.2.zip
http://wakaba.c3.cx/releases/kareha_3.0.4.zip
>>69 fixed (although I'm tempted to call it a Firefox bug, because it was pretty hard to reproduce, and it took a sort of ugly hack to work around it), and also >>70 (which I thought I fixed once already but apparently it didn't take).
Now that ordered lists work:
Undefined subroutine &main::get_reply_text called at /home/waha/public_html/sup/kareha.pl line 871.
Dead code calling a nonexistent sub, should probably be removed completely in the next release.
http://wakaba.c3.cx/releases/kareha_3.0.5.zip
Yet another bugfix! There were a couple of bugs related to deleting files that were fixed. You only need to update if you're using images.
Oh, and can you include the fix for >>38 in the next release? I dont want to edit kareha.pl after every update.
I thought I fixed that?
I get a Mozilla yellow screen of death when using admin.pl:
XML Parsing Error: mismatched tag. Expected: </body>. Location: http://mysite/forum/admin.pl Line Number 8, Column 50:<br /></div></div></div> </div></div> </div> </div> <div id="navi"> Pages: 0 <a href="/forum/admin.pl/p1">1</a> <a href="/forum/admin.pl/p2">2</a> <a href="/forum/admin.pl/p3">3</a> <a href="/forum/admin.pl/p4">4</a> <a href="/forum/admin.pl/list">Thread list</a> </div> </body></html> -------------------------------------------------^
If you get around to it, the CSS files in Kareha's mode_image have a lot of old unused elements still defined -- and THREADS_LISTED still exists in config.pl, while HOME is nowhere to be found. Also:
> the CSS files in Kareha's mode_image have a lot of old unused elements still define
Once again, the CSS for mode_image is the same as both Wakaba and Futallaby uses. It's not supposed to be perfectly tailored to Kareha, and I won't be doing any tweaking for that.
> and THREADS_LISTED still exists in config.pl,
All options exist in config.pl, even those that don't apply to the current style.
> Error template div/body class in mode_image still missing -- on a side note, what font-size and/or font-weight would be appropriate to match h1 text styling in CSS?
I decided that since neither Wakaba nor Futallaby have it, I'm not going to add it, for the same reason as above.
> This might require its own sub function that basically removes all such limitations (text/file posts, permasaged/closed threads, choice of whether to use ID, etc).
Because it's a lot of work for something that will hardly ever be used, and really isn't necessary for anything.
Also, yet another release:
http://wakaba.c3.cx/releases/kareha_3.0.6.zip
Fixes >>77 (which was tricky to track down, because it only happens when posts posted in AA mode get abbreviated), and some other more obscure and harmless bugs I found.
What's the point of supporting Futallaby CSS when the only stock styles available are "Futaba" and "Burichan," both of which are also included in the Wakaba and Kareha packages? If it were an issue of maintaining compatibility with Futaba (the software) I would understand, because it's freely available and used across countless Japanese sites, but there is really no reason to bind ourselves to 4chan's crappy exclusive software.
(BTW, don't take any of this personally, despite the strong tones :))
It's just easier to work against a set standard than constantly changing things on a whim, like I do with mode_message. It's a major pain in the ass, keeping all styles updated.
Besides, lots of people have now created more styles to this standard, even if they're using Wakaba and not Futallaby.
>It's a major pain in the ass, keeping all styles updated.
Why not just work on the stock styles (Futaba and Pseud0ch) and leave the others up to the community to update?
Because I made all of them except Blue Moon (and Pseud0ch which was a cooperation)?
>>85
That doesn't mean you're the only person capable of maintaining them. I'm sure there's enough of a following that if people really wanted to keep certain styles, they wouldn't mind updating them every once in a while (especially for such a large version jump like 2.0.0 to 3.0.0).
Can you make the path to log.txt configurable? This would make it easy to place log.txt outside of the servers document root (e.g. somewhere in your home directory). While it is possible to configure the server to forbid access to it not many people seem to do this: http://wakaba.c3.cx/sup/log.txt and even if the file is encrypted it is a threat to posters anonymity.
I thought I had put that in as an option, but maybe I forgot. I should also add some more crypto on the password field, so that one doesn't matter either.
http://wakaba.c3.cx/releases/kareha_3.0.7.zip
Added config options for LOG_FILE and INCLUDE_DIR, and also a KEEP_MAINPAGE_NEWLINES option to disable the stripping out of newlines when generating the main page. This keeps Google ads working. Also added more encryption to log.txt, so there's really nothing in there to identify anyone in any way.
Configurable CSS directory?
$ grep CSS mode_*/config.pl
mode_image/config.pl:#use constant DEFAULT_STYLE => 'Futaba'; # Default CSS style title
mode_image/config.pl:#use constant CSS_DIR => 'css/'; # CSS file directory
mode_message/config.pl:#use constant DEFAULT_STYLE => 'Headline'; # Default CSS style title
mode_message/config.pl:#use constant CSS_DIR => 'css/'; # CSS file directory
There's a bug with the post abbreviation code, which you can see at http://pyc.h8r.net
I've noticed that one, actually, but for the life of me I can't figure out what causes it.
http://wakaba.c3.cx/releases/wakaba_3.0.3.zip
http://wakaba.c3.cx/releases/kareha_3.0.8.zip
Well, I sat down and tried again, and I did finally figure >>93 out. It was a regexp bug. I also fixed another regexp bug that caused both Wakaba and Kareha to change "." in filenames to "%2e", which technically isn't wrong, but it's a pretty silly thing to do.
Yeah, I had noticed the %2e thing too. Thanks for the fixes.
I've been extensively tweaking and slimming down the mode_image template for Kareha over the weekend, and making the necessary adjustments to each CSS file (while converting some deprecated variable parameters). Some of it dealt with removing redundant div elements such as postername/commentpostername and filetitle/replytitle, and for others it was changing certain structure elements to more closely resemble the Futaba board layout.
Some shortcomings:
Here's the template + CSS files: http://rapidshare.de/files/7635013/templatecss.zip.html
You can test it out on http://dongs.hadoken.net (WARNING: NWS), and use http://dongs.hadoken.net/kareha.pl/1131952971/ as the unofficial test thread. As you can see, older threads have been left in the dust due to these incompatible changes. The other possible issue is that I voluntarily removed the extra CSS elements that only Wakaba uses, but these can be easily readded if necessary. I hope you will find the changes useful.
Slight template update (changed body margin to 10px and removed the padding altogether).
I don't understand what you mean by "older threads have been left in the dust". Aren't they just created from the database when you rebuild caches?
Second update: created a CSS element each for the inner and outer page list table cells. For now, the border styles and widths are defined in templates.pl, but maybe they should be offloaded to individual CSS files. If not, they can just as easily be overriden.
>>99
Not in Kareha's case. Once threads/replies are created, the only way to keep them up to date is to modify the class names by hand in each html file.
http://pyc.h8r.net still exhibits the >>93 bug, even after updating wakautils and rebuilding the caches. Does the fix affect only new posts?
What in the... The fix has disappeared from all my files, too!
All right, I added it back one more time, and uploaded new files. Didn't bother to bump the version number, just re-download. The only file that's affected is wakautils.pl
>>103
Snacks is covertly undermining your efforts.
Also, new bug found: http://wakaba.c3.cx/soc/kareha.pl/1098492851
It happens when you put more than 3 whitespaces in front of a line of text.
Not a bug, it triggers code mode. Four space or one tab will make everything <pre> formatted. It's copied from Markdown, but it's a bit unfortunate since it's sort of easy to trigger by mistake. Haven't come up with a better solution though. Using only tabs would be hard to trigger accidentially, but most web browsers make it impossible to input tabs by anything except copy-paste.
is this a bug:
Eh... Let's say it isn't.
This is the ■ ▲ ▼ for the 6th thread on the /dis/ board, and it's located at the very top of the page. css bug?
It's worth noting Pseud0ch is still borked in Opera. Namely, the [del] links. I'm not certain whether it's the -1.3em or the relative positioning, but deletebutton should be replaced with one of the ones in the other CSS.
BTW, Amber seems to work fine with 3.0, at least for normal posting modes.
See here: http://forum.akatsukimanga.com/index.html
It's missing a ton of frames? So what? The differences are trivial. It also works better than Pseud0ch (cough).
http://wakaba.c3.cx/releases/wakaba_3.0.4.zip
http://wakaba.c3.cx/releases/kareha_3.0.9.zip
Latest batch of bugfixes:
>>111 a missing position: relative;
for sagethread in pseud0ch.css. This bug ist still present in kareha 3.0.9.
Thanks! Fixed and re-uploaded 3.0.9 without bumping the version number.
Some of the "Return" links match the referring url (eg: the error page when a thread doesn't exist) - but when there isn't a referer, those links go nowhere.
Did you make any substantial changes to how build_cache() and build_cache_page() work? The changes I did for my board were done with a nebulous understanding of the inner workings, so...
Umm... In Wakaba, no, in Kareha, yes. As I recall.
Pretty much. Not planning any big work in the near future.
>>122
So we will not have a working post preview in the near future?
>>123
Post preview shouldn't be implemented in the core functionality. It would work best as a browser extension.
It's not a very big thing, actually, if I implement it with XMLHttpRequest as mentioned elsewhere.
Kareha (in Futaba mode, at least) seems to have a bug where clicking a post number on a main page (to reference the post in a reply) produces a something like http://dongs.hadoken.net/kareha.pl/1134468901/#i%3E%3E1 in the URL bar. The link actually works for inserting post references -- that's why I'm not sure if it's a bug or not.
What happened to the dumplog.pl file came with kareha 2.x? How do I decode the IP address of a poster in kareha 3.x?
Aah, I didn't leave in any automatic way to do it, but you can edit admin.pl and change <var $masked_ip>
to <var $ip>
to have it show the real IPs instead of the masked ones.
i've found a bug in kareha... if i set CAPPED_TRIPS and rebuild caches, all posts on the board disappear from index.html and the thread views, but are still in the files in res/. if i comment out the line for CAPPED_TRIPS, the posts reappear when i rebuild caches.
What did you set it to?
use constant CAPPED_TRIPS => ('!hoTarufiRE!!yUegcdbn'=>'<span title="admin">!hoTarufiRE</span>');
That's very weird... I can't think of any way that could happen in the first place. I'm even using CAPPED_TRIPS right now on this board and it works fine.
Is there a function yet that limits the number of times you can post / start threads in a given time?
That can be controlled to some extent with the ancient RENZOKU options that were inherited from Futaba. For Kareha, no such options exist.
Maybe there should be. Just to be able to prevent people from scriptspamming.
Also: Is it possible to define a keyword that one could use as name or link and that would sage a thread but reveal the ID code (for boards that have it usually turned off or turned off when saged)?
>>140
yes, if you don't mind writing a little bit of perl.
i would do it for you, but i'm too lazy.
maybe WAHa will do it for you, but he's almost as lazy as me, so i wouldn't count on it.
http://wakaba.c3.cx/soc/kareha.pl/1100499906/q81 gives
Software error:
Undefined subroutine &main::get_reply_text called at /home/waha/public_html/soc/kareha.pl line 875.
For help, please send mail to the webmaster ([email protected]), giving this error message and the time and date of the error.
So, will Kareha maybe get its needed banning script soon maybe? Please?
Don't you think that Kareha has awfully bloated and complicated code for what it does? Come on, you can write it with maybe two hundred lines, and you don't have to include the sources of a http server... :)
The idea is very cool, but I'd be afraid to run this code on my server.
> you can write it with maybe two hundred lines,
then why don't you?
Actually, I might end up adding some banning functionality, just so I can put in traps to automatically ban spammers. But we'll see.
And >>145, are you sure you know "what it does"?
I think >>145 is looking for something more like http://www.graffitiwall.net/
>>146
I'm going to ;)
Got something like >>149 so far...
>>147
You know, including the sources of perl libraries you use just to make some changes in them... Copy-paste programming...
I know, I know, it's Perl, it must be ugly ;)
>>148
I thought so at the beginning, but the more I read the sources the less sure I am ;)
>>149
Much simplier, indeed, but lacks some of the less-frequently used functionalities of this board :).
Sorry for the harsh words, but I really think it could benefit greatly from some code cleanup.
> You know, including the sources of perl libraries you use just to make some changes in them...
Pretty much the only external library that is included is MIME::Base64. This is because it's not in all default installs, and most people can't install external libraries. A lot of other code is written from scratch, but duplicates functionality that exist in third-party modules, but since lots of people can't install those, I can't use them if I want people to be able to use the script.
>>151
If you want to be free of dependencies, why don't you make it into an operating system?
I always hate programs that require root access to install. It's a huge damper on popularity.
Ever written any software for public consumption, >>152? --;
To give a straigh answer to a rhethorical question: Because if people can't install modules because they're on a shared host, they can't install a new operating system either.
I'm not avoiding dependencies for the sake of it, I'm doing what is needed in order that the largest number of people be able to use the software.
Well, besides switching to PHP. There are limits.
I don't think using PHP would gain you much. Very few hosts that offer PHP don't offer the other two P's.
The main thing it would gain is that idiots who limit Perl to running in /cgi-bin/ usually don't apply the same restriction to PHP (making the restriction pretty useless in the first place, needless to say).
What's wrong with putting all the scripts in cgi-bin/ and your custom perl modules in some directory in your home?
It just works, unless you try to use some scripts with hardcoded paths in them.
It's not rocket science.
Most Perl modules use compiled code. Even for those modules that are pure Perl, most people don't know how to do this anyway. It is more work when installing, and people are more likely to not bother.
As it is now, you upload a handful of files, chmod, and it works pretty much just like that. The fact that your program will be more popular the less trouble it makes for your users shouldn't be this difficult to grasp.
You mean there are hosts that have all those fancy image processing libraries you use, but lack base64 modules? Come on...
Ban-script.
>>160
Wakaba can work without any of those libraries. It's not a good idea, but it's possible.
> As it is now, you upload a handful of files, chmod, and it works pretty much just like that.
I think it's quite telling that there are many people who have difficulty doing only this. If anything, the installation should be made significantly more easy.
So if they have problems with editing config.pl and using chmod, does anyone think they'll be able to do it if they need to install additional perl modules too?
The point is to have a running board. Making users jump hoops isn't.
I see, so ugly code and sloppy programming is for dummies...
Sounds fair. Sorry for my bitching, didn't think about the "marketing" part of programming.
Forsaking code reuse through external dependencies might not appeal to your sense of aesthetics, but I will take offense at "ugly" or "sloppy". If you want to make claims like that, you'd better come up with a better reason than not using external dependencies.
Well, wakaba (at least) could be cleaner. It's a prettier than the alternatives, but it has certainly grown a few hairs over time.
Yet I think worrying about this is silly. There's one main developer. This individual has a limited amount of time. What would be a better idea in spending it: refactoring code that isn't broken, or fixing code that is? What about adding requested features?
From a user's point of view, the former gives no return. Remember, successful software is "good enough". The perfectionists never go anywhere (except in circles), while the imperfect software is actually being useful to the market.
This is reality.
Well, right, for Wakaba, what I'd really like to do is cut certain parts up in modules, but there are only so many hours in the day. The moderation interface in particular could really use some sort of plugin system, so one could implement various kinds of other moderation options and features.
Anyone feel like doing that, go ahead.
>>166
Sorry, didn't mean to offend you, just got a little carried away.
I'll just shut up and go now.
Btw. Somehow didn't say it before, but it's really the best kind of "forum" I ever tried, and the idea that the code doesn't look as beautiful as it could comes from the assumption that it's really top quality.
It happens to the best of us. Donmai, donmai.
My host has Perl v5.6.1 and I'm having trouble installing kareha 3.0.9. I followed the instructions in the documentation but I get a software error when try to run kareha.pl
It said
Invalid [] range "}-\x" before HERE mark in regex m/([\x{100}-\x << HERE {ffff}])/
Compilation failed in require at templates.pl line 3.
BEGIN failed--compilation aborted at templates.pl line 3.
Compilation failed in require at /kunden/homepages/5/d92823313/htdocs/bbs2/kareha.pl line 14.
BEGIN failed--compilation aborted at /kunden/homepages/5/d92823313/htdocs/bbs2/kareha.pl line 14.
I also tried to install an earlier version (2.0.4) in another directory and that works just fine. Anyone know how to get 3.0.9 to work correctly? Any help would be greatly appreciated.
Oh, I seem to have accidentially gotten a 5.8-only feature in there without any checking for earlier versions. I'm pretty sure that line is not important, so you can just open up wakautils.pl
, find the line, and comment it out. I'll have to fix that.
Bug: You can make empty posts by selecting HTML formatting and typing a post that consists only of an HTML tag that isn't allowed. Apparently the tag gets removed, thus leaving the post empty but bypassing the empty post check. For instance, entering just <!-- hello -->
will make an empty post, if you select HTML formatting.
I'd hardly call that a bug. There are any number of ways of making empty posts, with any formatting mode. It's hardly a problem. The check is only there to catch you if you click Reply by mistake.
>>174
What other possible ways are there to make an empty post without formatting?
__
**
There are a whole bunch of unicode characters that are completely invisible.
is this a bug?
http:javascript:alert(document.cookie)
> The requested URL /sup/javascript:alert(document.cookie was not found on this server.
It might work in IE (if you fixed the missing end parenthesis), but properly filtering out all the idiotic ways that IE will go out of its way to execute Javascript is pretty hard.
i was just reading >>157 and i thought of something... if you use a host that restricts perl to /cgi-bin/, can you just make a php script that just does passthru("./kareha.pl")
?
also, maybe you could implement this?
http://beta.4-ch.net/dis/kareha.pl/1130990333/
Links made with html formatting don't have rel=nofollow added. You might want to fix that before spammers start using it.
Yes, I know, I've fixed that already but I haven't had the time to put together a full release with the rest of the needed fixes.
>>182 in those setups, php is usually also restricted and it cannot run external programs. Usually -- YMMV.
The auto linker seems to not work right with urls that have a ) in them.
Example: http://en.wikipedia.org/wiki/Aspect_(linguistics)
So you have to use http://en.wikipedia.org/wiki/Aspect_(linguistics%29 or HTML formatting to link them properly.
That's a feature, because if it wasn't for Wikipedia, nobody would ever end a link with a ), but lots of people would say something (and include an URL: http://wakaba.c3.cx).
It would be a hack but you could include it in the link if the url is from wikipedia and it has a ( in it that is unmatched.
>>186 Likely not worth the work - click the link and add your own ) at the end, ya pansy!
A better solution would be to include the ) if there's a matching ( in the URL, but I'm really not sure I feel like writing that regexp. It's pretty horrendous already.
If somebody writes it for me, I'll put it in, though.
#https?://[^\s]+(?<!\([^\s]+)\)# doesn't match if there is a ( in the url
#https?://[^\s]+(?<=\([^\s]+)\)# does match if there is a ( in the url
#https?://[^\s]+\([^\s\)]+\)# if you don't want to be fancy about it, matches any url with a ( in it and a ) at the end
When are you ever going to have more than one set of parens in a url? I figured never so i didn't bother thinking about it.
So for the whole thing you end up with something like
#(https?://[^\s](?(?<=//[^s]\()[^\s]|[^\s\)])#<a href='\1' rel='nofollow'>#
Er, the last one should be
#(https?://[^\s]+(?(?<=//[^s]+\()[^\s]*?|[^\s\)]*?))#<a href='\1' rel='nofollow'>#
.. fucking wakabamark
There's a lot more to that regexp currently than what yours does, though. There are a number of of characters that are ignored at the end, for instance.
Currently it is:
($protocol_re:[^\s<>"]*?)((?:\s|<|>|"|\.|\)|\]|!|\?|,|,|")*(?:[\s<>"]|$))
...except that one of the commas is a numerical entity, which can not be posted. Sigh.
One is & # 44 ; Why didn't you do (?:[\s<>".)!?,\]]|"|& #44;)
It is kind of amazing how much I screwed up the ones last night, never drink and regexp =(... varible length lookbehind is perl6 even. I'll try to rewrite it with lookahead and factor in all of the current crap if this hangover doesn't kill me.
i wrote a recursive regexp that behaves exactly like the existing one in wakabamark (i think) except for including balanced parentheses. of course it's perl 5.8+ only, but since i have the regex in a slightly more readable form it might be a better place to start for doing the 'one or no pairs of parentheses' regex.
Suggestion: How about making a JavaScript box pop up when you ban someone in the Wakaba Management Panel, prompting to enter a comment, so that one doesn't have to copypaste the IP address into the ban Ban page every time?
Not a bad idea, probably.
I found a scrap of spare time, and started to work on putting together a Kareha 3.1.0 version with the bug fixes that have been piling up. So far I've done this:
I'm still looking into:
What did I forget? Also, got any brilliant ideas for anti-spam measures? I'm thinking mostly heuristics to run on the post text, but I'll consider other tricks too.
>Also, got any brilliant ideas for anti-spam measures?
I've been considering it. As stated it'd be too ugly, but adding an input field with style="display:none" should do the trick.
Bug: IMAGE_REPLIES_PER_THREAD counts the image in the first post.
Also, could you fix the "omitted posts/images" line in mode_image for when there's only a single post/image omitted?
Will this update include changes to mode_image's template? I have a highly customized version of the file, so a diff between 3.0.9 and 3.1.0 would be much appreciated.
P.S. What's the argument for implementing a ban system when you can configure it through the web server?
> Bug: IMAGE_REPLIES_PER_THREAD counts the image in the first post.
Hmm. I suppose that's a bug of config option naming at the very least. I'll try to get that fixed.
> Also, could you fix the "omitted posts/images" line in mode_image for when there's only a single post/image omitted?
Not easily, if I want to retain support for multiple languages.
> Will this update include changes to mode_image's template?
Probably not. The old version will be kept in the releases/old
subdirectory though, so you can run your own diff on it in case I end up making any changes, though.
>Hmm. I suppose that's a bug of config option naming at the very least. I'll try to get that fixed.
It doesn't make sense to omit any content in the first post. Maybe you could distinguish between first-post images and reply images just as you do with text.
>Not easily, if I want to retain support for multiple languages.
If need be, the board owner can modify the string text by hand.
That makes no sense.
All right, I've installed an almost-complete v3.1.0 here and on /soc/, as a test. It has the empty-field spam trap, so I've disabled captchas to see if it helps any.
Post previewing should also work now.
Feel free to do some testing and report problems! You may need to shift-reload the page to get the new CSS and JS files for everything to work right.
This may be asking too much, but I'd like to see mode_message's deletion functionality match mode_image's more closely -- that is, the post/reply boxes include a field for deletion passwords, a checkbox appears to the left of each post header, and there's a confirmation area at the bottom of each page for re-inputting the password -- granted that user deletion is enabled in the first place, of course.
Not going to happen, as it changes the 0ch page layout too much. You can make it for yourself by editing the templates, though (although you might run into trouble with nested forms).
Is there some reason the text "Lorem ipsum dolor" has to be there (I don't have CSS support)? It's kind of annoying. How about a if you need some text there for some reason.
Oh, oops, that's a leftover from development. I'll remove it in the next version.
For some reason it says "Thumbnail displayed, click image for full size." even though it isn't supposed to be thumbnailed. I set max widthxheight to 700x500 and posted a 640x480 picture. kareha thumbnailed it to same size, only difference being the thumbnailed picture got shittier in quality.
So I just turned on stupid thumbnailing for now. Is this a bug?
No, it's just not designed to be used for full-size images. It will always say "Thumbnail displayed", for instance. If you don't want it, you have to edit the template to remove it. If you always want full-size images, turn on STUPID_THUMBNAILING, and set the sizes to huge. If you want to display images, except if they are REALLY big, you can set THUMBNAIL_SMALL to 0 instead, which should make it stop recompressing images that are smaller than the thumbnail size.
I just upgraded my Kareha version, and now I need to delete some spam posts, but when I click on the "del" link beside the posts, it says the Admin password is incorrect. Where am I supposed to enter this password? In the documentation, it says to click on the "manage" link, but I don't see any such link!
Also, is it possible to completely remove a post, instead of having to see the "this post was deleted by a moderator" message? My board has been hit really hard by spam, and now its completely covered in these messages.
The Manage link is for Wakaba only. For Kareha, go to admin.pl
in your board directory manually to get to the admin interface. And no, there's no way to completely remove a post as it stands now.
http://wakaba.c3.cx/release/wakaba_3.0.5.zip
I finally got off my ass and fixed some outstanding bugs, and also put in the spam trap code from Kareha. This is a recommended upgrade for anyone who has problems with spam bots!
NOTE: You must rebuild caches after this upgrade, or the spam filter will stop all posting!
Fixes:
oekaki_style.pl
(hopefully).Changes to lots of files, wakaba.pl, wakaba.js, wakautils.pl, futaba_style.pl, oekaki_style.pl, strings_*.pl
and config_defaults.pl
. Note for people with custom templates: You will have to rename the fields name
,email
,subject
and comment
to field1
,field2
,field3
and field4
!
>You will have to rename the fields name,email,subject and comment to field1,field2,field3 and field4!
Wait, so you went from descriptive variables that are useful to generic, non-descriptive variables? Why?
Are you trying to make Wakaba unmaintainable or something?
Thank the spam bots. I am trying to confuse them. There are fake hidden fields with descriptive names that will cause the post to be discarded if they are filled in.
I don't know if this could be some unrelated problem of mine (I don't see how, since this is a fresh install using standard stuff), but I'm getting a very weird error with this new version that I'm not seeing on older installs.
Specifically, it's thumb nailing images with the dimensions reversed.
For example, a 1280x853 image (wide) is getting thumbnailed to a 133x200 image (tall). It's not instantly obvious because the img tag has width="200" height="133", so it's "correcting" the mistake. (Using quotes cause it doesn't really correct it, it still looks like shit)
Anyone else seeing this problem with 3.0.5 or do I need to pull apart my perl/imagemagick (Does wakaba even use imagemagick? I can't remember) install and look for brokenness?
Did some more testing, and it's not an imagemagick problem (Or it is, in a roundabout way)
convert wasn't in the path of the webserver, so putting a full path for CONVERT_COMMAND fixed it.
Aha. sips is the problem. According to sips --help:
-z, --resampleHeightWidth pixelsH pixelsW
Height, then width. No, I don't know why either.
But just switching the order makes it work fine:sips -z $height $width -s formatOptions $quality -s format jpeg $filename --out $thumbnail >/dev/null
; # quality setting doesn't seem to work
Also, even when it's working it gives this error in the logs:
Warning: File format jpeg does not support option 70
It looks like the way to do quality is either "formatOptions" or "quality", but neither of them supports integer settings, only low/normal/high (ewww)
I found this from doing "sips --helpProperties" (which is bloody hard to find out about)
Man, that's fucked up. Especially since the test board run on sips and I never even noticed. Well, I did notice the problem with the quality, but got so tired of it I never fixed it.
Oh, and also: A general request to board admins:
If you edit your own style based on futaba.css, please give it a new name. "Futaba" actually means something here, and many people also want to keep using that style. Give your style a new name, and keep the old futaba.css in place. There is an option to select the default style for a board, you don't need to rename it to "Futaba" just for that.
Thank you.
where would i find a list of usercodes to modifiy text within their posts?.. like bold, colors, strikeout and so on?.. wakabamarkup only explains so much.
After some testing, it appears there were a few bug left in 3.0.5, so here's a somewhat fixed version:
http://wakaba.c3.cx/releases/wakaba_3.0.6.zip
Bugfixes:
wakaba.js
has been renamed to wakaba3.js
, because the old version would fill in the name field, which triggered the anti-spam filter, and people's browsers kept the old version in cache. Renaming forces them to reload the new file./\x{202e}/
).(There were also some further fixes of the handling of numerical entities and charset internally, which may have broken something else. I hope it didn't, but report any problems. SQL dumps were also tweaked again and should work better now.)
Minor problems with 3.0.6:
Typos in the "YOU FUCK SPAMMER" error:
"[...] you are probably accidentiallytrying to use an URL that is listed in the spam file. Tryediting your post to remove it. [...]"
Also, the example.htaccess file uses "line-end comments", which apache (at least 1.3.x) doesn't support, and it will tell you this during every single access of your imageboard.
Just move the comment on "AddCharset utf-8 html" to the line above it, and it'll stop yelling on every access.
Would there be any way to get an sql dump that is not made for SQLite? I have already setup a wakaba imageboard and have been able to get it to connect and communicate just fine with a PostgreSQL server, and would like to be able to enter the initial data into there.
It might not work on PostgreSQL, even though it will talk to it. The syntax for making an autoincrementing column in the database seems to be different on all databases, and there's no code for doing it on PostegreSQL, so post numbers might not work right.
That said, what is the problem with the current SQL dump and Postegres? It should be simple enough to work with any SQL database, unless there is some lingering bug (there have been a number of them, so use the newest Wakaba to generate it).
>>237
Well I am using the DBI postgres driver so that should handle talking to the server no matter what the call correct? But the problem is importing the dump to the database, I can't seem to get it to work, so if someone had a different type of dump (plain diagram even, for me to input by hand) then I could make my own database for it.
That would be true is SQL was actually a standard that people follow, but it's not. There are subtle differences between pretty much every database out there. Wakaba is not built to support Postgres, and is pretty much guaranteed to not work right.
What version are you creating the dump with, by the way?
>>239
I have not created the dump, I was using the .sql dump provided in the zip of wakaba. It's an SQLite dump and I need either a postgresql dump or a more human readable dump if possible, so that I may input it by hand.
>>240
Look at the init_database, init_admin_database, and init_proxy_database functions in wakaba.pl. They do the database creation, and they're quite well commented.
If that's included, it's by mistake. It's not meant to be used for anything, it's just my test database. Wakaba creates its tables itself. However, even if you try to do it by hand, I doubt it will work with Postgres. Last I looked, the way to make an autoincrementing column in Postgres was completely different from other databases and would not work with the current code.
Hmmm, okay, then how do I get it to use the init_ functions, because at first when I made the db and started the board it said "SQL Connection Error." Then when I made all of the tables it said "SQL Fatal Error." And after reviewing the code they should be the first things executed if database pieces are missing, but they don't seem to be doing so.
Well, if you get an SQL connection error, then you're not even connecting to the database.
The thing is, I got that and then the only thing I changed was adding the "admin", "comments", "proxy", and (can't remember right now but there was another) tables to the database and that changed it from "SQL Connection Error" to "SQL Fatal Error."
I found a pretty annoying bug that I needed to fix, so I finally sat down and fixed a couple of old ones too.
http://wakaba.c3.cx/releases/wakaba_3.0.7.zip
http://wakaba.c3.cx/releases/kareha_3.1.2.zip
Changes only in wakautils.pl
, wakaba.pl
, kareha.pl
, spam.txt
and the config_default.pl
files (just bumped the version number in those).
Hopefully I didn't fuck up anything too badly packaging this, it's been a while.
:( did you put any comments in the files where you edited them?
>>252
there will be many differences between the two :(
Diff against a plain wakaba 3.0.6, it's in the old/ directory.
also, the more robust entity parser fixes a more serious bug that can let people put in their posts... this is really bad because then people can inject javascript, like the bee flying around this page...
p.s. hey WAHa you need to update this board.
Indeed I do. There, should be fixed now.
Also, that only works in Kareha, so Wakaba boards need not worry. Although it's still a good idea to upgrade to fix the spam filter.
gawd, that bee's annoying. I'm so glad this board's been updated xD
thanks for the update! Bees!
A little something that might be of interest to those running Wakaba boards with the captcha enabled: http://dmpk2k.wakachan.org/captcha.txt
It's a replacement for the stock captcha.pl, and reduces the load per board between 85-95% if you have FastCGI installed. It should work whether you have FastCGI or not, but you won't see the reduced load without FastCGI. Some of the letter strokes have had a little bit of tweaking as well.
It was tested on all the wakachan.org boards for several months, so I'm fairly confident it'll behave.
i have a user that is recieving the spammer msg whenever he tries posting. there is no text in his post and the msg it shows when he attempts posting is as follows:
Anti-spam filters triggered.
If you are not a spammer, you are probably accidentially trying to use an URL that is listed in the spam file. Try editing your post to remove it. Sorry for any inconvenience.
post
Joe#tripcode
0k1je6gP
1162910789576.jpg
anddddddddddd now i can't make any post that has an image attached to it.
.......it decided to work for a few minutes and now it's doing the same thing again.
[Sun Jan 21 21:00:35 2007] [error] [client 68.148.7.216] [Sun Jan 21 21:00:35 2007] wakaba.pl: Malformed UTF-8 character (UTF-16 surrogate 0xdc80) in substitution iterator at wakautils.pl line 391., referer: http://wtfux.org/temp/res/501.html
hmmmm
line 391 of wakautils.pl:
$str=~s{(&#([0-9]*)([;&])|&#([x&])([0-9a-f]*)([;&]))}{
no one has any ideas? this is causing a lot of problems :( the only 2 files that i edited are futaba_style.pl and wakaba.pl. i have placed the right changes from 3.0.6 to 3.0.7 into my wakaba.pl. When used on my friends hosting the wakaba.pl works fine. I have seen no changes in the futaba_style.pl on the switch to 3.0.7 so that cannot be the problem. The error i am getting, as seen above, is going on in wakautils.pl. I have no idea what the error means or how to go about debugging it.
What all do I have to upload to upgrade from 3.0.6 to 3.0.7? I'm lazy~
>>269
wakautils.pl, wakaba.pl, spam.txt, and the config_default.pl
Under what exact circumstance does this happen, or not happen?
>>271
replying to a thread with an image. and also sometimes when creating a thread. it does not happen to everyone and the people it happens to are not experiencing it 24/7.
I can't reproduce it. Can you determine if it happens to specific images or not?
>>273
images with less than 8 letters and numbers in it's filename (extension not included) post fine. more than that and i recieve the spam message.
As a side effect of the spam engine, it may be that the filename is checked against the spam filters... Do you have something unusual in spam.txt?
>>275
it is the same copy that you have hosted. i will replace it again to see if that helps.
Well, I can't reproduce it locally. What happens if you edit wakaba.pl and change
spam_engine(
query=>$query,
trap_fields=>SPAM_TRAP?["name","link"]:[],
spam_files=>[SPAM_FILES],
charset=>CHARSET,
) unless $whitelisted;
to
spam_engine(
query=>$query,
trap_fields=>SPAM_TRAP?["name","link"]:[],
spam_files=>[SPAM_FILES],
charset=>CHARSET,
excluded_files=>["file"],
) unless $whitelisted;
Anti-spam filters triggered.
If you are not a spammer, you are probably accidentially trying to use an URL that is listed in the spam file. Try editing your post to remove it. Sorry for any inconvenience.
post
cho0b
uWZbOD0k
OKAY KIDS DOES THIS WORK?
1142201616186.jpg
sadly that does not work waha. I am going to setup a wakaba board on my server that has none of my edits in it (again) to see if it works.
what does this error mean (in dumb people terms):
wakaba.pl: Malformed UTF-8 character (UTF-16 surrogate 0xdc80) in substitution iterator at wakautils.pl line 391
Maybe somebody tried to post a UTF-16 surrogate character? I don't know, what caused it?
okay, even without my edited version of the files (ie stock wakaba) I am getting the error. something strange is going on.
i am with dreamhost atm..... ahhhh
>>281
that error shows up in my error.log whenever anyone tries to post an image and gets the spam message.
also, another problem I have been having lately (of much smaller importance) why can't I put adbrite ads into my board? if i put the ad code into the post form i get xml not well formed errors :(
...what the hell haha. i replaced spam_engine with this code and at first it didn't fix it... but i removed the spam_engine portion and replaced it AGAIN and now it seems to be working... weiiiird. we shall see if it continues to work. :D
it seems i still can't post to certain threads with an image that has more than seven characters in it's filename (excluding the extension etc etc etc etc) Yes, I did rebuild caches. Also, whWREHSFDHBASFDGS GET THE FUCK OUT OF MY COMPUTER YOU FUCKING BEE AFGWERGAD
This really is weird. And I still can't reproduce it at all.
In the worst case, you can try disabling the spam.txt checker by commenting out the lines starting from:
my $spam_checker=compile_spam_checker(@spam_files);
in wakautils.pl
until the end of the function.
I'll try to take a wild guess at what might be the problem and try to work around that a bit later, and give you some code to try instead, if you want.
>>287
It seems to be only happening in certain (older) threads, now. And not often at all. Most users are saying that it is working fine now. Although, I don't understand why it would still happen sometimes with older threads.
Do not lose sleep over it, but if you can think of anything to try I would appreciate it very much.
Anti-spam filters triggered.
If you are not a spammer, you are probably accidentially trying to use an URL that is listed in the spam file. Try editing your post to remove it. Sorry for any inconvenience.
post
642
anonymous
lgsexiuS
HELLO BEN HOW ARE YOU
1142072561943.jpg
Delete password. It just dumps all the fields from the form onto that page in order to confuse spam bots into thinking they succeeded in posting.
ah i see i see.
p.s. still getting the error every now and again. :( still hates lengthy filenames for some reason.
http://wakaba.c3.cx/releases/kareha_3.1.3.zip
A bugfix for a very annoying bug that can cause multiplying mojibake in threads. This was a pretty subtle bug related to Perl's unicode handling, but it's hopefully fixed now.
I hope this fixes 4-ch.
Yeah, that was pretty much the point.
why are there a bee on this page
Somebody must've left the window open.
will pay user 10 dollars via paypal to insert 3 google ads on my wakaba form. please leave you email or aim address if you are interested.
will pay user 10 dollars via paypal to insert 3 google ads on my wakaba form. please leave you email or aim address if you are interested.
>>299
[email protected] send me an email
Alrighty, we have added the option to choose whether you will be returned to the main thread list or taken back to the thread you were posting in to wakaba. also, we added a "bump thread" button to clear up any confusion about saging. the bump checkbox is auto checked and the user must uncheck to not bump (sage) the thread.
>>278
I believe that should be "excluded_fields=>["file"]," not excluded_files=>["file"],
Didn't help on my installation. You can select no file and only enter "a" and it'll trigger the spam filter :(
>>302
Javascript!
Using 3.0.4 javascript with a 3.0.7 install will not work at all.
Minor bug I thought I'd report:
If I set: USE_SECURE_ADMIN => 1;
and click 'Manage', Firefox displays an error:
(my site) has sent an incorrect or unexpected message. Error code: -12263
The perl test script floating around this board works fine for me, and so does my imageboard when that option is not enabled, so it should be a genuine bug.
Running Firefox 2.0.0.3, Perl 5.8.7
No, that probably just means you have not set up your webserver to handle https.
I believe this line (1048) in wakautils.pl contains a bug:
my %excluded_fields=map ($_=>1),@{$args{excluded_fields}||[]};
It should be
my %excluded_fields=map +($_=>1),@{$args{excluded_fields}||[]};
Otherwise adding fields to the spam_engine call in wakaba.pl will do all of nothing. since file and password really really need to be on there if you intend to post to your board, this is a bit of a problem.
>>308
correction, adding entries to excluded_fields in spam_engine.
Is it possible to read Kareha boards with 2ch viewers now?
There was some trouble with that earlier, and that is probably the reason. I'll look into it when I get back home. Thanks!
Why does wakaba have a big <style type="text/css"> block in addition to the CSS?
Why aren't those styles just stuck in the CSS files (where they'd be cached)
Compatibility with old Futallaby CSS files.
>>314
That the same reason you haven't fixed "inert" after all this time?
Why are you maintaining compatibility with futallaby CSS files? I don't see the benefit.
Fixed what now? If there is a problem, somebody would have to report it before I could fix it.
I'm maintaining compatibility because I did it once, and it required no work after that. It would require work to break compatibility, and there would be no real benefit. Saving a couple hundred bytes per HTML page on an image board means pretty much nothing at all compared to the rest of the bandwidth usage.
>>317
There's a typo in one of the CSS rules:
.unkfunc {
background:inert;
It's "inherit" , not inert. Loading a wakababoard on firefox spams 2 lines of "Warning: Expected color but found 'inert'. Error in parsing value for property 'background'. Declaration dropped."
(Two because the typo is in both futaba.css and gurochan.css)
It's annoying when you're trying to debug javascript errors on wakaba, as every page gives those two errors.
Just deleting that line will have no effect on the rendering of the page, since all browsers are just ignoring it.
(I finally managed to get 4chan to fix this same CSS error.)
Huh, that's a new warning, because I never saw it back when I was doing actual development on that stuff. Also, I think that typo is inherited from Futallaby. That's my excuse, anyway, and also explains why 4chan would have it too.
Thanks to http://wakaba.c3.cx/sup/kareha.pl/1256252904/88, here is a security update for Wakaba:
http://wakaba.c3.cx/releases/wakaba_3.0.9.zip
I also disabled XHTML. Times sure do change, huh.
Hopefully I didn't mess anything up, I don't really have a good test setup at the moment. Report bugs and problems!
>>320
You left out an <html>
tag in the templates. Other than that, it looks fine.
Speaking of changing times, have you considered implementing IPv6 support? It's tricky, but ISPs like Comcast have started rolling out IPv6 to residential customers, and lots of webhosts are beginning to support it.
Also, you might want to consider removing the XHTML options entirely — browsers aren't going to render the page correctly if the correct DOCTYPE isn't there.
Its amazing how long it took for someone to find a vulnerability in Wakaba. Was it really that secure?
>>323
Writing secure software in Perl is quite easy, actually. Unlike PHP, there aren't billions of pitfalls which can screw you over (such as using include()
to grab HTML pages, a common beginner mistake), and the DBI module makes it easy to use parameterised statements, which practically makes successful SQL injection nearly impossible.
The attitude of the developer also means a lot; compare Waha's response to bugs and vulnerabilities with the Kusaba X developers':
<Taclink> RewriteCond %{REMOTE_ADDR} (77\.247\.181\.163|124\.186\.170\.134|76\.200\.120\.201|173\.254\.192\.38|184\.56\.238\.123|69\.47\.119\.236)$
<Taclink> is the current one
<savetheinternet> shouldn't there be a ^ at the start of that RewriteCond? otherwise, banning 10.0.0.0 would also ban 110.0.0.0 etc
<Sazpaimon> savetheinternet, that's such a small edge case it isnt even worth it
Ok, added <html> back, and removed USE_XHTML. I'm too lazy to bump the version again for that though so it's still 3.0.9. It doesn't really matter much with HTML5, anyway.
I never really understood the point of xhtml. Was it useful at some point? All it seemed to do was cause pages to render incorrectly because they didn't like the way a certain tag looked if there was too much white space between two tags.
It is a lot more consistent and easier to write a parser for. The parsing rules are simple and you know you'll get the same result in every parser.
HTML5 instead standardized all the weird behaviors of the old regular HTML parsers, which means parsing is still complicated but at least you can know how to do it, and the result is consistent.
>>327
Interesting. Well in any case, I'm happier this way. It makes modifying Wakaba SO much easier. I mean, I already got rid of XHTML myself a while back, but changing things to your liking really is a lot easier without it.
>such as using include() to grab HTML pages, a common beginner mistake
What the proper way to do something like this? All I've managed to do was make a whitelist of pages that can be included.
>>329echo file_get_contents($filename);
But this is really off-topic and you're better off seeking PHP help elsewhere.
Okay, so, what the fuck is going on here? My wakaba.pl is highly modified. What was actually changed? Is the patch in the other thread the only changed lines?
It's only that, and a few changes to disable XHTML which probably doesn't interest you if you've modified stuff a lot anyway.
After looking over the files, I saw that the changes were very minimal. I already made Wakaba XHTML compliant 5 or so years ago.
http://wakabatest.heliohost.org/wakaba.pl
Bad name after comments' at config_defaults.pl line 15.
Compilation failed in require at wakaba.pl line 17.
BEGIN failed--compilation aborted at wakaba.pl line 17.
how i can fix it?
the "place" is just for test wakaba
Don't edit config_defaults.pl.
Most likely either something broke the file, or your perl is broken.
>>337
was an error on the config_defaults.pl
but i have another error
No ADMIN_PASS or NUKE_PASS defined in the configuration at config_defaults.pl line 8.
BEGIN failed--compilation aborted at config_defaults.pl line 125.
Compilation failed in require at wakaba.pl line 17.
BEGIN failed--compilation aborted at wakaba.pl line 17.
i have the config_defaults.pl without any edit
>>338
Edit config.pl
. It says "config_defaults.pl" there, because that's where the script craps out and dies.
>>339
how i can fix it, erase the "config_defaults.pl"?
>>340 Delete the entire directory with the files. Delete your hosting account. Go away.
Fixed!
>>341
This. If you can't follow simple instructions, you shouldn't be running a website.
Upped a fresh Wakaba install and managed to make it run. However, visiting it in Firefox generates the error "This XML file does not appear to have any style information associated with it. The document tree is shown below."
Using wakaba 3.0.9
Don't set the web server to set the Content-Type to application/xhtml+xml.
>>344
What is the proper Content-Type for it then? text/html?
Yes. HTML5 is back to that one.
>>345
Ok fixed it. I was using the example.htaccess file as .htaccess and comment out the rewrite rule.
I thought I removed that from the example.htaccess but maybe I forgot.
Unarchiver no longer opens the folder after extracting it. Why?