This page explains how to update eZ Platform to a new version.
In the instructions below, replace <version> with the=
version of eZ Platform you are updating to (for example: v1.7.0). If you are testing a release candidate, use the latest rc tag (for example: v1.7.1-rc1).
Some versions introduce new features that require taking special= steps; they are marked on this page with yellow tags.
If you intend to skip a version (for example, update directly from v1.3 = to v1.5 without getting v1.4), remember to look at all the intermediate ste= ps as well =E2=80=93 this means you need to perform both the steps for v1.4= and v1.5.
1.1. From the project's root, create a new branch from = the project's master, or from the branch you're updating on:
git checkout -b <branch_name>=20
This creates a new project branch for the update based on your current p=
roject branch, typically master. An example <branch_n=
ame> would be update-1.4.
1.2. If it's not there, add ezsystems/ezplatform<=
/code> (or ezsystems/ezstudio, when updating an Enterpris=
e installation) as an upstream remote:
git remote add ezplatform http://github.com/ezsystems/ezplatform.g= it or git remote add ezstudio http://github.com/ezsystems/ezstudio.git=20
1.3. Then pull the tag into your branch.
If you are unsure which version to pull, run git ls-remote --tags<=
/code> to list all possible tags.
git pull ezplatform <version> or git pull ezstudio <version>=20
At this stage you may get conflicts, which are a normal part of the proc=
edure and no reason to worry. The most common ones will be on compose=
r.json and composer.lock.
The latter can be ignored, as it will be regenerated when we execute
If you get a lot of conflicts (on the doc folder for instance), and eZ Platform was installed from the share.e=
z.no tarball, it might be because of incomplete history. You will have =
to run git fetch ezplatform --unshallow (or git fet=
ch ezstudio --unshallow) to load the full history, and run the merge=
again.
git checkout --theirs composer.lock && git add composer.lo= ck=20
If you do not keep a copy in the branch, you may also run:
git rm composer.lock=20
Conflicts in composer.json need to be fixed manually. =
If you're not familiar with the diff output, you may checkout the tag's ver=
sion and inspect the changes. It should be readable for most:
git checkout --theirs composer.json && git diff HEAD compo= ser.json=20
You should see what was changed, as compared to your own version, in the=
diff output. The update changes the requirements for all of the git checkout -p to selectively cancel those changes:=
git checkout -p composer.json=20
Answer no (do not discard) to the requirement cha=
nges of ezsystems dependencies. Answer yes&n=
bsp;(discard) to removals of your changes.
Once you are done, inspect the file, either using an editor or by runnin=
g git diff composer.json. You may also test the file's sanity =
with composer validate, and test the dependencies by runn=
ing composer update --dry-run. (will output what it would=
do to dependencies, without applying the changes.
Once finished, run git add composer.json and commit
Depending on the local changes you have done, you may get other conflict= s on configuration files, kernel, etc.
There shouldn't be many, and you should be able to figure out which valu= e is the right one for all of them:
git add conflicting-file to add the changes<=
/li>
At this point, you should have a composer.json file with th=
e correct requirements. Run composer update to update the=
dependencies.
composer update=20
If you want to first test how the update proceeds without actually updat=
ing any packages, you can try the command with the --dry-run switch:
composer update --dry-run
On PHP conflict | 16.02 and later requires PHP 5.5 or hi= gher
Because from release 16.02 onwards eZ Platform is compatible only with P= HP 5.5 and higher, the update command above will fail if you use an older P= HP version. Please update PHP to proceed.
This step is only relevant for some releases:
1.7.0
To enable the Form Builder feature in eZ Platform Enterprise Edition, im= port the following file:
mysql -p -u <database_user> <database_name> < vendor= /ezsystems/ezstudio-form-builder/bundle/Resources/install/form_builder.sql<= /pre>=20
1.7.0
To enable the Date-Based Publisher feature in Enterprise, import the fol= lowing file:
mysql -p -u <database_user> <database_name> < vendor= /ezsystems/date-based-publisher/bundle/Resources/install/datebasedpublisher= _scheduled_version.sql=20
In order to activate Date-Based Publisher open console (terminal) and us= e:
crontab -e=20
and add below configuration at the end of edited file.
For production environment:
* * * * * (cd /path/to/your/ezstudio-project && app/conso= le ezpublish:cron:run -e=3Dprod)=20
For development environment:
* * * * * (cd /path/to/your/ezstudio-project && app/conso= le ezpublish:cron:run -e=3Ddev)=20
The web assets must be dumped again if you are using the prod environment. In dev this happens automatically:
php app/console assetic:dump -e=3Dprod=20
If you encounter problems, additionally clear the cache and install asse= ts:
php app/console cache:clear -e=3Dprod php app/console assets:install --symlink -e=3Dprod php app/console assetic:dump -e=3Dprod=20
Once all the conflicts have been resolved, and composer.lock updated, the merge can be committed. Note that you may or may not ke=
ep composer.lock, depending on your version management wo=
rkflow. If you do not wish to keep it, run git reset HEAD <fi=
le> to remove it from the changes. Run git commit=
, and adapt the message if necessary. You can now verify the project=
and once the update has been approved, go back to master, and=
merge your update branch:
git checkout master git merge <branch_name>=20
Your eZ Platform should now be up-to-date with the chosen versio= n!