TYPO3 can be extended in nearly any direction without loosing backwards compatibility. The Extension API provides a powerful framework for easily adding, removing, installing and developing such extensions to TYPO3. This is in particular powered by the Extension Manager (EM) inside TYPO3 and the online TYPO3 Extension Repository (TER) found at typo3.org for easy sharing of extensions.
“Extensions” is a term in TYPO3 which covers two other terms, plugins and modules.
A plugin is something that plays a role on the website itself. Eg. a board, guestbook, shop etc. It is normally enclosed in a PHP class and invoked through a USER or USER_INT cObject from TypoScript. A plugin is an extension in the frontend.
A module is a backend application which has its own position in the administration menu. It requires backend login and works inside the framework of the backend. We might also call something a module if it exploits any connectivity of an existing module, that is if it simply adds itself to the function menu of existing modules. A module is an extension in the backend.
Extensions are designed in a way so that extensions can supplement the core seemlessly. This means that a TYPO3 system will appear as "a whole" while actually being composed of the core application and a set of extensions providing various features. This philosophy allows TYPO3 to be developed by many individuals without loosing fine control since each developer will have a special area (typically a system extension) of responsibility which is effectively encapsulated.
So, in one end of the spectrum system extensions makes up what is known as "TYPO3" to the outside world. In the other end, extensions can be 100% project specific and carry only files and functionality related to a single implementation.
An extension consists of
a directory named by the extension key (which is a worldwide unique identification string for the extension unless prefix with “user_”)
standard files with reserved names for configuration related to TYPO3 (of which most are optional, see list below)
any number of additional files for the extension itself.
This list of filenames are all reserved filenames in the root directory of extensions. None of them are required but for example you cannot have a TYPO3 extension recognized by TYPO3 without the “ext_emconf.php” file etc. You can read more details like that in the table below.
In general, do not introduce your own files in root directory of extensions with the name prefix “ext_”.
Filename | Description |
|---|---|
ext_emconf.php | Definition of extension properties Name, category, status etc. Used by the EM. Also auto-written by EM when extensions are imported from repository. Notice: If this file is not present the EM will not find the extension. |
ext_localconf.php | Addition to “localconf.php” which is included if found. Should contain additional configuration of $TYPO3_CONF_VARS and may include additional PHP class files. All 'ext_localconf.php' files of included extensions are included right after the typo3conf/localconf.php file has been included and database constants defined. Therefore you cannot setup database name, username, password though, because database constants are defined already at this point. Notice: Observe rules for content of these files. See section on caching below. |
ext_tables.php | Addition to “tables.php” which is included if found. Should contain configuration of tables, modules, backend styles etc. Everything which can be done in an “extTables” file is allowed here. All 'ext_tables.php' files of loaded extensions are included right after the 'tables.php' file in the order they are defined in the global array TYPO3_LOADED_EXT but right before a general “extTables” file (defined with the var $typo_db_extTableDef_script in the typo3conf/localconf.php file, later set as the constant TYPO3_extTableDef_script). Thus a general “extTables” file in typo3conf/ may overrule any settings made by loaded extensions. You should not use this file for setting up $TYPO3_CONF_VARS. See “ext_localconf.php”. Notice: Observe rules for content of these files. See section below. |
ext_tables.sql | SQL definition of database tables. This file should contain a table-structure dump of the tables used by the extension. It is used for evaluation of the database structure and is therefore important to check and update the database when an extension is enabled.If you add additional fields (or depend on certain fields) to existing tables you can also put them here. In that case insert a CREATE TABLE structure for that table, but remove all lines except the ones defining the fields you need. The ext_tables.sql file may not necessarily be “dumpable” directly to MySQL (because of the semi-complete table definitions allowed defining only required fields, see above). But the EM or Install Tool can handle this. The only very important thing is that the syntax of the content is exactly like MySQL made it so that the parsing and analysis of the file is done correctly by the EM. |
ext_tables_static+adt.sql | Static SQL tables and their data. If the extension requires static data you can dump it into a sql-file by this name.Example for dumping mysql data from bash (being in the extension directory):mysqldump --password=[password] [database name] [tablename] --add-drop-table > ./ext_tables_static.sql--add-drop-table will make sure to include a DROP TABLE statement so any data is inserted in a fresh table. You can also drop the table content using the EM in the backend. Notice: The table structure of static tables needs to be in the ext_tables.sql file as well - otherwise an installed static table will be reported as being in excess in the EM! |
ext_typoscript_constants.txt | Preset TypoScript constants Deprecated (use static template files instead, see extMgm API description) Such a file will be included in the constants section of all TypoScript templates. |
ext_typoscript_setup.txt | Preset TypoScript setup Deprecated (use static template files instead, see extMgm API description) Such a file will be included in the setup section of all TypoScript templates. |
ext_typoscript_editorcfg.txt | Preset TypoScript editor configuration Deprecated (use static template files instead, see extMgm API description) Such a file will be included in the “Backend Editor Configuration” section of all TypoScript templates. |
ext_conf_template.txt | Extension Configuration template. Configuration code in TypoScript syntax setting up a series of values which can be configured for the extension in the EM. If this file is present the EM provides you with an interface for editing the configuration values defined in the file. The result is written as a serialized array to localconf.php file in the variable $TYPO3_CONF_VARS["EXT"]["extConf"][extension_key] The content of the “res/” folder is used for filelists in configuration forms. If you want to do user processing before the content from the configuration form is saved (or shown for that sake) there is a hook in the EM which is configurable with $TYPO3_CONF_VARS['SC_OPTIONS']['typo3/mod/tools/em/index.php']['tsStyleConfigForm'][] = “function reference” |
ext_icon.gif | Extension Icon 18x16 gif icon for the extension. |
(*/) locallang*.php | Localization values. The filename “locallang.php” (or any file matching locallang*.php) is used for traditional definition of language labels in the $LOCAL_LANG array. If you use this name consistently those files will be detected by the translation tool! Notice: PLEASE DO ONLY put the definition of the variable $LOCAL_LANG into this file and don't rely on comments in the file. The file will be automatically updated by the extension repository when translations are applied. |
class.ext_update.php | Local Update tool class If this file is found it will install a new menu item, “UPDATE”, in the EM when looking at details for the extension. When this menu item is selected the class inside of this file (named “ext_update”) will be instantiated and the method “main()” will be called and expected to return HTML content. Also you must add the function “access()” and make it return a boolean value whether or not the menu item should be shown. This feature is meant to let you disable the update tool if you can somehow detect that it has already been run and doesn't need to run again.The point of this file is to give extension developers the possibility to provide an update tool if their extensions in newer versions require some updates to be done. For an example, see “newloginbox” extension. |
ext_api_php.dat | PHP API data A file containing a serialized PHP array with API information for the PHP classes in the extension. The file is created - and viewed! - with tools found in the extension “extdeveval” (Extension Development Evaluator) |
pi*/ | Typical folder for a frontend plugin class. |
mod*/ | Typical folder for a backend module. |
res/ | Extensions normally consist of other files: Classes, images, html-files etc. Files not related to either a frontend plugin (pi/) or backend module (mod/) might be put in a subfolder of the extension directory named “res/” (for “resources”) but you can do it as you like (inside of the extension directory that is). The “res/” folder content will be listed as files you can select in the configuration interface. Files in this folder can also be selected in a selector box if you set up Extension configuration in a “ext_conf_template.txt” file. |
The files for an extension are located in a folder named by the extension key. The location of this folder can be either inside typo3/sysext/, typo3/ext/ or typo3conf/ext/.
The extension must be programmed so that it does automatically detect where it is located and can work from all three locations. If it is not possible to make the extension that flexible, it is possible to lock its installation requirement to one of these locations in the emconf.php file (see “lockType”)
Type | Path | Description |
|---|---|---|
Local | typo3conf/ext/ | This is where to put extensions which are local for a particular TYPO3 installation. The typo3conf/ dir is always local, containing local configuration (eg. localconf.php), local modules etc. If you put an extension here it will be available for a single TYPO3 installation only. This is a “per-database” way to install an extension. Notice about symlinking: Local extension can successfully be symlinked to other local extensions on a server as long as they are running under the same TYPO3 source version (which would typically also be symlinked). This method is useful for maintenance of the same local extension running under several sites on a server. |
Global | typo3/ext/ | This is a “per-server” way to install an extension; they are global for the TYPO3 source code on the web server. These extensions will be available for any TYPO3 installation sharing the source code. Notice on distribution: As of version 4.0, TYPO3 is no longer distributed with a fixed set of global extensions. In previous versions these were distributed for reasons like popularity and sometimes history. |
System | typo3/sysext/ | This is system default extensions which cannot and should not be updated by the EM. They are distributed with TYPO3 core source code and generally understood to be a part of the core system. |
Local extensions take precedence which means that if an extension exists both in typo3conf/ext/ and typo3/ext/ the one in typo3conf/ext/ is loaded. Likewise global extension takes precedence over system extensions. This means that extensions are loaded in the order of priority local-global-system.
In effect you can therefore have - say - a “stable” version of an extension installed in the global dir (typo3/ext/) which is used by all your projects on a server sharing source code, but on a single experimental project you can import the same extension in a newer “experimental” version and for that particular project the locally available extension will be used instead.
The “extension key” is a string uniquely identifying the extension. The folder where the extension resides is named by this string. The string can contain characters a-z0-9 and underscore. No uppercase characters should be used (keeps folder-,file- and table/field-names in lowercase). Furthermore the name must not start with an “tx” or “u” (this is prefixes used for modules) and because backend modules related to the extension should be named by the extension name without underscores, the extension name must still be unique even if underscores are removed (underscores are allowed to make the extension key easily readable).
The naming conventions of extension keys are automatically validated by the registration at the repository, so you have nothing to worry about here.
There are two ways to name an extension:
Project specific extensions (not generally usable or shareable): Select any name you like and prepend it “user_” (which is the only allowed use of a key starting with “u”). This prefix denotes that this extension is a local one which does not come from the central TYPO3 Extension Repository or is ever intended to be shared. Probably this is an “adhoc” extension you have made for some special occasion.
General extensions: Register an extension name online at the TYPO3 Extension Repository. Your extension name will automatically be validated and you are sure to have a unique name returned which nobody else in the world uses. This makes it very easy to share your extension later on with every one else, because it ensures that no conflicts with other extension will happen. But by default a new extension you make is defined “private” which means nobody else but you have access to it until you permit it to be public. It's free of charge to register an extension name. By definition all code in the TYPO3 Extension Repository is covered by the GPL license because it interfaces with TYPO3. You should really consider making general extensions!
Suggestion: It is far the easiest to settle for the right extension key from the beginning. Changing it later involves a cascade of name changes to tables, modules, configuration files etc. About GPL and extensions: Remember that TYPO3 is GPL software and at the same moment you extend TYPO3 your extensions are legally covered by GPL. This does not force you to share your extension, but it should inspire you to do so and legally you cannot prevent anyone who gets hold of your extension code from using it and further develop it. The TYPO3 Extension API is designed to make sharing of your work easy as well as using others work easy. Remember TYPO3 is Open Source Software and we rely on each other in the community to develop it further.
Responsibility: It's also your responsibility to make sure that all content of your extensions is legally covered by GPL. The webmaster of TYPO3.org reserves the right to kick out any extension without notice that is reported to contain non-GPL material.
Based on the extension key of an extension these naming conventions should be followed:
General | Example | User specific | Example | |
|---|---|---|---|---|
Extension key (Lowercase “alnum” + underscores. ) | Assigned by the TYPO3 Extension Repository. | cool_shop | Determined by yourself, but prefixed “user_” | user_my_shop |
Database tables and fields | Prefix with “tx_[key]_” where key is without underscores! | Prefix: tx_coolshop_ Examples: tx_coolshop_products tx_coolshop_categories | Prefix with “[key]_” | Prefix: user_my_shop_ Examples: user_my_shop_products user_my_shop_categories |
Backend module (Names are always without underscores!) | Name: The extension key name without underscores, prefixed “tx” | txcoolshop | Name: No underscores, prefixed “u” | uMyShop or umyshop or ... |
Frontend PHP classes | (Same as database tables and fields. Prepend class file names “class.” though.) |
If you study the naming conventions above closely you will find that they are complicated due to varying rules for underscores in keynames; Sometimes the underscores are stripped off, sometimes not.
The best practice you can follow is to not use underscores in your extensions keys at all! That will make the rules simpler. This is highly encouraged.
Some the “classic” extensions from before the extension structure came about does not comply with these naming conventions. That is an exception made for backwards compatibility. The assignment of new keys from the TYPO3 Extension Repository will make sure that any of these old names are not accidentially reassigned to new extensions.
Further, some of the classic plugins (tt_board, tt_guest etc) users the “user_” prefix for their classes as well.
There are only two (maybe three) simple steps involved in using extensions with TYPO3:
You must import it. This simply means to copy the extensions files into the correct directory in either typo3/ext/ (global) or typo3conf/ext/ (local). More commonly you import an extension directly from the online TYPO3 Extension Repository. When an extension is found located in one of the extension locations, it is available to the system. The EM should take care of this process, including updates to newer versions if needed. Notice that backend modules will have their “conf.php” file modified in the install process depending on whether they are installed locally or globally!
You must install it.An extension is loaded only if its extension key is listed in comma list of the variable $TYPO3_CONF_VARS["EXT"]["extList"]. The list of enabled extensions must be set and modified from inside typo3conf/localconf.php. Extensions are loaded in the order they appear in this list. Any extensions listed in $TYPO3_CONF_VARS["EXT"]["requiredExt"] will be forcibly loaded before any extensions in $TYPO3_CONF_VARS["EXT"]["extList"].An enabled extension is always global to the TYPO3 Installation - you cannot disable an extension from being loaded in a particular branch of the page tree.The EM takes care enabling extensions. It's highly recommended that the EM is doing this, because the EM will make sure the priorities, dependencies and conflicts are managed according to the extension characteristics, including clearing of the cache-files if any.
You might need to configure it.Certain extensions may allow you to configure some settings. Again the EM is able to handle the configuration of the extensions based on a certain API for this. Any settings - if present - configured for an extension is available as an array in the variable $TYPO3_CONF_VARS["EXT"]["extConf"][extension key].
Loaded extensions are registered in a global variable, $TYPO3_LOADED_EXT, available in both frontend and backend of TYPO3. The loading and registration process happens in t3lib/config_default.php.
This is how the data structure for an extension in this array looks:
$TYPO3_LOADED_EXT[extension key] = Array (
“type” =>S, G, L for system, global or local type of availability.
“siteRelPath” => Path of extension dir relative to the PATH_site constant
eg. “typo3/ext/my_ext/” or “typo3conf/ext/my_ext/”
“typo3RelPath” => Path of extension dir relative to the “typo3/” admin folder
eg. “ext/my_ext/” or “../typo3conf/ext/my_ext/”
“ext_localconf” => Contains absolute path to 'ext_localconf.php' file if present
“ext_tables” => [same]
“ext_tables_sql” => [same]
“ext_tables_static+adt.sql” => [same]
“ext_typoscript_constants.txt” => [same]
“ext_typoscript_setup.txt” => [same]
“ext_typoscript_editorcfg.txt” => [same]
)
The order of the registered extensions in this array corresponds to the order they were listed in TYPO3_CONF_VARS["EXT"]["requiredExt"].TYPO3_CONF_VARS["EXT"]["extList"] with duplicates removed of course.
The inclusion of ext_tables.php or ext_localconf.php files are done by traversing (a copy of) the $TYPO3_LOADED_EXT array.
These two files are the most important for the execution of extensions to TYPO3. They contain configuration used within the system on almost every request. Therefore they should be optimized for speed.
ext_localconf.php is always included in global scope of the script, either frontend or backend. You can put functions and classes into the script, but you should consider doing that in other ways because such classes and functions would always be available - and it would be better if they were included only when needed.So stick to change values in TYPO3_CONF_VARS only!
ext_tables.php is not always included in global scope on the other hand (in the frontend)Don't put functions and classes - or include other files which does - into this script!
Use the API of the class extMgm for various manipulative tasks such as adding tables, merging information into arrays etc.
Before the inclusion of any of the two files, the variables $_EXTKEY is set to the extention-key name of the module and $_EXTCONF is set to the configuration from $TYPO3_CONF_VARS["EXT”]["extConf"][extension key]
$TYPO3_LOADED_EXT[extension key] contains information about whether the module is loaded as local, global or system type, including the proper paths you might use, absolute and relative.
The inclusion can happen in two ways:
1) Either the files are included individually on each request (many file includes) ($TYPO3_CONF_VARS["EXT”]["extCache"]=0;)
2) or (better) the files are automatically imploded into one single temporary file (cached) in typo3conf/ directory (only one file include) ($TYPO3_CONF_VARS["EXT”]["extCache"]=1; [or 2]). This is default (value “1”)
In effect this means:
Your ext_tables.php / ext_localconf.php file must be designed so that it can safely be read and subsequently imploded into one single file with all the other configuration scripts!
You must NEVER use a “return” statement in the files global scope - that would make the cached script concept break.
You should NOT rely on the PHP constant __FILE__ for detection of include path of the script - the configuration might be executed from a cached script and therefore such information should be derived from the $TYPO3_LOADED_EXT[extension key] array. Eg. $TYPO3_LOADED_EXT[$_EXTKEY][“siteRelPath”]
This script configures the extension manager. The only thing included is an array, $EM_CONF[extension_key] with these associative keys (below in table).
When extensions are imported from the online repository this file is auto-written! So don't put any custom stuff in there - only change values in the $EM_CONF array if needed.
Key | Data type | Description |
|---|---|---|
title | string, required | The name of the extension in English. |
description | string, required | Short and precise description in English of what the module does and for whom it might be useful. |
category | string | Which category the extension belongs to:
|
shy | boolean | If set, the extension will normally be hidden in the EM because it might be a default extension or otherwise something which is not so important. Use this flag if an extension is of “rare interest” (which is not the same as un-important - just an extension not sought for very often...) It does not affect whether or not it's enabled. Only display in EM. Normally “shy” is set for all extensions loaded by default according to TYPO3_CONF_VARS. |
dependencies | list of extention-keys | This is a list of other extension keys which this extension depends on being loaded before itself. The EM will manage that dependency while writing the extension list to localconf.php |
conflicts | list of extention-keys | List of extension keys of extensions with which this extension does not work (and so cannot be enabled before those other extensions are un-installed) |
priority | “top”, “bottom” | This tells the EM to try to put the extensions as the very first in the list. Default is last. |
loadOrder | ||
TYPO3_version | [version-span] | Defines the TYPO3 version requirements of the extension. Syntax:
Version string syntax is [int].[int].[int][pre-release][int] where [pre-release] is “dev”, “b” or “rc” in that order. Examples (in order of precedence): 4.0.0 3.6.1 3.6.1rc1 3.6.0 3.6.0rc2 3.6.0rc1 3.6.0b2 3.6.0b1 3.6.0dev2 3.6.0dev1 3.6.0dev (=3.6.0dev0) 3.5.10 3.5.0 3.1.1 3.1 (=3.1.0) 3 (=3.0.0) |
PHP_version | [version-span] | Defines the PHP version requirements of this extension. Syntax is the same as for “TYPO3_version”, see above. |
module | list of strings | If any subfolders to an extension contains backend modules, those foldernames should be listed here. It allows the EM to know about the existence of the module, which is important because the EM has to update the conf.php file of the module in order to set the correct TYPO3_MOD_PATH constant. |
state | string | Which state is the extension in?
|
internal | boolean | This flag indicates that the core source code is specifically aware of the extension. In other words this flag should convey the message that “this extension could not be written independently of core source code modifications”. An extension is not internal just because it uses TYPO3 general classes eg. those from t3lib/. True non-internal extensions are characterized by the fact that they could be written without making core source code changes, but relies only on existing classes in TYPO3 and/or other extensions, plus its own scripts in the extension folder. |
uploadfolder | boolean | If set, then the folder named “uploads/tx_[extKey-with-no-underscore]” should be present! |
createDirs | list of strings | Comma list of directories to create upon extension installation. |
modify_tables | list of tables | List of table names which are only modified - not fully created - by this extension. Tables from this list found in the ext_tables.sql file of the extension |
lockType | char; L, G or S | Locks the extension to be installed in a specific position of the three posible:
|
clearCacheOnLoad | boolean | If set, the EM will request the cache to be cleared when this extension is loaded. |
author | string | Author name (Use a-z) |
author_email | email address | Author email address |
author_company | string | Author company (if any company sponsors the extension). |
CGLcompliance | keyword | Compliance level that the extension claim to adhere to. A compliance defines certain coding guidelines, level of documentation, technical requirements (like XHTML, DBAL usage etc). Possible values are:
Please see the Project Coding Guidelines for a description of each compliance keyword (and the full allowed list). |
CGLcompliance_note | string | Any remarks to the compliance status. Might describe some minor incompatibilities or other reservations. |
private | boolean | If set, this version of the extension is not included in the public list! (Not supported anymore) |
download_password | string | If set, this password must additionally be specified if people want to access (import or see details for) this the extension. (Not supported anymore) |
version | main.sub.dev | Version of the extension. Automatically managed by EM / TER. Format is [int].[int].[int] |
A rather exotic thing to do but nevertheless...
If you are programming extensions yourself you should as a standard procedure include the “class extension code” in the bottom of the class file:
if (defined("TYPO3_MODE") && $TYPO3_CONF_VARS[TYPO3_MODE]["XCLASS"]["ext/class.cool_shop.php"]){include_once($TYPO3_CONF_VARS[TYPO3_MODE]["XCLASS"]["ext/class.cool_shop.php"]);
}
Normally the key used as example here (“ext/class.cool_shop.php”) would be the full path to the script relative to the PATH_site constant. However because modules are required to work from both typo3/sysext/, typo3/ext/ and typo3conf/ext/ it is policy that any path before “ext/” is omitted.
Extensions are managed from the Extension Manager inside TYPO3 by "admin" users. The module is located at "Tools > Ext Manager" and offers a menu with options to see loaded extensions (those that are installed or activated), available extensions on the server and the possibility to import extensions from online resources, typically TER (TYPO3 Extension Repository) which is at TYPO3.org.
The interface looks like this for the list of available extensions:
The interface is really easy to use. You just click the +/- icon to the left of an extension in order to install it.
This document will not describe into details how to create extensions. It only aims to be a reference for the facts regarding the rules of how extensions register with the system.
To learn to create extensions you should read one of the extension tutorials that are available. They will take you through the process step by step and explain best-practices for you.
To start up a new extension the most popular tool is the Extension Kickstarter Wizard. From a series of menus it allows you to configure a basic set of features you want to get into your extension and a selection of default files will be created. The idea is that you continue to develop these files into your specific application.
Before starting a new extension you should register an extension key on TYPO3.org (unless you plan to make an implementation specific extension of course which does not make sense to share).
Go to TYPO3.org, log in with your (pre-created) username / password and enter http://typo3.org/extensions/register-extension-keys/. In the bottom of the page you can enter the key name you want to register.
Before you can use the Kickstarter Wizard you will have to enable it. The "Kickstarter" is an extension like everything else (key: "extrep_wizard") so it must be installed first:
After the installation of the extension you will find a new menu item named "Make new extension" in the selector box menu of the Extension Manager.
In the Kickstarter you should always fill in the General Information which includes the title, description, author name etc for the extension. But the most important thing is to enter the extension key as the very first thing!
After entering this information you can begin to create new tables and fields in the database, you can configure backend modules and frontend plugins etc. Basically this is what tutorials will cover in detail.
When you are through with the configuration you click the button to the left called "View result". This will let you preview the content of the files the Kickstarter will write to the server.
It is important that you write the extension to the correct location. Most likely that will be "Local" in your case.
Finally, if there already is an extension with the same extension key every file from that extension will be overwritten with the Kickstarters output! Remember: This is a kickstarter, not an editor! It is meant to kick you off with your new TYPO3 extension and nothing more! So of course it overwrites all existing files!
After the extension is written to the servers harddisk you should see a message like this. Immediately you can now install the extension:
In the process of creating an extension is it rather typical to go back to the Kickstarter a few times to fine tune to base code. Experience suggests that this is especially useful to tuning the configuration of database tables and fields.
If you want to load the Kickstarter with the original configuration used for your extension so you can add or edit features, just click the extension title in the list of loaded/available extensions and select "Backup/Delete" from the menu:
Clicking the "Start new" button will bring you back to the Kickstarter with all the original configuration used (configuration loaded from "doc/wizard_form.dat" which must still exist).
It is potentially dangerous to introduce this feature because it may leave you with the wrong impression of the Kickstarter. It is still not an editor for your extensions! Whatever custom changes that has been made to the scripts of your new extension will be overwritten when you write back the extension from the Kickstarter.
A good workflow for using the Kickstarter turns out to be this:
Start by setting up all the features you need for your extension and write it with the Kickstarter.
Begin to fill in dummy information in the database tables your extension contain. You will most likely find that you forgot something or misconfigured a database field. Since you have not yet done any changes to the files in the extension you can safely re-load the extension configuration (see above) and add the missing fields or whatever. Your dummy database content will not be affected by this operation.
When you have tested that your database configuration works for your purpose you can begin to edit the PHP-scripts by hand (fx. programming the extension plugin). This is the "point-of-no-return" where you cannot safely return to the Kickstarter because you have now changed scripts manually.
