Extension points 

What the promise means 

Public API does not change silently. A release that breaks or deprecates anything listed on this page says so in the changelog of the extension:

• a Breaking entry when existing code stops working, with the migration;
• a Deprecation entry when the old way keeps working until the next major version, and says what replaces it.

Anything else may change in any release, a bugfix release included, and without a changelog entry. Code that relies on it has to be checked on every update.

What is public API 

• The events, and the types they hand to a listener.
• The interfaces.
• The services and classes a project names in its configuration or its code.
• The base class of a profile factory.
• The two traits of academic_base for Extbase controllers.
• The domain models: their public getters, which the templates read, and extending them to add fields.
• Templates, partials and sections: their paths below Resources/Private/, the names of their sections, the variables they receive, and the ViewHelpers they call, by tag name and arguments. The Templates chapter of each extension describes how to override them.
• Settings: the site settings of the site sets, the TypoScript constants and settings, and the settings of the content elements.
• The TypoScript and page TSconfig keys the extensions document.
• The keys of the language files, which a site overrides labels by.
• The identifiers academic-persons/apply-settings-to-tca and academic-jobs/apply-settings-to-tca of the listeners that apply the persons and the jobs settings to the compiled TCA, so that a listener of \TYPO3\CMS\Core\Configuration\Event\AfterTcaCompilationEvent can be ordered after them. The listener classes are not public API.
• The format of Configuration/CategoryTypes.yaml, see the category types chapter of category_types.
• The routing aspect type CategoryFilterMapper of category_types and its settings, see the routing chapter of category_types. The class behind it is not public API.
• The format of Configuration/FrontendIcons.php, the frontend icon registry of academic_base: the format of Configuration/Icons.php, read from every active package, and a package loaded later replaces an identifier, see Frontend icons.
• The view helper icon of academic_base, in the namespace http://typo3.org/ns/FGTCLB/AcademicBase/ViewHelpers, by tag name and arguments, which renders an icon of the frontend icon registry, and the identifier default-not-found of the icon it renders for an unknown identifier. The class behind it is not public API.
• The view helper frontendIconMap of academic_base, in the same namespace, by tag name and arguments, and the JSON data block it renders: the element <script type="application/json" data-academic-icons> , its data-academic-icons-* attributes and the object of identifier and markup it holds, see Icons in frontend JavaScript. Which icons it serves is part of the contract, see Which icons are served. The class behind it is not public API.
• The icon endpoint of academic_base, _academic/icons.json below the base of every site and site language: its path, its parameters, the JSON object it answers, its status codes and its caching headers, see The icon endpoint. The middleware behind it is not public API.
• The JavaScript module @fgtclb/academic-base/frontend/icons.js of academic_base and its exports, IconFactory , endpointFrom() , Sizes , Size , IconEndpoint and IDENTIFIER_PATTERN , see The icon factory.
• The view helper ct:categoryTypeTitle of category_types, by tag name and arguments, which names a category type in a template by its registered title, see naming a type in a template. The class behind it is not public API.

What is not public API 

Everything else. In particular:

• Controllers. Every plugin controller is final , so neither a subclass nor an XCLASS of one loads. A plugin is extended through its events: every plugin action that renders a view dispatches the plugin view event, except the profile editing of academic_persons_edit, which offers each of its writes to an event instead. The partner, program and project lists and the program finder dispatch a demand and a list event as well, and the B-ITE job list a request and a result event.
• Repositories. A condition a plugin should apply belongs in a demand or a query event, not in an XCLASS of the repository.
• Services, data processors, ViewHelper classes, backend item providers, hooks, event listeners, commands and upgrade wizards, except the few a project names. A service is replaced through the container where it is registered behind one of the interfaces below, never by subclassing it.
• Everything marked @internal . The marker says in the code what the absence of @api says for the rest.

An XCLASS is unsupported for every class but a domain model, listed or not: a listed class keeps what it promises to a caller, not what it offers to a subclass. The upgrade check reports such an XCLASS as a warning, and as an error when the class is final or gone. How to extend a model is described under Domain models.

Events 

Every event is a final class, dispatched through the PSR-14 event dispatcher of TYPO3. A listener registers for it with the #[AsEventListener] attribute of TYPO3. The developer chapters of academic_bite_jobs, academic_contacts4pages, academic_persons, academic_persons_edit, academic_partners, academic_programs and academic_projects describe their events in detail, with examples.

One event is not on this list. The event the commands academic:createprofiles and academic:updateprofiles dispatch before they set up the environment of a frontend user's site, ModifyProfileCommandEnvironmentStateBuildContextForFrontendUserEvent , is marked @internal as experimental, like the environment handling it belongs to. The event the 2.4 changelog of academic_persons_edit mentions for filling form data from other sources before it is written is BeforeProfileEditingWriteEvent from 3.0 on.

namespace MyVendor\MySitepackage\EventListener;

use FGTCLB\AcademicBase\Event\ModifyPluginViewEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;

final class AddOfficeHoursLink
{
    #[AsEventListener]
    public function __invoke(ModifyPluginViewEvent $event): void
    {
        $context = $event->getPluginControllerActionContext();
        if ($context->getControllerExtensionName() !== 'AcademicPersons'
            || $context->getActionName() !== 'detail'
        ) {
            return;
        }
        $event->getView()->assign('officeHoursPageId', 42);
    }
}

What an event hands over 

A listener types against whatever an event's methods declare, so these types are public API together with the events. Classes of TYPO3 and of other packages are not listed; their own documentation applies.

Interfaces 

A project implements an interface, types against it, or aliases it to an implementation of its own where the container hands one out.

The abstract classes that implement some of them for the extensions themselves are not public API.

Services and classes a project names 

These are named in a project's configuration, or injected into its code. Use them as they are; they are not meant to be subclassed or replaced.

Base classes 

Traits 

Domain models 

The domain models are what the templates read, so their public getters are public API. A project may extend a model to add fields of its own. Extbase creates a model through GeneralUtility::getClassName() , so the way to do that is a subclass registered as the XCLASS of the model:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects'][\FGTCLB\AcademicPersons\Domain\Model\Profile::class] = [
    'className' => \MyVendor\MyExtension\Domain\Model\Profile::class,
];

Extbase maps the subclass by its own class name, so it needs an entry in the project's Configuration/Extbase/Persistence/Classes.php: the tableName of the model, and its recordType if the extension declares one - a subclass inherits the properties of the parent entry, but neither of those two. The new columns need their TCA and their database fields; a properties entry is needed only for a column whose name does not match the property. A model the extensions create themselves with new , a profile a profile factory creates for instance, is still of the original class. The upgrade check lists such an XCLASS as a notice: it does not fail the check, and it is a reminder to make sure the getters and setters the subclass overrides still exist after an update.

The models of category_types are not Extbase models; the extension builds them itself. Their getters are public API all the same, but they cannot be extended through an XCLASS.

The extension points every extension should have 

Three kinds of extension point together make subclassing and XCLASSing unnecessary. Not every extension offers all three yet:

A planned extension point is listed here once it is dispatched, and not before.