Text
A basic text field which is normally stored in a VARCHAR column in the database. Contains formatting and validation options for name, address, email and URL. Text field types are stored in the database with HTML characters encoded (you do not need to run htmlspecialchars when outputting them in your templates).
Textarea
A basic textarea for larger blocks of text which is normally stored in a TEXT column in the database. This field type is identical in behavior (HTML characters are encoded) to the Text field type with the exception of drawing a larger area for input.
HTML Area
A textarea with an advanced WYSIWYG editor normally stored in a TEXT column in the database. Gives normal users the ability to format text through a 'Word-style' interface. Includes validation options, a 'simple' and 'full' mode. The HTML Area field type is not HTML character encoded (HTML tags are included when using data from this field type in your templates).
Upload
An upload field with options for image cropping and creating thumbnails which is normally stored in a VARCHAR colum in the database. The stored value houses the full path to the image (i.e http://ww.yoursiite.com/files/documents/my-file.pdf).
List
A select box populated either via a manually entered list of options or from another table in the database. List fields are typically stored in a VARCHAR column in the database.
Checkbox
A basic checkbox which stores its value as either 'on' or ''. Checkbox fields are typically stored in a CHAR(2) column in the database.
Date Picker
A calendar style date picker widget. Date Picker fields are typically stored in a DATE column in the database.
Time Picker
A draggable time picker widget. Time Picker fields are typically stored in a TIME column in the database.
Date & Time Picker
A calendar style date picker with a draggable time picker. Date & Time Picker fields are typically stored in a DATETIME column in the database.
Photo Gallery
A set of images grouped as a gallery which includes options for image cropping and creating thumbnails. The photo gallery data is stored in the database as a JSON-encoded object and is returned in templates/module class calls as an array. Photo Gallery fields are typically stored in a TEXT column in the database.
Array of Items (OBSOLETE)
A unique field that allows developers to define 'items' through a set of other field types. Users then add, delete and reorder these 'items' by interacting with the widget. This data is stored in the database as a JSON-encoded object and is returned in templates/module class calls as an array. Array of Items fields are typically stored in a TEXT column in the database. This field type was made obsolete and no longer available in BigTree 4.2 — it's functionality is incorporated into the Matrix field type.
Matrix
The Matrix field type allows you to create repeatable sets of content. For instance, you can create a set containing a title and description field made of the Text and Textarea field types. You can use any field type that is set to be allowed in a Callout when building your Matrix field. Matrix fields are typically stored in a TEXT column in the database.
Callouts
The Callouts field type allows you to pull Callouts into your template / form / setting. You can choose which callout groups to allow in a given field (or allow them all). Callouts fields are typically stored in a TEXT column in the database.
Generated Route
A generated route will produce a URL friendly string based on a specified text field, usually the title of the item, to be used in routed templates. This could be used for news items stored in a module, creating the generated route from the news title for use in the URL string. Generated Route fields are typically stored in a VARCHAR column in the database.
Many to Many
The Many to Many field type allows you to create relationships between two tables via a third connecting table. A good use case for this is associating categories to a news article. We'll work with that example assuming we have the following tables: demo_news, demo_categories, demo_news_categories.
demo_news
id - INT(11) - PRIMARY KEY
title - VARCHAR(255)
description - TEXT
demo_categories
id - INT(11) - PRIMARY KEY
title - VARCHAR(255)
demo_news_categories
news - INT(11)
category - INT(11)As you can see, the connecting table doesn't require an id column like other module tables do. If for some reason you wanted to use that table for a module it would need an id column added. It's also advised that you setup foreign keys for the news and category columns to demo_news' id and demo_categories' id columns with ON CASCADE DELETE so that you don't have leftover data when a news article or category is deleted.
When fetching this relationship you will need to manually build SQL queries — the BigTreeModule class does not provide methods for pulling Many to Many relationships. Example code for pulling all the categories for a news item is below:
$categories = array();
$q = sqlquery("SELECT demo_categories.* FROM demo_categories JOIN demo_news_categories ON demo_categories.id = demo_news_categories.category WHERE demo_news_categories.news = '$news_id'");
while ($f = sqlfetch($q)) {
$categories[] = $f;
}Filters
The Many to Many field type supports filtering the available data (either to restrict what a user can choose or to adjust the "description" of the items available). When adding/editing a Many to Many there is an option titled "List Parser Function" that enables you to do this filtering. Enter your function name (or static method, i.e. "parseThis" or "ClassName::parseThis") in this box. An example function for parsing data and making everything uppercase in the available list is below:
function parseManyToMany($data,$type) {
$return_data = array();
// If $type is true, we're parsing the full list of values available for a user to tag
if ($type === true) {
foreach ($data as $id => $description) {
$return_data[$id] = strtoupper($description);
}
return $return_data;
// If $type is false, we're parsing the currently tagged values
} else {
// Let's leave it how it is.
return $data;
}
}One to Many
The One to Many field type is nearly identical in function to the Many to Many field type, the difference being the storage mechanism. In a One to Many field the relationship is stored as an array rather than being stored in a separate table. This is great for use in templates, callouts, or settings where a Many to Many field is not available (or if you only need a one-way relationship a One to Many will make querying much easier for you). Because a One to Many stores its data local to the data set, it does require a column in a Module's database table (unlike a Many to Many which uses a separate table).
Geocoding
The Geocoding field type allows you to turn an address (or partial address) into latitude and longitude. It requires two columns name latitude and longitude in your table (they do not have to be visually present in the form, just part of the MySQL table itself). These columns don't have specific requirements for their type other than being capable of storing a latitude and longitude. The could be VARCHAR, FLOAT, or many other column types.
Many Geocoding Services are included with BigTree, some of which are free and some of which are paid solutions for commercial purposes.