Troubleshooting

You should first look into the board’s error log. You can find it in the unb_lib/logs/ directory, named error-‹year›-‹month›.log. If this doesn’t help, you should look into the PHP error log. Ask your system administrator where to find it. If you have no access to it, you can alternatively enable PHP error messages and warnings in the page output by adding "+showerrors" to the $DEBUG line in the file forum.php. Be sure to revert this change when the problem is resolved.

The same as in the previous section applies.

Automatic output gzip compression only works from PHP 4.2 on. With previous versions you need to enable it explicitly in the board configuration.

This seems to be a Firefox-specific problem. Remove all cookies named “Unb...” from the forum domain. There are likely to be multiple of them with the same name and Firefox gets confused then.

You should change the definition order in your smileys configuration file. If an earlier-defined smiley’s code contains a part of another and is followed by an accepted character in the post (e.g. punctuation), it will be replaced only half. You need to move the recognised smiley’s line after the intended one.

If this problem occurs without further notice, there was most probably an encoding problem with one of the PHP source files. All source code files are normally encoded in 7-bit US-ASCII but i.e. the translation files are encoded in UTF-8. There are two variations of UTF: one with and one without the so-called “Byte-Order Marker” (sometimes also called “Unicode Cookie”). This BOM is the first two or three characters of a UTF-encoded file and it defines the exact method the file is encoded with. Unfortunately, PHP cannot handle this BOM and treats it as normal text output. But HTTP headers and cookies can only be sent before the very first text output. Since the BOM is sent out before any PHP programme code is executed, this whole thing cannot work. The only solution is to store all source files without the BOM which is like I publish all files already. When you edit one of the files yourself, like when you’ve translated the board, you must pay attention to store the files in the correct encoding.
To determine whether this was the problem, you should enable the display of PHP error messages by adding “+showerrors” to the $DEBUG string in the file forum.php. Then a warning is issued whenever an HTTP header could not be sent because the output has already started.

The forum uses XHTML markup to display the pages in the browser. The most significant difference between HTML and XHTML is that the latter one must be strictly well-formed. If there is an error in the syntax of the web page, the browser may decide to show nothing at all. (Internet Explorer is not affected by this because it doesn’t support XHTML at all and will be served HTML-compatible pages instead.) Here are the most common XML error messages and what they really mean:

• This XML file does not appear to have any style information associated with it. The document tree is shown below.
  The server returned an empty document. This is the case when a fatal PHP error occured before any output was produced. The script was terminated then and the web page remained empty. Most likely the PHP error was logged into the PHP error log. Ask your system administrator how to access it. If this log is not available for you, enable the display of PHP error messages with the php.ini configuration options display_errors and error_reporting. There’s a shortcut to these at the beginning of forum.php in the $DEBUG line. Read the comments near that for details. The PHP error will give you more details about the actual error.
• XML Parsing Error: No element found
  This is the same error as the first one only that there may already be HTML output before the PHP error occured. Check the end of the page source or your web server’s error log for a PHP error message that leads the actual problem.
• XML Parsing Error: mismatched tag. Expected: </ul>.
  This describes an actual XML syntax error in the document. The line of XHTML code that caused the error is displayed, in Firefox along with a pointer to the exact place. Well, not so exact if there are tabs at the beginning, but you'll be able to find the problem. If you made any changes to the forum code or the templates or included the forum into another website, the usual bug tracking beginning from point 3 applies. Be aware that you need to write XHTML compatible code when working with the forum.

As a temporary fix you can set “+htmltype” in the $DEBUG line in forum.php to disable use of the XML content type. The browser will not show XML errors on pages delivered as text/html.

This could be because of Apache’s MultiViews option that tries to find the correct page with additional filename extensions. This way it can select an appropriate language or encoding of a web page that exists as say “page.html.de” and “page.html.en” when accessing “page.html”. This mechanism seems to interfer with URL rewriting such that URLs like “forum” that should actually be rewritten to something else are first matched to the actual file “forum.php” without any further parameters. Then you won’t get to see the forum you requested but the overview page.
There are two possible solutions to this. The easy one is adding the line “Options -MultiViews” to your main .htaccess file. It disables this feature and lets URL rewriting properly do its job. If you’re not able to use this line (the administrator may have prohibited its use, resulting in an “Internal server error” message), the second option is renaming the file forum.php and update all references to it. You can find these references in the files .htaccess and board.conf.php at the keys basefile and baseurl. The new name should not be similar to the old one, i.e. “app.php”.

In the e-mails, so they arrive, you can see parts of the header lines at the beginning of the mail body. This is a problem with the participated local MTA (mail transfer agent, commonly the “mail server”) which translates line breaks of incoming local messages from a bare LF (\n) to CRLF (\r\n). This violates agains the standard because e-mails require line breaks of CRLF and applications must already format them this way. UNB also does it right but when the MTA replaces all LF by CRLF, the CR is doubled, resulting in incorrect, but likely doubled line breaks that split up the headers and move them into the body part where they cannot be processed anymore. See the PHP mail() function documentation, the note about the additional_headers parameter. (Forum thread)

The default access rule for guests is missing. If it is not present, guests have no rights at all, they must not even view any forum.

http://www.ozerov.de/bigdump.php