Backtalk Installation Guide

Part VII: Backtalk Customization

Version 1.3.1

© 1996-2003 Jan Wolter, Steve Weiss

Prev: Part VI: (Cron Configuration


At this point your Backtalk system should be working, but you will probably want to customize it. This requires editing some configuration pages written in the Backtalk Script language, which is a bit weird. Simple configuration should be easy to do without help, but if you want to do anything more complex, it may help to read the Script Language Tutorial Manual.

(1) Edit the System Configuration File

A few of Backtalk's configuration settings live in the etc/backtalk.conf file. These are mostly settings that need to be used not only by Backtalk itself but by various helper programs, which don't necessarily have a script interpretor built in, and thus find config.bt hard to parse.

Many of these settings have to do with the SQL server configuration, and have already been set, if you are using them. There are a few others though.

(2) Edit the Global Configuration Script

Almost all Backtalk pages are generated by scripts written in the Backtalk script language, which is a stack-based language somewhat similar to Postscript. All scripts are installed in the script directory under the Backtalk directory. The script/config.bt script is a header script run before every other Backtalk script. Many global settings are defined here. You will probably want to change at least some of them.

Note that lines starting with '%' are comments. Most options are described in details by the comments in the file.

  1. Edit the automatic recompilation flag. Look for the line
     
       /auto_recompile 2 def
     
    This controls what checks Backtalk does to decide if a script needs to be recompiled. It is set to 2 by default, which means that every time Backtalk runs a script, it first checks the last update times of all source scripts and automatically triggers a recompilation if any are newer than the compiled script. This is nice because it means any changes made to the scripts will be instantly reflected on the web pages, but it does have a small performance penalty.

    If you aren't going to be updating your scripts much or if your processor is unusually slow, changing it to 1 is a good choice. Then only the date of the main configuration script config.bt will be checked.

    If eventually your system configuration gets stable enough that you aren't going to be making changes to the config.bt file, and if you want to make Backtalk run a wee bit faster, you may eventually want to change it to 0, but this is probably not worth the effort.
     

  2. Edit the system name. Look for the line
     
       /bbsname (SITE-NAME) defconstant
     
    and change the portion in parenthesis to the name of your conferencing system. It can have spaces in it. For example, if you conferencing system is to be called "Star Forum" you might set this to
     
       /bbsname (Star Forum) defconstant
     
  3. Set up your system's logo. Backtalk allows you to define an image to use as a logo for your conferencing system. You can define two different logo images. The standard logo should be about half a screen wide, maybe 250 to 400 pixels. You can also define a wide logo, intended to be about as wide as a screen, maybe 600 to 800 pixels wide. However, none of the standard interfaces actually use this, so unless you are installing other interfaces, you needn't bother with that.
     
    Create the logo image as a .gif, .jpg or .png file and store it in the image directory under Backtalk's home directory (where backtalk.jpg already is). Look for the lines
     
       /logo imghost(/backtalk.jpg)+ defconstant
       /logo.h 125 defconstant         % height of logo
       /logo.w 285 defconstant         % width of logo

     
    and replace the (/backtalk.jpg) part with the name of your logo image file, replace 125 with the height of your image, and replace 285 with the width of your image. For example, if your logo is a 200 by 400 pixel GIF file named `starforum.gif', then you'd change these lines to
     
       /logo imghost(/starforum.gif)+ defconstant
       /logo.h 200 defconstant         % height of logo
       /logo.w 400 defconstant         % width of logo

     
    Actually, the image doesn't have to be under the image directory. You can give arbitrary URLs, by doing something like:
     
       /logo (http://www.mysite.com/picts/starforum.gif) defconstant
     
    If you want the image to be clickable, then find the line that says
     
       %/imageURL (http://localhost) defconstant
     
    uncomment it by deleting the initial percent sign, and change the `http://localhost' part to the URL that you want people sent to if they click on your logo image.
     
  4. Who may Create Accounts? By default, Backtalk is configured to allow random people coming in off the net to create Backtalk accounts simply by filling out the registration form, and immediately start using those accounts. This can be changed by editting the configuration file line that looks like:
     
       /newuseropen 2 defconstant
     
    If you change the newuseropen value to '1', then people will still be able to create accounts with the same public form, but the accounts will be created in an "unvalidated" state, and will not be usable until an administrator has "validated" them (this can be done through the web interface).
     
    If you change the newuseropen value to '0', then it will no longer be possible to create accounts using the public newuser form. Accounts will only be creatable by adminstrators.
     
  5. Should Email Addresses be Validated? By default, Backtalk does no email address validation. But if you change value in the
     
       /validatemail 0 defconstant
     
    line to 1 or 2, then Backtalk will automatically send an email message to users who have filled out the registration form. The message will contain a URL with an imbedded validation code. When the user's click on that URL, Backtalk will record the fact that their email address is validated.

    If validateemail is set to 1, all it does is record that the email addresss is validated. It does not change the validation state of the account. This could be used with a newuseropen setting of 1 or 2.

    If validateemail is set to 2, then the account will be automatically validated when the email addresses is validated. This only makes sense with a newuseropen setting of 1.

    Note that by default the registration form does not require that email addresses be entered. If you want to do email address validation, you'll probably want to edit the lib/userinfo.bt configuration script to flag the email question as a "required" one.

    Obviously none of these options work unless Backtalk has been configured to send email.
     

  6. Should Unauthenticated Reading be Allowed? By default, Backtalk is configured to allow users who have not authenticated, and possibly don't have accounts, to read all open conferences anonymously. They can't post, and the system won't remember what they have seen, but they can observe. If you would like to disable unauthenticated reading entirely, so that only people with accounts may read the conferences, then edit the line that looks like:
     
       /allowanon 1 defconstant
     
    Just change the 1 to a 0.
     
  7. Should Unauthenticated Posting be Allowed? By default, Backtalk conferences do not allow users who aren't logged in to post items or responses. If you want to enable this, you'll need to set up appropriate acl files in each of the conferences you want it to work in and uncomment the anonposter definition in config.bt. This definition gives the name of the backtalk account that is to be used as the owner of all anonymous postings. If you uncomment this, you should create a backtalk account by that name. The full name on that account will be the default name for all anonymous posters. So you could set it to something like:
     
       /anonposter (anonymous) defconstant
     
    Then create that account witht that name, and forget the password (since you'll never want anyone to actually log into this account).
     
  8. Set Author Powers Different systems have different ideas of what kinds of editing powers the person who originally posted an item should have over that item. These are configured with the settings below:
     
       /author_freeze  1 defconstant
       /author_kill    1 defconstant
       /author_retire  1 defconstant
       /author_retitle 1 defconstant
       /author_erase   1 defconstant
       /author_hide    1 defconstant
       /author_edit    0 defconstant

     
    They are all normally enabled by default. You can disable them by changing the 1's to 0's.
     
    The author_freeze option, if enabled, allows the original poster of an item to freeze it, so that no further postings can be made to it by other users.
     
    The author_kill option, if enabled, allows the original poster of an item to delete it so long as no responses have yet been made by other users. If other people have responded to an item, then it cannot be deleted by the author, even if author_kill is enabled.
     
    The author_retire option, if enabled, allows the original poster of an item to retire it, so that it is no longer displayed to users who ``read new'' or ``read all'' but can still be seen by people who explicitly request to see it.
     
    The author_retitle option, if enabled, allows the original poster of an item to edit the title of the item.
     
    The author_erase option, if enabled, allows the original poster of a response to erase that response at a later date. (Normally copies of erased responses are logged.)
     
    The author_hide option, if enabled, allows the original poster of a response to hide that response at a later date. Hidden responses aren't displayed unless the reader makes an extra mouse click. Disabling this would be a bit weird.
     
    The author_edit option, if enabled, allows the original poster of a response to change the text of that response at a later date. (A copy of the previous text is logged.) If attachments are enabled on the system, it also allows addition, deletion and editing of attachments on previously posted messages. Some people think this disrupts the flow of the conversation, but some sites seem to enable it without many problems ensuing. It defaults off.
     
  9. Set Fairwitness Powers Different systems have different ideas of what kinds of editing powers that conference hosts should have. (Conference hosts are traditionally called ``fairwitnesses'' in Backtalk. They are users appointed by the system administrator to oversee one particular conference.) These are configured with the settings below:
     
       /fw_erase   1 defconstant
       /fw_hide    1 defconstant
       /fw_retitle 1 defconstant
       /fw_edit    0 defconstant

     
    They are all normally enabled by default. You can disable them by changing the 1's to 0's.
     
    System administrators always have all of these powers. Fairwitnesses can always freeze, retire, and kill items.
     
    The fw_erase option, if enabled, allows the fairwitnesses to erase other user's responses to items in their conferences. The erased text is logged so it can be recovered, but becomes inaccessible to other users.
     
    The fw_hide option, if enabled, allows the fairwitnesses to hide other user's responses to items in their conferences. Hidden responses are not normally displayed to users, but they can see them with one extra mouse click if they want.
     
    The fw_retitle option, if enabled, allows the fairwitnesses to edit the titles of items in their conferences. This may be useful if the author chooses undescriptive titles, or the conversation drifts into other topics.
     
    The fw_edit option, if enabled, allows the fairwitnesses to edit the content of items and responses posted by other users. The original content is logged. We think letting someone change someone else's words is a horrible idea, so this option defaults off, and we strongly discourage turning it on.
     
  10. Disable Editing Frozen Items? By default, Backtalk allows you to do operations like erasing, hiding or editing responses on a frozen item without thawing the item first, if you have the power to thaw the item. These are implemented by briefly thawing the item and then quickly refreezing it. This might open a brief window in which a frozen item might appear unfrozen to other users. If this worries you, you can disable this behavior, so that operations cannot be performed on frozen items.
     
  11. Hide User's Names and Personal Info? Some systems, notably those with users who are minors, don't want to publish their user's names and personal information on the web. Backtalk can be configured to identify users only by their login IDs, not by their full names and to suppress display of other personal information. There are two kinds of names whose visibility is controlled by the anonymity setting: the user's "real" name saved in the user database, and the name or alias that the user attaches to postings he makes. The different anonymity levels are:
     
    Anonymity  Who can see full names:   Who can see response names:  

         0     everyone.                 everyone.
         1     authenticated users only. authenticated users only.
         2     admins only.              current conf fairwitness only.
         3     admins only.              admins only.

     
    Level 0 is the default. You can set other levels by doing something like:
     
       /anonymity   1 defconstant
     
  12. Allow HTML Postings by Default? With Backtalk fairwitnesses (conference hosts) can decide if HTML is to be allowed in postings to their conferences. The dflt_html switch sets the default value for conferences where the fairwitness has not set the option. It is initially set to 1. Set it to 0 to disable HTML by default. Note that only a safe subset of HTML is allowed, and if you are sharing conferences with Yapp or Picospan, Backtalk automatically filters the HTML out of the versions of the postings that they will display.
     
  13. External Links in New Windows? Messages posted to Backtalk by users often contain URLs of other sites on the web. Backtalk will generally make most of these clickable. By default, Backtalk will create the links in such a way that clicking on them causes the linked page to come up in a new window, instead of replacing the Backtalk screen in the original window. If you'd prefer more normal link behavior, set linktonew to zero and the pages will be loaded into the same page instead.
     
  14. Show server's motd file? If you want the web interface to display your system's /etc/motd file, then you should uncomment the line:
     
       %/show_motd 1 defconstant
     
    by removing the percent sign from the front. This is most often used on installations with real Unix logins. If this is not defined, then Backtalk will instead display the motd.html file found in the bbs directory. This is specific to Backtalk and can contain HTML tags.
     
  15. Display user's .plan files? If you want to store user's personal information in their .plan files instead of in their .backtalk files, then you should uncomment the line:
     
       %/useplan 1 defconstant
     
    by removing the percent sign from the front. This is most often used on installations with real Unix logins.
     
  16. Acknowledge a Text Interface? If you are setting up Backtalk to share conferences with Picospan or Yapp, you should define the text_interface constant to the name of that system, either:
     
       /text_interface (Picospan) defconstant
     
    or:
     
       /text_interface (Yapp) defconstant
     
    or:
     
       /text_interface (Fronttalk) defconstant
     
    Otherwise, just leave it commented out:
     
       %/text_interface (Picospan) defconstant This will cause Backtalk to display a plain text version of their posts as well as an HTML version when they preview it.
     
  17. Use public.txt as the Conference List? If you are setting up Backtalk to share conferences with Picospan or Yapp, then the usual place to store the list of conferences is in a text file named "public.txt". Backtalk strongly prefers to use a more rigidly formatted file named "confmenu", but if you want to be compatible with Picospan, you should uncomment the line:
     
       %/usepublic_txt 1 defconstant
     
    by removing the percent sign from the front. There is no universal standard for the format of the public.txt file. To enable Backtalk to be able to parse yours, you need to supply a pair of regular expressions, as decribed in config.bt. Or just use the default Grex-style format, making sure your file matches the format described in the Administrative Guide for Conference Creation.
     
  18. Do you have Many Users on a Slow Machine? If your system has a somewhat slow computer, and you expect to have many thousands of users, you should probably turn on the many_users switch. This tells the scripts to avoid doing things like loading the full list of users into memory and sorting it before displaying it, which are nice on a small installation, but impractical on a large one. To set this flag, edit the line:
     
       /many_users 0 defconstant
     
    Change the default 0 value to 1 if you expect to have too many users.
     
  19. Do you have Shy users? If you have anonymous reading but some of your users don't want their responses read by unregistered users, then Backtalk supports a "shyfile" facility where particular user's responses are hidden from unregistered readers. If you want to use this, uncomment the line
     
       %/shyfile (/usr/local/backtalk/etc/shylist) defconstant
     
    by removing the percent sign from the front, and change the path name in the parenthesis to the place where you want to have your shylist saved.
     
  20. What is the URL of the Account Registration Form? This is the page you would like people who want an account directed to. By default it points to the standard Backtalk account creation form, which is probably fine for most sites. If you are using a non-Backtalk tool to create accounts, edit this to point to it.
     
  21. What is the URL of the User Bio Page? If you are using a non-Backtalk program to create accounts, then it is possible that user profile information is stored away in some database that Backtalk doesn't understand. You'll want to use an external program to find and edit user profiles. To do this, uncomment the definition of the extern_bio flag and edit the script/lib/biolink.bt file.

    Note that this option does not (yet) work with the pistachio interface, although abalone, bubblegum and papaya understand it.
     

  22. May Robots Index the Conferences? Not all clicks on your web site will come from human beings running web browsers. There are lots of computer programs called "robots" or "web spiders" wandering around the web collecting information. Search sites like "Google" have robots continually updating their indexes by searching the web. Spammers have robots that search the web for email addresses to add to their mailing lists. Occasional poorly designed robots will hammer a site with many requests in a short period of time.

    Most robots are well-behaved and useful. If you don't mind robots indexing your site, you need do nothing. Skip to the next section. However, if you don't all of your site to appear in things like the Google index, then read on.

    There are two standard methods for requesting that robots not index your site. One involves placing a "robots.txt" file in your document root directory. For instance, we used the following "robots.txt" file on Grex to prevent robots from indexing Backtalk or any other program installed in the system CGI directory:
     
       User-agent: *
       Disallow: /cgi-bin/

     
    For more information see sites like Robotstxt.org.

    The other method is to generate special headers on each page that tell whether or not it is OK to index that page. Backtalk's interfaces are able to generate such headers, if you set the confrobots and biorobots switches.

    If biorobots is set to 1, then all user bio pages and lists of user id's will be generated with a header saying robots should not index them. If confrobots is set to 2, then all item pages, lists of items in a conference, and lists of conferences will have exclusion headers. If confrobots is set to 1, then each conference fairwitness can set whether or not robots are allowed in his conference (the default is not to allow them). The list of conferences will always be indexable.

    Obviously, there is no guarantee that all robots will respect the "robots.txt" file or the headers, but all the respectable ones do. If you don't want any indexing, I recommend doing both the "robots.txt" and the headers. If you want partial indexing the headers alone are your best bet.
     

  23. What Languages Does Your Spell Checker Support? If you are using aspell or ispell for spell checking you should provide a list of the different dictionaries you have.

    Ispell comes with standard dictionaries for american and british english. Many others exist. You might give them in the languages constant. For example,
     
       /languages (american,british,russian,polish) defconstant
     
    The default language is whatever you get when you run aspell or ispell without designating a language.

    Older versions of Ispell seem to have dictionary names similar to ispell dictionaries. Newer aspell dictionary names are usually combinations of language and country codes. For example,
     
       /languages (en_US,en_GB,en_CA) defconstant
     
    Aspell isn't distributed with any dictionaries, so installations vary a bit in what dictionaries they actually have. For aspell versions after 0.50, the command 'aspell dump dicts' should give you a list of all the installed dictionaries.
     

  24. Enable Syndication? With the optional 'cinnamon' interface installed, Backtalk is able to generate RSS and/or Atom syndication feeds. For more information on how to configure these, see the RSS documentation.

    One warning though: enabling syndication can add a lot of server load. Normal web pages get hit only when users look at the pages, but RSS feed pages get polled regularly by every person who subscribes to that feed. This can add to a lot of traffic and a lot of load on your server.
     

  25. Set up a Favicon? Many browsers (Internet Explorer 5, Mozilla, Firefox and Konqueror) like to request an tiny icon image called 'favicon.ico' from web sites. This may be displayed in location bar, in tabs, or in the bookmark list. Normally backtalk responds to all such requests with an empty document. If you have a custom .ico file for your site that you would like sent, set the favicon variable to to the full path of that file. Visit www.favicon.com for more info on favicons and how to make them.
     
  26. Enable Posting Logs? Backtalk can optionally keep a log file that contains a one line description of each item or response posted. The main use of these is to support showing lists of "most recent postings" in the interfaces that support them. There is little use in enabling these logs if you are also running Picospan or an older version of Yapp that does not generate such logs, because messages posted through those systems won't be logged.

    Warning: Post logs currently include postings from all conferences, including private conferences. This may enable other users to see item titles and participant names from private conferences. If this is a problem, don't enable post logs. In the future we'll probably figure out a way to enable/disable them on a per-conference basis.

    If you are running Backtalk in a stand-alone configuration, then enabling a Backtalk-format postlog file might be nice. Uncomment the lines defining post_log_file and bt_post_log.

    If you are running Backtalk with a newer Yapp installation that maintains a posting log in /usr/bbs/resplog, then you might want the Yapp-compatible format. Uncomment the three lines, and edit the URL to the URL for the cgi-bin directory for web Yapp on your system. Using this format should be avoided unless you are actually sharing conferences with Yapp.

    Other formats can be supported if you edit lib/postlog.bt and lib/readpostlog.bt.

    To actually get listings of recent items on the web pages, you may have to edit the pistachio and abalone config.bt files as described below.
     

  27. Use web Yapp Compatible Response Formatting? If you are sharing the conference between Backtalk and web Yapp, then something needs to be done to deal with the fact that Yapp treats all responses as HTML (appending a <BR> to each line), while Backtalk treats some as plain text and others as HTML (with appending <BR>). If run in the default configuration, this can make Backtalk postings look bad in Yapp, and Yapp postings look bad in Backtalk.

    To fix this problem, set the yapp_formats constant to 3. This will change the way Backtalk posts its messages and interprets messages so that most postings will look pretty much alike in both programs. The stuff this does is a somewhat horrible kludge and should be avoided if you are not using Backtalk with web Yapp. It is not needed if you are using Backtalk with command-line Yapp, but not web Yapp.
     

  28. Configure Session Settings. If you built Backtalk with the --login=cookies option, then you may want to alter the settings that control how sessions.

    One setting controls how long a user can go without sending a request before we expire his session, forcing him to re-login before his next request will work. You don't want this too long, as it increases the chance of someone else being able to access a user's account if they leaves their computer without logging out. You don't want this too low, otherwise people have to re-login every time they enter a longer post.

    You can also alter the page that the user is sent to when they log out.
     

  29. Does your Server Use an HTTP Proxy? Sometimes Backtalk actually sends HTTP requests instead of serving them. This is currently mostly used with the 'tobacco' interface which does Trackbacks and Pingbacks. If you are using this, and if your server is configured so that outgoing HTTP requests need to be sent through a proxy, then set the http_proxy variable. For example:
     
       /http_proxy (proxy.mysite.com:80) defconstant
     
    Here the part after the colon is the port number, and can be omitted if it is port 80.
     
  30. Ignore Debug Settings for Now. The saverep and secure settings can be extremely useful for debugging Backtalk. However, changing them from the default configuration can also open substantial security holes. So until you want to be able to rerun Backtalk queries under a debugger like 'gdb' just leave these alone, and if you do ever change them, be sure to change the back when you are done debugging.
(3) Edit Pistachio Configuration Script
 
The Pistachio interface is an older style user interface. It consists of a set of scripts. It has it's own configuration file, where there are a few settings you may want to alter. The file is installed under the Backtalk directory at script/pistachio/config.bt.
 
If editing this file seems to have no effect, remove all the "script/pistachio/*.bb" files. If the automatic recompilation flag above is not set to 2, Backtalk will not automatically recompile scripts after they have changed, and will instead keep using the old compiled copy. Deleting the compiled scripts is a sure way to force them all to be recompiled.

  1. Edit the default background. Each conference fairwitness can set a different background for their conferences. The background defined here is used for conferences with no defined background, and for other, non-conference pages.
     
    The default background color is ugly, so changing it should be a priority for administrators of good taste.
     
    You can also define a background image. This is very rarely a good idea. Background images are often hard to read text on, and a lot of people will be reading a lot of text on the background you choose.
     
  2. Edit the text colors. Unless you are using a very dark background color, the default text colors should be fine.
     
  3. Edit the default button style. Again, probably just leave it be for now.
     
  4. Edit the global page header. This is some HTML that is inserted at the top of every Pistachio page. The default is nothing. This can be used for ad rotators and such (yick). You should also set global_header_height to the approximate height in pixels of the page header. This is used to enlarge the size of the top frame on read pages enough to hold both the header and the buttons.
     
  5. Edit the global page footer. This is some HTML that is inserted at the bottom of every Pistachio page. The default is a Backtalk copyright message in small print. You are welcome to take that out (though we would prefer that you display the copyright someplace, it doesn't have to be on every page) and replace it with anything you like.
     
  6. Set default values for numbers of recent postings. If you enabled post logs by uncommenting the definition of post_log_file in the top-level config.bt file, then Pistachio will be able to show lists of recent postings. These are available in two places - on the entrance page and on a separate page accessible from the entrance page via a button.

    The dflt_recent_entrance setting is the default number of most recent messages to list on the entrance page. If it is zero, they are not listed. Users can override this setting from the options page.

    The dflt_recent_page setting is the default number of most recent messages to list on the separate page. If it is zero, the separate page is not available. If it is positive, users will be able to enter other values.
     

  7. Edit the default item list type. Pistachio can display four kinds of item lists:
         new      - only items with new responses
         current  - all items not forgotten or retired
         all      - all items
         forgotten- only forgotten or retired items


    You can configure which of these is the default that will be shown to users when they click on the "item list" button (later they can select whichever they want). Only the new and current options are really very sensible. To change this, edit the line that looks like
     
       /dflt_item_list (new) defconstant
     
  8. Edit names for things. Backtalk's terminology, in which "confernces" are managed by "fairwitnesses" and contain "items" consisting of many "responses," has the virtue of long tradition. However, everyone seems to have their own idea what things should be called. Some people like "fairwitnesses" to be "hosts" or maybe "moderators". Some people think "conferences" should be "forums" or "rooms" or "channels" or "departments". Some people think "items" should be "topics" and "responses" should be "postings" or "comments". Other people other ideas.
     
    So pick your terminology, and configure it into the interface, and excuse us for continuing to call things by the same old names in our documentation. (Although your new terminology will appear in online help files.) Look for the following lines:
     
       /Fairwitness (fairwitness) defconstant
       /AFairwitness (a fairwitness) defconstant
       /Fairwitnesses (fairwitnesses) defconstant
       /Item (item) defconstant
       /AnItem (an item) defconstant
       /Items (items) defconstant
       /Conference (conference) defconstant
       /AConference (a conference) defconstant
       /Conferences (conferences) defconstant
       /Conf (conf) defconstant
       /Response (response) defconstant
       /AResponse (a response) defconstant
       /Responses (responses) defconstant
       /Resp (resp) defconstant
       /Erase (erase) defconstant
       /Erased (erased) defconstant
       /Hide (hide) defconstant
       /Hidden (hidden) defconstant
       /Show (show) defconstant
       /Unseen (unseen) defconstant
       /MarkUnseen (Mark Unseen) defconstant

     
    Edit the parts in parentheses to your favorite terms. You terms should be all lower case (except MarkUnseen which should be capitalized). The scripts will take care of capitalizing them where necessary. I recommend against using multi-word phrases for these things, partly because it's clumsy, partly because the capitalization may not work right.
     
    Note that there are three definitions for most terms - singular, plural and singlar with an article. So if you want to rename 'items' to 'topics' you'll need to change three lines, like this:
     
       /Item (topic) defconstant
       /AnItem (a topic) defconstant
       /Items (topics) defconstant

     
    Note that a lot of these terms appear in the default Pistachio buttons too. Changing the definitions here will not, of course, change the buttons image files. So you may have to spend (a lot) of time manufacturing new buttons if you want to change the terminology.

(4) Edit Abalone Configuration Script
 
The ``abalone'' interface is a newer, prettier, slower Backtalk user interface. It consists of a set of scripts. It has it's own configuration file installed under the Backtalk directory at script/abalone/config.bt. Currently that file is very like the Pistachio configuration file.

If editing this file seems to have no effect, remove all the "script/abalone/*.bb" files. If the automatic recompilation flag above is not set to 2, Backtalk will not automatically recompile scripts after they have changed, and will instead keep using the old compiled copy. Deleting the compiled scripts is a sure way to force them all to be recompiled.

  1. Edit the global page header. This is some HTML that is inserted at the top of every Abalone page. It works exactly like the same option in Pistachio.
     
  2. Edit the global page footer. This is some HTML that is inserted at the bottom of every Abalone page. It works exactly like the same option in Pistachio.
     
  3. Edit the Colors. Abalone uses the same color scheme everywhere (unlike Pistachio, which allows it to be set differently in different conferences). You can choose one of these as the default by editing the config file line:
     
       /default_scheme (coffee) defconstant
     
    Current color schemes are 'coffee', 'blue', 'openforum', dark', or 'bright'.
     
    You can create new color schemes by creating new style sheets. See the css/abalone/README file for more information.
     
  4. Edit style sheet inclusion method. There are three different ways an HTML document can include in a style sheet. Abalone can do any of them. You can choose one from the config.bt, but for the most part, the default should be fine.
     
  5. Edit numbers of recent postings to show. Just as in Pistachio, you can edit the numbers of recent postings to show by default.
     
  6. Edit names for things. Just as in Pistachio, you can edit the names used for 'fairwitness', 'conference', 'item' and 'response'. This works exactly as in Pistachio. In a way, it works better - since Abalone doesn't use buttons with words in them, you can change the terminology without having to make new buttons.

 
(5) Edit Admin Configuration Script
 
The ``admin'' interface is a set of administrative tools. It is hardly configurable at all. The only case where you'd want to edit its configuration file is if you are removing the Pistachio interface from your system, in which case you'll want to edit script/admin/config.bt to designate a different interface to jump into when a user clicks on the name of a conference.
 
That's all. Happy Backtalking.
Prev: Part VI: (Cron Configuration