The config.php file
The config.php file content is generated by the installation script. It's NOT in the download packages.
The config.php file, located in your /global
folder contains the unique settings for your Form Tools
installation: your database connection settings, root folder and URLs and other information. This file is the
only file in the script that should be customized.
The installation script will create this file for you on your server - or provide manual instructions if it
doesn't have the permissions - but the following sections outline all settings for file, beyond those that
are included in the generated file.
Required Settings
$g_root_url
This is the base URL of the Form Tools installation on your server. e.g.
http://www.yoursite.com/formtools. You can either supply an absolute or
relative URL. Note: if you include the full URL, make sure that the "www." part
is either included or removed consistently; if you try to log in at
http://www.yoursite.com/admin but your $root_url is set to
http://yoursite.com/admin it will not work! (and vice versa).
$g_root_dir
The server directory path to your Form Tools folder.
$g_db_hostname
The database hostname (often just 'localhost').
$g_db_name
The name of the database. Most often, hosting providers provide you with some sort of
user interface for creating databases and assigning user accounts to them. If you are
creating a new database for Form Tools, I would recommend "form_tools" for clarity.
Enter the database name here.
$g_db_username
The MySQL username. Note: this user account must have privileges for creating new
tables, in addition to adding and removing records.
$g_db_password
The MySQL password.
Optional Settings
$g_table_prefix
This value lets you define a custom database prefix for your Form Tools tables. This is handy if Form Tools
will be added to an existing database and you want to avoid table name conflicts. By default it it set to
ft_
. If you do not need to use a different value, you needn't define it in your config.php
file: it is already defaulted to ft_ in your library.php file. Even though this is optional, it's such a
commonly
overridden setting it's generated in the installation script.
$g_default_error_reporting
This controls the level of warnings you'll see output to the screen. For beta and main releases, this is
set to 1
by default, meaning that only genuine PHP errors are displayed. For alpha releases, this
is set to 2047
: all errors and warning are displayed, which can help identify issues and aid
debugging.
$g_custom_cache_folder
This was added in 3.1.5. Form Tools uses a cache folder to generate temporary files; up until 3.1.5 there were
multiple cache folders, one per theme. Now there's a single one located here: [form tools root]/cache/
.
If you would like to customize this location, e.g. for security reasons to place it outside your webroot,
just enter this setting. It should contain the full path to the folder. Note: you will need to create the
folder yourself and give it full read-write permissions.
$g_max_nav_pages
This controls the maximum number of pagination links that appear in the Form Tools UI (e.g. for viewing the
submission listings page).
$g_debug
When this setting is set to true it provides more detailed, technical reasons for some errors that occur.
$g_smarty_debug
When enabled, this option pops open a Smarty console for each webpage, displaying the contents of variables
available on the page.
$g_smarty_use_sub_dirs
This tells Smarty to create the compiled templates in subdirectories, which is
slightly more efficient. It's not compatible on some systems, so it's set to false
by default.
$g_query_str_multi_val_separator
This determines the value used to separate the content of array form submissions (e.g. checkboxes in your
form that have the same name, or multi-select dropdowns) when submitted via a query string for "direct"
form submissions (added in version 1.4.2). Defaults to ,
.
$g_session_type
This controls the type of sessions the application uses. The default value is php
, but you can
change it to database
if you'd rather use database sessions. This affects all Form Tools accounts
and determines the session type for forms that are integrated with the API. If you are running Form Tools
using a load balancer without sticky sessions you'll want to set this to database
.
$g_session_save_path
This setting was added in 2.0.0-beta-20090614. It lets you define the location where temporary PHP
sessions files should be created. Generally you won't need to define this value, but some hosting providers
require that you do so in order to use sessions.
$g_api_debug
This enables debugging for the API functions. Generally this just causes the database errors and other
messages to be outputted along with the problem error code. Enabled by default.
$g_api_recaptcha_public_key
Used in the following methods when displaying a CAPTCHA in your form. Please see that function for more
information.
$g_api_recaptcha_private_key
Used in the following methods when displaying a CAPTCHA in your form. Please see that function for more
information.
$g_api_header_charset
This setting determines the header charset sent by the following API methods. Defaults to
utf-8
.
$g_api_sessions_timeout
Determines how long sessions last for the API. This value defaults to 1 hour (3600 seconds).
$g_filename_char_whitelist
Allowed characters in a filenames uploaded to Form Tools. All other characters are stripped out. By default
the allowed characters are a-Z, _ and 0-9 but you
can override it by setting this value in your global/config.php
file.
$g_password_special_chars
Special characters that are required in passwords to help make them more secure (optional setting through
interface).
$g_password_history_size
Form Tools keeps track of passwords for each user, to (optionally) prevent users from re-using a password that
they used before. Defaults to 10. N.B. this maps to the password_history
setting in the
settings table.
$g_search_form_date_field_format
In Form Tools 2.1.0, when you search on a date field on the main Submission Listing page, you will see a
javascript dialog window to let you search by range, before a date, etc. This setting controls the format
of that date. This is deliberately simple: you have only two options: d/m/y and m/d/y.
$g_max_ft_forms
Added in 2.2.3, this setting limits the Form Tools installation to only manage the number of forms
specified here. This feature is disabled by default.
$g_max_ft_form_fields
Added in 2.2.3, this limits all Form Tools forms to a certain number of fields. This feature is disabled by
default.
$g_use_smarty_bc
Added in 3.0.1, this tells Form Tools to use the SmartyBC (Smarty Backward-compatibility) class instead
of Smarty for all template rendering. The SmartyBC class lets you use {php}
and
{include_php}
in your smarty templates - something that was removed in Smarty 3.
$g_sql_strict_mode
Defines the SQL strict mode for database queries. Added in 3.0.2. This is a string with any of the following
values: "on", "off", "default".
Form Tools 2 settings
The following settings were removed in Form Tools 3.
$g_db_ssl
This should be set to true if you want to make a secure connection to the
database server.
$g_unicode
This offers support for unicode. All form submissions will be sent as UTF-8. This
is enabled for all new installations.
$g_check_ft_sessions
This setting should be enabled prior to including this file in any external script that doesn't require
the person to be logged into Form Tools. The API, for example, automatically sets this to false. This lets
you leverage the Form Tools functionality in the outside world without already being logged into Form Tools.
With Form Tools 3, to achieve the same thing you would require() the global/library.php
file,
then initialize the Core, specifying that sessions should be enabled or not, e.g.:
Core::init(array("start_sessions" => false));
$g_delete_module_folder_on_uninstallation
For module developers. This prevents the code from automatically deleting your module folder when you're
testing your uninstallation function. Defaults to TRUE, but doesn't work on all systems: sometimes the PHP
doesn't have the permission to remove the folder.