Date de publication: le mardi 24 mars 2009 à 22h37
Dernière modification: par Pascal BOYER le jeudi 2 septembre 2010 à 09h01
« Article précédent: eZ Publish : NOTES IMPORTANTES pour mise à jour vers 4.0
» Article suivant: eZ Publish : mise à jour de 3.10.x vers 4.0.y

24/09/2008 1:30  

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

In order to benefit from the latest bug fixes, you should upgrade directly to the latest stable release in the 4.0 branch (4.0.1 at the time of writing). Refer to the changelogs and security advisories for more information about the issues that were fixed in the latest releases. 
Afin de bénéficier des dernières corrections de bugs, vous devez procéder à la mise à jour directe vers la dernière version stable de la branche 4.0 (4.0.1 à l'heure d'écrire ces lignes). Référez-vous au fichier changelogs  et à la page avis de sécurité  pour de plus amples informations sur les problèmes corrigés par les dernières versions.

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 4.0.1 
   Mettre à jour les fichiers de distribution vers ceux de la version 4.0.1,
2. Upgrading the database to 4.0.1 
   Mettre à jour la base de données pour la rendre compatible avec la version 4.0.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 4.0.1 to a separate 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 ensuite de copier, dans le répertoire de la version 4.0.1, 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" and "ezurlaliasmigration"). Note that upgrading the distribution files will overwrite the autoload arrays for extensions. You will need to re-generate the autoload arrays for active extensions later (after enabling the "ezurlaliasmigration" extension in step 3). 
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 et ezurlaliasmigration). Retenez que la mise à jour des fichiers de la distribution écraseront les tableaux d'auto-chargement  des extensions. Vous devrez donc régénérer ces derniers pour les extensions activées (après avoir activé l'extension ezurlaliasmigration à l'étape 3).

If you are using the Website Interface front-end, be sure to copy the "extension/ezwebin/" directory. 
Si vous utilisez l' interface Website , assurez-vous de copier le répertoire extension/ezwebin/.

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 4.0.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 3.10.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 unique ID distant . 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 4.0.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é dans cette table que des ID distants uniques. Vous devez pour cette raison vous assurer, avant la mise 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é ajoutés à eZ PUblish 3.9.5 et 3.10.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 4.0.1 directory. 
   Placez-vous dans le répertoire de eZ Publish 4.0.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/4.0/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 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/4.0/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

Follow the instructions below to upgrade your eZ Publish database from version 4.0.0 to 4.0.1.  
Suivez les instructions ci-après pour mettre à jour la base de données de votre version 4.0.0 de eZ Publish vers la version 4.0.1.

Switching to InnoDB (MySQL only) / Passer au moteur de stockage InnoDB (MySQL uniquement)

If you are using MySQL, note that the recommended storage engine is InnoDB. This storage engine is used by default during the installation process when the setup wizard initializes the database structure for eZ Publish. In addition, InnoDB will most likely be required for future versions of eZ Publish to run on MySQL. Contact your database administrator if you are unsure about whether InnoDB is available on your server. 
Retenez que si vous utilisez MySQL, alors le moteur de stockage recommandé est InnoDB . Ce dernier est utilisé par défaut lors du processus d'installation lorsque l'assistant d'installation initialise la structure de la base de données de eZ Publish. Par ailleurs, InnoDB sera certainement requis pour les futures versions de eZ Publish liées à un serveur MySQL. En cas de doute, contactez l'administrateur de votre base de données pour savoir si InnoDB est disponible sur votre serveur.

In the future, all database upgrade scripts will use the InnoDB storage engine when creating new tables. Because of this, it is recommended (but not required) to make sure that all existing tables in your database use InnoDB. If you want to use the MyISAM (or another) storage engine instead, all existing tables in your database must use this engine. 
Dans le futur, tous les scripts de mise à jour de la base de données utiliseront le moteur de stockage InnoDB lors de la création de nouvelles tables. Pour cette raison, il est recommandé (mais non obligatoire) de s'assurer que toutes les tables de votre base de données utilisent InnoDB. Si vous souhaitez utiliser le moteur de stockage MyISAM (ou tout autre moteur) alors toutes les tables de votre base de données doivent l'utiliser.

You can use the "bin/php/ezconvertmysqltabletype.php" script to find out about the current storage engine in your database and convert your tables to use another engine if needed (refer to the "Switching to InnoDB" part of the "Upgrading from 3.10.x to 4.0.y" documentation page for more information about this script). 
Vous pouvez utiliser le script bin/php/ ezconvertmysqltabletype.php pour connaître le moteur de stockage utilisé par votre base de données et convertir vos tables, si nécessaire, à l'utilisation d'un autre moteur (référez-vous au paragraphe Passer au moteur de stockage InnoDB  de l'article eZ Publish : mise à jour de 3.10.x vers 4.0.y  pour de plus amples informations).

Running the database upgrade scripts / Exécuter les scripts de mise à jour de la base de données

The following text describes how to run the database upgrade scripts. (Note that even though the sql file contains a section marked with "from 3.10.1" comments, you do not need to skip this part when upgrading from 4.0.0 to 4.0.1.) 
Le texte qui suit explique comment exécuter les scripts de mise à jour de la base de données (retenez que même si le fichier .sql contient certaines sections marquées du commentaire from 3.10.1, vous ne devez pas passer ces sections lors de la mise à jour de 4.0.0 vers 4.0.1)

MySQL

1. Navigate into the eZ Publish 4.0.1 directory. 
   Placez-vous dans le répertoire d'installation de eZ Publish 4.0.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/4.0/dbupdate-4.0.0-to-4.0.1.sql

PostgreSQL

1. Navigate into the eZ Publish 4.0.1 directory. 
   Placez-vous dans le répertoire d'installation de eZ Publish 4.0.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/4.0/dbupdate-4.0.0-to-4.0.1.sql

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

The 4.0.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 4.0.1 de eZ Publish introduit un certain nombre de corrections de bugs importantes et de nouvelles modifications de fonctionnalités. Afin de s'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 4.0.1, the multi-language support for URL aliases was substantially improved, along with some important bug fixes related to this functionality. 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 4.0.1 and provides tools for the purpose of URL alias migration. 
Dans la version 4.0.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. 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. Cela 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 4.0.1 de eZ Publish et fournissant les outils nécessaires à la migration des alias des URI.

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. 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. Pour cela, éditez le fichier site.ini.append.php situé dans le répertoire settings/siteaccess/example/ (remplacez example par le nom du siteaccess cible) et ajoutez-y la ligne suivante sous la section [ExtensionSettings]:

ActiveAccessExtensions[]=ezurlaliasmigration

3. Update the autoload arrays for extensions (optional) / Mettre à jour les tableaux d'auto-chargement pour les extensions (optionnel)

If you are using custom extensions, some of them might stop working after upgrading to 4.0.1. The reason for this is that the "autoload/ezp_extension.php" file is overwritten in the first step of the upgrade procedure (when upgrading the distribution files). To solve the problem, you need to regenerate the autoload arrays for active extensions as described below. 
Si vous utilisez des extensions personnalisées, certaines d'entre elles peuvent ne plus fonctionner après la mise à jour vers la version 4.0.1. Cela est dû au fait que le fichier autoload/ ezp_extension.php est écrasé lors de la première étape de la procédure de mise à jour (lors de la mise à jour des fichiers de la distribution). Pour résoudre ce problème vous devez régénérer les tableaux d'auto-chargement  des extensions actives comme décrit ci-après.

Note that the default "autoload/ezp_extension.php" file in eZ Publih 4.0.1 contains all the information needed for the following extensions to work correctly: "ezdhtml", "ezodf", "ezurlaliasmigration", "ezflow" and "ezwebin". If you are only using these extensions (no custom ones), you do not have to regenerate the autoload arrays when upgrading to 4.0.1. 
Retenez que le fichier autoload/ ezp_extension.php par défaut de eZ Publish 4.0.1 contient toutes les informations nécessaires au bon fonctionnement des extensions suivantes: ezdhtml, ezodf, ezurlaliasmigration, ezflow et ezwebin. Si vous n'utilisez que celles-ci (pas d'extensions personnalisées), vous ne devez pas régénérer les tableaux d'auto-chargement lors de la mise à jour vers la version 4.0.1.

The following example shows how to regenerate the autoload arrays for extensions. 
L'exemple suivante explique comment régénérer les tableaux d'auto-chargement pour les extensions:

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

php bin/php/ezpgenerateautoloads.php --extension

The script will look for class definitions in the "extension" directory and update the "autoload/ezp_extension.php" file accordingly. 
Le script recherche les définitions de classe dans le répertoire extension/ et met à jour le fichier autoload/ ezp_extension.php en conséquence.

Note that the command above makes the script go through all extensions regardless of whether or not they are enabled. You can also instruct the script to skip inactive extensions by listing them in the optional "--exclude" parameter (replace "ext1" and "ext2" with the actual names of the extension subdirectories): 
Retenez que la commande ci-dessus fait parcourir au script toutes les extensions qu'elles soient ou non actives. Vous pouvez également indiquer à ce script de ne pas tenir compte des extensions inactives en indiquant la liste de celles-ci grâce au paramètre --exclude (remplacez ext1 et ext2 par les vrais noms des sous-répertoires de ces extensions):

php bin/php/ezpgenerateautoloads.php --extension --exclude="extension/ext1 extension/ext2"

4. Create the migration table / Créer la table de migration

The "ezurlaliasmigration" extension requires a custom database table called "ezurlalias_ml_migrate" to be created in the database. This table will be used for storing the migrated URL alias data. The new table must be created in accordance with the definitions specified in the "schema.sql" file included in the extension. This can be done by executing the SQL queries from the "schema.sql" file as described below. 
L'extension ezurlaliasmigration requière une table particulière nommée ezurlalias_ml_migrate devant être créée dans la base de données. Cette table, utilisée pour stocker les données des alias d'URI migrés, doit être créée en accord avec les définitions spécifiées par le fichier schema.sql inclus dans l'extension. Pour cela, exécutez les requêtes SQL du fichier schema.sql comme indiqué ci-après.

If you are using MySQL, navigate into the eZ Publish 4.0.1 directory and run the following shell command: 
Si vous utilisez MySQL, placez-vous dans le répertoire de eZ Publish 4.0.1 puis exécutez la commande suivante:

mysql -u <username> -p<password> <database> < extension/ezurlaliasmigration/sql/mysql/schema.sql

If you are running PostgreSQL, use the following shell command instead: 
En revanche, si vous utilisez PostgreSQL, exécutez la commande suivante:

psql -d <database> -U <dbowner> < extension/ezurlaliasmigration/sql/postgresql/schema.sql

Alternatively, you can use the "migrate.php" script to create the migration table. This option will work regardless of which database implementation you are using. You need to navigate into the eZ Publish 4.0.1 directory and run the script from within the system shell: 
Vous pouvez, alternativement, utiliser le script migrate.php afin de créer la table de migration. Cette option fonctionnera indépendamment de la base de données utilisée. Vous devez vous placer dans le répertoire de eZ Publish 4.0.1 puis exécutez le script depuis un shell:

php extension/ezurlaliasmigration/scripts/migrate.php --create-migration-table

With this command, the script will create the "ezurlalias_ml_migrate" table in the database that is used by the default siteaccess. If your site makes use of two or more databases, you need to run the script once for each database, specifying one siteaccess per database. Use the "-s" parameter to specify the target siteaccess as shown below: 
Avec cette commande, le script créera la table ezurlalias_ml_migrate dans la base de données utilisée par le siteaccess par défault . Dans le cas où votre site utilise deux bases de données ou plus, vous devez exécuter le script pour chacune d'elles en spécifiant un siteaccess pour chaque base de données. Utilisez pour cela le paramètre -s comme indiqué ci-dessous:

php extension/ezurlaliasmigration/scripts/migrate.php -s example --create-migration-table

(Replace "example" with the actual name of your siteaccess.)  
(Remplacez example par le vrai nom de votre siteaccess).

5. Transfer your URL aliases to the migration table / Transférer les alias des URI dans la table de migration

To find out about the current number of manual/user-defined URL aliases and URL history entries in your system, run the "migrate.php" script without parameters or with the "-s" parameter only. The following example shows how this can be done. 
Pour rechercher sur votre système le nombre d'alias d'URI créés manuellement et les entrées de l'historique des URI, exécutez le script migrate.php sans paramètre ou uniquement avec le paramètre -s. L'exemple suivant montre comment faire:

1. Navigate into the eZ Publish 4.0.1 directory. 
   Placez-vous dans le répertoire de la version 4.0.1 de eZ Publish,
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 extension/ezurlaliasmigration/scripts/migrate.php -s example

Note that the commands for running the "migrate.php" and "updateniceurls.php" scripts in the examples below will assume that all your siteaccesses share the same database. Because of this, the "-s example" part will be omitted and the scripts will be run for the database that is used by the default siteaccess. If you are using two or more databases, the "migrate.php" script should be run once for each database, specifying one siteaccess per database (by adding the "-s" parameter to each command). This also applies to the "updateniceurls.php" script. Both scripts need to be run from the root directory of your eZ Publish 4.0.1 installation. The following table reveals the available parameters for the "migrate.php" script. 
Retenez que les commandes d'exécution des scripts migrate.php et updateniceurls.php des exemples ci-dessous supposent que tous vos siteaccess paratgent la même base de données. Pour cette raison, si la partie -s example est omise alors les scripts s'appliqueront à la base de données utilisée par le siteaccess par défault . En revanche, si vous utilisez deux bases de données ou plus alors le script migrate.php doit être exécuté une fois pour chacune d'elles et en spécifiant un siteaccess par base de données (en ajoutant le paramètre -s à chaque commande). Cela s'applique également au script updateniceurls.php. Ces deux scripts doivent être exécutés depuis la racine du répertoire de eZ Publish 4.0.1. Le tableau si-dessous récapitule les paramètres possibles du script migrate.php:

To transfer your manual URL aliases and URL history entries into the migration table, run the "migrate.php" script as shown below: 
Pour transférer vos alias d'URI créés manuellement ainsi que les entrées de l'historique des URI dans la table de migration, exécutez le script migrate.php comme suit:

php extension/ezurlaliasmigration/scripts/migrate.php --migrate

The script will go through all manual URL aliases and URL history entries in the "ezurlalias_ml" table and put the collected data into the "ezurlalias_ml_migrate" table. 
Ce script parcourt dans la table ezurlalias_ml tous les alias d'URI créés manuellement et toutes les entrées de l'historique des URI puis transfert les données collectées dans la table ezurlalias_ml_migrate.

Instead of transfering both manual URL aliases and URL history entries at once, it is also possible to run the script once for each type of URL entries. To do this, use either the "--migrate-alias" or "--migrate-history" parameter instead of "--migrate" when running the script (refer to the table above for more information about these parameters). 
Au lieu de transférer les alias d'URI créés manuellement et les entrées de l'historique des URI en une seule fois, il est possible d'exécuter le script pour chaque type d'entrées d'URI. Pour cela, utilisez, lors de l'exécution du script, soit le paramètre --migrate-alias soit le paramètre - -migrate-history en lieu et place de --migrate (référez-vous au tableau ci-dessus pour de plus amples informations sur ces paramètres).

It is important not to change any configuration settings after transfering the data to the migration table. The configuration of the URL alias system must remain untouched until you're finished with regenerating the URL aliases and transfering the data back to the "ezurlalias_ml" table (otherwise, there might be some broken or inconsistent URLs on your site after upgrading to 4.0.1). 
Il est important de ne modifier aucun paramètre de configuration une fois effectué le transfert des données dans la table de migration. La configuration du système d'alias des URI doit resté inchangé jusqu'à ce que vous ayez terminé la régénération des alias des URI et opéré le retour des données dans la table ezurlalias_ml (sans quoi certains URI de votre système pourraient être cassés ou dans un état instable après la mise à jour vers la version 4.0.1).

6. Remove old URL alias data / Supprimer les anciens alias d'URI

Use the following SQL query to empty the "ezurlalias_ml" table in your database: 
Utilisez la requête SQL suivante pour vider la table ezurlalias_ml de votre base de données:

TRUNCATE ezurlalias_ml;

7. Create new auto-generated URL aliases / Créer les nouveaux alias d'URI auto-générés

Now that the "ezurlalias_ml" table is empty, you need to create new auto-generated URL aliases based on the existing node tree structure and content object names. To do this, run the "updateniceurls.php" script using the following command: 
Maintenant que la table ezurlalias_ml est vide, vous devez créer les nouveaux alais d'URI auto-générés en conformité avec la structure existante de l'arbre de noeuds et avec les noms des objets de contenu. Pour cela, exécutez le script updateniceurls.php avec la commande suivante:

php bin/php/updateniceurls.php --fetch-limit=number

Specify the desired number of items to handle per one iteration instead of "number". On a system with a 128 MB memory limit for PHP, this parameter can be set to 2000. (The script will automatically do as many iterations as necessary to generate the URL aliases for all nodes, based on the number specified. If the optional "--fetch-limit" parameter is omitted, the script will handle 200 items per one iteration.) 
Spécifiez, en remplaçant number par une valeur, le nombre d'items que vous souhaitez voir gérés à chaque itération. Sur un système dont la mémoire réservée à l'exécution des srcipts PHP est limitée à 128 MB, ce paramètre peut prendre pour valeur 2000 (en fonction de la valeur spécifiée, le script effectuera alors autant d'itérations que nécessaires pour générer les alias d'URI de tous les noeuds. Si le paramètre optionnel --fetch-limit est omis, le script gère 200 items par itération).

The script will go through all content objects stored in the database and create new virtual URLs for them in accordance with the current transformation settings. New URL aliases will be generated for all of the translation languages and placed in the "ezurlalias_ml" table in the database. 
Le script parcourt tous les objets de contenu stockés dans la base de données puis crée les nouveaux alias d'URI en accord avec les paramètres de transformation existants. Ces nouveaux alias sont générés pour toutes les langues de traduction  puis placés dans la table ezurlalias_ml de la base de données.

8. Restore migrated URL data / Restaurer les URI migrés

You need to restore the custom URL aliases and URL history entries from the migration table. This can be done by running the "migrate.php" script: 
Vous devez restaurer les alias d'URI personnalisés ainsi que les entrées de l'historique des URI depuis la table de migration. Pour cela, exécutez le script migrate.php:

php extension/ezurlaliasmigration/scripts/migrate.php --restore

The script will go through all entries in the "ezurlalias_ml_migrate" table and put the collected data back into the "ezurlalias_ml" table. 
Ce script parcourt toutes les entrées de la table ezurlalias_ml_migrate et place les données collectées dans la table ezurlalias_ml.

Instead of restoring both manual URL aliases and URL history entries at once, it is also possible to run the script once for each type of URL entries. To do this, use either the "--restore-alias" or "--restore-history" parameter instead of "--restore" when running the script (refer to the table above for more information about these parameters). 
Au lieu de restaurer en une seule fois les alias d'URI créés manuellement et les entrées de l'historique des URI, il est possible d'exécuter le script pour chaque type d'entrées d'URI. Pour cela, utilisez, lors de l'exécution du script, soit le paramètre --restore-alias soit le paramètre - -restore-history en lieu et place de --restore (référez-vous au tableau ci-dessus pour de plus amples informations sur ces paramètres).

It might happen that a URL alias entry was previously corrupted and cannot be automatically restored from the migration table. In this case, you will see "F" in the console output of the "migrate.php" script. The following SQL query can be used in order to display the migrated entries that were not restored: 
Il peut arriver que l'entrée d'un alias d'URI était corrompu et ne puisse donc pas être automatiquement restauré depuis la table de migration. Dans ce cas, vous verrez un F dans les lignes de sortie du script migrate.php. La requête SQL suivante peut être utilisée pour afficher les entrées migrées n'ayant pas été restaurées:

SELECT id, link, parent, lang_mask, text, action, is_original, is_alias, lang_mask_adjusted FROM ezurlalias_ml_migrate WHERE is_restored=0;

If you want the URL entries that were not restored automatically to work on your site, you must create new user-defined URLs later (when the upgrade procedure is finished). This can be done from within the administration interface as described on the "Managing URL aliases" documentation page. 
Si vous souhaitez que les entrées d'URI non restaurées automatiquement fonctionnent sur votre site, vous devrez créer ultérieurement (c'est à dire une fois terminée la procédure de mise à jour) et manuellement de nouveaux alias d'URI. Utilisez pour cela l'interface d'administration comme indiqué par la documentation Gestion des alias d'URI .

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.10 or 4.0, skip this part. Otherwise, read it carefully. 
Si votre installation était à l'origine une version 3.10 ou 4.0 de eZ Publish, passer cette étape. Dans le cas contraire, lisez-la attentivement.

The "updatevatcountries.php" upgrade script in eZ Publish 3.10.0 contains a bug. The same bug exists in eZ Publish 3.9.3 and 3.9.4 (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.1. If you previously upgraded to 3.10.0 using the original version of the script and then didn't run the updated version when upgrading from 3.10.0 to 4.0.0, you need to run it when upgrading to 4.0.1. 
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.1 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 et que vous n'avez pas exécuté sa version corrigée lors du passage de la version 3.10.0 à 4.0.0, alors vous devez exécuter la version corrigée lors de la mise à jour vers la version 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 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 ce script:

1. Navigate into the eZ Publish 4.0.1 directory. 
   Placez-vous dans le répertoire de la version 4.0.1 de eZ Publish,
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/4.0/updatevatcountries.php -s example

The script will go through all the VAT rules in the database and update them. 
Le script va parcourir toutes les règles de TVA présentes dans la base de données et les mettre à jour.

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 4.0.x to 4.0.y. 
Vous êtes tenu de ne faire aucune modification de la configuration lors de la mise à jour d'une version 4.0.x vers une version 4.0.y

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

eZ Publish 4.0.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 4.0.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 4.0.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 4.0.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 4.0.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 3.10.1. 
Retenez qu'en raison d'un bug dans eZ Publish 4.0.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 3.10.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 4.0.1 directory. 
   Placez-vous dans le répertoire d'installation de eZ Publish 4.0.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 (refer to this page for more information). 
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 (repportez-vous à cette page  pour de plus amples informations).

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 the "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