...
The fine print: bundled with eZ Publish Platform is a Composer extension which makes it possible to store authentication information in that file.
Using composer
...
Update workflow
This section describes a best practice for use of composer, essentially it suggests treating updates like other code/configuration/* changes on your project tackling them on a development machine before staging them for roll out on staging/prod.
1. Running composer update and version changes in development
Updating eZ Publish Platform via composer is nothing different then updating other projects via composer, but for illustration here is how you update your project locally:
...
| Info | ||
|---|---|---|
| ||
| Tip: This will load in all updated packages, from eZ as well as third party libraries both used by eZ and others you may have added. So when updating like this it is recommended to take note of what was updated so you have an idea of what you should test before putting the updates into production. |
When this has completed, At this stage you might need to manually clear Symfony's prod environment class cache (cached interfaces and lazy services) in case the classes/interfaces in it has changed, this can be done in the following way:
| Code Block | ||||
|---|---|---|---|---|
| ||||
rm -f ezpublish/cache/prod/*.php |
When update has completed, and local install is verified to work, make sure to version (assuming you use a version control system) changes done to composer.lock file. This is the file that contains all details of which versions are currently used and makes sure the same version is used among all developers, staging and eventually production when current changes are approved for production (assuming you have a workflow for this).
...
| Info | ||
|---|---|---|
| ||
| Tip2: In large development teams make sure people don't blindly update and install third party components, this might easily lead to version conflicts on composer.lock file and can be tiring to fix-up if happening frequently. A workflow involving composer install and unit test execution on proposed changes can help avoid most of this, like available via Github/Bitbucket Pull Request workflow. |
...
2. Installing versioned updates on other development machines and/or staging
Installing eZ Publish Platform packages via Composer is nothing different then installing vanilla packages via Composer, and for illustration here is how you install versioned updates:
...
| Info | ||
|---|---|---|
| ||
| Tip: Here the importance of composer.lock comes in as this command will tell composer to install packages in exactly same version as defined in composer.lock. If you don't keep track of composer.lock it will instead just install always latests version of a package, hence not allow you to stage updates before moving it towards production. |
...
General notes on use of composer
Installing additional eZ packages via composer
Also requiring eZ Publish Platform packages via composer is nothing different then requiring vanilla packages via Composer, and for illustration here is how you install a eZ package:
| Code Block | ||
|---|---|---|
| ||
php -d memory_limit=-1 composer.phar require --prefer-dist ezsystems/ezfind-ls:5.3.* |
...
Using Composer with Legacy
(eZ Publish) Legacy by design places all important customizable folders within it's own structure. This is not ideal with Composer, as installation and updates might cause them to become as provided by packages again.
To make sure you are safe from this, and to allow you to version these custom folders independently, it is recommended that you use symlinks and keep your custom settings, extensions and design outside of the ezpublish_legacy folder. To not have to manually deal with these symlinks it is recommended to use Composer post-install-cmd and post-update-command script commands to make this automated.
...