Content Elements & Plugins

This chapter handles content elements & plugins: What they are, how they can be created, how existing content elements or plugins can be customized etc.

Introduction

In TYPO3, Content elements and plugins are both stored as Database records in table tt_content. They are usually edited in the backend in module Web > Page.

Content elements and plugins are both used to present and manage content on a website, but they serve different purposes and have distinct characteristics:

Content element Text & Media

Content elements

A content element is a standard unit for managing and displaying content, such as text, images, videos, tables, and more. TYPO3 provides a variety of built-in content elements. It is possible to define custom content elements.

Plugin news article detail

Plugins

A plugin in TYPO3 is more complex, typically providing dynamic or interactive functionality. Plugins are usually provided by extensions that introduce new features to the website.

The data to be displayed is usually supplied by a special PHP class called a "controller". Depending on the technology used in the controller the plugin can be an Extbase plugin or a plain plugin.

Content elements in TYPO3

A content element is a standard unit for managing and displaying content, such as text, images, videos, tables, and more.

In the TYPO3 backend, content elements are commonly managed in module Web > Page.

From a technical point of view content elements are records stored in the database table tt_content. Each content element has a specific content element type, specified by the database field tt_content.CType. This type influences both the backend form and the frontend output.

The appearance of a content element in the backend form is defined via the TYPO3 Configuration Array (TCA) of table tt_content. Each content element type is configured by one entry in the section $TCA['types'].

The output of the content element in the frontend is configured by an entry in the TypoScript top-level object tt_content using the same key as in TCA. In most cases a FLUIDTEMPLATE is used delegating the actual output to the templating engine Fluid.

A content element can be of a type supplied by TYPO3, such as textmedia (text with or without images or videos). Or it can have a custom type supplied by an extension such as carousel provided by the bk2k/bootstrap-package extension.

You can add custom content elements to your extension or site package.

It is also possible to use an extension such as contentblocks/content-blocks , mask/mask , or t3/dce to add custom content elements to your projects.

Adding custom content elements is possible without writing PHP code and can therefore also be done by TYPO3 integrators.

Plugins in TYPO3

A plugin in TYPO3 is a more complex implementation, typically providing dynamic or interactive functionality. Plugins are usually provided by extensions that introduce new features to the website.

The data to be displayed is usually supplied by a special PHP class called a "controller". Depending on the technology used in the controller the plugin can be an Extbase plugin or a plain plugin.

Extbase plugins

For usage in the TYPO3 backend Extbase plugins are registered with utility functions of class \TYPO3\CMS\Extbase\Utility\ExtensionUtility (not to be confused with \TYPO3\CMS\Core\Utility\ExtensionManagementUtility ).

An Extbase plugin is configured for the frontend with ExtensionUtility::configurePlugin() in file EXT:my_extension/ext_localconf.php:

EXT:my_extension/ext_localconf.php
<?php

declare(strict_types=1);
defined('TYPO3') or die();

use MyVendor\MyExtension\Controler\MyController;
use TYPO3\CMS\Extbase\Utility\ExtensionUtility;

ExtensionUtility::configurePlugin(
    'MyExtension',
    'MyPlugin',
    [MyController::class => 'list,comment'],
    [MyController::class => 'comment'],
    ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT,
);
Copied!

By using ExtensionUtility::PLUGIN_TYPE_PLUGIN as fifth parameter is is also possible to add the plugin as a list type. See CType vs list_type plugins.

Method ExtensionUtility::configurePlugin() also takes care of registering the plugin for frontend output in TypoScript using an object of type EXTBASEPLUGIN.

If it is desired that editors can insert the Extbase plugin like a content element into the page it also needs to be registered with ExtensionUtility::registerPlugin() in the TCA Overrides, for example file EXT:my_extension/Configuration/TCA/Overrides/tt_content.php:

EXT:my_extension/Configuration/TCA/Overrides/tt_content.php
<?php

declare(strict_types=1);

use TYPO3\CMS\Extbase\Utility\ExtensionUtility;

defined('TYPO3') or die();

ExtensionUtility::registerPlugin(
    'MyExtension',
    'MyPlugin',
    'LLL:EXT:my_extension/Resources/Private/Language/locallang.xlf:my_plugin.title',
    'myextension_pluginicon',
    'plugins',
    'LLL:EXT:my_extension/Resources/Private/Language/locallang.xlf:my_plugin.description',
);
Copied!

For a detailed explanation of Extbase plugins including examples for controllers see chapter Extbase.

Plugins without Extbase

It is possible to create a plugin without using Extbase by creating a plain PHP class as a controller.

In this case you have to define the TypoScript configuration yourself. A USER or USER_INT TypoScript object can be used to delegate the rendering to your controller:

EXT:my_extension/Configuration/TypoScript/setup.typoscript
plugin.tx_myextension_myplugin = USER_INT
plugin.tx_myextension_myplugin {
  userFunc = MyVendor\MyPlugin\Controller\MyController->doSomething
}

tt_content.myextension_myplugin < plugin.tx_myextension_myplugin
Copied!

To register such a plugin as content element you can use function ExtensionManagementUtility::addPlugin() in the TCA overrides, for example EXT:my_extension/Configuration/TCA/Overrides/tt_content.php:

EXT:my_extension/Configuration/TCA/Overrides/tt_content.php
<?php

declare(strict_types=1);

use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;

defined('TYPO3') or die();

ExtensionManagementUtility::addPlugin(
    [
        'label' => 'LLL:EXT:my_extension/Resources/Private/Language/locallang_db.xlf:my_plugin.title',
        'value' => 'myextension_myplugin',
        'group' => 'plugins',
        'icon' => 'myextension_mypluginicon',
        'description' => 'LLL:EXT:my_extension/Resources/Private/Language/locallang_db.xlf:my_plugin.description',
    ],
    'CType',
    'my_extension',
);
Copied!

By using 'list-type' as second parameter is is also possible to add the plugin as a list type. See CType vs list_type plugins.

Plugins are a specific type of content elements. Plugins use the CType='list'. Each plugin has its own plugin type, which is used in the database field tt_content.list_type. The list_type could be understood as subtype of CType.

Typical characteristics of plugins

  • Plugins often use additional database tables which contain records which are dynamically displayed via the plugin - often in a list view, a single view, optionally with pagination and search functionality. An extension may provide several plugins, each with a dedicated function, such as the list view.
  • Plugins are often used if more complex functionality is required (than in non- plugin content elements)
  • Plugins can be created using the Extbase framework or by Core functionality.

A typical extension with plugins is the georgringer/news extension which comes with plugins to display news records in lists or as a single view with only one news record.

The news records are stored in a custom database table (tx_news_domain_model_news) and can be edited in the backend.

There are also system extensions that have plugins. typo3/cms-felogin has a plugin that allow frontend users, stored in table fe_user to log into the website. typo3/cms-indexed-search has a plugin that can be used to search in the index and display search results.

CType vs list_type plugins

Historically it was common to add plugins as a list type to the content element types. In this case the column CType is set to 'list' for all plugins while the field list_type contains the key of the actual plugin.

As different plugins need different fields in the backend form this let to the creation of all type of complicated TCA constructs to influence the behaviour of backend forms for plugins.

The existence of the list_type also made a separate layer of content element definitions in the TypoScript necessary.

Therefore the list_type complicates registration and configuration of plugins while it poses no advantages. Therefore it is recommended to always use the CType for new plugin types while the list_type is retained for now for backward compatibility.

If you are refactoring the plugins of your extension, for example while getting rid of switchable controller actions it is recommended to migrate your plugins to use the CType. You should then supply a upgrade wizard for easy migration for your users.

Editing

The Editors Tutorial describes how to work with page content and lists the basic TYPO3 content elements and how to work with them.

Additional descriptions can be found the fluid_styled_content documentation.

Customizing

Backend Layouts can be configured to define how content elements are arranged in the TYPO3 backend (in rows, columns, grids). This can be used in the frontend to determine how the content elements are to be arranged (e.g. in the footer of the page, left column etc.).

Often content elements and plugins contain a number of fields. Not all of these may be relevant for your site. It is good practice to configure which fields will be displayed in the backend. There are a number of ways to do this:

Creating custom content element types or plugins

The following chapters handle how to create custom content element types and plugins:

How to make your plugins or content elements configurable by editors with