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.
>>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 itOk, 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?