NineChime forum

I might have to experiment a bit, because I just found out that adding a backslash corrupts the output.  Why a backslash isn't interpreted as an escape code with the PHP tag is beyond me.  I'll probably have to change it from HEREDOC style to a regular string style.

Maybe I shouldn't be surprised.  Inline JavaScript has similar, strange behavior.

By the way, what do I have to do for making the nested responses feature to be available in Wacintaki 1.5 as an option?

I thought about this at one time, but I figured the board is meant to be more like a gallery than a social web site or a forum, so nested comments wasn't a high priority.  Now that I've been spending so much time on blogs and places like FurAffinity, I'm changing my mind.  Adding nested comments as a standard feature seems like a good idea, even if it does make the code messier than it already is.  LOL

All you really have to do is send me the files you changed, and I can hunt down the modifications.  I may need to further change them, but you'll still get credit for your contribution!

What is going into your mind right now? Are you incubating the next Wacintaki fix or feature?

Oh, I have more things in store for Wacintaki.

I was going to write a whole new board from scratch, but now I'm not too keen on the idea.  I'm not big on the "Web 2.0" style of writing software that requires AJAX and JavaScript, so most of the time when people ask for those fancy new features, I'm not too keen on actually implementing them.  If web browsers didn't choke on JavaScript, and free web hosts were more compatible with the Java applets, I'd have no trouble rewriting the board from scratch.  However, if a banner ad can cause JavaScript to crash, that essentially makes it impossible to run the oekaki unless you're on a dedicated host, and that's not realistic for most people because it's just too expensive.  The fact that the applets can cause JavaScript exceptions doesn't help.

We'll see what happens when HTML 5 becomes more popular.  Maybe by then, web browser developers will get their act together and JavaScript support won't suck so badly.

My... I have tried to install it. And as I feared, the modified heredoc, screw the installation.  I have no Idea what to do.
That php is printed as plain text instead of being executed. Back to the beginning. why I cant put a php open tag in heredoc? damn.

For years PHP syntax has been a pain.  Some things will just cause failures for no apparent reason, and different versions of PHP will have different problems.

lines 363 & 428

Oh, good!  I wasn't aware of this one.  I'm trying to fix as many "gotchas" as I can with Wacintaki 1.5.

Wacintaki 1.5 is currently being tested, and it fixes a number of these issues, including HEREDOC closures, short tags, special symbols, strict parsing, and other old things that should have been fixed a long time ago.  I've also found out that one of the coding standards used by the Drupal team is to omit the closing PHP tag (?>) from the end of documents to make sure there are no empty spaces.  I'm considering that, although omitting it sounds like that might cause a problem in the future, rather than prevent one.  With PHP, you can never be sure.

Another thing I'm fixing is the hack I used for my code editor.  Following HEREDOC lines, I use //?> to make my syntax highlighter happy.  It doesn't seem to cause a problem with PHP, but I'll be getting rid of those just to be sure.  I ran into an issue a short time ago where just using the copyright symbol in a PHP comment causes the whole script to crash.  Go figure.

/etc/php.ini

Yeah, your server is set up to use PHP as CGI (and not an Apache module), so everything will be configured in the php.ini file.  If you try to change PHP behavior in an .htaccess file, it won't work.  That's important, because on a production server, you'll most likely have to use .htaccess to modify PHP behavior.

Anyway, thanks for the feedback!

A quick search revealed that the "WSOD" (White Screen of Death) is actually quite common.  Here's a few things you can try:

1.) Remove the condition that checks for the presence of GDlib.  GDlib is an image library that allows the oekaki to generate thumbnails.  Apparently, using it if it is not installed can cause problems.  If this does fix the installer, it will be necessary to fix the control panel as well.  It's possible that your install of PHP doesn't have GDlib turned on, so we might have to take care of that.

if (!extension_loaded ('gd')) {
echo <<<EOF
                <p class="infonote">{$langop_err_nogdlib}</p>

EOF;
}

2.) Remove the condition that checks for short tag support.  If the GDlib condition can fail, this might as well.

// OP/Wax still requires short open tags.
if (function_exists ('ini_get') && ! ini_get ('short_open_tag')) {
    exit ('OP requires PHP setting "short_open_tag" to be "On".  Try copying the ".htaccess" file from the documentaion folder to the server.  If that doesn\'t work, contact your sysadmin for help.');
}

3.) Remove the trailing ?> at the end of the file.  Sometimes this will cause a problem.  I have no idea why, but it's worth a try.

4.) Do a syntax check.  In a shell prompt in the oekaki folder, type "php -l install.php".  The flag is a small L, as in "lucky".

Well, if echo() doesn't return anything, I'd say we have a big problem.  First, some questions...

- Is a bare PHP script having problems, or is this just the oekaki installer?  Sometimes a syntax error or a bad filter option can cause a completely blank page, rather than an error message.

- How did you install your development system?  Are you installing all the components separately, or are you using an all-in-one package like XAMPP?

- Is PHP running as CGI or an Apache module?  CGI is when you tell Apache to use "php.exe" using when dealing with PHP files, using the "AddType" configuration option.  A module is when you add an SO library using the "LoadModule" configuration option.

- Can you run a PHP info script?  <?php phpinfo(); ?>

- Windows, OSX, Linux?