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

Blueprints/ModuleRegistration

From TYPO3Wiki
Jump to: navigation, search

<- Back to blueprints overview

Blueprint: Unified Module Registration

Proposal Have one module registration for all modules in the module menu, for extbase modules, for modules in the toolbar loaded on request by convention not by configuration
Owner/Starter Benni Mack
Participants/Members Helmut Hummel, Benni Mack, ?
Status Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn
Current Progress Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed
Topic for Gerrit Modules

Target Versions/Milestones

  • Started during TYPO3 CMS 7.1 development

Goals / Motivation

There are currently several way of registering modules, and most of them are registered in the common ext_tables.php of each extension. There are different ways (with conf.php, via Extbase) to register. Several criterias (position, access, workspace access) are configured at this place.

"Main modules" have to have a separate folder, then there are submodules, which are identified by their parent (e.g. web_list for the common list module where "web" is the web module is the parent, and "list" is the submodule). Then there are module functions (level 3) and modules like "wizards" that are just linked to but not used in the module menu.

Most of it is bundled in $TBE_MODULES and inside the ModuleLoader class which originated more than 10 years ago.

The main goals are

  • load all modules via convention, where configuration files are put as PHP files returning an array (similar to the TCA/tx_mytable.php concept)
  • load all modules available in a separate cache file not on every request but only when needed
  • modules / submodules / module functions should be registered the same way
  • the position of the module / submodule should be configured more clearly
  • each module needs to have an "identifier" (packagename_modulename) instead of web_list (related to the position of the top module), with a fallback logic for existing modules ("legacy identifier")

Concept

  • Have one class that builds and holds the common data, have a legacy layer that builds "TBE_MODULES" again.
  • Only aggregate + load the data when accessing TBE_MODULES, not on every BE request.


Implementation Details

Research

  • Study ModuleLoader PHP class
  • Study ExtensionUtility functions + Extbase registration
  • Study Top Module registration
  • Study TBE_MODULES

Steps

  1. Build the new PHP API class with a deprecation logic
  2. Replace the relevant ExtensionUtility functions inside with the new API, deprecate them with 8, remove them with 9 (?)
  3. Replace ModuleLoader and BackendController access of the Module Menu with the new API.
  4. Documentation
  5. Move all sysext registrations to the new registration concept

Risks

Issues and reviews

External links for clarification of technologies