All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh


From TYPO3Wiki
Jump to: navigation, search

<- Back to blueprints overview

Blueprint: Unified Hook and Signal Slot Registration

Proposal Determine a concrete hook definition and registration within Packages
Owner/Starter Benni Mack
Participants/Members -
Status Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn
Current Progress Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed
Topic for Gerrit ###gerrit_topic###

Target Versions/Milestones

  • Brainstorming started during TYPO3 CMS 7 development
  • Implementation is set for v7.3 (once we agreed on the idea)

Goals / Motivation

The TYPO3 Core uses Hooks and Signal Slots in more than 30 ways, some are improperly configured (Design Pattern of Signals should not modify anything) and have different syntax most of the time. The names of the hooks are outdated. Additionally all hooks are registered at runtime on the global array $TYPO3_CONF_VARS['SC_OPTIONS'] in ext_localconf.php. A common place for registering and calling hooks should be implemented. Same goes for Signals. This way the caching of the hooks is separated from the rest of the logic in ext_localconf.php.


A main class named "HookManager" that loads and caches all hooks that are registered, thus takes all PHP files based on Configuration/Hooks/* which return arrays with the information about a hook (a name / ID of the hook, currently SC_OPTIONS.... but can be replaced to something else) and a "getItemsForHook($hookId)" which returns all items where the hook can actually do what he wants with them. At a later step this could be even improved to have the HookManager call the hookItems directly.

It is still open if the registration is "Configuration" or something else, as callback functions could be registered as well.

Implementation Details


Issues and reviews

Dependencies upon other Blueprints

External links for clarification of technologies