Before installing Wacintaki, make sure your server meets the following requirements:
The following are optional:
It is recommended that you have an FTP utility to upload files to your server. It will take you much more time (and effort) to FTP the files manually from a command prompt. Free utilities offer all the basics for running Wacintaki; commercial FTP programs have features useful for maintaining entire web sites:
Note that some Mac FTP clients may only work on MacOS X. Fetch is one program that will work on older Macs, like System 7 and MacOS 8.
Like any BBS, Wacintaki will put a strain on your server's resources. The developers hold no responsibility if your site goes over its monthly disk or bandwidth usage, and you are charged zillions of dollars, rupees, pounds, etc. because of over-usage.
Since Wacintaki is very graphically intensive, make sure your server can handle:
NOTE: using the uniformity thumbnail mode can decrease bandwidth drastically.
Also keep in mind that certain BBS functions will use more resources than others, as follows:
You are considered a newbie if..
... then you need the Newbie Guide.
To update an existing OekakiPoteto or Wacintaki board, please read the readme.html file that came with your distribution.
Before updating, it is recommended that you backup all files in the resource folder. In fact, you should always have a backup of these files.
You may need to know the version number of your existing board before you can update. To get the current version of your board, view the FAQ on your board.
Also note that Wacintaki 1.1.4 now uses a “hacks.php” file in the resource folder to control cookie usage and other features that used to be at the top of the “functions.php” and “header.php” files. If you have edited those files, you will need to copy the changes into the “hacks.php” file.
Make sure you have read the requirements, and have the following information before you proceed:
If you do not know any of the following, please e-mail your web host for the information and if your web hosting plan meets the requirements to install Wacintaki.
Note that when creating a MySQL database, your server control panel may automatically add a prefix to your database name or user name. For example, if your login for the control panel is “bob”, and you typed “myoekaki” as the database name, the actual name of the database may be “bob_myoekaki”. Take this into account if you are having connection problems with your database.
Log into your site with FTP. If you're not that experienced with FTP, keep in mind that many FTP programs can use both a www and ftp address to log into a server, so “www.Server.com” and “ftp.Server.com” should both work. If you have trouble, try the ftp prefix instead of www. The “Server Port” is almost always 21. Other ports can be specified by the server, but 21 is the default for most servers and FTP programs. The FTP username and password should be obvious. :)
Many servers have a special folder in which you need to upload files. If you're used to uploading files with a web-based file manager, rather than FTP, you'll need to look for a public share folder which is usually called “public_html”, “www”, “web”, or sometimes “home”. If you do not create your oekaki folder in that special “public” folder, your files are considered to be private and will not show up on the Internet. Some servers do not have this public share folder, so if you don't see it, don't worry. UNIX / Linux servers usually have this folder, Windows servers may not.
Once you're logged in and viewing the correct upload folder, you may either upload the files directly, or create a sub-folder on your server for Wacintaki. If you create a sub-folder, it may be any name you choose, though names in all lower-case letters and with no spaces or weird characters (like apostrophes, tildes, and symbols) are recommended.
If you are uploading the files to the root folder of the server (“public_html”), you do not need to change the file permissions. If the files are in a sub-folder, it should have a CHMOD number of 755. Most servers default to 755, so you may not need to change it. To CHMOD files in most FTP programs, right-click the file and choose CHMOD or something related to changing permissions or properties. The middle digit is what controls write permission for “groups” (different scripting services on the server).
NOTE: Some servers will not work with a CHMOD of 755, and may return either a 500 Internal Server Error or 403 Forbidden error. In these cases, try using 775, which allows group write. If this gives you a 500 Internal Server Error, try using 777, which enables all permissions. For some servers, 777 will return an error because the permissions are too generous. Always try the lowest permissions that will work, so start with 755, then try 775, then 777 as a last resort. If problems persist, ask your system administrator for help.
Example: The “oekaki” folder is created as the directory in which to install Wacintaki.
/oekaki CHMOD 755
Within this new directory, upload the contents of the “oekaki” folder from your Wacintaki distribution. Do NOT upload the documentation folder or anything else outside the “oekaki” folder of this distribution. It may sound silly to point this out, but it's a fairly common mistake.
CHMOD the resource, and templates directories to 775 (preferred), or 777. The other directories do not need to be CHMODed. Your Wacintaki directory should now look something like this:
/oekaki CHMOD 755 /language CHMOD 755 /lytebox CHMOD 755 /resource CHMOD *775 /shipainter CHMOD 755 /smilies CHMOD 755 /templates CHMOD *775 2Draw.gif addusr.php banlist.php ...
All folders you create should be named with lower-case letters to minimize problems.
The installer will automatically create a pictuers folder and an avatars folder for storing images, so you should not create them. If you must make them yourself (for example, if moving the board from one server to another), make sure you CHMOD them correctly. Using a CHMOD of 775 makes it easier to edit files in the pictures folder with an FTP program, but normally files in the pictures folder are created by Wacintaki, and you should leave them alone.
It's unlikely, but if your FTP program cannot determine that PHP files must be uploaded in ASCII mode, you will have to verify they have been uploaded as ASCII instead of BINARY. Most FTP programs will do this correctly.
Normally Wacintaki creates all the files it needs automatically. If you are using a custom install of Wacintaki or moving it to another server, you must CHMOD some additional files in the resource folder. This is only required if you create the files yourself.
Open the resource folder and CHMOD the following files to 664:
The resource folder contains all the files that make your BBS unique and/or may change frequently. Your banner and rules images, as well as other custom files, should go into this folder. Images used for custom templates should go into their own folders in the templates directory. See the “Banana” template for an example.
In a web browser, go to http://www.yourwebsite.com/yourWacintakiDirectory/. You will be redirected to the installer. Use the information gathered in Step 1 to fill out the required fields. If you only want to install one board, use “op_” for both database prefix fields. To install multiple boards, read the section on Installing Multiple Boards before continuing.
If you have manually created a pictures directory, be sure to type it in the proper field on the install page, otherwise, the installer will make it automatically. At the bottom of the page, fill in the login name and password you will use for the owner account. This will be your personal account from which you can both view and maintain the BBS.
After the install has completed, you will be asked to click a button to delete the installer and updater. Click it, and Wacintaki will be ready to use. Further configuration changes may be made by going into the Control Panel.
If something didn't go right, there is an option to remove the database at the top of the installer. Only copy the install.php file back onto the server if you need to delete the database. Once the database has been removed, you can install a new board, or remove the Wacintaki files from your server.
If you remove the Wacintaki files from your server before uninstalling the database, you will have to manually remove the MySQL database, or it will remain on your server forever. This isn't a catastrophe, but it will waste space, as well as a perfectly good database slot. :)
This option is for those who want to set up two or more oekaki boards, and want to share the member database, so users can use the same login for each board.
On the first board, go to Owner > Control Panel, and note down the following:
The table below is an example of what you might have if you are using the default install configuration.
| Board 1 | |
| Database Prefix | _op |
| Member Database Prefix | _op |
Install your additional Wacintaki into a new, separate directory. Do NOT copy your Wacintaki files from the first board. When you enter install.php for the new board, you must do the following:
If you are using the default Database Prefix and Member Database Prefix, you can try using these values on your additional board(s).
Note: You WILL receive errors such as:
Table 'op_oekaki' already exists
Duplicate entry '' for key 2
Table 'op_oekakichat' already exists
Table 'op_oekakionline' already exists
Table 'op_oekakimailbox' already exists
Table 'op_oekakikill' already exists
This is normal.
Once installed, members will have to login for each board independently, even though all the boards are sharing the same member database. A workaround is described in the section Sharing cookies with more than one Wacintaki board.
Example of two board configuration:
| Board 1 | Board 2 | Notes | |
| Database Prefix | _op | _op2 | All boards must not share the same Database Prefix. |
| Member Database Prefix | _op | _op | Must share the same Member Database Prefix. |
Example of three board configuration:
| Board 1 | Board 2 | Board 3 | Notes | |
| Database Prefix | _op | _op2 | _op3 | All boards must not share the same Database Prefix. |
| Member Database Prefix | _op | _op | _op | Must share the same Member Database Prefix. |
If you want to have separate member registrations for each board, follow the directions above and upload a new set of Wacintaki files to your server, but do not use the same Member Database Prefix as any other board on your server.
This will ensure that each Wacintaki board will have its own, unique member list. People will have to register for each board independently of each other.
Normally, Wacintaki uses one cookie for each oekaki board, forcing people to re-login for each board even though every board uses the same member database. It is possible to resolve this by editing the “hacks.php” file in the resource folder.
The hacks file is new for Wacintaki v1.1.4, and includes extra functionality that is considered too risky or difficult to implement into the control panel. This file replaces the hacks in the functions.php file, ensuring that every time you install a new patch, your hacks will not be discarded.
Inside the hacks.php file, there are two variables named “$cookie_path” and “$cookie_domain”. By editing these paths you can make cookies visible to the entire server, or just a part of it. If you have your own server (or domain name), you can use a single slash as the path (the root path), and every cookie made by any one of your Wacintaki boards will be visible throughout the server and work with every board. If you have an account on a shared server, you can specify your account name as the path. For example, if the URL to your oekaki board is “http://www.Server.com/MyAccount/oekaki”, then the cookie path would be /MyAccount (note the lack of the “http” and server name). This will make the cookie visible only to MyAccount, but NOT to the rest of the server. You wouldn't want other peoples' oekaki boards installed on, for example, Tripod, to all have access to your cookies!
Be very careful when using this feature, as an improper value may make it impossible for people to log in, and cookies made global to the entire server may conflict with other boards not owned by you. PHP knowledge is also recommended, as you are editing the source code directly and mixing single and double quotes can cause errors that will render the board inoperable. If you mess up, just replace the hacks.php file with an older copy or one that came with Wacintaki, and leave the $cookie_path and $cookie_domain variables alone.
Please note: all your boards must have an identical copy of the hacks.php file! Once you have edited the hacks file, copy it to the resource folder of each BBS that will share a single cookie.
Here is a list of account types. For more information on account management and user flags, view the “Admin > Modify Permissions” menu.
There are four types of menus at the top of the main page. The one that starts with “FAQ” is the main menu and will be visible to the public. The “My Oekaki” menu is available to all members to manage their pictures and posts. “Admin” is a menu reserved for administrators and super administrators and provides several methods for board moderation. There is also an “Owner” menu reserved exclusively for the board owner. Other admins and super admins cannot access the owner functions.
Use the “Admin > Edit Banners” menu. The banner will show up above the main menus, the notice will show below the menus and above the page numbers. HTML is required for both. A plain <div> is automatically used for banner content. For clarity, consider using <div class="infotable"> for the notice. That will pad the information and put it on a plain background.
Use the “Admin > Edit Rules” menu. HTML is required, so use a <div>, <p>, or <table> for the content, and a <br /> is required for each line break. Unordered lists, made with <ul> and <li> tags, are recommended.
Normally when people register on your board, they will be taken to the registration screen first. There is a control panel option under “Registration” that will show the board rules to people before they can register. It is off by default because a clean install of Wacintaki has no rules.
Only owners may access the control panel. Most of the features have explanations below each item as to what it does. Unlike OekakiPoteto, if a Wacintaki feature is not compatible with your server, it will be automatically disabled in the control panel.
If you need to update SQL information, there are tools to do this in the documentation folder, as well as on the NineChime web site.
Wacintaki allows each member to upload an avatar to his or her profile via the profile editor. This is a small picture, typically 50×50 pixels that shows up before that member's name when they post. The installer creates an avatar folder, and the feature must be enabled in the control panel. Avatars may show up on picture posts or on every comment on the board, depending on the config options chosen by the owner.
Safety saves are pictures that are drawn but not immediately posted to the board, and may be finished at a later time. They are automatically removed if they are not finished after a certain amount of time, and people are only allowed to have one safety save at a time. Safety Saves are on by default, and may be disabled in the control panel.
Be aware that a safety save will take up one slot on the board, so increasing the safety save delete time may not be a good idea, depending on how many slots you have available and how much space you have on your server.
If a picture appears to be incomplete, admins may turn it into a safety save by clicking “WIP” in the post header. A mailbox message will be sent to the artist, alerting him or her that the picture must be finished within the time period set in the control panel.
People may assign passwords to their pictures when they are saved. Anyone with access to the password may retouch that picture. When pictures with passwords are edited, they will not be posted in new slots, but may be bumped. This is ideal for collaborations, as frequent edits will not flood the board, causing older pictures to be deleted quickly.
Public pictures are similar to password protected pictures, although they have no password, thus allowing any registered member to edit them. When edited, a public picture will be posted in a new slot, leaving the original picture unaffected. Frequent use of public images may result in a flood of new posts, so if this feature is enabled in the control panel, tight moderation, and having more than one admin, is recommended.
Public pictures are credited to the original artist automatically. This feature is therefore ideal for a coloring book oekaki, where people are asked to color unfinished lineart, and a large number of similar posts is tolerated.
To view all public pictures on a board, a new sort option for Public Images has been added to the View menu.
If you elect to approve registrations manually (set “Require Approval” to “yes”), you will need to go to “Admin > View Pending” to accept or reject pending members. The number of people waiting for approval will be shown in the menu. Note that if you switch to the automated registration system, people already in the pending members list will still have to be manually accepted or rejected.
If you are using an automated registration system, make sure that you have set a registration e-mail in the control panel. When people register on an automated registration system, an e-mail will be sent to them with a verification code so they can activate their accounts. However, you may still go to “Admin > View Pending” to manually add or reject pending members.
If you want to make someone a moderator, admin, or super admin, go to “Admin > Modify Permissions.” Use Immunity to prevent a member from being removed by the auto-kill feature if it is enabled. Uncheck a member's General User tab to suspend their account without deleting all their pictures and posts, as deleting an account will remove all traces of that person from your board(s)!
It is pointless for owners to modify their own flags, as owners already have all permissions for the entire board. If you lose your owner flags for some reason, look for “flagrestore.php” in the docs folder. Edit the file so your username is at the top, copy it to the oekaki folder on your server, then run it to get your flags back.
It is strongly recommended that there only be one owner on an oekaki board. The owner has the ability to access SQL information, and therefore giving anyone else owner status can potentially put your entire server account at risk!
Automatic User Delete may be enabled in the control panel. This will automatically delete any member account without the immunity flag if they fail to log in within a specific amount of time, which can help keep the memberlist shorter and more current. It will remove all pictures and comments by an affected member, however, so if you enable this feature, choose a fairly large value, such as 60 - 90 days.
If an artist has pictures archived, the auto kill feature will not apply to them (they will automatically be granted immunity). An admin will have to either un-archive each picture or manually remove that member's account.
To only trim old lurker accounts, and not artists, enable the “ Auto Immunity for Artists” feature in the control panel. This will automatically assign the immunity flag to members if they draw a picture. This is on by default, as many people who register for an oekaki never draw pictures.
To archive a picture, click “Archive” in the post header. This will prevent the picture from being deleted as new pictures are posted and old ones are removed from the board. Be careful not to archive too many pictures, as this will reduce the total number of slots usable by the board, causing new non-archived pictures to be deleted quickly.
Archived pictures behave just like normal posts. They may be edited at any time with or without a password, and the original artist may delete the picture.
Wacintaki 1.3.12 introduced a new log file system to help admins monitor board activity. This log is accessible via the admin menu, and is available to all admins.
The log tracks admin activity (deleting files, archiving, modifying flags, etc.), as well as member activity (editing comments, deleting posts, changing passwords, etc.).
Log information is considered to be private, so for security reasons, do not post log information publicly.
This section covers issues with a board that has been installed. Installation and server issues are covered in the “readme.html” file that came with your Wacintaki distribution.
As of Wacintaki 1.3.6, the diagnostics screen is accessible from the main menu when logged in as an owner. It will show various database and config settings, statistics such as space usage, as well as filesystem permissions.
If you are having problems where people cannot log in, or you cannot properly administrate the board, first see if the diagnostics screen shows any errors.
Information on the diagnostics screen is considered to be statistical data, and may be shared. However, most data may only be changed in the control panel, and is therefore only under the control of the board owner. For this reason, admins cannot see the diagnostics screen.
Serious board errors and security violations are recorded by the log file. If you run into a problem with your board and ask for help on the NineChime forum, you may be asked to submit log information. The forum administrator will help you determine if the log information may be posted publicly, or if it must be submit to the administrator's e-mail address.
Log information is considered to be private, so for security reasons, do not post log information publicly.
Mail errors were redesigned in Wacintaki v1.1.3 so they should no longer crash the script. Instead, they will print directions on what to do since e-mail is not working on your server. If your server does not support sending e-mail, and you want new registrations to be automatically accepted, you should set the Control Panel option “Require Approval?” to “No (Forced).” This will force Wacintaki to automatically approve any registration. Otherwise, administrators will be required to approve each registration manually.
You might want to ask your tech support to enable e-mail support, since it allows more sophisticated moderation of the board. Due to the potential for spam abuse, e-mail services are rarely available on free hosts.
Templates won't work: This happens if you delete a default template but don't update the setting in the control panel. Also, if you delete a template that someone is already using, their pages will show up very plain. Tell that member to go into Edit Profile and select a new template
Templates don't update: Wacintaki 1.4.2 includes a new template build system which only works for administrators. If templates will not build with Wacintaki 1.4.2 or higher, check your member permissions, and then check that the CSS files in the templates folder are not locked. The files may be locked if you copied them to the server manually with an FTP program. If a moderator has FTP access and has uploaded a new template, the CSS version of the template must be deleted. Templates will only build automatically for admins.
As of version 7.51, Java now refuses to run unsigned applets. For artists to continue drawing on an oekaki board, they must go into the Java control panel and add a security exception for each oekaki board they visit. This is a royal pain, but unfortunately Oracle, the company that controls Java, has made this security change permanent. For more information, go to the Java web site and do a search for “Exception Site List”.
The only effective way to bypass the whitelist requirement is to sign the applet with a CA signature. This requires you to purchase a signature from a Certificate Authority, requires your hosting service to support HTTPS, and for you to have a reasonable knowledge of the Java security tools.
Some servers, particularly free hosts, will not allow .JAR files to be hosted. If you can directly view images by typing the file paths into your web browser address bar, but trying to view the JAR files returns a 404 Not Found error, then your host cannot serve JAR files. Try asking you host to allow JAR files, though they probably will not agree, citing security/spam concerns. If you are not paying for hosting, you may need to seek a new host in these cases. It may be possible to add the necessary MIME type for JAR files, but this usually does not work. Visit the NineChime forum for tips on how to add MIME types to your host.
Some servers require HTTP referrers to view any pages other than an index. Java does not use HTTP referrers and therefore will not function on these servers. This happens only on free hosts, or if you have explicitly turned on some kind of “anti-leeching” setting in your server's control panel.
In rare cases, some servers may require execute permissions to be granted to folders that contain JAR files. If the drawing applets work correctly, but the PaintBBS/ShiPainter animation viewer shows a red “X”, try setting the permissions of the “shipainter” folder to 757 or 777.
Some hosts have anti-spam filters in place that will not allow certain words to be posted in comments and other web page content. If the pages refresh after you submit information, but the board does not seem to do anything and does not return any errors, your server might have a strict filter policy in place. Many servers with comment filters will not return errors if a word match is made, and will just dump all information submit to the server. Servers doing this are said to “blackhole” the data. Sometimes 403 (Forbidden) or 404 (Not Found) errors will also be returned, and Wacintaki itself may return the message “no mode”.
Observe your site's Terms of Service and avoid using certain questionable words. Check your host's FAQ or support forum to see if any threads explain what is being filtered. Some links to external sites (such as PhotoBucket) may also trigger this error, so try to host as many banner and notice images on your own server as possible.
There is no way for Wacinaki to detect if a comment has been rejected, as the server itself simply throws away the data. This is a difficut problem to diagnose. This is a common problem with free hosts, and is very rare with paid hosts.
This may occur if you've moved your oekaki from one server/folder to another and FTP'd the config files. This causes problems because PHP is unable to write new config files if you make changes in the control panel. CHMODing to a lower security level may or may not work, but is not a proper solution.
Solution: Copy the “reclaim.php” script from the documentation folder into your oekaki folder on the server and run it.
The Wacintaki updater attempts to CHMOD the pictures and templates folders to allow the storage of images, and the generation of templates. If it fails, the “draw.php” file will not allow people to draw pictures until the issue has been resolved. CHMOD these folders to 755 or 777 to use them. If you cannot CHMOD them, ask your sysadmin to do it. Even if you cannot CHMOD the directories, some servers will allow you to delete them via FTP and re-create them, though you will lose all contents in those directories.
If your board is hosted by an Apache server, animations may return a “Not in GZip Format” error. This is usually caused by banner ads, because the way servers use advertisements corrupts animation data. To fix this, copy the “.htaccess” file in the documentation folder of your Wacintaki distribution to the “oekaki” folder on your server. This file isn't copied by default as some servers do not like this file and will disable your board if you use it. Copy it only if you need it. This file only works with Apache servers, regardless of whether UNIX/Linux or Windows is the OS.
If your board runs on a server using Microsoft IIS (Internet Information Services), this is a permissions issue. IIS will not, by default, serve files without registered MIME types. Therefore, the animation files will return a “404 Not Found” error, even though they are visible in the pictures folder. If you click “View Animation” and the pop-up shows the filesize, but you cannot download the animation via the link, the proper MIME types must be added to your server. Only a server administrator can do this.
The following MIME types are required for IIS servers:
| PaintBBS PCH: | “video/x-pch” |
| ShiPainter SPCH: | “video/x-spch” |
| Chibi Paint CHI: | “video/x-chi” |
Check the FAQ after installing Wacintaki. It includes information for general users as well as how to get oekaki applets working, and how to install Java.
Please read the manual (specifically, the troubleshooting section) in the documentation folder of this distribution before seeking help.
Before reporting bugs, make sure you have the latest stable version of Wacintaki.
For help using Wacintaki or to report a bug, please visit the NineChime Forum. The forum does not require registration and all questions regarding OekakiPoteto, Wax Poteto, and Wacintaki are welcome.
Please do not ask questions about Wacintaki on OekakiPoteto forums. Wacintaki functions very differently compared to OekakiPoteto and you may not be able to get any help.
Please read through the entire Newbie Guide before doing anything else. :)
This Newbie Guide will cover most of what you need to know, including which servers can run oekaki boards, PHP, MySQL, CHMOD, FTP, and bandwidth.
It also covers a little about Java, which you do not need on your server, but all of your members will have to have on their computers. Don't worry, most computers these days have Java technology built-in, or a clone like the Microsoft Virtual Machine, and Wacintaki has directions for members on how to get Java if they don't have it.
To learn how to set up a MySQL database or an FTP account for your server, take a look at the control panel for your server, or ask your system administrator for help. Every system is different, and how much you can do depends on how the account on your server is set up.
There are a number of sites on the Internet that will help you find a free hosting service. A starting point is to use Google and search for “php mysql hosting free”. You'll likely find a nubmer of sites that rate hosting services, rather than offer hosting.
You may also ask some other oekaki owners on the NineChime Forum for tips or recommendations.
Keep in mind that many free sites may severely restrict what you may upload, how scripts will behave, or what kinds of comments people may write. Observe each hosts's Terms of Service to make sure that all the permissions you need are present. Many sites also have advertising banners which may momentarily block certain features of your oekaki board, though you may make your oekaki's banner taller to keep menus from being blocked by ads.
It is recommended that you use a paid hosting service. A service that costs even $5 a month will ususally suffice. This ensures that there are no compatibility surprises, and you can contact a system administrator if something isn't working right (example: the Java applets cannot upload pictures, because there are upload limits in effect).
The essentials are a server that offers the ability to upload script files, as well as a database. The scripting language used for Wacintaki is PHP, and the database is MySQL. MySQL should not be confused with “MS SQL”, which is made by Microsoft. PHP and MySQL are considered a pair these days, so servers that have PHP most likely have MySQL, too. Most free web sites offer one database, and pay sites usually offer between two to six — or more. Only one database is required for Wacintaki.
You must also have the ability to access PHP and MySQL, so just because your server supports it, doesn't mean you can use it. Sometimes you have to pay extra to use MySQL. Ask your system administrator if you have the ability to use PHP and MySQL. PHP requires no special setup, but you will have to create a MySQL database yourself. This can normally be done with your web site's tools, the most popular of which is CPanel.
Creating a MySQL database is beyond the scope of this guide, as the procedure is usually different on each web site. Getting SQL working involves creating a database user, creating a database, and giving that user permission to use the database. The user name, password, and database names are what is used in the Wacintaki installer to set up the tables in the database, which actually stores the information for your oekaki board. If you get stuck, it's best to ask your system administrator or check any available documentation to which you have access from your server provider.
Some servers have a tool called phpMyAdmin, which lets you create, maintain, and back-up databases. It will not let you create a database user or password. Ask your system administrator for help with setting up a database user and password. phpMyAdmin is helpful for maintaining a database, but is not recommended for creating one.
Almost all modern hosts will work correctly with the primary (and most fully-featured) drawing app, ChickenPaint. There may be problems with the older Java-based applets, and therefore you cannot even host the JAR files on the server. This is not a concern, as almost no mainstream computers are capable of running Java applets anymore.
Some hosts have anti-spam filters in place that will not allow certain words to be posted in comments and other web page content. If such a word is encountered, the server will simply pretend it never received the comment at all, and you may receive the cryptic message “no mode”. This may result in comments not showing up on the board. This may also prevent you from changing the banner/notice of your oekaki, and can cause the server to serve only a blank page. This is a common problem with free hosts, and is very rare with paid hosts. See the troubleshooting section for more info.
As a general rule, if your hosting service is still running PHP version 5, ask them to upgrade to at least version 7. While Wacintaki works fine under PHP 5, hosting services still using this obsoltete platform may have many other compatibility and security concerns that may cause problems.
MySQL usually presents no problems, so long as you are allowed access to it. In some cases, when server administrators upgrade MySQL, you may be required to reset the database password. This is a hosting issue that only affects board owners. Normal members of Wacintaki BBS do not need to reset their passwords.
PHP is a free scripting language designed for making complex, dynamic web sites. All you really need to know about PHP is that your server must have it installed. PHP scripts end with “.php”, and are plain text files so they must be uploaded to a server in ASCII format with an FTP program. Most FTP programs already know PHP files must be uploaded in ASCII mode.
SQL stands for “Structured Query Language”, and is a standard for talking to databases. The type of SQL database used for Wacintaki is MySQL, which is available on almost every server that has PHP.
Creating a MySQL database isn't terribly difficult, but how you do it depends largely on what kinds of tools are available for your server. If you have a control panel for your server, like CPanel, you should find a way to make a database on the main page (not through an administration tool, like phpMyAdmin, which can be difficult to use). If you don't have a control panel, ask your system administrator for help.
CHMOD is a way of modifying a file's access permissions, so it can be read, written, or run as a script. There's more to server security than that, but CHMOD is the only command you'll have to worry about to install an oekaki board. You pronounce it as “shmod” -- as one syllable that rhymes with “clod.”
Several CHMOD programs exist, though it is often used as a verb, as in, “to CHMOD a file.” FTP programs have the ability to CHMOD files. Web-based file managers offer similar functionality, but use read/write/execute flags instead of the CHMOD three-digit standard.
By default, all files uploaded to a server can be read by the public, but not run as scripts, or written or deleted by anyone but you. A file's permissions are determined by a set of flags or numbers. Although every server uses different numbers for determining a file's permissions, most FTP programs use the UNIX CHMOD standard, which uses a three-digit number.
Don't panic... the installation instructions tell you which numbers to use for each files, and only a small number of files must have their CHMOD number modified. Most files are just uploaded as they are and the installer will take care of the rest, so you don't really need to know what the numbers mean.
FTP stands for “File Transfer Protocol”, and is the most important Internet standard for uploading and downloading files to and from a server. It differs from HTTP (what web browsers use), in that you must use a password to get access to files. Although you can use a raw FTP program from a command prompt, there are a number of free, simple programs that will handle all the hard stuff for you and just let you transfer files and CHMOD them. A list of programs is provided in the Wacintaki Pre-Installation section.
All servers support FTP, and you should be able to use it, but some servers provide alternatives, like web-based file managers. These may be used if they allow you to set file permissions (either with the CHMOD standard or with read/write/execute flags), though FTP is the most reliable method.
Many FTP programs can use both a www and ftp address to log into a server, so “www.Server.com” and “ftp.Server.com” should both work. If you have trouble, try the ftp prefix instead of www. The “Server Port” is almost always 21. Other ports can be specified by the server, but 21 is the default for most servers and FTP programs.
Many servers have a special folder in which you need to upload files. If you're used to uploading files with a web-based file manager, rather than FTP, you'll need to look for a public share folder which is usually called “public_html”, “www”, “web”, or sometimes “home.” If you do not upload files in that special “public” folder, they are considered to be private and will not show up on the Internet. Some servers do not have this public share folder, so if you don't see it, don't worry. UNIX / Linux servers usually have this folder, Windows servers may not.
Technically, bandwidth is the measure of how fast you can transfer data from one place to another. In web lingo, it is the amount of data delivered by your server to the public in a given amount of time. Most Internet service providers measure bandwidth monthly. If you go over your allotted bandwidth for a given month, you may be charged extra money for your hosting or your site might be disabled temporarily until next month. The amount of bandwidth used depends how many people are using your oekaki and what they are drawing (mostly, the size of the canvas used).
Bandwidth is usually measured in Megabytes and Gigabytes. One Megabyte is good for downloading 10-15 standard-sized pictures (not thumbnails). A Gigabyte is approximately 1,000 Megabytes.
Wacintaki is much more efficient with bandwidth than OekakiPoteto, so if you're upgrading from OekakiPoteto to Wacintaki, you shouldn't have to worry. If your board is hugely popular and has hundreds of members, you may need 5-10 Gigabytes of bandwidth a month. A board with a few dozen members shouldn't use much more than 1 Gigabyte. You should keep track of bandwidth usage in your server's control panel if your host only gives you a small amount, like 1 Gigabyte per month or less.
As of 2009, most free web sites will give you between 500 Megabytes to 2 Gigabyte per month. Paid sites will generally give between 5-30 Gigabytes per month. Be wary of sites that advertise “unlimited” bandwidth, as this is only for marketing purposes. When dealing with free hosts, these “unlimited” sites should be avoided, as they will likely not honor promises, either for bandwidth or other services. Paid hosts usually offer plenty of bandwith for running an oekaki.
Note that many chat rooms use a lot of bandwidth, so if you're having a lot of bandwidth issues, try disabling the chat room first. Oekakis are structured to be like forums, so the lack of a chat room shouldn't be a big deal.
For more help on bandwidth, read the section on Using Wacintaki in this manual.
OekakiPoteto ©Copyright 2001-2003 Theo Chakkapark and Marcello Bastéa-Forte.
Wacintaki modifications ©Copyright 2004-2022 Marc A. Leveille.
PaintBBS and Shi-Painter paint applets are ©Copyright Shi-chan
Chibi Paint applet is ©Copyright Marc Schefer
ChickenPaint HTML5 app is ©Copyright Nicholas Sherlock