plugin¶
This is used for extensions in TYPO3 set up as frontend plugins.
Typically you can set configuration properties of the plugin here. Say
you have an extension with the key "myext" and it has a frontend
plugin named "tx_myext_pi1" then you would find the TypoScript
configuration at the position plugin.tx_myext_pi1
in the object
tree!
Most plugins are USER and USER_INT objects which means that they have at least 1 or 2 reserved properties. Furthermore this table outlines some other default properties. Generally system properties are prefixed with an underscore:
Properties for all frontend plugin types¶
userFunc¶
-
userFunc
¶ -
- Type
- (array of keys)
Property setting up the USER and USER_INT object of the plugin.
_CSS_DEFAULT_STYLE¶
-
_CSS_DEFAULT_STYLE
¶ -
Use this to have some default CSS styles inserted in the header section of the document.
_CSS_DEFAULT_STYLE
outputs a set of default styles, just because an extension is installed. Most likely this will provide an acceptable default display from the plugin, but should ideally be cleared and moved to an external stylesheet.This value is read by the frontend
RequestHandler
script when collecting the CSS of the document to be rendered.This is for example used by frontend and indexed_search. Their default styles can be removed with:
plugin.tx_frontend._CSS_DEFAULT_STYLE > plugin.tx_indexedsearch._CSS_DEFAULT_STYLE >
Copied!However, you will then have to define according styles yourself.
_CSS_PAGE_STYLE¶
Deprecated since version 12.1
Integrators should avoid using _CSS_PAGE_STYLE
on plugin level.
They should switch adding CSS on a PAGE level. A direct
replacement using page.cssInline looks like
this:
Before:
plugin.tx_myPlugin._CSS_PAGE_STYLE (
.myClass { text-align: center }
)
After:
page.cssInline {
10 = TEXT
10.value (
.myClass { text-align: center }
)
}
As a general note, the PAGE
property includeCSS is often better suited to include CSS as
files, especially when frontend CSS is generated by some processor like
SCSS.
-
CSS_PAGE_STYLE
¶ -
- Type
- string
- Default
false
_CSS_PAGE_STYLE
is included only on the affected pages. Depending on your configuration it will be written in an external file and included on the page or directly added as inline CSS block. Compression for page specific CSS also depends on the globalconfig.compressCss
setting.This setting can be used to only include the CSS when the plugin of a certain extension is included on that page.
This value is read by the frontend
RequestHandler
when collecting the CSS of the document to be rendered.
Properties for all frontend plugins based on Extbase¶
Extbase is an extension framework to create frontend plugins.
General¶
ignoreFlexFormSettingsIfEmpty¶
New in version 12.3
-
ignoreFlexFormSettingsIfEmpty
¶ -
- Type
- string
Define FlexForm settings that will be ignored in the extension settings merge process, if their value is considered empty (either an empty string or a string containing
0
).Additionally, there is the PSR-14 event BeforeFlexFormConfigurationOverrideEvent available to further manipulate the merged configuration after standard override logic is applied.
Examples: Ignore certain FlexForm settings if empty¶
Definition for all plugins of an extension:
plugin.tx_myextension.ignoreFlexFormSettingsIfEmpty = field1,field2
Definition for one plugin of an extension:
plugin.tx_myextension_myplugin.ignoreFlexFormSettingsIfEmpty = field1,field2
If an extension already defined ignoreFlexFormSettingsIfEmpty
,
integrators are advised to use addToList
or
removeFromList
to modify existing settings:
plugin.tx_myextension_myplugin.ignoreFlexFormSettingsIfEmpty := removeFromList(field1)
plugin.tx_myextension_myplugin.ignoreFlexFormSettingsIfEmpty := addToList(field3)
Features¶
Activate features for Extbase or a specific plugin.
features.skipDefaultArguments¶
Deprecated since version 12.4
Switch to proper routing configuration instead.
Example¶
plugin.tx_blogexample_rssfeed {
features {
skipDefaultArguments = 1
}
}
features.ignoreAllEnableFieldsInBe¶
Deprecated since version 12.4 See :ref:`setup-plugin-features-ignoreAllEnableFieldsInBe-migration`
Example¶
plugin.tx_blogexample_admin { features { ignoreAllEnableFieldsInBe = 1 } }
Copied!
Migration¶
When the repository in question is only used in backend context, the code below should trigger the same behavior. Note as with other query settings, this toggle needs to be used with care, otherwise backend users may see records they are not supposed to see.
/**
* Overwrite createQuery to not respect enable fields.
*/
public function createQuery(): QueryInterface
{
$query = parent::createQuery();
$query->getQuerySettings()->setIgnoreEnableFields(true);
return $query;
}
When the repository is used in both backend and frontend context, the code should be refactored a bit towards a public method that can be set by the Extbase backend controller only.
Persistence¶
Settings, relevant to the persistence layer of Extbase.
persistence.enableAutomaticCacheClearing¶
Example: Disable automatic cache clearing for Extbase plugin¶
plugin.tx_blogexample_admin {
persistence {
enableAutomaticCacheClearing = 0
}
}
persistence.storagePid¶
Example: Set storage PID for Extbase plugin¶
plugin.tx_blogexample {
persistence {
storagePid = 42
}
}
persistence.recursive¶
Example: Fetch records recursively from storage folder¶
plugin.tx_blogexample {
persistence {
# Includes 4 sub-levels of the storagePid
recursive = 4
}
}
View¶
View and template settings.
All root paths are defined as an array which enables you to define multiple root paths that will be used by Extbase to find the desired template files.
The root paths work just like the one in the FLUIDTEMPLATE.
Example: Set template paths for Extbase plugin¶
plugin.tx_blogexample {
view {
layoutRootPaths {
0 = EXT:blog_example/Resources/Private/Layouts/
10 = EXT:my_extension/Resources/Private/Layouts/
}
partialRootPaths {
0 = EXT:blog_example/Resources/Private/Partials/
10 = EXT:my_extension/Resources/Private/Partials/
}
templateRootPaths {
0 = EXT:blog_example/Resources/Private/Templates/
10 = EXT:my_extension/Resources/Private/Templates/
}
}
}
view.layoutRootPaths¶
view.partialRootPaths¶
view.templateRootPaths¶
view.pluginNamespace¶
MVC¶
These are useful MVC settings about error handling:
mvc.callDefaultActionIfActionCantBeResolved¶
Example: Call default action if action cannot be resolved¶
plugin.tx_blogexample {
mvc {
callDefaultActionIfActionCantBeResolved = 1
}
}
mvc.throwPageNotFoundExceptionIfActionCantBeResolved¶
-
mvc.throwPageNotFoundExceptionIfActionCantBeResolved
¶ -
- Type
- boolean
- Default
false
Same as mvc.callDefaultActionIfActionCantBeResolved but this will raise a "page not found" error.
Example: Show 404 (page not found) page if action cannot be resolved¶
plugin.tx_blogexample {
mvc {
throwPageNotFoundExceptionIfActionCantBeResolved = 1
}
}
Format¶
Warning
Using this parameter is considered bad practice. In most cases it is better use different actions for different output formats.
-
format
¶ -
- Type
- string
- Default
html
Define the default file ending of the template files. The template files have to take care of creating the desired format output.
Example: Define alternative output formats for RSS feeds¶
plugin.tx_blogexample_rssfeedxml {
// Use template List.xml
format = xml
}
plugin.tx_blogexample_rssfeedatom {
// Use template List.atom
format = atom
}
_LOCAL_LANG.[lang-key].[label-key]¶
-
_LOCAL_LANG.[lang-key].[label-key]
¶ -
- Type
- string
Can be used to override the default language labels for Extbase plugins. The
lang-key
setup part isdefault
for the default language of the website or the 2-letter (ISO 639-1) code for the language.label-key
is the 'trans-unit id' XML value in the XLF language file which resides in the pathResources/Private/Language
of the extension or in thetypo3conf/l10n/[lang-key]
(var/labels/[lang-key]
in composer mode) subfolder of the TYPO3 root folder. And on the right side of the equation sign '=' you put the new value string for the language key which you want to override.All variables, which are used inside an Extbase extension with the ViewHelper
<f:translate>
can that way be overwritten with TypoScript. Thelocallang.xlf
file in the plugin folder in the file system can be used to get an overview of the entries the extension uses.
Example: Override a language key in an Extbase plugin¶
plugin.tx_myext_pi1._LOCAL_LANG.de.list_mode_1 = Der erste Modus
Settings¶
Here reside are all the settings, both extension-wide and plugin-specific.
These settings are available in the controllers as the array variable
$this->settings
and in any Fluid template with {settings}
.
The settings for a specific plugin can be overridden by FlexForm values of the same name.