Building backend modules with Extbase
A backend module is where editors and administrators work with an extension's own data: reviewing submissions, maintaining records that have no frontend form, running reports over the domain model. Extbase is designed for this. The domain models, repositories and validators an extension already has work in a module unchanged, and the module's controllers are ordinary Extbase controllers dispatched by the same code as a frontend plugin.
What changes is everything around the controller. A backend module does not run inside a frontend request, so it reaches Extbase by a different route, reads its configuration from a different place, and resolves its storage pages and its language from the backend rather than from a plugin on a page. Knowing these differences is what makes a module behave predictably.
Registering an Extbase backend module
The two Extbase-specific keys in Configuration/Backend/Modules.php,
access control, labels and rendering through the module template.
How an Extbase backend module works
How a module request reaches the controller, which TypoScript a module sees, and how storage pages and language are resolved.
Building an Extbase backend module without a page tree
A module that stands alone: global configuration, a list with search, filters and pagination, and filters kept in the module data.
Building an Extbase backend module with a page tree
A module that follows the page tree: what the selected page supplies, hidden records in the list, hiding with Core's toggle and answering in an Extbase action.
Editing records from an Extbase backend module
Creating, editing and deleting records with Fluid links to FormEngine and DataHandler, and when a module should write records itself.
See also
- Backend modules API — the module registration reference, which applies to every module whether it uses Extbase or not.
- Button components — buttons and menus in the document header of a module. They are not Extbase-specific and work the same in an Extbase module.