102 lines
5.3 KiB
ReStructuredText
102 lines
5.3 KiB
ReStructuredText
.. include:: /Includes.rst.txt
|
|
|
|
.. _feature-94996:
|
|
|
|
======================================================================
|
|
Feature: #94996 - Consider all Composer installed extensions as active
|
|
======================================================================
|
|
|
|
See :issue:`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 :file:`typo3conf/PackageStates.php` file obsolete and it is neither created nor
|
|
evaluated anymore.
|
|
|
|
For Composer based installs the artifact is located at
|
|
:file:`vendor/typo3/PackageArtifact.php`. This file must be deployed
|
|
together with all other Composer dependencies. In a TYPO3v11 sprint this file was located at
|
|
:file:`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 :file:`typo3conf/ext` folder, but not installed by Composer,
|
|
will still be considered and marked as part of TYPO3 packages when executing
|
|
:bash:`composer install`. The only requirement here is, that such extensions need a
|
|
:file:`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
|
|
:bash:`extension:activate` and :bash:`extension:deactivate` are disabled in Composer managed
|
|
systems as well.
|
|
|
|
A new command :bash:`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 :bash:`extension:setup` *all* 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 :file:`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 :file:`vendor` folder, they can
|
|
not deliver public resources. This remains exclusive for TYPO3 extensions
|
|
installed into :file:`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 :file:`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 :file:`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 :file:`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 :bash:`extension:setup` needs to be executed additionally. :bash:`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 :file:`ext_emconf.php` file of extensions is now obsolete and therefore completely ignored
|
|
in Composer based instances. Make sure the information in the :file:`composer.json` file is in
|
|
sync with the one in your :file:`ext_emconf.php` file in case you want to provide one for
|
|
compatibility with non Composer mode.
|
|
|
|
.. index:: CLI, ext:core
|