How Data Is Stored in TYPO3
TYPO3 uses a database (typically MySQL) and the file system to store data. The file system keeps configuration files, some cache files, images, and uploaded files. The database stores pages, content elements, and lots of system data (such as TypoScript templates, logs, and so on).
All (to be precise most, but for our purpose, all) tables in TYPO3 roughly follow the same structure. They have a set of predefined (reserved) fields. TYPO3 will not work properly if one or more of the required fields is missing. Examples of predefined fields are uid
(unique identifier of the record), pid
(id of the page where this record is located), crdate
(record creation time), tstamp
(last update time), cruser_id
(uid of the Backend user, who created this record). A table may also contain other reserved fields. If it does, TYPO3 will automatically provide additional functionality for the table. The best examples of such fields are deleted
(indicates whether a record is deleted), starttime
(indicates when a record becomes visible in the FE), endtime
(indicates when a record stops being visible), and hidden
(indicates whether a record is hidden). There are other fields, which will be discussed later. All these fields are managed by the system, and extensions usually do not change them.
TYPO3 comes with several default tables. These main tables are:
pages
andpages_language_overlay
The
pages
table stores page data (uid, title, and so on), while thepages_language_overlay
table stores translations of the page data.tt_content
This table stores information about content elements. This is usually one of the largest tables in the system.
be_*
This table stores information related to BE users.
cache_*
This table stores cache data.
fe_*
This table stores information related to FE users.
sys_*
This tables stores various system data.
tx_*
This table stores tables from extensions.
If an extension provides a new table, it must ensure that the table name has a certain format. The table name must start with tx_
, followed first by the extension key without underscores and next by an underscore, and the table name. For example, an extension with the extension key my_ext
can have the following valid table names:
tx_myext_data
tx_myext_elements
The following table names are not valid:
data
myext_data
my_ext_data
data_my_ext
tx_my_ext_data
We will discuss tables in more detail when we generate extensions later in this book. At the moment, it is important to remember two things:
There are certain naming conventions for tables.
Each table must have a certain set of fields.