Date de publication: le mardi 24 mars 2009 à 21h48
Dernière modification: par Pascal BOYER le jeudi 2 septembre 2010 à 08h33
« Article précédent: eZ Publish : faire une sauvegarde
» Article suivant: eZ Publish : modifications apportées à la base de données

07/05/2008 3:31  

This section describes how to upgrade your existing eZ Publish installation to a newer version. 
Cet article décrit la procédure de mise à jour de votre installation eZ Publish existante vers une nouvelle version.

If you are running one of the supported versions, it is recommended to upgrade your installation when the next stable release within that branch is out. The instructions for upgrading within the same stable release branch can be found in the upgrade manuals of that branch. 
Si vous faites tourner l'une des versions supportées , il est recommandé de la mettre à jour lorsque sort une nouvelle version stable de la même branche. Les instructions de mise à jour au sein d'une même branche stable sont disponibles dans les manuels de mise à jour de cette branche.

If you are running a version which is no longer supported, it is highly recommended to switch to a supported one. For example, if you are running eZ Publish 3.7, consider upgrading to version 3.9 or later. In order to benefit from the latest security and bug fixes, choose the latest stable release in the desired branch. You can either upgrade directly or split the upgrade process into several stages (depending on the number of stable release branches between your current version and the desired one). 
Si vous faites tourner une version n'étant plus maintenue, il est alors grandement conseillé de passer à l'une des versions supportées. Si vous avez, par exemple, une version 3.7 de eZ Publish, vous devez envisager une mise à jour vers une version 3.9 ou ultérieure. Afin de bénéficier des dernières corrections de sécurité et de bugs, choisissez la dernière version stable de la branche considérée. Vous pouvez pour cela effectuer soit une mise à jour directe soit diviser le processus de mise à jour en différentes étapes ( en fonction du nombre de branches stables qui séparent votre version en production de la version de mise à jour choisie).

Direct upgrade / Mise à jour directe

If you want to upgrade directly from version X to version Y, the upgrade procedure consists of the following steps: 
Si vous souhaitez effectuer une mise à jour directe d'une version X vers une version Y, le processus de mise à jour se compose des étapes suivantes:

1. Upgrading the distribution files to version Y. 
   Mise à jour des fichiers de la distribution vers ceux de la version Y,
2. Upgrading the database schema to version Y following the official upgrade path. 
   Mise à jour du schéma de la base de données vers celui de la version Y en suivant le chemin de mise à jour officiel ,
3. Running the system upgrade scripts for versions between X and Y. 
   Exécuter les scripts de mise à jour du système de la version X vers la version Y,
4. Updating the system configuration for compatibility with all the changes made from version X to Y. 
   Mise à jour de la configuration du système pour conserver la compatibilité avec toutes les modifications effectuées entre les versions X et Y,
5. Clearing the caches. 
   Effacer les caches.

This procedure is only applicable when upgrading to the next stable release branch. Skipping a branch is not recommended, since some of the system upgrade scripts might not be present (or not work correctly) in later versions. The only exception is that you can upgrade directly from eZ Publish 3.6 to version 3.8. 
Cette procédure n'est applicable que dans le cadre d'une mise à jour vers la prochaine version stable de la branche. Omettre une branche n'est pas recommandé dans la mesure où certains scripts de mise à jour du système pourraient être absents (ou ne pas fonctionner correctement) dans les versions ultérieures. La seule exception possible étant la mise à jour d'une version 3.6 de eZ Publish vers une version 3.8.

The instructions for direct upgrading from version 3.a.b to 3.x.y can be found here. In order to upgrade from version 3.10 to 4.0, refer to the eZ Publish 4.0 upgrade manuals. 
Les instructions de mise à jour directe d'une version 3.a.b vers une version 3.x.y est disponible ici . Pour une mise à jour d'une version 3.10 vers une version 4.0, référez-vous à la au manuel de mise à jour vers eZ Publish 4.0 .

Two upgrades / Deux mises à jour

If a lot of changes were made between versions X and Y, you can do the following: 
Si de nombreuses modifications existent entre deux versions X et Y, vous pouvez procéder ainsi:

1. Upgrade from version X to some intermediate version Z. 
   Mise à jour d'une version X vers une version intermédiaire Z,
2. Make sure that your site is working correctly. 
   S'assurer que le site fonctionne correctement,
3. Upgrade from version Z to version Y. 
   Mise à jour de la version Z vers la version Y.

Exemple 1

If you are running eZ Publish 3.8.x, you cannot upgrade directly to 3.10.y, because the system upgrade scripts needed for eZ Publish 3.9 might not work correctly in 3.10. However, you can upgrade to some intermediate version 3.9.z first and then upgrade to version 3.10.y. 
Si vous faites tourner une version 3.8.x de eZ Publish, vous ne pouvez alors procéder à une mise à jour directe vers une version 3.10.y car les scripts de mise à jour du système nécessaires à une version 3.9 pourraient ne pas fonctionner correctement sur une version 3.10. En revanche, vous pouvez effectuer une mise à jour vers une version 3.9.z intermédiaire puis effectuer la mise à jour vers une version 3.10.y.

Exemple 2

It is not possible to upgrade directly from eZ Publish 3.9 to version 4.0, and the 4.0 distribution does not contain upgrade scripts for this. The solution is to upgrade to 3.10 first, and then upgrade to 4.0. 
Il est impossible de procéder à une mise à jour directe d'une version 3.9 de eZ Publish vers une version 4.0 qui ne contient d'ailleurs aucun scripts de mise à jour pour cela. La solution consiste à pratiquer une première mise à jour vers une version 3.10 puis de faire une mise à jour vers une version 4.0.

Multiple upgrades / Plusieurs mises à jour

It is also possible to split the upgrade process into three or more stages. Since each branch introduces a set of new features, you have to do one upgrade for each stable release branch between versions X and Y. For example, if you are running eZ Publish 3.7 and want to run 3.10, you have to upgrade to 3.8 first, then to 3.9 and then finally to 3.10. 
Il est également possible de diviser le processus de mise à jour en trois étapes ou plus. Chaque branche introduisant de nouvelles fonctionnalités, vous devez procéder à une mise jour vers chacune des branches stables qui séparent votre version X de la version Y. Si vous faites tourner, par exemple, une version 3.7 de eZ Publish que vous souhaitez mettre à jour vers une version 3.10, vous devez alors commencer par effectuer une mise à jour vers une version 3.8, poursuivre avec une mise à jour vers une version 3.9 pour finir par une mise à jour vers une version 3.10.

While the last direct upgrade in the chain should be done to the latest stable release in the desired branch, there are two different rules about which versions to choose for preceding upgrades. You can either follow the official upgrade path for database schema changes or select the latest stable release in each branch. The following text describes the advantages and disadvantages of both approaches. 
Alors que la dernière mise à jour directe de cette chaîne de mises à jour doit être réalisée vers la dernière version stable de la branche, il existe deux règles différentes pour choisir les mises à jour précédentes. Vous pouvez soit suivre le chemin de mise à jour officiel  pour les modifications du schéma de bases de données soit sélectionner la dernière version stable de chaque branche. Ce qui suit décrit les avantages et inconvénients des deux approches.

The "database upgrade path" approach / L'approche du chemin de mise à jour de la base de données 

This approach makes it possible to minimize the number of database upgrade scripts involved and avoid situations where you need to skip some parts in the ".sql" files when upgrading the database. In the example above, the official upgrade path for database changes looks like this: 
Cette approche permet de minimiser le nombre de scripts de mise à jour de la base de données invoqués et évite les situations dans lesquelles vous devez ne pas tenir compte de certaines parties des fichiers .sql lors de la mise à jour de la base de données. Dans l'exemple ci-dessus, le chemin de mise à jour officiel des modifications de la base de données ressemble à ceci:

3.7 -> 3.8.0 -> 3.9.0 -> 3.10

This means that you should upgrade to 3.8.0 first, then to 3.9.0 and then finally to 3.10. 
Cela signifie que vous devez procéder dans un premier temps à la mise à jour vers la version 3.8.0 puis à la mise à jour vers la version 3.9.0 pour finir par la mise à jour vers la version 3.10.

The disadvantage of this approach is that you upgrade to early versions in each branch, which may contain bugs that were fixed in later releases. (Important bugs are mentioned in the upgrade instructions for certain versions of eZ Publish. In addition, changelogs provide information about all issues that were fixed in the latest releases.) 
L'inconvénient de cette approche tient dans le fait que vous devez effectuer une mise à jour vers des versions antérieures de chaque branche pouvant contenir des bugs corrigés par des versions ultérieures. (Les bugs importants sont mentionnés par les instructions de mise à jour de certaines versions de eZ Publish. Par ailleurs, les changelogs fournissent des informations sur tous les problèmes corrigés par les dernières versions).

If an early version contains a bug that may corrupt your data, you can either fix the problem yourself (if possible) or upgrade to a later release where this issue was fixed. For example, when upgrading from 3.8 to 3.9 you need to run the "correctxmltext.php" upgrade script. If you run this script when upgrading to 3.9.0, it will crash due to a bug. To make it work, you need to edit the script file manually as described here. Another option is to skip version 3.9.0 and upgrade directly to version 3.9.1 or a later 3.9.x release where the updated version of the script is available. 
Si une version moins récente contient des bugs pouvant corrompre vos données, vous pouvez soit corriger le problème vous-même (si possible), soit faire une mise à jour vers une version plus récente corrigeant ce problème. Par exemple, vous devez, lors d'une mise à jour d'une version 3.8 vers une version 3.9, exécuter le script correctxmltext.php. Son exécution au cours d'une mise à jour vers une version 3.9.0 ne fonctionnera pas en raison de la présence d'un bug. Pour que cela fonctionne vous devez éditer manuellement le script comme décrit ici . Une autre solution consiste à éviter la version 3.9.0 pour passer directement à la mise à jour vers la version 3.9.1 ou 3.9.3 ou vers la dernière version 3.9.x pour laquelle le script corrigé existe.

The "latest stable release" approach / Approche de la dernière version stable 

Upgrading directly to the latest stable release in every branch between X and Y allows you to avoid dealing with possible bugs that might be present in earlier versions. With this approach, the path for upgrading from eZ Publish 3.7 to version 3.10 would look like this: 
Mettre directement à jour vers la dernière version stable de chaque branche comprise entre les versions X et Y vous permet d'éviter la confrontation avec de possibles bugs présents dans les versions précédentes. Avec cette approche, le chemin de mise à jour d'une version 3.7 de eZ Publish vers une version 3.10 ressemble à ceci:

3.7 -> 3.8.10 -> 3.9.4 -> 3.10

This means that you should upgrade to 3.8.10 first, then to 3.9.4 (the latest stable release in the 3.9.x branch at the time of writing) and then finally to 3.10. 
Cela signifie que vous devez procéder dans un premier temps à la mise à jour vers la version 3.8.10 puis à la mise à jour vers la version 3.9.4 (la dernière version stable de la branche 3.9 à l'heure d'écrire ces lignes) pour finir par la mise à jour vers la version 3.10.

Generally, this approach requires running more database upgrade scripts than the previous one (since there is usually one database upgrade script for each stable release). However, you can reduce the number of database upgrade scripts to run by skipping all version-focused scripts for intermediary versions. 
En général, cette approche implique l'exécution de plus de scripts de mise à jour de la base de données que dans le cas de la précédente approche (puisqu'il y a un script de mise à jour pour chaque version stable). Cependant, vous pouvez réduire le nombre de ces scripts à exécuter en passant tous les scripts liés aux version intermédiaires .

The disadvantage of the "latest stable release" approach is that you might have to skip some parts of the database upgrade scripts if the database schema was changed from previous stable releases within the same branch. This is because the upgrade scripts between branches contain all of the necessary schema changes from the first stable release in the older branch to the first stable release in the newer branch. (Refer to "Notes about database changes" for more information about the database schema changes within stable release branches.) 
L'inconvénient de cette approche réside dans le fait que vous devrez passer certaines parties des scripts de mise à jour si le schéma de la base de données a été modifié depuis la précédente version stable de la même branche. Ceci est dû au fait que les scripts de mise à jour entre branches contiennent toutes les modifications du schéma de la base de données nécessaires depuis la première version stable de la précédente branche jusqu'à la première version stable de la nouvelle branche. Référez-vous au document Notes sur les modifications de la base de données  pour de plus amples informations sur les modifications du schéma de la base de données des branches stables.

For example, in eZ Publish 3.8.5, some database schema changes were introduced as a bug fix for missing indexes in database tables. The fix was added to both eZ Publish 3.8.5 and 3.9.0 beta1 and included in the following database upgrade scripts: 
Dans eZ Publish 3.8.5 par exemple, certains schémas de la base de données ont été ajoutés pour corriger un bug d' index manquant dans des tables de la base de données . Cette correction a été ajoutée aux versions 3.8.5 et 3.9.0 beta1 de eZ Publish et incluent les scripts de mise à jour de la base de données suivants:

• .../3.8/ dbupdate-3.8.4-to-3.8.5.sql 
• .../3.9/unstable/ dbupdate-3.9.0alpha1-to-3.9.0beta1.sql 
• .../3.9/ dbupdate-3.8.0-to-3.9.0.sql 

If you are upgrading to eZ Publish 3.9 from version 3.8.5 or later, running the "dbupdate-3.8.0-to-3.9.0.sql" upgrade script will produce an error, because your 3.8.5 database already contains some of the database schema changes included in this ".sql" file. The solution is to skip the part marked with "from 3.8.5" comments in this file. 
Si vous procédez à la mise à jour d'une version 3.8.5 (ou ultérieure) vers une version 3.9 de eZ Publish alors l'exécution du script dbupdate-3.8.0-to-3.9.0.sql produira une erreur car votre base de données 3.8.5 contient déjà certaines modifications du schéma de la base de données inclusent dans le fichier .sql. La solution consiste donc à ne pas tenir compte de la partie de ce fichier marquée from 3.8.5.

Commentaires