Date de publication: le jeudi 26 mars 2009 à 13h48
Dernière modification: par Pascal BOYER le jeudi 2 septembre 2010 à 21h48
« Article précédent: eZ Publish : modifications apportées à la base de données
» Article suivant: eZ Publish : mise à jour de 3.9.x vers 3.10.y

24/09/2008 3:00

This section describes how to upgrade your existing eZ Publish 3.10.x installation to version 3.10.y, for example from 3.10.0 to 3.10.1. If you are upgrading from a version prior to eZ Publish 3.10.0, refer to the "Upgrading from 3.9.x to 3.10.y" section for upgrade instructions. 
Cet article décrit la mise à jour d'une version eZ Publish 3.10.x existante vers une version 3.10.y comme par exemple d'une version 3.10.0 vers une version 3.10.1. Si vous souhaitez effectuer la mise à jour d'une version antérieure à la version 3.10.0, référez-vous alors aux instructions du document eZ Publish : mise à jour de 3.9.x vers 3.10.y .

It is recommended to upgrade directly to the latest stable release in the 3.10 branch, which contains all important bug fixes. Refer to the changelogs and security advisories for more information about the issues that were fixed in the latest releases or view the short list of changes here. 
Il est recommandé de procéder à une mise à jour directement vers la dernière version stable de la branche 3.10 proposant toutes les corrections de bugs importantes. Référez-vous aux changelogs  et avis de sécurité  pour plus d'information sur les problèmes résolus par les dernières versions stables ou reportez-vous à la courte liste de modifications .

The upgrade procedure described below is generic and does not cover any specific cases. If you are running eZ Publish in a clustered environment, refer to the developer documentation for upgrade instructions. In case the eZ Publish Extension for Oracle® Database is used, refer to the documentation of the database extension.
La procédure générique de mise à jour décrite ci-après ne couvre aucun cas spécifique. Si votre installation eZ Publish tourne dans un environnement clusterisé, référez-vous à la documentation des développeurs  pour les instructions de mise à jour et si vous utilisez l'extension eZ Publish pour les bases de données Oracle®, référez-vous alors à la documentation de l'extension de la base de données .

Make sure that you have a working backup of the site before you do the actual upgrade. The upgrade procedure consists of the following steps: 
Assurez-vous d'être en possession d'une sauvegarde  de votre site avant de vous lancer dans sa mise à jour dont la procédure comprend les étapes suivantes:

1. Upgrading the distribution files to 3.10.1 
   Mettre à jour les fichiers de distribution vers ceux de la version 3.10.1,
2. Upgrading the database to 3.10.1 
   Mettre à jour la base de données pour la rendre compatible avec la version 3.10.1 de eZ Publish, 
3. Running the system upgrade scripts 
   Exécuter les scripts de mise à jour du système,
4. Updating the system configuration 
   Mettre à jour la configuration du système,
5. Clearing the caches 
   Vider les caches.

Etape 1: Upgrading the distribution files / Mettre à jour les fichiers de la distribution

The easiest way to upgrade the distribution files is to unpack eZ Publish 3.10.1 to a directory and then copy the directories that contain site-specific files from the existing installation. Make sure that you copy the following directories: 
Le moyen le plus simple de mettre à jour les fichiers de la distribution consiste à extraire les fichiers de l'archive de eZ Publish 4.0.1 dans un répertoire à part puis d'y copier les répertoires contenant les fichiers spécifiques à l'installation existante (celle à mettre à jour). Assurez-vous d'y copier les répertoires suivants du site existant:

• design/example
• design/example_admin
• var
• settings/siteaccess
• settings/override

Replace "example" and "example_admin" with the actual names of your siteaccesses. 
Remplacez example et example_admin par les vrais noms de vos siteaccess

Custom extensions / Extensions personnelles

If you are using custom extensions, the subdirectories inside the "extension" directory will also have to be copied. However, make sure that you do not overwrite any extensions that come with eZ Publish (currently "ezdhtml", "ezodf", "ezpaypal" and "ezurlaliasmigration"). 
Si vous utilisez des extensions personnelles, les sous-répertoires du répertoire extension/ devront également être copiés. Cependant, assurez-vous de n'écraser aucune des extensions présentes par défaut dans eZ Publish (à savoir les extensions ezdhtml, ezodf, ezpaypal et ezurlaliasmigration).

If you are using the Website Interface front-end, be sure to copy the "extension/ezwebin/" directory. It is also possible to upgrade the Website Interface extension to a newer version (you can find more information and instructions in the "Upgrading the Website Interface" chapter of the Website Interface installation guide). 
Si vous utilisez l' interface Website , assurez-vous de copier le répertoire extension/ezwebin/. Il est également possible de mettre à jour cette interface vers une nouvelle version (vous pouvez trouver plus d'informations et d'instructions au chapitre Upgrading the Website Interface du guide d'installation de l'interface Website ).

Important bug fix for remote IDs / Importante correction de bug lié aux ID distants

Due to some bugs in previous versions of eZ Publish (3.9.0 and others), it might happen that not all content objects in your database have unique remote IDs. This basically means that the "remote_id" column of the "ezcontentobject" table in the database might contain duplicate values. In eZ Publish 3.10.1, a database schema change was introduced in order to ensure that only unique remote IDs can be stored in this table. Because of this, you need to make sure that there are no content objects with identical remote IDs before upgrading the database. This can be done by running the "fixobjectremoteid.php" upgrade script. (Note that both the database schema change and the upgrade script were added to eZ Publish 3.9.5 and 4.0.1 as well.) 
En raison de certains bugs présents dans les précédentes versions de eZ Publish ( 3.9.0 et autres), il peut arriver que tous les objets de contenu stockés par votre base de données n'aient pas un ID distant  unique. Cela signifie que la colonne remote_id de la table ezcontentobject de la base de données peut contenir des valeurs dupliquées. Dans la version 3.10.1 de eZ Publish, une modification du schéma de la base de données a été apportée afin de s'assurer que ne puisse être stockés dans cette table que des ID distants uniques. Vous devez pour cette raison vous assurer, avant la mise à jour de la base de données, qu'il n'existe pas d'objets de contenu ayant le même ID distant. Pour cela, exécutez le script de mise à jour fixobjectremoteid.php (retenez que la modification du schéma de la base de données et le script de mise à jour ont été aussi ajoutés à eZ PUblish 3.9.5 et 4.0.1).

This script should be run once for each database, specifying one siteaccess per database. If you only have a public and an administration siteaccess that share the same database (which is the most typical/usual case), you only need to run the script for one of the siteaccesses. If the siteaccess isn't specified, the default siteaccess will be used. 
Ce script ne doit être exécuté qu'une fois pour chaque base de données et en spécifiant un siteaccess pour chacune d'elles. Si vous n'avez qu'un siteaccess public et d'administration partageant la même base de données (ce qui reste le cas le plus fréquent), vous ne devez exécuter le script que pour l'un des deux siteaccess. Et si ce dernier n'est pas mentionné alors le siteacces par défaut  sera utilisé.

The following example shows how to run the script: 
L'exemple suivant montre comment exécuter le script:

1. Navigate into the eZ Publish 3.10.1 directory. 
   Placez-vous dans le répertoire de eZ Publish 3.10.1,
2. Run the script (replace "example" with the actual name of your siteaccess):  
   Exécutez le script (remplacez example par le vrai nom de votre siteaccess):

php update/common/scripts/3.10/fixobjectremoteid.php -s example

The script will search for objects with non-unique remote IDs. Every time such an object is found, the script will suggest to either display more detailed information or fix the problem automatically. If you choose the first option, the script will display the list of objects that have the same remote ID and let you decide which one should remain unchanged; all other objects in the list will get new remote IDs. Otherwise, the script will fix the problem automatically based on the objects' creation dates. This means that the script will generate new remote IDs for all objects in the list except the one that was created first. 
Le script recherche tous les objets n'ayant pas un ID distant unique. Chaque fois qu'un tel objet est trouvé, le script suggère soit d'afficher une information plus détaillée soit de résoudre le problème automatiquement. Si vous choisissez la première option, le script affichera la liste des objets ayant le même ID distant et vous laissera choisir celui devant rester inchangé. Tous les autres objets de la liste se verront affecter un nouvel ID distant. Dans le cas de la deuxième option, le script corrigera automatiquement tous les problèmes en se basant sur la date de création des objets, ce qui signifie que le script génèrera un nouvel ID distant pour tous les objets excepté pour le premier créé (celui ayant la date de création la plus ancienne).

The optional "--mode" parameter makes it possible to run the script in either "auto-fix" or "manual-fix" mode as shown below. 
Le paramètre optionnel --mode permet d'exécuter le script en mode auto-fix (correction automatique) ou manual-fix (correction manuelle) comme indiqué ci-dessous:

php update/common/scripts/3.10/fixobjectremoteid.php -s example --mode=value

If you replace "value" with "a" in the command above, the script will automatically fix all non-unique remote IDs that are found in the database based on the objects' creation dates. In this case, no further input is required from the user. If you specify "--mode=d", the script will display the list of objects for each non-unique remote ID so that you can manually choose which objects should keep their remote IDs. 
Si vous remplacez, dans la commande ci-dessus, value par a, le script corrigera alors automatiquement tous les IDs distants identiques trouvés dans la base de données en se basant sur la date de création des objets. Dans ce cas, aucune autre saisie n'est requise de votre part. A l'inverse, si vous précisez --mode=d alors le script affichera la liste des objets n'ayant pas un ID distant unique afin que vous puissiez manuellement choisir ceux dont il faudra conserver le ID.

Etape 2: Upgrading the database / Mettre à jour la base de données

The following text describes how a 3.10.0 database can be upgraded to 3.10.1. 
Le texte qui suit explique comment mettre à jour une version 3.10.0 de la base de données vers une version 3.10.1.

MySQL

1. Navigate into the eZ Publish 3.10.1 directory. 
   Placez-vous dans le répertoire d'installation de eZ Publish 3.10.1
2. Run the database upgrade script:  
   Exécutez le script de mise à jour de la base de données:

mysql -u <username> -p<password> <database> < update/database/mysql/3.10/dbupdate-3.10.0-to-3.10.1.sql

Note that the CREATE TABLE statement in the database upgrade script does not specify which storage engine to use (no ENGINE or TYPE option), and thus the default storage engine will be used. Normally, it is MyISAM (starting from MySQL v.3.23). If you are using InnoDB, make sure the default storage engine is set to InnoDB before you run the database upgrade script (refer to the MySQL documentation for information about how to set the default engine). If you were not able to change the MySQL configuration on your server, and the upgrade left you with a mix of table types, you can convert the newly created table to InnoDB using the following SQL query: 
Retenez que la déclaration CREATE TABLE du script de mise à jour de la base de données ne spécifie pas le moteur de stockage à utiliser (pas d'option ENGINE ou TYPE), en conséquence de quoi le moteur de stockage par défaut sera utilisé, normalement le moteur MyISAM (utilisé depuis MySQL v 3.23). Si vous utilisez InnoDB, assurez-vous que le moteur de stockage par défaut soit positionné à InnoDB avant d'exécuter le script de mise à jour de la base de données (référez-vous à la documentation de MySQL  pour savoir comment paramétrer le moteur par défaut). Si vous ne pouvez ou ne parvenez pas à modifier la configuration de votre serveur MySQL et que la mise à jour engendre un mélange des types de tables, vous pouvez associer la nouvelle table créée au moteur InnoDB en exécutant la requête suivante:

ALTER TABLE ezurlwildcard TYPE = innodb;

It is also possible to use the "bin/php/ezconvertmysqltabletype.php" script for database conversion. 
Il est également possible d'utiliser le script bin/php/ezconvertmysqltabletype.php pour effectuer la conversion des tables.

PostgreSQL

1. Navigate into the eZ Publish 3.10.1 directory. 
   Placez-vous dans le répertoire d'installation de eZ Publish 3.10.1
2. Run the database upgrade script:  
   Exécutez le script de mise à jour de la base de données:

psql -d <database> -U <dbowner> < update/database/postgresql/3.10/dbupdate-3.10.0-to-3.10.1.sql

Etape 3: Running the system upgrade scripts / Exécuter les scripts de mise à jour du système

The 3.10.1 version of eZ Publish introduces a couple of important bug fixes and functionality changes. In order to make sure that your site is compatible with these changes, you may need to run a few upgrade scripts. 
La version 3.10.1 de eZ Publish introduit un certain nombre de corrections de bugs importantes et de nouvelles modifications de fonctionnalités. Pour vous assurer que votre site sera compatible avec celles-ci, vous devez exécuter quelques scripts de mise à jour.

Multi-language support for URL aliases / Support multilingue pour les alias d'URL

In eZ Publish 3.10.1, the multi-language support for URL aliases was substantially improved, along with some important bug fixes related to this functionality. In addition, the "bin/php/updateniceurls.php" script was updated and the support for new parameters was added. When upgrading, you need to regenerate all URL aliases that are stored in the "ezurlalias_ml" database table. This basically means that all auto-generated URL aliases will be deleted and then created from scratch by using the "updateniceurls.php" script. However, manual/user-defined URL aliases and URL history entries cannot be regenerated automatically. Instead, these items will be transfered/migrated into a temporary table in the database (hereinafter called "migration table") and then restored at a later stage. This must be done by using the "migrate.php" script, which is included in the "ezurlaliasmigration" extension. This new extension is included in eZ Publish 3.10.1 and provides tools for the purpose of URL alias migration. (Note that the "ezurlaliasmigration" extension was added to eZ Publish 4.0.1 as well.) 
Dans la version 3.10.1, le support multi-langues des alias d'URI  a été largement amélioré grâce à d'importantes corrections de bugs liés à cette fonction. Par ailleurs, le script bin/php/updateniceurls.php a été mis à jour et le support de nouveaux paramètres ajouté. Au cours de la mise à jour, vous devez régénérer tous les alias d'URI stockés dans la table ezurlalias_ml de la base de données. Ce qui signifie que tous les alias d'URL auto-générés  seront supprimés puis recréés en partant de zéro par l'emploi du script updateniceurls.php. Cependant, les alias définis manuellement ou par un utilisateur  et les entrées de l'historique des URL  ne pouvant être automatiquement régénérés, ils sont transférés dans une table temporaire de la base de données (appelée par la suite table de migration) pour être restaurés à une étape ultérieure. Tout ceci est réalisé par l'exécution du script migrate.php inclut dans l'extension ezurlaliasmigration présente dans la version 3.10.1 de eZ Publish et fournissant les outils nécessaires à la migration des alias des URI. (Retenez que l'extension ezurlaliasmigration a également été ajoutée à la version 4.0.1 de eZ Publish).

Follow the instructions below in order to update your URL aliases. 
Suivez les instruction ci-après pour mettre à jour vos alias d'URI.

1. Create a database backup / Créer une sauvegarde de la base de données

Before you continue, create a backup of your database (or at least make sure that you have a backup of the "ezurlalias_ml" table itself). 
Avant de poursuivre, créez une sauvegarde de la base de données (ou assurez-vous tout au moins d'être en possession d'une sauvegarde de la table ezurlalias_ml).

2. Review your configuration settings / Vérifier les paramètres de configuration

In eZ Publish 3.10.1 the default type of URL transformation was changed from "urlalias_iri" to "urlalias". Because of this, you must review your URL alias configuration settings as described below. 
Dans eZ Publish 3.10.1, le type de transformation d'URI par défaut a été modifié pour passer de urlalias_iri à urlalias. Vous devez par conséquent contrôler les paramètres de configuration des alias d'URI comme indiqué ci-dessous.

• If the "TransformationGroup" directive is present in either global override for "site.ini" or "settings/siteaccess/<your_siteaccess>/site.ini.append.php" for all siteaccesses, no configuration changes are required. 
  Si le paramètre TransformationGroup  existe soit dans la surcharge globale du fichier site.ini soit dans le fichier settings/siteaccess/<your_siteaccess>/site.ini.append.php de tous les siteaccess, alors aucune modification de la configuration n'est nécessaire.
• Otherwise, your site makes use of the default type of URL transformation. In eZ Publish 3.10.0, it was "urlalias_iri". When upgrading to 3.10.1, you must explicitly specify "urlalias_iri" using the "TransformationGroup" directive located in the [URLTranslator] section of either "settings/siteaccess/<your_siteaccess>/site.ini.append.php" (for each siteaccess) or "settings/override/site.ini.append.php" (if all your siteaccesses are using the same database). 
  Dans le cas contraire, votre site utilise le type de transformation d'URI par défaut. Dans eZ Publish 3.10.0 ce type était urlalias_iri. Lors de la mise à jour vers la version 3.10.1 vous devez explicitement spécifier urlalias_iri comme valeur du paramètre TransformationGroup placé sous la section [URLTranslator] soit du fichier settings/siteaccess/<your_siteaccess>/site.ini.append.php (pour chaque siteaccess) soit du fichier settings/override/site.ini.append.php (si tous vos siteaccess utilisent la même base de données).

In other words, make sure that your existing URL alias configuration does not change because of the new default value of the "TransformationGroup" directive introduced in 3.10.1. Without this, there might be some broken or inconsistent URLs on your site after upgrading to 3.10.1. 
En d'autres termes, assurez-vous que votre configuration existante des alias d'URI ne soit pas modifiée à cause de la nouvelle valeur par défaut du paramètre TransformationGroup introduit par la version 3.10.1. Sans cela, des URI cassés ou instables pourraient apparaître sur votre site une fois terminée la mise à jour vers eZ Publish 3.10.1.

3. Enable the "ezurlaliasmigration" extension / Activer l'extension ezurlaliasmigration 

The "ezurlaliasmigration" extension must be enabled for all of your siteaccesses. To do this, edit the "site.ini.append.php" file located in the "settings/override" directory and add the following line under the [ExtensionSettings] section: 
L'extension ezurlaliasmigration doit être activée pour tous vos siteaccess. Pour cela, éditez le fichier site.ini.append.php situé dans le répertoire settings/override/ et ajoutez-y la ligne suivante sous la section [ExtensionSettings]:

ActiveExtensions[]=ezurlaliasmigration

Alternatively, you can enable the extension separately for each siteaccess. To do this, edit the "site.ini.append.php" file located in the "settings/siteaccess/example" directory (replace "example" with the name of the target siteaccess) and add the following line under the [ExtensionSettings] section: 
Vous pouvez alternativement activer l'extension pour chacun des siteaccess en éditant le fichier site.ini.append.php situé dans le répertoire settings/siteaccess/example/ (remplacez example par le nom du siteaccess cible) et en y ajoutant, sous la section [ExtensionSettings], la ligne suivante :

ActiveAccessExtensions[]=ezurlaliasmigration

4. Proceed with updating your URL aliases / Procéder à la mise à jour des alias des URI

In order to update your URL aliases, you need to do the following: 
Pour mettre à jour vos alias d'URI, suivez les étapes ci-dessous:

• Create the migration table. 
  Création de la table de migration,
• Transfer your URL aliases to the migration table. 
  Transfert de vos alias d'URI dans la table de migration,
• Remove old URL alias data. 
  Supression des anciens alias d'URI,
• Create new auto-generated URL aliases. 
  Création des nouveaux alias d'URI auto-générés,
• Restore migrated URL data. 
  Restauration des URI migrés.

When upgrading from 3.10.0 to 3.10.1, these operations are exactly the same as when upgrading from version 4.0.0 to 4.0.1. Read the corresponding subsections of the "Upgrading from 4.0.x to 4.0.y" documentation page starting from "4. Create the migration table".
Lors de la mise à jour d'une version 3.10.0 vers une version 3.10.1, ces étapes sont en tous points identiques à celles de la mise à jour d'une version 4.0.0 vers une version 4.0.1. Reportez-vous au paragraphe Créer la table de migration  de l'article eZ Publish : mise à jour de 4.0.x vers 4.0.y.

Binary files uploaded via WebDAV (optional) / Fichiers binaires uploadés via WebDAV (optionnel)

In eZ Publish 3.10.0, there is a bug in the "File" datatype which may cause problems with binary file uploading via WebDAV. The typical symptoms are that the file extension of the uploaded file is missing and that you may not be able to download the file once it is uploaded (refer to http://issues.ez.no/9450 for more information). The same bug exists in eZ Publish 3.9.4 and earlier versions. This issue was fixed in eZ Publish 3.9.5, 3.10.1 and 4.0.0. 
La version 3.10.0 de eZ Publish contient un bug dans le datatype File  pouvant entraîner des problèmes avec les fichiers binaires uploadés via WebDAV. Les symptômes typiques de ce bug sont l'absence des extensions des fichiers uploadés et l'impossibilité de downloader ces derniers (référez-vous au lien http://issues.ez.no/9450  pour de plus amples informations). Ce bug, qui existe dans les versions 3.9.4 et précédentes de eZ Publish, est corrigé dans les versions 3.9.5, 3.10.1 and 4.0.0.

If your site has objects that were created by uploading files via WebDAV and you have configured MIME-type-to-class mapping using the "MimeClassMap[]" directive in an override for "upload.ini", you need to run the "updatebinaryfile.php" script in order to fix the file extensions. (If a content class does not have any attributes that make use of the "File" datatype, instances of this class are not affected.) 
Si votre site contient des objets créés en uploadant des fichiers via WebDAV et que vous avez configuré la correspondance des types MIME avec les classes  grâce au paramètre MimeClassMap[] d'une surcharge du fichier upload.ini, alors vous devez exécuter le script updatebinaryfile.php afin de corriger le problème. (Si une classe de contenu ne contient aucun attribut basé sur le datatype File, alors les instances de cette classe ne sont pas affectées).

Refer to the corresponding part of the "Upgrading from 3.9.x to 3.10.y" documentation page for instructions about how to run the "updatebinaryfile.php" script. 
Référez-vous au paragraphe correspondant  de l'article e Z Publish : mise à jour de 3.9.x vers 3.10.y pour obtenir des informations sur la procédure d'exécution du script updatebinaryfile.php.

Changes to system upgrade scripts (optional) / Modifications des scripts de mise à jour du système (optionnel)

If your solution was initially built on eZ Publish 3.9 or an earlier version and then upgraded to 3.10.0, read this part carefully. Otherwise, skip this part. 
Si votre installation était à l'origine une version 3.9 ou plus ancienne de eZ Publish et que vous avez procédé à la mise à jour vers la version 3.10.0, alors lisez attentivement cette partie. Dans le cas contraire, ignorez-là

The "updatevatcountries.php" upgrade script in eZ Publish 3.10.0 contains a bug. The same bug exists in eZ Publish 3.9.4 and 3.9.3 (refer to http://issues.ez.no/11955 for more information). The updated version of the script is available in eZ Publish 3.9.5, 3.10.1 and 4.0.0. If you previously upgraded to 3.10.0 using the original version of the script, you need to run the updated version of the script when upgrading from 3.10.0 to 3.10.1. Refer to the corresponding part of the "Upgrading from 3.9.x to 3.10.y" documentation page for instructions about how to run the "updatevatcountries.php" script. 
Le script de mise à jour updatevatcountries.php de la version 3.10.0 de eZ Publish contient le même bug que celui présent dans les versions 3.9.3 et 3.9.4 (référez-vous au lien http://issues.ez.no/11955  pour de plus amples informations). La version corrigée de ce script est présente dans les versions 3.9.5, 3.10.1 et 4.0.0 de eZ Publish. Si vous avez effetcué une précédente mise à jour vers la version 3.10.0 en utilisant la version originale de ce script, alors vous devez exécuter la version corrigée lors de la mise à jour de la version 3.10.0 vers la version 3.10.1. Référez-vous au paragraphe correspondant  de l'article eZ Publish : mise à jour de 3.9.x vers 3.10.y pour obtenir des informations sur la procédure d'exécution du script updatevatcountries.php.

If you are running eZ Publish on Windows, note that in eZ Publish 3.10.0 there is a bug in the "updatetipafriendpolicy.php" upgrade script that prevents it from granting access to the "Tip a friend" feature to the users. The same bug exists in eZ Publish 3.9.3 - 3.9.4 and 3.8.9 - 3.8.10 (refer to http://issues.ez.no/11663 for more information). The updated version of the script is available in eZ Publish 3.9.5, 3.10.1 and 4.0.0. Windows users that previously upgraded to 3.10.0 using the original version of the script are encouraged to re-run this script when upgrading from 3.10.0 to 3.10.1. Refer to the corresponding part of the "Upgrading from 3.9.x to 3.10.y" documentation page for instructions about how to run the "updatetipafriendpolicy.php" script. 
Si vous faites tourner eZ Publish sur une plate-forme windows, retenez que la version 3.10.0 contient un bug dans le script de mise à jour updatetipafriendpolicy.php qui l'empêche de donner aux visiteurs l'accés à la fonction Envoyer à un ami. Le même bug existe dans les versions 3.9.3 - 3.9.4 et 3.8.9 - 3.8.10 (référez-vous au lien http://issues.ez.no/11663  pour de plus amples informations). La version corrigée de ce script est présente dans les versions 3.9.5, 3.10.1 et 4.0.0 de eZ Publish. Les utilisateurs de windows ayant préalablement effectué une mise à jour vers la version 3.10.0 en utilisant la version originale de ce script sont encouragés à excécuter à nouveau ce script lors de la mise jour d'une version 3.10.0 vers une version 3.10.1. Référez-vous au paragraphe correspondant  de l'article e Z Publish : mise à jour de 3.9.x vers 3.10.y pour obtenir des informations sur la procédure d'exécution du script updatetipafriendpolicy.php.

Etape 4: Updating the system configuration / Mettre à jour la configuration du système

You are not required to do any configuration changes when upgrading from 3.10.0 to 3.10.1. 
Vous êtes tenu de ne faire aucune modification de la configuration lors de la mise à jour d'une version 3.10.0 vers une version 3.10.1

Tree menu configuration (optional) / Configuration du menu de l'arborescence (optionnel)

eZ Publish 3.10.1 introduces some changes to the dynamic tree menu functionality. In particular, the "treemenu" view of the "content" module no longer makes use of parameters that are transferred using GET variables (this improves tree menu compatibility when running PHP in FastCGI mode; refer to http://issues.ez.no/11806 for more information). 
eZ Publish 3.10.1 apporte quelques modifications à la fonctionnalité du menu dynamique de l'arborescence. En particulier, la vue treemenu  du module content n'utilise plus de paramètres transférés par la variable GET (ce qui accroît la compatibilité du menu lorsque l'on utilise PHP en mode FastCGI  : référez-vous à la page http://issues.ez.no/11806  pour de plus amples informations).

If you have instructed Apache to use "index_treemenu.php" instead of "index.php" when the treemenu view of the content module is requested, this feature will stop working after upgrading to version 3.10.1. To make it work, update your rewrite rules as described below. 
Si vous avez configuré le serveur Apache pour qu'il utilise le fichier index_treemenu.php à la place de index.php lorsque la vue treemenu du module content est demandée, alors cette fonctionnalité sera hors d'usage après la mise à jour vers la version 3.10.1. Pour remédier à cela, corrigez vos règles de réécriture comme indiqué ci-après:

If your ".htaccess" file contains the following line: 
Si votre fichier .htaccess  contient la ligne suivante:

RewriteRule content/treemenu/?$ index_treemenu.php

you need to remove "$" from there. The updated line should look like this: 
vous devez supprimer le $ pour que la nouvelle ligne ressemble à ceci:

RewriteRule content/treemenu/? index_treemenu.php

If no ".htaccess" file is used, check whether the following line is present in your Apache configuration file: 
Si le fichier .htaccess n'est pas utilisé, recherchez la présence de la ligne suivante dans le fichier de configuration de votre serveur Apache:

RewriteRule content/treemenu/?$ /index_treemenu.php [L]

If found, remove "$" from this line. The result will look like this: 
Le cas échéant, supprimez le $ pour que la nouvelle ligne ressemble à ceci:

RewriteRule content/treemenu/? /index_treemenu.php [L]

Note that due to a bug in eZ Publish 3.10.1, you need to download the updated version of "index_treemenu.php" from http://pubsvn.ez.no and replace the corresponding file in your installation. The same bug exists in eZ Publish 4.0.1. 
Retenez qu'en raison d'un bug dans eZ Publish 3.10.1, vous devez télécharger la version corrigée du fichier index_treemenu.php depuis le lien http://pubsvn.ez.no  pour remplacer la version originale de votre installation. Le même bug  existe dans eZ Publish 4.0.1.

Etape 5: Clearing the caches / Vider les caches

Whenever an eZ Publish solution is upgraded, all caches must be cleared in a proper way. This should be done from within a system shell: 
Chaque fois qu'un site eZ Publish est mis à jour, tous les caches doivent être correctement vidés avec la commande suivante:

1. Navigate into the eZ Publish 3.10.1 directory. 
   Placez-vous dans le répertoire d'installation de eZ Publish 3.10.1
2. Run the script using the following shell command: 
   Exécutez le script avec la commande suivante:

php bin/php/ezcache.php --clear-all --purge

Purging ensures that the caches are physically removed. When the "--purge" parameter is not specified, the caches will be expired but not removed. 
Vider les caches permet de s'assurer qu'ils ont été physiquement supprimés. Sans l'option --purge les caches expireront mais ne seront pas supprimés.

Sometimes the script is unable to clear all cache files because of restrictive file/directory permission settings. Make sure that all cache files have been cleared by inspecting the contents of the various cache subdirectories within the "var" directory (typically "var/cache/" and "var/<name_of_siteaccess>/cache/" directories). If there are any cache files left, you need to remove them manually. 
Il arrive parfois que le script ne puisse vider correctement tous les caches en raison de droits d'accès insuffisants sur des fichiers et répertoires. Assurez-vous qu'ils soient vidés en contrôlant le contenu des nombreux sous-répertoires de cache du répertoire var/ (typiquement, les répertoires var/cache/ et var/<nom_du_siteaccess>/cache/). S'il reste des fichiers cachés supprimez-les manuellement.

Commentaires