(B) The optional configuration variables are as follows:

As noted above, the rest of the variables do *not* have to be altered
from their default values.  If you’re not quite sure what you’re doing,
don’t change any of them until you actually have the script running,
and are ready to begin “fine-tuning” it.

$SearchFriendlyURLs:  If this variable is set to 0, the script will
generate URLs using standard QUERY_STRING attachments; thus, your
forum’s messages will *not* be indexed by search engines.  This is
to be preferred in most situations, especially if your forum isn’t
set to keep messages for a long period.  If the variable is set to
1, the script will utilize “search engine friendly” URLs, which
*can* be indexed by search engines.

$DBMType:  This variable determines how the DBM (database) file used
for storage of index information will be accessed.  Most users can
leave it set to 0.  If the script can’t open the database file,
though — and especially if you receive “Inappropriate file type
or format” errors — try setting it to 1.  This will replace the
basic tie() command with a version of the command specific to the
DB_File module, which produces the above error message.  If all
else fails, set $DBMType to 2, and instead of tie() commands, the
more generic (but less efficient) dbmopen() commands will be
used.

The following four variables allow you to add “spell checking”
functionality to your forum.  This is done by interfacing WebBBS
with the SpellChecker.net system.  If you choose to use this system,
you’ll need to register.  (The registration is *not* free.)  You’ll
also need to download and install a few extra files; those files are
of course available from and documented on the SpellChecker.net Web
site, at http://spellchecker.net.  Any questions about the files
and their setup should be directed to the folk at SpellChecker.net.

$SpellCheckerID:  Define this variable with the ID number you
receive from SpellChecker.net.

$SpellCheckerPath:  This variable should be defined with the path
to your “sproxy.cgi” CGI script obtained from SpellChecker.net.
Note that this “path” isn’t a true path, as are the paths elsewhere
in the WebBBS configuration, but rather, is the path portion of
the file’s URL.  In other words, if the URL of the file is
“http://foo.com/cgi-bin/sproxy.cgi,” you need to define this
variable as “/cgi-bin/sproxy.cgi.”  It’s a bit confusing, yes,
but I have no control over it.  ;)

$SpellCheckerJS:  This variable should be defined with the URL
(*not* the path!) of the “spch.js” JavaScript file obtained from
SpellChecker.net.

$SpellCheckerLang:  Define here the default language to be used in the
spell checking.  (For most WebBBS users, that will of course be “en”
for English.)

The next few variables concern “user profiles,” which you can, if
you like, allow your forum’s visitors to create.  These profiles will
be more-or-less permanent features of your forum.  A particular user’s
profile will be accessible from any messages he posts, and will allow
him to tell other visitors a bit more about himself than is evident
from his messages.  A user can update his profile whenever he likes.
The administrator can also edit or delete profiles easily, as all
profiles are accessible from the administrative script’s “poster
stats” menu option.

$UserProfileDir:  If you want to allow your visitors to create user
profiles, define here the path (not the URL) of the directory in
which the profile files should be stored.  This directory does not
need to be — and in fact should not be — accessible to Web
browsers.

$ProfileColumns:  This variable simply defines the number of columns
to be used when displaying the list of available profiles on the
forum.

$UserProfilePicsDir:  If you allow your visitors to upload graphic
images to your server to be included with their profiles, define here
the path of the directory in which the images should be stored.
This directory, of course, should be accessible to Web browsers!
If you do *NOT* want to allow users to upload files to your server,
simply leave this variable undefined.  You do *not* have to allow
file upload in order to allow your users to create profiles

$UserProfilePicsURL:  If you allow your visitors to upload graphic
images to your server to be included with their profiles, define here
the URL corresponding to the directory defined in $UserProfilePicsDir.

$MaxGraphicSize:  If you’re allowing file uploads, define here the
maximum size (in kilobytes) of the graphic files that can be uploaded.

$ListAllProfiles:  If this variable is left set to 0, then the only
profiles which will be included in the list seen by visitors are
profiles for people who’ve actually posted at least one message on
the forum.  (This can be useful, especially if you have several
different forums sharing a single profiles directory.)  If you
prefer to have *all* profiles included in the list, even if no
messages have been posted under the user name, then set this
variable to 1.

$ListEmptyProfiles:  If this variable is set to 1, then all profiles
allowed by the $ListAllProfiles setting will be included in the
“View User Profiles” list.  This will of course include some
profiles which contain nothing but a user name and (perhaps) an
e-mail address.  If you want the list to be a bit more useful, you
can set this variable to 0.  If you do, then “empty” profiles –
those which contain nothing but a name and e-mail address — will
*not* be included in the list.  This can be especially helpful on
forums where profiles and e-mail addresses are required, since
the percentage of “empty” profiles will typically be rather high.
(Note that profiles are still accessible from individual messages;
this variable only determines whether or not they are listed in the
“View User Profiles” list.)

If you wish to allow users to upload images with their messages, you
need to define the following two variables.  Note that it is *strongly*
recommended that you not do so!  Even visitors without Web sites of
their own can upload pictures to any of a number of public servers
set up for the purpose.  Allowing your visitors to upload an effectively
unlimited number of graphic images to your server as they post messages
could result in problems as your disk space and bandwidth usage increase
accordingly.

$UserPicsDir and $UserPicsURL:  These variables are similar to the
$UserProfilePicsDir and $UserProfilePicsURL variables described
above, except that they define where pictures uploaded with messages,
rather than pictures uploaded with profiles, are to be stored.

The next group of variables define how your forum will look and act;
this is where most of the customization of your forum’s “personality”
will be done.

$MetaFile:  The path to a text file containing any HTML code (META tags,
etc.) to be inserted within the <HEAD> section of the pages produced
by the script.

$HeaderFile & $FooterFile:  The paths to text files containing HTML code
to be placed immediately following the <BODY> tag and at the very end
of the BBS index page.  These are included to allow you an easy way to
give your WebBBS index page the same “look” as the rest of your site’s
pages.  This header and footer are used only on the main message index
page.

$MessageHeaderFile & $MessageFooterFile:  The paths to text files,
similar to the above, containing code to be placed at the top and
bottom of the BBS message pages when the forum is *NOT* viewed with
frames.  You can use the same header and footer on these pages as you
use on the index page, or use different ones, or use none at all.
This header and footer are used on all individual message pages,
configuration pages, and administrative pages.  (In other words,
they’re used on everything *except* the main message index page.)

$FramedHeaderFile & $FramedFooterFile:  These variables serve the same
purpose as the $HeaderFile and $FooterFile variables, except that the
header and footer defined here will be used on the index page when
the forum is viewed using frames.  If you’re using horizontal frames,
there will usually be no need to define these variables, since the
header and footer files used on unframed pages will most likely work
just as well on a page seen in the upper frame.  However, if you’re
using vertical frames, you might want to structure your header and
footer differently depending upon whether they’re seen on an unframed
page or in the left-hand frame.

$FramedMessageHeaderFile & $FramedMessageFooterFile:  These variables
serve the same purpose as the $MessageHeaderFile and $MessageFooterFile
variables, except that the files defined here will be used on secondary
pages when the forum is viewed with frames.  There are two separate
pairs of variables, so that you can (for example) have your message
pages display the same header as your index page when frames are not
in use, to allow consistency of appearance, and yet *not* have that
same header information repeated in both frames when frames actually
are in use.

$SSIDebug:  WebBBS will attempt to interpret any SSI tags contained in
your header and footer files.  If you set $SSIDebug to 1, WebBBS will
print “SSI TAG NOT SUPPORTED” in place of any SSI tag (or anything
it *thinks* is an SSI tag) that it can’t interpret.  This will allow
you to easily spot any problems in your header or footer files.  For
normal operation of your forum, however, you can leave this variable
set to 0, to suppress such messages.

$bodyspec:  Any attributes (BACKGROUND, BGCOLOR, TEXT, etc.) which
should be assigned to the <BODY> tag in message posts. Do *not*
include in this variable a full <BODY> tag; include only the contents
*of* the body tag.

$fontspec:  Any attributes (FACE, etc.) which should be assigned to
a page-wide <FONT> tag.  Table cells will also be defined with the
same <FONT> tag, so that the page presents a uniform appearance even
in Netscape Navigator, in spite of the fact that that browser is too
stupid to realize that global <FONT> specifications *should* apply
inside tables as well as outside of them.

$navbarspec:  The attributes (BORDER, BGCOLOR, etc.) to be used in
the table containing the “navigation bar” at the tops and bottoms of
your pages.

$navbarfontspec:  Font specifications specific to the nav bar.

$navbaropen and $navbarclose:  In these variables, you define any
characters or code (such as brackets) which you want to have
“surrounding” the entries in the navigation bar at the top and
bottom of the WebBBS pages.

$tablespec:  The attributes (BORDER, BGCOLOR, etc.) to be used in
the tables used by the script for the “post form” boxes.

$tablefontspec:  Font specifications specific to the above tables.

$PrepostMessage:  If you want any special instructions or other
information to appear above the “post new message” form, simply
define it here.

$PreEmailMessage:  If you’re utilizing the “blind e-mail” feature
(described below), any text defined here will appear above the
“send e-mail” form.

$ListBullets:  By default, WebBBS (as of version 4.20) creates its
index listings with “unbulleted” lists, using the <DL> and <DD>
HTML tags.  If you prefer “bulleted” lists, set this variable to
1, and the script will instead use the <UL> and <LI> tags.

@SubjectPrefixes:  An optional list of “mandatory” subject prefixes.
If you’ve defined anything here, those posting on your forum will
have to pick one of your options, which will precede whatever they
enter as the subject of their message.  For example, if you want
an easy way to tell business-related from personal messages on your
forum, you might use “@SubjectPrefixes=(‘Business:’,'Personal:’);”
so that all message subjects end up beginning with either
“Business:” or “Personal:”.

$MessageOpenCode and $MessageCloseCode:  These variables should be
defined with any HTML code you want to appear before and after the
text of messages.  They can be used, for example, to place message
text within <BLOCKQUOTE> tags, or to highlight the text with a
different font and/or color than is used on the rest of your site.
$MessageCloseCode should, of course, contain “closing” tags for
whatever $MessageOpenCode opened.

$NewOpenCode and $NewCloseCode:  These variables should be defined
with any HTML code that you want to have appear before and after
“new” messages in the index listings.  By default, a red “NEW:”
will show up preceding the message subject in the index listing.
You might want to change it to call a graphic image, for example.

$AdminOpenCode and $AdminCloseCode:  Very similar to the above, these
variables should be defined with any HTML code that you want to have
appear before and after admin posts in the index listing.

$UseLocking:  Under most circumstances, this variable should be defined
as 1.  Set it to 0 only if, for whatever reason, your server doesn’t
support the flock() command.  (If this variable is set to 0, a
semaphore-based file locking will be used instead of flock(); while
it works reasonably well in most situations, it isn’t nearly as
efficient.)

$RefreshTime:  The number of seconds that the various “admin” screens
(“Your message has been posted,” etc.) will wait before sending a
visitor back to the main index.  If you’re displaying banners on the
pages, you’ll probably want to set this fairly high; otherwise, set
it low so that your visitors don’t have long waits.  If you define
this variable to 0, the pages will *not* auto-refresh at all.

$UseFrames:  This can either be set to “horizontal” (or “horiz” or “h”)
if you want an upper frame for the message index and a lower frame for
message texts, set to “vertical” (or “vert” or “v”) if you want side-
by-side frames, or left undefined if you don’t want to use frames at
all.  (Even if your forum is framed by default, a “remove frames”
option will always be available for those visitors who prefer not
to use them.)

$AllowFramesChoice:  This variable is used to determine what sort of
frames (horizontal or vertical) your visitors will use if they opt
for frames on a forum which is normally (by default) unframed.  (If
$UseFrames is set, this variable will automatically be set to the
same value.)  If you leave both this variable and $UseFrames
undefined, no option will exist for visitors to utilize frames when
viewing your forum.  However, there is absolutely no reason to so
restrict your visitors.  Frames allow for easier navigation, and
also help to reduce your site’s bandwidth and server resource
consumption.  Even if you don’t want to use frames on your forum
by default, you really should at least allow those visitors who
like them, to use them.

$BBSFrame:  If you’re using WebBBS with frames within another frameset,
you’ll want to define this with the name of the frameset in which
WebBBS is being displayed.  (The default definition of “_parent”
might also suffice, depending upon your setup.)

$WelcomePage:  If you’re using WebBBS with frames, you can define this
variable with the URL of a page you want to appear initially in the
WebBBS “message” window (which otherwise will initially be blank).

$Moderated:  If you set this variable to 1, any new posts will be put
“on hold” until approved by the administrator, rather than being
posted publicly immediately.  Note that in order to run a moderated
board, you *must* have the administrative script, as without it,
you’d have no way of approving the posts!

$SearchURL:  Generally speaking, this variable should be left undefined,
as the search facilities built into WebBBS are quite sufficient for
most any purpose.  However, if you’ve got a site-wide search facility
which includes the message content of your forum(s), and you prefer
that all searches be conducted through it, you can define this variable
with its location.  Anyone clicking on the “Search” option on a WebBBS
page will then be taken to *that* search form, rather than the one
generated by WebBBS itself.

$TopNPosters:  If this is defined (with a number), visitors to your
bulletin board will be able to access a list showing who’s posted
the most messages.

$Navbar_Links:  You may use this hash variable to define the names
and URLs of “extra” links you’d like to have appear in the main index
page navigation bar.  These could be links to FAQs or policies pages,
a link to an archive board, a link back to your main page, or anything
else you find relevant.  You can specify a TARGET destination for the
link by appending it to the URL, separated by a “pipe” (|) character.
If you do *not* specify a TARGET, the link will open in the window
used for display of messages.  The example below would put two new
links on the navbar: a link to a “welcome” page, which would be
loaded (by default) in the message window, and a link to a “help”
page, which would be loaded in the full browser window.

%Navbar_Links = (
‘Welcome’,'welcome.html’,
‘Help’,'help.html|_top’
);