All TYPO3 extensions installed with Composer are now considered to be
active and therefore can and will interact with TYPO3 API.
At Composer install time a persistent artifact is created, holding the
information which extensions are installed and the path where these
reside. This makes the typo3conf/PackageStates.php file obsolete and
it is neither created nor evaluated anymore.
For Composer based installs the artifact is located at
vendor/typo3/PackageArtifact.php. This file must be deployed together
with all other Composer dependencies. In a TYPO3v11 sprint this file was
located at var/build/PackageArtifact.php which did need a special
handling and caused some issues for example on platform.sh, which were
solved by storing it in the vendor folder.
Any extension present in the typo3conf/ext folder, but not installed
by Composer, will still be considered and marked as part of TYPO3
packages when executing composer install. The only requirement here
is, that such extensions need a composer.json file nonetheless. Note
this behaviour is deprecated and will be removed with TYPO3 v12.
Because all extensions present in the system are considered to be
active, the Extension Manager UI is adapted to not allow changing the
active state of extensions anymore for composer based instances.
Respectively the commands extension:activate and
extension:deactivate are disabled in Composer managed systems as well.
A new command extension:setup is introduced, which supersedes both the
extension manager UI as well as the activate/deactivate commands. It
performs all steps that were performed during activation and
deactivation (the active-state is of course not changed).
With the command extension:setupall extensions are set up in terms
of database schema changes, static data import, distribution files
imports, etc. As example, requiring an additional extension and then
using this command will create database tables or additional database
fields the extension provides.
Any installed Composer package that defines an
extra.typo3/cms section in their
composer.json file will be considered a TYPO3 extension and will have
full access to the TYPO3 API.
However, because these Composer packages reside in the vendor folder,
they can not deliver public resources. This remains exclusive for TYPO3
extensions installed into typo3conf/ext for now - those composer
packages that not only have a
extra.typo3/cms section, but are also of
type typo3-cms-extension.
Impact
In Composer mode this has the following impact:
The PackageStates.php file is completely ignored. When migrating
projects that still have this file e.g. under version control, it is
recommended to remove this file.
Projects with extensions that reside directly in typo3conf/ext, and
which therefore are not installed with Composer, should consider
migrating them to a local path repository. In any case, such extensions
now require to have a composer.json file. This file can be created by
using the according UI in the Extension Manager.
When working on a Composer based project and adding new extensions via
the Composer cli tool during development, all added extensions are
considered active automatically, but are not yet set up in terms of
database schema changes for example. The TYPO3 cli command
extension:setup needs to be executed additionally. extension:setup
can and should also be used, when deploying a TYPO3 project to make sure
database schema is up to date.
The Composer root project package will be recognized as a TYPO3
extension as well, if it provides a
extra.typo3/cms section in its
composer.json, as mentioned above.
Because this package, like packages in the
vendor folder isn't accessible by the web
server, the root package can not deliver public resources as well.
However, when extensions are used as root package for testing (e.g., for
running unit, functional or integration tests in a CI pipeline) and
these extensions have files in the
Resources/Public directory, a symlink in
the typo3conf/ext directory is
automatically created. Additionally the package path is adapted to be
inside typo3conf/ext. This allows TYPO3
to properly calculate URLs for public resources of this extension.
If the root package isn't of type
typo3-cms-extension or does not have a
Resources/Public directory the absolute
path to the extension remains the original path to the composer root
directory and no symlink is created.
This special behaviour for root packages of type
typo3-cms-extension is introduced as a
temporary fix to ease extension testing. It is explicitly NOT
recommended to use such a setup in production.
The ext_emconf.php file of extensions is now obsolete and therefore
completely ignored in Composer based instances. Make sure the
information in the composer.json file is in sync with the one in your
ext_emconf.php file in case you want to provide one for compatibility
with non Composer mode.
Feature: #94996 - Consider all Composer installed extensions as active
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.4/Feature-94996-ConsiderAllComposerInstalledExtensionsAsActive.html
Feature: #94996 - Consider all Composer installed extensions as active
See 94996
Description
All TYPO3 extensions installed with Composer are now considered to be active and therefore can and will interact with TYPO3 API.
At Composer install time a persistent artifact is created, holding the information which extensions are installed and the path where these reside. This makes the
typo3conf/PackageStates.phpfile obsolete and it is neither created nor evaluated anymore.For Composer based installs the artifact is located at
vendor/typo3/PackageArtifact.php. This file must be deployed together with all other Composer dependencies. In a TYPO3v11 sprint this file was located atvar/build/PackageArtifact.phpwhich did need a special handling and caused some issues for example on platform.sh, which were solved by storing it in the vendor folder.Any extension present in the
typo3conf/extfolder, but not installed by Composer, will still be considered and marked as part of TYPO3 packages when executingcomposer install. The only requirement here is, that such extensions need acomposer.jsonfile nonetheless. Note this behaviour is deprecated and will be removed with TYPO3 v12.Because all extensions present in the system are considered to be active, the Extension Manager UI is adapted to not allow changing the active state of extensions anymore for composer based instances. Respectively the commands
extension:activateandextension:deactivateare disabled in Composer managed systems as well.A new command
extension:setupis introduced, which supersedes both the extension manager UI as well as the activate/deactivate commands. It performs all steps that were performed during activation and deactivation (the active-state is of course not changed).With the command
extension:setupall extensions are set up in terms of database schema changes, static data import, distribution files imports, etc. As example, requiring an additional extension and then using this command will create database tables or additional database fields the extension provides.Any installed Composer package that defines an extra.typo3/cms section in their
composer.jsonfile will be considered a TYPO3 extension and will have full access to the TYPO3 API.However, because these Composer packages reside in the
vendorfolder, they can not deliver public resources. This remains exclusive for TYPO3 extensions installed intotypo3conf/extfor now - those composer packages that not only have a extra.typo3/cms section, but are also of type typo3-cms-extension.Impact
In Composer mode this has the following impact:
The
PackageStates.phpfile is completely ignored. When migrating projects that still have this file e.g. under version control, it is recommended to remove this file.Projects with extensions that reside directly in
typo3conf/ext, and which therefore are not installed with Composer, should consider migrating them to a local path repository. In any case, such extensions now require to have acomposer.jsonfile. This file can be created by using the according UI in the Extension Manager.When working on a Composer based project and adding new extensions via the Composer cli tool during development, all added extensions are considered active automatically, but are not yet set up in terms of database schema changes for example. The TYPO3 cli command
extension:setupneeds to be executed additionally.extension:setupcan and should also be used, when deploying a TYPO3 project to make sure database schema is up to date.The Composer root project package will be recognized as a TYPO3 extension as well, if it provides a extra.typo3/cms section in its composer.json, as mentioned above. Because this package, like packages in the vendor folder isn't accessible by the web server, the root package can not deliver public resources as well.
However, when extensions are used as root package for testing (e.g., for running unit, functional or integration tests in a CI pipeline) and these extensions have files in the Resources/Public directory, a symlink in the typo3conf/ext directory is automatically created. Additionally the package path is adapted to be inside typo3conf/ext. This allows TYPO3 to properly calculate URLs for public resources of this extension.
If the root package isn't of type typo3-cms-extension or does not have a Resources/Public directory the absolute path to the extension remains the original path to the composer root directory and no symlink is created.
This special behaviour for root packages of type typo3-cms-extension is introduced as a temporary fix to ease extension testing. It is explicitly NOT recommended to use such a setup in production.
The
ext_emconf.phpfile of extensions is now obsolete and therefore completely ignored in Composer based instances. Make sure the information in thecomposer.jsonfile is in sync with the one in yourext_emconf.phpfile in case you want to provide one for compatibility with non Composer mode.