Chapter 1. About TYPO3 API

Let's get a picture of TYPO3 API before we start to talk about extension creation. There are a lot of files, functions, and function groups in TYPO3 API. Beginners can easily miss the function they should use in a particular part of the code.

This chapter is going to discuss TYPO3 API. We will not go into the details, but will provide pointers to where developers can look. The best way to read this chapter is to keep a copy of each discussed PHP file and read function description inside that file along with the description mentioned in the book.

After completing this chapter, the reader will have a general picture of TYPO3 API, and will be able to find the necessary functions in the API.

Overview of TYPO3 API

TYPO3 is a large system with lots of PHP classes. Trying to learn each class in order to learn the API is time consuming, and will not provide an understanding of the system as a whole. It is much easier to logically split the system into blocks and look at the API from this perspective.

As seen from the user experience, TYPO3 has two main parts: the Frontend (or FE) and the Backend (or BE). Website visitors see the FE of TYPO3. Website editors create and modify the website content from the BE of TYPO3.

The TYPO3 API can be divided approximately the same way: FE API and BE API. The FE API includes classes to create website output, while the BE API includes classes for content manipulation and other functionality to help editors do their work in an effective way. Extensions can extend existing or add new APIs to the system. One of the best examples is TemplaVoila. It adds point-and-click templates to the TYPO3 BE and flexible content elements to the FE.

However, there is one more part, which is not visible to website visitors or editors but used by both FE and BE API. There is no name for it in TYPO3. In this book, we will call it the Common API. An example of such an API is the database API. It would be wrong to use different database layers for BE and FE (otherwise programmers would have to learn more APIs and would tend to use the one most convenient instead of the one "assigned" to Backend or Frontend). So, TYPO3 has only one layer that works with the database. All system classes and extensions are expected to use this API to access and retrieve data from the database.

While we can logically separate the TYPO3 API into three parts, it should be noted that most TYPO3 classes and functions have a very long history. They are constantly updated, but their age is still visible. Most classes are in the same file system directory (t3lib), and it is hard to tell where the class really belongs just by looking at its name. However, this applies only to the file system. Generally, these classes include functions for a single API group only. So logically, they are well-designed and separated from other groups.

The TYPO3 core team makes every effort to keep the API clear, logical, and effective. Extension developers can learn a lot about TYPO3 by looking into the implementation of the TYPO3 API while programming extensions. This is really a good way to become a TYPO3 professional.

In the following sections, we will look at each API group and certain classes inside them. Due to the large number of API classes, it is not possible to cover them all. It would take the whole book alone to cover them all. So, we are going to cover only those classes that extension developers will most likely meet or use during extension development. We are going to start with the most basic and universal classes and move on to more specialized classes. Note that this chapter will provide only an overview of the API, and not a detailed description of each function. We will look deeper into many of these classes later in the book.

But first, we need to discuss certain basic issues about TYPO3 from a developer's view.