Configuring The Plugin ¶
An extension normally offers a so called
for the output of the data.
A plugin is a content element, that can be placed on a page like a text element
or an image. It is a “virtual” collection of one or more actions.
These actions could lie in completely different controllers.
In our example there is only one controller action combination, namely
This combination is registered in the file
, that we
create in the top level of our extension directory.
<?php defined('TYPO3_MODE') || die('Access denied.'); \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin( 'MyVendor.StoreInventory', 'Pi1', [ 'StoreInventory' => 'list', ], // non-cacheable actions [ 'StoreInventory' => '', ], );
With the first line we ensure, that the PHP code can not be
called directly outside of TYPO3, for security reasons. The static method
offers several arguments. With the first one we assign the extension key (it
derives from the name of the extension directory), prefixed by the vendor
namespace, followed by a dot. This indicates, that we use namespaces for our php
classes. With the second argument we give a unique name for the plugin (in
UpperCamelCase notation). Because of historical reasons there is often used
, but maybe it is better to use more meaningful names like
This is used later to clearly identify the plugin amongst other plugins on the page.
The third argument is an array with all controller action combinations, the plugin
can execute. The array key is the name of the controller (without the suffix
and the array value is a comma separated list of all actions that are executable by the plugin.
In our case this is the
action (also without the suffix
Thus the array
allows the plugin to execute the method
By default all results of the actions are stored in the cache. If it is not desired for
individual actions, they can be specified by a fourth, optional argument.
It is an array that has the same format as the previous. There are all actions listed whose
results should not be stored in the cache.
Technically this is solved by a condition in the automatically generated TypoScript code, to call Extbase either as content object of the type USER (cached), if necessary, or of type USER_INT (not cached). If you are experiencing caching problems, it is worth to look at the generated TypoScript.
After that, the registration of the plugin follows, to make it appear in the selection box
of the content element
. For this we insert the following line into a new file
<?php \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin( 'MyVendor.StoreInventory', 'Pi1', 'The Store Inventory List', 'EXT:store_inventory/Resources/Public/Icons/Extension.svg' );
The first argument is, just like in the method
before, the vendor namespace and extension key
and the second is the name of the plugin. The third argument is an arbitrary, not too long,
title of the plugin for the selection box of the content element. After installing the
extension we can insert the plugin on a page. Don’t forget to set the sys folder, in which the
products are stored, as the starting point (in our case “Inventory”) in the plugin.
Otherwise your products can not be found (see figure 4-4).
The next call of the page, with the plugin on it, shows the inventory as a table (figure 4-5).
With this the first little Extbase extension is finished. The example was intentional held simple. It illustrates the important steps and the conventions we have to observe. For a full-grown extension there are some ingredients missing:
- Real domain models have a high complexity. (Products for example have different prices and are assigned to product categories.)
- Multiple different views have to be generated (single view, list view with search and so on).
- The user of the web site should interact with the data by different modes (edit, create, sort and so on).
- Input from the web site user has to check (validate) for consistence.
The sample extension we show from chapter 5 on, is significant multifaceted.