Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
Glad to be of help! I don't really ask for donations, but I'd certainly appreciate anything offered. My PayPal is the same as my regular e-mail address.
I got it integrated and running. You can see it live at http://www.furcartzone.com.
Thank you for your help. Do you have a paypal I can send a donation to?
Appears to be working fine now. Thanks for your help! I can't wait to put this live on my art website.
Well, ChibiPaint works just fine for me. It's hard to tell what the exact server response is, because Java gets it, and the web browser does not. So, you can't use a tool like Live HTTP Headers to find out what the server is saying.
The basic procedure is this:
- The server gets the picture data, parses it, and saves it as a WIP.
- The server sends a plain text message to the applet with the function "print_ok()". This tells the applet that the picture was received properly.
- The applet forwards the web browser to the comment page, so the artist can leave a comment, set a password, etc.
- Once a main comment is assigned to the picture, it is changed from a WIP to a regular post.
So, if the web browser does not forward to the comment page, and no comment is left, then the picture will remain a WIP. We need to find out why the server is either sending a garbled response, or why the applet is misinterpreting it.
My guess is this: PHP might be printing something before the "print_ok()" function is called and the HTTP header is set to text/plain. PHP error messages can do this. The applet will not print the exact output from the server, so PHP errors won't show up. Your server has an "error_log" file in the oekaki folder, which means PHP is set up to dump errors into this file. Take a look at it. You will have to download it to your computer via FTP to read it, as by default, it is not a public file (I can tell it's there, but I can't view the contents).
It's also possible that the problem is with your own computer. Checking for an update to Java can help, or try temporarily disabling any non-Microsoft firewall software you're using.
I hope this helps!
Okay! I'm excited I've got almost all of the problems resolved. Hopefully you can help me solve my final problem.
Shi-Painter and PaintBBS submit images without a problem.
The only problem I have is with Chibi Paint. Whenever I go to submit a drawing I get the same type of error I was getting above, but if you go back out to the main index you can find it showing up as a WIP.
So I hope you can help me solve this! Thanks!
I was using SMF's $context['is']['logged'] to check and see if a user was logged into SMF. (If they aren't they can't even get to the Oekaki Board.) Then I was passing $context['user']['name'] to $OekakiU. This may of course be where my problem is because I didn't pass anything through for $OekakiPass and essentially stripped password functions out of a lot of files since the sessions were being handled by SMF.
I'll have to go back and play with it some more now that I know better where this is falling through.
O.K., what exactly did you do to the $OekakiU and $OekakiPass variables? How does the oekaki know what the username is? The problem is that no password is being encoded and set to the applet at all, and we have to figure out how "boot.php" is dealing with that.
The code that handles uploads is limited to only two files:
- "paintsave.php", which handles thumbnails and the actual saving of the image data.
- "shiget.php", or the respective collection code for each applet your board supports. This collects the raw data over HTTP and parses it into the picture and header information.
My guess is that "shiget.php", "chibipaintget.php", or "paintbbsget.php" is the problem, and is probably related to authorization. Forums generally use a different and stronger password encryption system than Wacintaki, and there might be character conflicts, truncation, or HTML encoding issues.
This can be very complicated to diagnose, so it'd be easier if I registered and took a look at what is being put into the applet headers. If something isn't being encoded properly, that can be detected right away.
On my modified copy of Wacintaki 1.4.2 I am able to use the upload feature to submit an image from my computer but I am not able to save a drawing.
However, if I use an unmodified version of Wacintaki 1.4.2 I can upload and save drawings without a problem. Any leads on where I should look to fix this?
I've currently got the forum at wwwmatthirschfelt.com/test/
You'll have to register on the SMF forums to get to the Oekaki board.
I appreciate any help you can provide me.
Edit: FYI, nothing is posting to my error log either when attempting to save drawings.
Do you know if file uploads work, using the "Upload" option instead of "Draw"?
Many times this is caused by an aggressive server security policy, which causes the picture data to be simply "thrown out" without returning an error. Normally, if the oekaki can't receive or save picture data, it will return a specific error to the applet, and something will show up in the Wacintaki log file. You may want to check your server's error log to see if any security warnings are being issued. More and more servers these days, especially those running on free hosts, will reject uploaded data without returning an error (such as HTTP 403 or HTTP 500). Since ChibiPaint is returning HTTP 200, I assume the server is just rejecting uploads.
The reason for rejecting uploads is that some servers will only accept file uploads that come from common, well-know applications. Firefox, IE, Opera, and Chrome may not have a problem uploading files, but Java will. If you can upload files with a web browser, but cannot submit pictures, that may be the case, here. The only way to fix this is to ask your sysadmin for help and tell them that Java needs to be recognized as a valid client for sending chunked data over HTTP. Many web hosts do this to prevent their bandwidth from being consumed by bots or zombie PCs infected with viruses.