Project

General

Profile

Actions

Story #64274

open

Add new Plugin registration

Added by Mathias Schreiber about 9 years ago. Updated about 7 years ago.

Status:
Accepted
Priority:
Should have
Category:
System/Bootstrap/Configuration
Start date:
2015-01-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
5.5
Tags:
Sprint Focus:

Description

Registering a non-extbase plugin currently needs two things:

  • Add the TCA necessary by calling
    \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin
  • Add the typoscript by calling
    \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPItoST43

addPItoST43 adds typoscript in this form:

plugin.tx_extensionkey_suffix = USER
plugin.tx_extensionkey_suffix.userFunc = tx_extensionkey_suffix->main

When you want to use namespaced code (and I say that's what we all want) you need to manually supply a classmap in this form:
tx_extensionkey_suffix => '\Vendorname\Extensionname\Controller\Class'

I propose a new method to register non-extbase plugins that enforces stronger defaults and reduces the clutter in the Typoscript Obejct Browser.

New method:

static public function addPluginTyposcript($FQCN, $methodName = 'render')

See the example:

static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\Plugin\MyPlugin::class, 'dispatch')
static public function addPluginTyposcript(\MyAgency\MyExtension\UnCached\Plugin\MyPlugin::class, 'dispatch')
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\Menu\MyMenu::class, 'render')
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\CType\MyCType::class, 'render')
static public function addPluginTyposcript(\MyAgency\MyExtension\Cached\Header\MyHeader::class, 'render')

As you can see the FQCN (Fully qualified class name) holds a strong default for registering a plugin in the frontend.
Let's take the example above apart:
  • \MyAgency
    • the Vendor name
  • \MyExtension
    • Your extension key
  • \Cached
    • defines whether a plugin runs cached or uncached (just for TS registering, you can re-define it via TS, possible values are:
      • Cached
      • Uncached
  • \Plugin
    • Determines the type, possible values are:
      • Plugin
      • Menu
      • CType
      • Header
  • \MyPlugin
    • Your class name
We will drop support for "just include library", because the design is just broken.
All TS get's added to page.1000, which is problematic if
  • you have multiple of these plugins installed
  • your root object simply has another name than page

Typoscript result

I propose to add more "dots" to the TS.
Possible result:

plugin.MyAgency.MyExtension.Plugin.MyPlugin = USER
plugin.MyAgency.MyExtension.Plugin.MyPlugin.userFunc = \MyAgency\MyExtension\Cached\Plugin\MyPlugin->dispatch
plugin.MyAgency.MyExtension.Menu.MyMenu = USER
plugin.MyAgency.MyExtension.Menu.MyMenu.userFunc = \MyAgency\MyExtension\Cached\Menu\MyMenu->render

This will clean up the Typoscript Object browser.

tt_content.CType result

We could also derive the TCA necessary from this classes.
The following fields in tt_content are affected:
  • CType
  • list_type
  • menu_type
  • header_layout

Storing values in these fields needs to comply to the TS being generated.
So the resulting value from the example would be:

MyAgency.MyExtension.Plugin.MyPlugin
MyAgency.MyExtension.Menu.MyMenu

When selecting values in the database this comes in handy because you can now use proper wildcards to isolate specific extensions.

In order to generate the label for the field in the BE we would use a locallang.xlf hit for the same identifier.

Registering multiple Plugins/CTypes

Currently TYPO3 loops through all registered plugins and adds the TS on demand (in every hit).
Additionally, it's painful if you have an extension that registers, say, 50 CTypes.
The idea would be to look up all CTypes automatically and cache this information.
This way an extension would just need to "configure" something like "I do supply UserFunctions".
If there are cached registrations, use those.
If no cached registrations are in place, try to look them up via the filesystem (using the logic described above) and build up the caches.


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Task #102821: Drop \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPItoST43Under Review2024-01-11

Actions
Actions

Also available in: Atom PDF