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

Blueprints/Packagemanager

From TYPO3Wiki
Jump to: navigation, search

<- Back to blueprints overview

Blueprint: Packagemanager

Proposal Implement a proper Extension and Package API
Owner/Starter Thomas Maroschik
Participants/Members -
Status Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn
Current Progress Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed, DONE
Topic for Gerrit packagemanager-in-cms

Target Versions/Milestones

  • Started during TYPO3 CMS 6.1 development
  • Targeted for TYPO3 CMS 6.2

Goals / Motivation

Goals

  • Proper API for Package Management
  • Vendor Namespace Support
  • Composer Package Support
  • Flow Package Support
  • Autoloader refactoring

By the end of 2012 a prototypical Flow implementation in CMS has been explored. The Package Manager of the prototype delivered the base for this implementation.

Concept

Some classes out of Flow's Package subpackage will be placed into the core extensions Resources folder. These work as a common interface for the packages and establish a common ground between CMS Extensions and Flow Packages. The CMS Package Manager extends the Flow Package Manager and adapts the behavior to CMS needs. The CMS Package Class extends the Flow Package Class and implements a fallback handling for ext_emconf.php metadata. Flow's Package Class assumes just the presence of a composer.json file in that regard. The autoloader and the very initial bootstrapping process will be reworked in order to introduce the Package Manager. A silent upgrader will be provided for the introduction of the PackageStates.php file.

Implementation Details

  • $TYPO3_CONF['EXT']['extListArray'] will be removed
    • A fallback replacement ArrayObject will be provided that handles requests to this array transparently
  • A PackageStates.php file will be created in order to capture the active/inactive state of extensions and their location
  • A Failsafe Mode for the Installer will be established that boots solely the required packages
  • In order to be able to rename the sysexts to Flow's vendor namespaced package keys a package/extension key alias system will be established
  • The following paths relative to PATH_site will be scanned for extensions/packages:
    • typo3/sysext
    • typo3/ext
    • typo3/contrib
    • typo3conf/ext
    • Packages/ (recursively)
  • Required extensions will become required by a protected flag in their Package class.
    • If PackageStates.php will be deleted and no extListArray is present in Local Configuration the system will recreate the PackageStates.php file and activate only required packages.
  • The autoloader gets a custom caching backend
    • The backend creates "proxy require" files so that the memory consumption of the autoloader is lowered
    • Classname to file mappings are resolved through those "file links"
    • A future Flow implementation in CMS can use this to place the compiled classes instead of the links into the caching backend
  • The class alias mechanism will be separated from the autoloader
    • It will append the class aliases to the "proxy require" files, so that the class alias map does not have to be loaded into memory

Risks

  • Performance impacts through higher object count
    • Can and will be mitigated with further patches and better PHP OO implementation
  • is_array checks upon $TYPO3_CONF['EXT']['extListArray']

Issues and reviews

https://review.typo3.org/19605

Mailing List Topics

https://forum.typo3.org/index.php/m/698229/#msg_698229