3.2 Hooks, Signals/Slots and XCLASSes

Signals notify developers about security risks in their code

The signal/slot concept can be used to extend TYPO3 core functionality

The signal/slot dispatcher is required to emit a signal

Slots are an abstract instance of a signal class

Signals are classes located in directory Classes/Signals/

Signals are used to write entries to the internal log

Signals are building blocks for domain driven design

Signals are used to connect external data sources to Extbase

Signals are emitted by the TYPO3 core or by extensions to extend existing functionality

Signals/slots extend the TYPO3 core without the need to edit core files

Signals/slots are meant to simulate SQL procedures using pure PHP code

Signals are never marked deprecated and will remain in the TYPO3 core forever

One signal can trigger multiple slots

join()

connect()

attach()

insert()

slot()

XCLASSes prevent cross-site scripting (XSS) attacks

XCLASSes extend core classes and/or overwrite core methods

XCLASSes need to be registered in the file Configuration/Overrides/xclasses.php

XCLASSes need to be registered in the following global array: $GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects']

XCLASSes replace files from TYPO3 source package which possibly impacts the TYPO3 update process

XCLASSes only work on core classes that are instantiated using the GeneralUtility::makeInstance() method

XCLASSes do not work on static classes, static methods or final classes

There can only by one XCLASS per base class

XCLASSes only work in Composer-based TYPO3 installations

The visibility of all properties of an XCLASS must be private