$LockRemoteUser:  If your WebBBS script is password protected via
.htaccess or another system which sets the “REMOTE_USER” environment
variable, you can elect to force users to post under their login names
by setting this variable to 1.  (The variable will be logged and will
be available to the administrator when viewing messages, even if you
don’t require that it be used as a posting name.)

$RequireProfile:  If you set this variable to 1, visitors will only be
able to post to the forum if they first create a user profile.  By
itself, this setting isn’t of much use, though it can be of use, for
example, to help limit extraneous postings to a forum intended for
use only by “regular” posters on your other forums.  But if used in
conjunction with the $RequireEmail option below, it can serve as a
sort of simple access protection.  More on that below.

$RequireEmail:  If you set this variable to 1, anyone attempting to
create a profile will be required to provide a valid e-mail address.
(The script will generate a random password, and e-mail it to the
address provided.)  Users will not be able to change the address
later or delete the profile, and of course won’t be able to post
messages under the user name attached to the profile without the
password provided by the script.  By itself, this option isn’t
terribly useful, though it might allow you at least to keep tabs
on some of your more prolific posters.  But if used in conjunction
with the $RequireProfile option, it can serve as a sort of simple
access protection.  Anyone who wants to will still be able to post
on your forum, but in order to do so, a visitor will have to create
a profile with a valid e-mail address.  Since he won’t be able to
change the address or delete the profile later, you’ll be able to
identify anyone posting “offensive” material.  Of course, the mere
fact that a real e-mail address is required will probably prevent
most such posts from being made in the first place.

$AllowUserDeletion:  Set this to “1″ if you want users to be able to
include a password with their messages which will allow them to come
back and delete them on their own.  Leave it undefined if you want
them to be stuck with what they posted.

$AllowEmailNotices:  Set this to “1″ if you want users to be able to
request e-mail notifications whenever someone responds to their
messages.  Leave it undefined if you want to require them to actually
visit the BBS again to find out.  This ONLY defines whether or not
people can request automatic notifications of responses to their own
posts, and is distinct from the $email_list variable, which defines
what, if any, new post “subscription” capability your board will
support.  Like the other e-mail functions, the automatic notification
of responses will be disabled if you do not define the $mailprog
variable.

$AllowPreview:  Set this to “1″ if you want your users to be able to
“preview” their posts before actually submitting them.

$AllowHTML:  If this variable is set to “1″ people posting messages will
be able to embed HTML tags (hyperlinks, image references, formatting
commands, blinking text, etc.) in their messages.  If it is set to “0″
they will not be able to do so.  Be aware that allowing embedded HTML
virtually invites abuse of your bulletin board.  Setting the variable
to “2″ will allow any HTML codes to be displayed in the message rather
than being either interpreted or stripped.  This can be handy, for
example, if the subject of your BBS is how to code HTML.  SSI commands
will *never* be interpreted by the script.  If this variable is set to
“2″ they will be displayed along with any HTML tags; otherwise, they
will simply be stripped.

$AllowURLs:  Set this to “1″ if you want users to be able to include
a URL link at the bottom of their messages.  (This can be handy if
you don’t allow HTML in posts, and can even be nice if you *do*
allow it.)

$AllowPics:  Set this to “1″ if you want users to be able to include
a link directly to a graphic image on their own or another server.
Depending upon the nature of your BBS and the demographics of your
audience, of course, you very well may not want them to be able to
post unapproved graphics….

$AllowProfileHTML, $AllowProfileURLs and $AllowProfilePics:  These three
variables work just as do the $AllowHTML, $AllowURLs and $AllowPics
variables, only they apply (obviously) to user profiles rather than
to messages.

$SaveLinkInfo:  If you set this variable to 1, any information provided
in the optional link and image fields will be stored in the user’s
cookie file.  If you have a lot of people who use those fields for
a sort of “signature,” you’ll probably want to turn this feature on.
If, on the other hand, most of your users only fill out those fields
with information relevant to a specific post, you’ll want to keep
it turned off.

$AllowUserPrefs:  If you set this variable to 0, users will *not* be
able to alter the style in which messages are displayed.  (They will,
of course, still be able to search for specific messages.)

$AllowNewThreads:  If you set this variable to 0, users will be able to
post responses to messages, but will *not* be able to start new
threads.  (See also $AllowResponses, below.)

$AllowResponses:  If you set this variable to 0, users will only be able
to post new messages; posting follow-ups (responses) to existing
messages will not be possible.  This is useful if, for example, you’re
setting up a “classified ads” system, and don’t want visitors to be
able to respond publicly to the listings.  Note that if you set both
$AllowNewThreads and $AllowResponses to 0, users will not be able to
post any messages at all.  This is very similar to the result you get
if you define $ArchiveOnly as 1.  However, there is one important
difference.  A true archive board will not allow users to specify
a time frame to view, since, for example, viewing all messages posted
within the last “2 Week(s)” is rather pointless if the board doesn’t
contain any messages posted less then two months ago.  On these
boards, only actual searches (which can, of course, include date
ranges) will display any messages.  On the other hand, if you have
*not* defined the board as an archive board, but have simply “turned
off” both $AllowNewThreads and $AllowResponses, users *will* be able
to select default time frames for their viewing.  If you’re running
a *busy* “announcements” board, this is probably a preferable option.

$NaughtyWordsFile:  You can, if you like, define here the path of a file
in which “naughty” language (words or phrases you don’t want included
in posts on your forum) will be stored.  The file can be edited with
the administrative script.

$CensorPosts:  If this variable is set to 1, any words (or character
strings) matching the contents of the “naughty words” file will be
replaced by a string of hash marks in the actual post.  For example,
if you defined $NaughtyWords as “this that” and someone attempted to
post the message, “This is one thing, that is another,” the actual
post would appear as “##### is one thing, ##### is another.”  If you
leave this variable set to 0, a message containing forbidden words
will not be posted at all; instead, the poster will be shown a message
stating that his message was rejected for content, and will be given
the option to go back and “clean up” the post himself.  If you set
this variable to 2, posts containing “naughty words” will be accepted
but not displayed until approved by the administrator (just as if
you were running a moderated forum).

$ShowPosterIP:  If you set this variable to 1, whenever a visitor posts
a message, the “thanks for posting” message will display his IP address
and host domain.  This can serve as a subtle reminder to potential
troublemakers that they aren’t really anonymous, but is *not* likely
to annoy legitimate posters and visitors, as displaying IP addresses on
the index page might.

$BannedIPsFile:  You can, if you like, define here the path of a file
in which the IP addresses or domain names of any individuals you want
banned from your forum will be stored.  The file can be edited with
the administrative script.

$BanLevel:  If this variable is set to 0, anyone whose IP address or
domain name matches an entry in the “banned users” file will simply
be unable to post messages to your forum.  If it is set to 1, such
visitors *will* be able to submit posts, but those posts will only
appear on the forum if and when an administrator approves them.  (In
other words, they’ll be treated as if you were running a moderated
forum.)  If the $BanLevel variable is set to 2, on the other hand,
such visitors will not only be unable to post, but will not even be
able to read messages posted by others.  They won’t have any access
to the forum whatsoever.

$BanUnresolved:  If this variable is set to 1, anyone whose IP address
cannot be resolved to a domain name will be banned, just as if they
were posting from a specifically-banned address.

===========================================

CONVERTING OLDER WEBBBS IMPLEMENTATIONS

The 4.XX and 5.XX versions of WebBBS utilize a number of features — the
DBM database file, the search index file, etc. — which didn’t exist in
earlier versions of the script.  As well, the organization of the data
files is different, as message files are now stored in a series of
subdirectories rather than in one single directory.

Upgrading is basically just a simple matter of replacing the old script
files with the new ones; however, there is, of course, a caveat.  Until
you tell the script to “rebuild” the database — a process which not
only includes creation of the basic index database, but which also
includes creation of the search terms index and any necessary shuffling
of message files to new directories — the new version of the script
won’t know that your old messages exist.

There are two ways to rebuild (or, if this is a first time conversion,
to build) the necessary database files.  If your forum is relatively
small, you can simply access WebBBS directly from your browser, with
“?rebuild” tacked on to the end of the URL.  (For example, you could
call “http://www.foo.com/forum/index.cgi?rebuild” to force a needed
build or rebuild.)

But if your forum is fairly busy, WebBBS might not be able to handle the
entire conversion process in the time your browser is willing to wait.
(In particular, construction of the search index file can take a while,
since each message file has to be opened and read.)  If you have more
than a few hundred messages on your forum to be converted, you need to do
one of two things.  Either run the new WebBBS script the first time from
your telnet command prompt, rather than through your browser, including
“rebuild” as a command line argument (as in “./index.cgi rebuild”) or
convert only a few hundred messages at a time.  (In other words, move a
few hundred messages into your data directory, run the rebuild from your
browser, then move a few hundred more into your data directory, run
another rebuild, etc.)  Obviously, the former is more efficient, but if
you don’t have telnet access, and don’t want to move to a better hosting
service, the latter may be your only option.