# Upgrade TYPO3 8.2 > 9.5

> Les scripts mis en oeuvre peuvent être retrouvés ici: <https://gitlab.2iopenservice.com/opentalent/upgrade_typo8>

# POC

### Programme

Migration planifiée le mardi 23/09, le 24 sera pour la recette
et la mise en prod définitive pour le 24 17h sauf erreur).

#### 14/09

* [Equipe] Envoyer un mail pour prévenir de la maintenance

#### 23/09

##### 8:30 => 12:00:

* [Tony] Fais un snapshot
* [Olivier] Active le verrouillage du backend `Configure => [BE][adminOnly] = 2`
* [Olivier] Upload maintenance.html et configure le .htaccess, attention au renommage du répertoire, vérifier avec un PC hors-VPN
* [Olivier] Rediriger la page de login vers admin.prod.opentalent (**url à ajouter à la page de maintenance**)
* [Tony] * Installation de php-fpm7.4
  * upgrade mysql5.7 vers mariadb10.3 et patch
  * copier le php.ini de la 7.4 de preprod vers prod-front
* [Olivier] Installe python3 et python3-pip
* [Olivier] lance le script d'upgrade
* [Tony] prépare un autre vhost pour les sites `opentalent.fr` et `2iopenservice.com` en version php7.0
* [Olivier] Créer des symlinks pour que le portail ait encore accès aux images
* [Olivier] Retirer le mode maintenance des htaccess de typo3_82 et typo3

NB:

    https://www.opentalent.fr   -> /var/www/typo3_82    <>   php7.0, openassos
    https://2iopenservice.com   -> /var/www/typo3_82    <>   php7.0, openassos
    https://*****.opentalent.fr   -> /var/www/typo3    <>   php7.4, typo3


##### 20/10 am, 21/10

* [Equipe] Recette et corrections eventuelles
* [Tony] Fais un snapshot
* [Olivier] Lance le `upgrade --clean`

##### 15:30 => 18:00

> En cas de pépin grave, on rollback! (sauter direct au paragraphe suivant)
> Sinon, on continue.

* [Olivier] Redirige le vhost apache vers le nouveau système
* [Tony] Active le vhost pour les sites `opentalent.fr` et `2iopenservice.com`
* [Tony] Supprime php-fpm7.0 (à confirmer)

#### 28/09

* [Equipe] Communique au sujet du déploiement réussi?
* [Tony] Supprime le snapshot initial

##### Switch en mode maintenance

Pour basculer l'ancier typo3 vers le mode maintenance, lancer les commandes suivantes:

    mv /var/www/typo3_82/.htaccess /var/www/typo3_82/.htaccess_200
    mv /var/www/typo3_82/.htaccess_503 /var/www/typo3_82/.htaccess

Pour revenir au mode standard:

    mv /var/www/typo3_82/.htaccess /var/www/typo3_82/.htaccess_503
    mv /var/www/typo3_82/.htaccess_200 /var/www/typo3_82/.htaccess

##### Rollback

En cas de gros pépin

* [Tony] Restaure le snapshot



### Préparation de prod-front

### php et apache

Les corrections suivantes doivent être apportées au serveur prod-front avant de procéder à l'upgrade.

Installer php-fpm 7.4

Changer le user php-fpm et apache2 pour mettre 'exploitation' à la place de 'www-data', et faire un:

    chown -R exploitation:www-data /var/www/typo3

Corriger le fichier php.ini pour régler la timezone sur Europe / Paris

    [Date]
    ; Defines the default timezone used by the date functions
    ; http://php.net/date.timezone
    ;date.timezone =

Tony fera un upgrade mariadb 10.3 sur prod-back avec patch ci dessous + switch mysql5.7 vers mariadb10.3 sur prod-front (repo: source.list):

    /lib/systemd/system/mariadb.service:   Your workaround is working but it seems that removing only these 3 lines
    is sufficient:
    > ProtectSystem=full
    > PrivateDevices=true
    > ProtectHome=true

Aprés l'upgrade:

préparer un autre vhost pour les sites `opentalent.fr` et `2iopenservice.com` en version php7.0 (/var/www/typo3_82)
sortir *.opentalent.fr dans un vhost spécifique (/var/www/typo3), en php7.4




### scripts

Renommer les fichiers:

* `constants.py` -> `constants-preprod.py`
* `constants-prod.py` -> `constants.py`


### Installation de la 9.5

> T0

Avec MysqlWB, en tant que user root:

    CREATE SCHEMA `typo3` DEFAULT CHARACTER SET utf8 ;

Shell (3min):

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 openassos | mysql -h localhost -P 3306 -u root --password=mysql2iopenservice369566 -D typo3


Se loguer sur prod-front en tant que root:

    mv /var/www/typo3 /var/www/typo3_82
    mkdir /var/www/typo3
    cp -p /var/www/typo3_82/.htaccess /var/www/typo3/.htaccess
    cp -pr /var/www/typo3_82/typo3_src_version/typo3_src-8.7.22 /var/www/typo3/
    cp -pr /var/www/typo3_82/typo3conf /var/www/typo3/
    ln -s /var/www/typo3/typo3_src-8.7.22 /var/www/typo3/typo3_src
    ln -s /var/www/typo3/typo3_src/typo3 /var/www/typo3/typo3
    ln -s /var/www/typo3/typo3_src/index.php /var/www/typo3/index.php
    mkdir /var/www/typo3/typo3temp

On déplace les répertoires de type uploads:

    mv /var/www/typo3_82/fileadmin/_migrated /var/www/typo3/fileadmin/
    mv /var/www/typo3_82/fileadmin/shared_folder /var/www/typo3/fileadmin/
    mv /var/www/typo3_82/fileadmin/stockage /var/www/typo3/fileadmin/
    mv /var/www/typo3_82/fileadmin/user_upload /var/www/typo3/fileadmin/
    mv /var/www/typo3_82/uploads /var/www/typo3/
    mv /var/www/typo3_82/websites /var/www/typo3/

    sudo chown -R exploitation:www-data /var/www/typo3


MysqlWB:

    CREATE USER 'typo3'@'localhost' IDENTIFIED BY 'Vq2icge7SM3P26CaC3';
    GRANT ALL PRIVILEGES ON typo3.* TO 'typo3'@'localhost'; 
    TRUNCATE typo3.cf_cache_hash;
    TRUNCATE typo3.cf_cache_hash_tags;
    TRUNCATE typo3.cf_cache_imagesizes;
    TRUNCATE typo3.cf_cache_imagesizes_tags;
    TRUNCATE typo3.cf_cache_news_category;
    TRUNCATE typo3.cf_cache_news_category_tags;
    TRUNCATE typo3.cf_cache_pages;
    TRUNCATE typo3.cf_cache_pagesection;
    TRUNCATE typo3.cf_cache_pagesection_tags;
    TRUNCATE typo3.cf_cache_pages_tags;
    TRUNCATE typo3.cf_cache_rootline;
    TRUNCATE typo3.cf_cache_rootline_tags;
    TRUNCATE typo3.cf_extbase_datamapfactory_datamap;
    TRUNCATE typo3.cf_extbase_datamapfactory_datamap_tags;
    TRUNCATE typo3.cf_extbase_reflection;
    TRUNCATE typo3.cf_extbase_reflection_tags;
    TRUNCATE typo3.cf_workspaces_cache;
    TRUNCATE typo3.cf_workspaces_cache_tags;
    DELETE FROM typo3.sys_log WHERE tstamp < UNIX_TIMESTAMP('2020-01-01 00:00:00');
    DELETE FROM typo3.sys_history WHERE tstamp < UNIX_TIMESTAMP('2019-01-01 00:00:00');
    DELETE FROM typo3.sys_log WHERE details LIKE 'User %s has cleared the cache%';
    DELETE FROM typo3.sys_log WHERE details LIKE 'Core: Error handler%';
    DELETE FROM typo3.sys_log WHERE details LIKE 'Core: Exception handler%';
    DELETE FROM typo3.pages WHERE uid IN (15983, 16009, 16087, 16412, 16798, 17058, 17162, 17331, 17461, 18696);

Shell:

    nano /var/www/typo3/typo3conf/LocalConfiguration.php

Corriger la section `'DB' => ['Connections' => [` de la manière suivante:

    'charset' => 'utf8',
    'dbname' => 'typo3',
    'driver' => 'mysqli',
    'host' => 'localhost',
    'initCommands' => '',
    'password' => 'Vq2icge7SM3P26CaC3',
    'user' => 'typo3',


Shell (en tant que root):

    cd /var/www/typo3/
    rm /var/www/typo3/.htaccess
    wget --content-disposition https://get.typo3.org/9.5.21
    tar xzvf typo3_src-9.5.21.tar.gz
    ln -sfn typo3_src-9.5.21 typo3_src
    touch /var/www/typo3/typo3conf/ENABLE_INSTALL_TOOL
    cp -p typo3/sysext/install/Resources/Private/FolderStructureTemplateFiles/root-htaccess ./.htaccess
    rm -r /var/www/typo3/typo3temp/*
    chmod 2770 /var/www/typo3
    chmod 2770 /var/www/typo3/typo3temp
    chmod 2770 /var/www/typo3/typo3conf
    chmod 2770 /var/www/typo3/typo3conf/ext
    chmod 2770 /var/www/typo3/typo3conf/l10n
    chmod 2770 /var/www/typo3/fileadmin
    chmod 2770 /var/www/typo3/fileadmin/_temp_
    chmod 2770 /var/www/typo3/fileadmin/user_upload
    chmod 2660 /var/www/typo3/.htaccess
    rm /var/www/typo3/fileadmin/_temp_/index.html
    rm /var/www/typo3/fileadmin/user_upload/_temp_/importexport/index.html
    rm /var/www/typo3/typo3conf/How\ to\ install\ Matomo.html
    rm /var/www/typo3/typo3conf/realurl_autoconf.php.auto.save
    rm /var/www/typo3/typo3conf/realurl_autoconf.php.copy
    rm /var/www/typo3/typo3conf/realurl_autoconf.php.save
    rm /var/www/typo3/typo3conf/tx_mmforum_config.ts
    rm /var/www/typo3/typo3conf/domains_list.php.save
    rm -r /var/www/typo3/typo3conf/matomo
    rm -r /var/www/typo3/typo3conf/piwik
    chown -R exploitation:www-data /var/www/typo3/


Recharger apache:

    systemctl reload apache2
    /etc/init.d/php7.4-fpm restart

Firefox:

Accéder à https://preprod.opentalent.fr/typo3/install.php
Si la page s'affiche et que la version est bien la 9.5.21, tout va bien.

* Settings/Presets -> passer en mode debug
* Lancer l'outil 'Environnement/Directory Status', et cliquer sur 'Try to fix file and folder permissions'
* "Upgrade / Check for broken ext", résoudre tout
* Outil 'Maintenance/Manage Language Packs': update all
* Outil 'Maintenance/Rebuild PHP Autoload'
* Cliquer sur "Maintenance/Analyze Database Structure"
  Créer les tables et les champs manquants, modifier les champs qui doivent l'être (c'est un long, env 5min)

Vider le cache

> T0+15min


Avant d'effectuer le premier correctif du wizard (formulaires), il est nécessaire
de remplacer les rep uploads et user_upload par des repertoires vides:

    rm /var/www/typo3/uploads
    rm /var/www/typo3/fileadmin/user_upload
    mkdir /var/www/typo3/uploads
    mkdir /var/www/typo3/fileadmin/user_upload

Cliquer sur "Upgrade/Upgrade Wizard"
Executer le correctif 1
Fermer le wizard

Restaurer les répertoires:

    rm -r /var/www/typo3/uploads
    ln -s /var/www/typo3_files/uploads /var/www/typo3/uploads
    rm -r /var/www/typo3/fileadmin/user_upload/
    ln -s /var/www/typo3_files/fileadmin/user_upload /var/www/typo3/fileadmin/user_upload

Cliquer sur "Upgrade/Upgrade Wizard"

1. Rename form definition file extension from .yaml to .form.yaml

> Execute

2. Add the default Extension Manager database tables

> Execute

3. Update backend user setting "startModule"

> Execute

4. Migrate bullet content element rendering selector from layout to bullets_type

> Execute

5. Migrate upload content element rendering from layout to uploads_type

> execute

6. Install compatibility extension for TYPO3 7 compatibility

> execute, puis laisser à "no do not execute"

7. Install extension "form_legacy"

> execute, puis laisser à "no do not execute"

8. Install extension "rtehtmlarea" from TER

> execute, puis laisser à "no do not execute"

9. Install extension "typo3db_legacy" from TER

> execute, puis laisser à "no do not execute"

10. Install extension "func" from TER

> execute, puis mettre à "Yes, execute"

11. Migrate pages.urltype to pages.url

> Execute

12. Migrates existing sys_log entries into sys_history

> Execute

13. Merge be_groups access rights from pages_language_overlay to pages

> execute, puis mettre à "Yes, execute"

14. Install system extension "redirects" if a sys_domain entry with redirectTo is necessary

> execute, puis mettre à "Yes, execute"

15. Install extension "adminpanel"

> execute, puis mettre à "Yes, execute"

16. Introduce URL parts ("slugs") to all existing pages

> Ignore

17. Reminder to verify live system supports argon2i

> "Yes I understand" > Execute
>
18. Update backend user configuration array

> Execute

19. Updates slug field "path_segment" of EXT:news records

> Ignore



Flush TYPO3 and PHP Cache
Rebuild PHP Autoload Information
Reset Backend User Preferences
Analyze Database Structure: cocher les corrections suivantes, puis apply

    DROP INDEX `deleted_hidden` ON `sys_file_storage`
    DROP INDEX `sys_log_uid` ON `sys_history`
    DROP INDEX `uid_foreign_tablenames` ON `sys_category_record_mm`
    DROP INDEX `tx_realurl` ON `sys_domain`
    DROP INDEX `tx_realurl` ON `sys_template`


Shell:

    nano /var/www/typo3/typo3conf/PackageStates.php

Modifier ainsi les lignes suivantes:

    #'theme_gallery' => [
    #    'packagePath' => 'typo3conf/ext/theme_gallery/',
    #],
    #'typo3_api' => [
    #    'packagePath' => 'typo3conf/ext/typo3_api/',
    #],    


Se rendre sur le BE, menu extensions, menu "ajouter des extensions", mettre a jour l'index
Maj les extensions qui en ont besoin, en principe:

* fe_editing
* news_system
* rte_ckeditor

> T0+25min

Shell (**env. 2h**):

Lancer `01_fix_db_95.py`

Lancer `02_populate_slugs_95.py`,

> T0+140min

Lancer:

    php7.4 -d memory_limit=-1 /var/www/typo3/typo3/sysext/core/bin/typo3 cleanup:orphanrecords

> T0+175min

Lancer (en tant que exploitation, IMPORTANT!):

    php7.4 -d memory_limit=-1 /var/www/typo3/typo3/sysext/core/bin/typo3 upgrade:run pagesSlugs

> T0+205min

Lancer `03_gen_sites_yaml.py`

Dans le repertoire contenant les scripts:

    tar czf sites.tar.gz sites/

Transférer sites.tar.gz vers le serveur (dans `/var/www/typo3/config/`).
Sur le serveur:

    cd /var/www/typo3/typo3conf/
    rm -r sites
    tar xzvf sites.tar.gz
    rm sites.tar.gz

Verifier qu'aucun site ne manque

> T0+210min


### Switch vers composer


Sur le serveur, en tant que root:

    mv /var/www/typo3 /var/www/typo3_95
    mkdir /var/www/typo3
    chown -R exploitation:www-data /var/www/typo3

Sur le serveur, en tant que exploitation:

    cd /var/www/typo3
    
    php7.4 -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
    php7.4 -r "if (hash_file('sha384', 'composer-setup.php') === '795f976fe0ebd8b75f26a6dd68f78fd3453ce79f32ecb33e7fd087d39bfeb978342fb73ac986cd4f54edd0dc902601dc') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
    php7.4 composer-setup.php
    php7.4 -r "unlink('composer-setup.php');"
    
    php7.4 composer.phar require "typo3/cms-about:^9.5" "typo3/cms-adminpanel:^9.5" "typo3/cms-backend:^9.5" "typo3/cms-belog:^9.5" "typo3/cms-beuser:^9.5" "typo3/cms-core:^9.5" "typo3/cms-extbase:^9.5" "typo3/cms-extensionmanager:^9.5" "typo3/cms-felogin:^9.5" "typo3/cms-filelist:^9.5" "typo3/cms-filemetadata:^9.5" "typo3/cms-fluid:^9.5" "typo3/cms-fluid-styled-content:^9.5" "typo3/cms-form:^9.5" "typo3/cms-frontend:^9.5" "typo3/cms-info:^9.5" "typo3/cms-install:^9.5" "typo3/cms-lowlevel:^9.5" "typo3/cms-recycler:^9.5" "typo3/cms-redirects:^9.5" "typo3/cms-reports:^9.5" "typo3/cms-rte-ckeditor:^9.5" "typo3/cms-scheduler:^9.5" "typo3/cms-seo:^9.5" "typo3/cms-setup:^9.5" "typo3/cms-t3editor:^9.5" "typo3/cms-tstemplate:^9.5"
    php7.4 composer.phar require fluidtypo3/flux fluidtypo3/vhs georgringer/news helhum/typo3-console:^5.7
    
    ln -s /var/www/typo3_files/fileadmin/_migrated /var/www/typo3/public/fileadmin/_migrated
    ln -s /var/www/typo3_files/fileadmin/_shared_folder /var/www/typo3/public/fileadmin/_shared_folder
    ln -s /var/www/typo3_files/fileadmin/stockage /var/www/typo3/public/fileadmin/stockage
    ln -s /var/www/typo3_files/fileadmin/user_upload /var/www/typo3/public/fileadmin/user_upload
    ln -s /var/www/typo3_files/uploads /var/www/typo3/public/uploads
    ln -s /var/www/typo3_files/websites /var/www/typo3/public/websites
    
    cd /var/opentalent/git
    git clone git@gitlab.2iopenservice.com:olivier/ot_typo3.git
    ln -s /var/opentalent/git/ot_typo3/ot_connect /var/www/typo3/public/typo3conf/ext/ot_connect
    ln -s /var/opentalent/git/ot_typo3/ot_templating /var/www/typo3/public/typo3conf/ext/ot_templating
    
    mkdir /var/www/typo3/config
    cp -pr /var/www/typo3_95/typo3conf/sites /var/www/typo3/config/
    cp -p /var/www/typo3_95/typo3conf/LocalConfiguration.php /var/www/typo3/public/typo3conf/LocalConfiguration.php
    mkdir /var/www/typo3/public/typo3temp
    
    cp -p /var/www/typo3/public/typo3/sysext/install/Resources/Private/FolderStructureTemplateFiles/root-htaccess /var/www/typo3/public/.htaccess
    
    chown -R exploitation:www-data /var/www/typo3/
    touch /var/www/typo3/public/FIRST_INSTALL

Maj le composer.json:

    nano /var/www/typo3/composer.json

ajouter les lignes:

    ,
    "scripts":{
        "typo3-cms-scripts": [
            "typo3cms install:fixfolderstructure",
            "typo3cms install:generatepackagestates"
        ],
        "post-autoload-dump": [
            "@typo3-cms-scripts"
        ]
    },
    "autoload": {
        "psr-4": {
            "Opentalent\\OtConnect\\": "public/typo3conf/ext/ot_connect/Classes",
            "Opentalent\\OtTemplating\\": "public/typo3conf/ext/ot_templating/Classes"
        }
    }

Shell:

    cd /var/www/typo3
    php7.4 composer.phar dumpautoload

En tant que root:

Maj la conf apache:

    nano /etc/apache2/sites-available/001-preprod.opentalent.fr.conf
    nano /etc/apache2/sites-available/001-preprod.opentalent.fr-le-ssl.conf

Dans ces deux fichiers, remplacer:

    DocumentRoot /var/www/typo3

Par:

    DocumentRoot /var/www/typo3/public

lancer:

    /etc/init.d/apache2 reload

Shell:

    cd /var/www/typo3/
    php7.4 composer.phar req causal/image_autoresize
    php7.4 composer.phar req bueroparallel/bp-pagetree
    php7.4 composer.phar req guzzlehttp/guzzle:^6

> T0+220min

## Finalisation et correctifs

Firefox:

Se rendre à https://preprod.opentalent.fr/typo3/install.php

Page extensions, vérifier que le mode composer est bien activé
Page maintenance: 'Database compare', lancer toutes les commandes de création de tables et de champs (mais ni alter ni delete!)
Page maintenance: 'Flush cache'
Page maintenance: 'Remove Temporary Assets', tout virer

Shell:

> T0+225min

Lancer le script `04_update_struct_ids.py`
Lancer le script `05_update_templates.py`

> T0+270min

Lancer le script `08_delete-old-sites.py`

> T0+290min

Lancer le script `06_update_constants.py`

> T0+310min

Lancer le script `07_generate_welcome_shortcuts.py`

> T0+330min

Lancer le script `09_regen_carousel_contents.py`

> T0+340min

Lancer le script `10_regen_media_contents.py`   (10min)
Lancer le script `11_update_theme_colors.py`   (10min)

> T0+350min

MysqlWB:

    DELETE FROM backend_layout;
    
    UPDATE pages 
    SET tx_fed_page_controller_action = 'OpenTalent.OtTemplating->contact' 
    WHERE dokType=1 AND slug='/footer/contact';

    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid  
    SET t.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->structures',
            t.tx_fed_page_controller_action_sub = 'OpenTalent.OtTemplating->1Col',
            t.backend_layout = 'flux__grid'
    WHERE o.backend_layout = 'theme_gallery__members_list_fede';
        
    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid  
    SET t.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->structuresEvents',
            t.tx_fed_page_controller_action_sub = 'OpenTalent.OtTemplating->1Col',
            t.backend_layout = 'flux__grid'
    WHERE o.backend_layout = 'theme_gallery__association_spectacle';
        
    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid
    SET t.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->events'       
    WHERE o.backend_layout='theme_gallery__events';

Firefox:

Page maintenance: 'Flush cache'

> Si des enregistrements de la table pages ont pour valeur de slug '0', exécuter `UPDATE pages SET slug = NULL WHERE slug='0';`,
> puis relancer 'populate_slugs_95.py'

A ce niveau, contrôler:

* les slugs null ou valant '0' (il devrait y en avoir 1030 null)
* les contenus mal positionnés (voir LOG ligne 1774 et 2819)
* la table sys_redirect a été remplie correctement (voir LOG ligne 2333)

**Important**: il faut voir quelles url il faut rediriger pour qu'elles
continuent de pointer vers l'ancienne install de typo3


Sur le backend, editer les groupes writer basic et writer full pour activer dans l'onglet Access List:

* ot_customizer
* news

> T0+360min

### Nettoyage

Une fois les tests terminés, lancer le nettoyage:

    sh /var/www/typo3/12_clean.sh > cleaning.log &

> ATTENTION: sur la prod, il faudra copier d'abord le script 12_clean.sh vers /var/www/typo3/cleaning.sh


## Mise en pratique



# POC Upgrade TYPO3 8.2 > 9.5

## Notes

L'upgrade est effectuée sur la preprod, aprés une synchro complète de la prod le 17/06/2020

Sauf mention contraire, toutes les commandes shell sont exécutées en exploitation@preprod.opentalent.fr

## Mise en place - 17/06/2020

L'objectif est de vérifier que l'environnement de preprod est fonctionnel et qu'il est identique à la prod.

Pour éviter tout problème avec les sessions typo3, je ferme toutes les pages en *.opentalent.fr dans le navigateur,
et je supprime les cookies opentalent.fr

Je vais commencer par vérifier que l'install typo3 fonctionne bien après la synchro.

Je me rend sur https://preprod.opentalent.fr/typo3/
Résultat: "An error occured"

![img](images/01.png)

Je me rend donc sur https://preprod.opentalent.fr/typo3/install.php
Résultat: l'install tool est verrouillé

![img](images/02.png)

Je créé le fichier nécessaire pour déverrouiller l'install tool:

    touch /var/www/typo3/typo3conf/ENABLE_INSTALL_TOOL

Puis je réactualise https://preprod.opentalent.fr/typo3/install.php

Je renseigne le mot de passe du compte `oaos`, je valide

Je tombe sur le wizard d'installation typo3. Pas normal.
Avant de maj les params de connexion à la DB, je vais vérifier la conf de typo3:

    cat /var/www/typo3/typo3conf/LocalConfiguration.php

A la section DB => Connections => Default, je constate que la base est définie de la manière suivante:

    'charset' => 'utf8',
    'dbname' => 'openassos',
    'driver' => 'mysqli',
    'host' => 'localhost',
    'initCommands' => '',
    'password' => 'Vq2icge7SM3P26CaC3',
    'user' => 'openassos',

Un test de connexion avec Mysql Workbench montre que le user 'openassos' n'existe pas sur le serveur preprod.

Je contacte Tony qui s'occupe de restaurer les deux user mysql opentalent et openassos
qui n'avaient pas été synchronisés.
> https://ressources.opentalent.fr/display/EX/Mise+en+oeuvre+exploitation  => chapitre "Accès PHPMYADMIN centralisé  / MYSQL"

Pour vérifier que le user est créé, je me connecte avec ce compte via mysql workbench. Ca fonctionne bien.
J'essaie:
* un select sur la table `be_users_SAVE` => ok
* un update sur la table `be_users_SAVE` => ok
* de drop la table `be_users_SAVE` => ok

Le user a tous les droits, c'est bon.

Je réactualise https://preprod.opentalent.fr/typo3/install.php

J'arrive bien sur la page de l'install tool, tout va bien.

![img](images/03.png)

Je clique sur le bouton "Backend admin", je renseigne le login/mdp du compte oaos,
me voilà sur le backend: jusque là tout va bien.

Je vais donc contrôler plus en détail que tout est identique à la prod.

Pour la comparaison entre les différents sites, je procède
par échantillonage, avec le site de la CMF (uid=12055)

Côté Backend / Pages, pas de différences.
En revanche, je n'ai pas réussi à comparer les frontend (voir erreur ci dessous)...

![img](images/04.png)

J'essaie donc de desactiver realurl via le menu des extensions,
puis d'accéder à nouveau au frontend.

Je constate à cette occasion que j'avais fait une erreur dans l'url,
le paramètre n'est pas `uid=`, mais `id=`

Je réactive realurl, je reessaye d'accéder à l'adresse <https://preprod.opentalent.fr/index.php?id=12055>
Ca fonctionne partiellement, mais j'ai des erreurs avec certains widgets:

Je vide le cache, je réessaye: les erreurs persistent.
Je n'en recherche pas la cause pour le moment, probablement un conflit causé par le fait que
realurl est activé mais qu'on accès à la page depuis un autre domaine...

Je compare maintenant la liste des extensions.
Les extensions sont parfaitement identiques: installées, activées, versions.
Je n'ai contrôlé la config que des deux premières, ça m'a paru suffisant pour valider.

Je contrôle les onglets suivants:

* Langues: idem
* Corbeille: idem
* Workspaces: idem
* Formulaires (onglet extrêmement long à charger): idem
* gabarits: idem
* galerie de thèmes: idem
* accès: idem
* users backend: idem
* planificateur: idem
* Configuration: idem a priori (trop long pour être entièrement contrôlé)

L'onglet actualités a été testé avec le site Fédération musicale d'Anjou (uid=99494)


J'ouvre les onglets 'install' de chaque instance, **premières différences**:
les versions de mysql, et le nombre de tables.

![img](images/07.png)

On se souvient qu'une table a été supprimée de la preprod (be_users_SAVE)
pour tester les droits du compte restauré.

Pourtant, on a encore 6 tables de plus sur la preprod!

L'onglet Rapports présente aussi des différences:

![img](images/08a.png)
![img](images/08b.png)
![img](images/08c.png)

Ces différences sont:

* Droits d'écriture sur la preprod
* Avertissement quant au charset de mysql: Checking database character set failed,
  got key "latin1" instead of "utf8" or "utf8mb4"

La comparaison des onglet 'Ficjhier journal' présente aussi
des différences, avec des erreurs en plus côté preprod:

![img](images/09.png)

Ces erreurs sont sans doute liées aux problèmes de droits mentionnés dans l'onglet rapport.

Un contrôle du côté des phpinfo montre encore quelques différences:

* Dans "Additional .ini files parsed": la ligne suivante
  est sur la preprod mais pas sur la prod: `/etc/php/7.0/fpm/conf.d/20-apcu_bc.ini`
* La section Configuration comporte une sous-section `apc` sur la preprod, pas sur la prod
* Le param `memory_limit` est à 4096k sur la preprod et de 512M sur la prod (!)
* Le param `post_max_size` est à 8M sur la preprod contre 150M sur la prod
* Le param `upload_max_filesize` est à 6M sur la preprod contre 100M sur la prod
* la timezone est reglée sur Paris pour la preprod, et sur Berlin pour la prod
* Les variables d'environnement sont aussi différentes:
  * Preprod: USER=exploitation et HOME=/home/exploitation
  * Prod: USER=www-data et HOME=/var/www


Pour résumer, voici les différences constatées entre les deux instances:

1. Versions de mysql: 5.5.5 sur la preprod, 5.7.3 sur la prod
2. Nombre de tables /!\: 7 tables en plus sur la preprod
3. Différence entre les droits sur les répertoires: typo3temp et typo3conf
4. DB n'ont pas le même charset
5. Quelques différences entre les confs php, a priori benignes

Les tables en trop sur la preprod sont:

* Access
* be_users_SAVE
* fe_users_adminassos
* fe_users_username
* pages_with_original_pidroot
* tt_content_save
* tt_content_v59

Il s'agit de tables obsolètes supprimées sur la prod par Michel il y a quelques jours,
étrange qu'elles aient été restaurées sur la preprod au cours de la synchro...

Je fais un retour à Tony de ces écarts pour en discuter.

Il en résulte que:

1. Les tables en trop viennent d'un souci avec le script de synchro
   des bases qui ne faisait pas le drop/creat database / corrigé

2. Les droits sur le répertoire viennent du fait que le user php
   sur preprod est 'exploitation', tandis que c'est 'www-data' sur prod-front.
   Tony corrige le pbm en faisant:

   chown -R exploitation:www-data /var/www/typo3

**IMPORTANT: Tony signale qu'il faudra envisager de changer ce user sur prod-front aussi**,
en faisant un chown pour exploit, puis en changeant le user de php-fpm et le user de apache2.

3. La différence de version entre les mysql ne peut pas être corrigée pour le moment,
   mais ne devrait pas engendrer de problème.

4. Tony supprime le fichier 20-apcu_bc.ini et redémarre php-fpm.

Les autres différences sont négligeables.

A ce niveau, Tony fait un nouveau snapshot ('before.upgrade.typo3' sur N2, 17/06 17h25).

## Essais

### Essai 1 - 18/06/2020

Pour commencer, je renomme le répertoire typo3 existant
et je créé un nouveau répertoire:

    sudo mv /var/www/typo3 /var/www/typo3_82
    sudo chown -R exploitation:www-data /var/www/typo3
    mkdir /var/www/typo3

Je récupère ensuite les fichiers que je sais être nécessaires à typo3:

    cp /var/www/typo3_82/.htaccess /var/www/typo3/.htaccess
    cp -r /var/www/typo3_82/typo3_src_version/typo3_src-8.7.22 /var/www/typo3/
    cp -r /var/www/typo3_82/typo3conf /var/www/typo3/

Je recréé les liens symboliques:

    ln -s /var/www/typo3/typo3_src-8.7.22 /var/www/typo3/typo3_src
    ln -s /var/www/typo3/typo3_src/typo3 /var/www/typo3/typo3
    ln -s /var/www/typo3/typo3_src/index.php /var/www/typo3/index.php

Ainsi que le répertoire du cache:

    mkdir /var/www/typo3/typo3temp

Je devrais aussi récupérer fileadmin, mais il est trop volumineux...
J'ai plusieurs possibilités:

* déplacer ce répertoire avec mv, mais on perd la possibilité de revenir en arrière
  si ce répertoire est modifié durant l'upgrade...
* Créer un lien symbolique, même problème.
* En faire une copie partielle, suffisante pour mener des tests avec deux ou trois sites.
  Je vais d'abord essayer cette méthode.

Je vais donc essayer de faire une copie partielle et minimale du répertoire fileadmin.
Je vais essayer de reprendre les fichiers des sites ohcluses (498) et cmf-france (12097)


* `_processed_` contient les miniatures d'images, elles seront regénérées
* `_temp_` sera regénéré aussi
* `user_upload` contient à la fois des fichiers "en vrac" et un sous-répertoire par site.

  mkdir /var/www/typo3/fileadmin
  mkdir /var/www/typo3/fileadmin/_processed_
  mkdir /var/www/typo3/fileadmin/_temp_
  mkdir /var/www/typo3/fileadmin/user_upload
  cp -r /var/www/typo3_82/fileadmin/user_upload/498 /var/www/typo3/fileadmin/user_upload/
  cp -r /var/www/typo3_82/fileadmin/user_upload/12097 /var/www/typo3/fileadmin/user_upload/

Je vais aussi créer la nouvelle base de données 'typo3', et de faire pointer le nouveau typo3 vers celle-ci.

J'essaie avec ces commandes, qui échouent ('erreur de syntaxe sql'?).

    mysql -h localhost -P 3306 -u root --password=mysql2iopenservice369566 -e "DROP DATABASE IF EXISTS `typo3`;"
    mysql -h localhost -P 3306 -u root --password=mysql2iopenservice369566 -e "CREATE SCHEMA `typo3` DEFAULT CHARACTER SET utf8;"

Je n'insiste pas, je passe par mysql workbench pour exécuter les requêtes.
Dans mysql workbench, connecté à preprod.opentalent.fr en tant que `root`, j'exécute:

    CREATE SCHEMA `typo3` DEFAULT CHARACTER SET utf8 ;

Je vais maintenant dupliquer les tables de la base locale openassos vers cette nouvelle base:

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 openassos | mysql -h localhost -P 3306 -u root --password=mysql2iopenservice369566 -D typo3

L'opération dure environ 8 minutes.

Je créé aussi un nouvel utilisateur nommé `typo3`, à qui j'accorde tous les droits sur la nouvelle base:
Le mot de passe est le même que openassos: Vq2icge7SM3P26CaC3

Via mysql workbench:

    CREATE USER 'typo3'@'localhost' IDENTIFIED BY 'Vq2icge7SM3P26CaC3';
    GRANT ALL PRIVILEGES ON typo3.* TO 'typo3'@'localhost'; 


Je modifie ensuite la configuration de la nouvelle instance typo3:

    nano /var/www/typo3/typo3conf/LocalConfiguration.php

Je corrige la section `'DB' => ['Connections' => [` de la manière suivante:

    'charset' => 'utf8',
    'dbname' => 'typo3',
    'driver' => 'mysqli',
    'host' => 'localhost',
    'initCommands' => '',
    'password' => 'Vq2icge7SM3P26CaC3',
    'user' => 'typo3',

J'essaie d'accéder à <https://preprod.opentalent.fr/typo3/install.php>

Typo3 me demande de créer un fichier ENABLE_INSTALL_TOOL dans typo3conf/

    touch /var/www/typo3/typo3conf/ENABLE_INSTALL_TOOL

Je rafraichis la page <https://preprod.opentalent.fr/typo3/install.php>
Je renseigne le mdp, je valide.

Jusqu'ici, tout a l'air ok:

![img](images/10.png)

Je me rend à la page 'Folder Structure', qui affiche les avertissements suivants:

    File /typo3temp/index.html does not exist
    Directory /typo3temp/assets/css does not exist
    Directory /typo3temp/assets/js does not exist
    Directory /typo3temp/assets/images does not exist
    Directory /typo3temp/assets/_processed_ does not exist
    File /typo3temp/var/.htaccess does not exist
    Directory /typo3temp/var/charset does not exist
    Directory /typo3temp/var/locks does not exist
    Directory /uploads does not exist
    File /uploads/index.html does not exist
    Directory /uploads/media does not exist
    File /uploads/media/index.html does not exist
    File /fileadmin/_temp_/.htaccess does not exist
    File /fileadmin/_temp_/index.html does not exist
    Directory /fileadmin/user_upload/_temp_ does not exist
    File /fileadmin/user_upload/_temp_/index.html does not exist
    Directory /fileadmin/user_upload/_temp_/importexport does not exist
    File /fileadmin/user_upload/_temp_/importexport/.htaccess does not exist
    File /fileadmin/user_upload/_temp_/importexport/index.html does not exist
    File /fileadmin/user_upload/index.html does not exist

L'installeur propose d'essayer de corriger lui-même ces erreurs
L'absence des sous-répertoires de typo3temp est normale, on va laisser l'outil les créer.
Idem pour /fileadmin/user_upload/_temp_/
En revanche, le répertoire uploads, que je n'avais pas copié plus tôt, est bien requis par typo3 en v8
(ce n'est plus le cas en v9)

Je vais lancer l'outil de correction, puis j'essaierai de copier de manière selective le contenu de uploads,
comme je l'avais fait pour le répertoire fileadmin.

Je clique sur le bouton 'Try to fix file and folder permissions'
Tout est corrigé, pas de problème.

Le répertoire original contient un trés grand nombre de fichiers, ainsi que les sous-répertoires suivants:

    ../typo3_82/uploads/manual/              ../typo3_82/uploads/tx_gridelements/      ../typo3_82/uploads/tx_rteckeditorimage/
    ../typo3_82/uploads/media/               ../typo3_82/uploads/tx_gsiwhoisonline/    ../typo3_82/uploads/tx_rtehtmlarea/
    ../typo3_82/uploads/newsletters/         ../typo3_82/uploads/tx_kickstarter/       ../typo3_82/uploads/tx_seobasics/
    ../typo3_82/uploads/openassos/           ../typo3_82/uploads/tx_mmforum/           ../typo3_82/uploads/tx_simpleslider/
    ../typo3_82/uploads/opentalent/          ../typo3_82/uploads/tx_newloginbox/       ../typo3_82/uploads/tx_tc2lcal/
    ../typo3_82/uploads/pics/                ../typo3_82/uploads/tx_news/              ../typo3_82/uploads/tx_templavoila/
    ../typo3_82/uploads/templates_email/     ../typo3_82/uploads/tx_phpmyadmin/        ../typo3_82/uploads/tx_tqseo/
    ../typo3_82/uploads/tf/                  ../typo3_82/uploads/tx_piwik/             ../typo3_82/uploads/tx_ttnews/
    ../typo3_82/uploads/tx_c1x1flashplayer/  ../typo3_82/uploads/tx_piwikintegration/  ../typo3_82/uploads/tx_txopenassos/
    ../typo3_82/uploads/tx_devlog/           ../typo3_82/uploads/tx_powermail/         ../typo3_82/uploads/tx_veguestbook/
    ../typo3_82/uploads/tx_felogin/          ../typo3_82/uploads/tx_realurl/
    ../typo3_82/uploads/tx_festat/           ../typo3_82/uploads/tx_rgsmoothgallery/

Pour savoir lesquels reprendre, j'envisage de me baser sur la table 'sys_file' de la base de données,
avec la requête suivante:

    SELECT * FROM sys_file WHERE identifier LIKE '/uploads/[nom du sous-répertoire]'

Les requêtes qui ne renverrait aucune ligne signaleraient (sauf erreur de ma part) des fichiers orphelins,
et donc plus nécessaires.

On constate ainsi que les fichiers contenus dans

Mais il faudrait faire la même chose pour chaque fichier...

On pourrait envisager un script qui recherche de tels fichiers, ou qui repositionne
correctement les fichiers qui sont "un peu perdus"...

Pour l'instant, je ne vais copier que les sous-répertoires 'media', 'tx_news', et 'pics'

    cp /var/www/typo3_82/uploads/media/* /var/www/typo3/uploads/media/
    cp -r /var/www/typo3_82/uploads/tx_news /var/www/typo3/uploads/
    cp -r /var/www/typo3_82/uploads/pics /var/www/typo3/uploads/pics

L'opération dure environ environ 3minutes.

Je retourne sur <https://preprod.opentalent.fr/typo3/install.php>
Je dois de nouveau créer le fichier ENABLE_INSTALL_TOOL:

    touch /var/www/typo3/typo3conf/ENABLE_INSTALL_TOOL

Je me rend à la page 'System environment': tout est ok.

Tout a l'air bon, je continue vers le backend.

**Premier souci**: l'outil 'Pages' n'affiche plus rien.

![img](images/11.png)

Si je clique sur 'Editer la page', l'écran d'édition s'ouvre bien.
Apparemment, les gabarits backend sont invalides ('theme_gallery__home' et '0')

De plus, la page 'galerie des thèmes' est vide.

Malgré ces erreurs au niveau backend (sans doute liées au fait que je n'ai pas copié certains
dossiers comme le lien vers 'websites' ), le frontend s'affiche sans problème apparent.
Je ne vais donc pas passer de temps à faire fontionner des extensions obsolètes.


Je procède donc à l'upgrade vers la v9.5.

    cd /var/www/typo3/
    rm .htaccess
    wget --content-disposition https://get.typo3.org/9.5.19
    tar xzvf typo3_src-9.5.19.tar.gz
    ln -sfn typo3_src-9.5.19 typo3_src
    touch typo3conf/ENABLE_INSTALL_TOOL
    cp typo3/sysext/install/Resources/Private/FolderStructureTemplateFiles/root-htaccess ./.htaccess

Je retourne sur <https://preprod.opentalent.fr/typo3/install.php>

Une erreur se produit:

![img](images/12.png)

Je commence par vider le cache avec:

    rm -r /var/www/typo3/typo3temp

Et en exécutant les requêtes suivantes sur mysql workbench:

    TRUNCATE `cf_cache_hash`;
    TRUNCATE `cf_cache_hash_tags`;
    TRUNCATE `cf_cache_imagesizes`;
    TRUNCATE `cf_cache_imagesizes_tags`;
    TRUNCATE `cf_cache_news_category`;
    TRUNCATE `cf_cache_news_category_tags`;
    TRUNCATE `cf_cache_pages`;
    TRUNCATE `cf_cache_pagesection`;
    TRUNCATE `cf_cache_pagesection_tags`;
    TRUNCATE `cf_cache_pages_tags`;
    TRUNCATE `cf_cache_rootline`;
    TRUNCATE `cf_cache_rootline_tags`;
    TRUNCATE `cf_extbase_datamapfactory_datamap`;
    TRUNCATE `cf_extbase_datamapfactory_datamap_tags`;
    TRUNCATE `cf_extbase_reflection`;
    TRUNCATE `cf_extbase_reflection_tags`;
    TRUNCATE `cf_workspaces_cache`;
    TRUNCATE `cf_workspaces_cache_tags`;

J'essaie de nouveau d'accéder à <https://preprod.opentalent.fr/typo3/install.php>
L'erreur persiste.
Pas de log dans typo3temp.

La commande suivante:

    tail /var/log/apache2/preprod.opentalent.fr-error.log 

Permet d'obtenir le messages d'erreur suivant:

    [Thu Jun 18 15:34:23.531613 2020] [proxy_fcgi:error] [pid 29124:tid 139930525337344] [client 10.8.0.10:45626] AH01071: Got error 'PHP message: https://preprod.opentalent.fr/ - Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1341397869: Path does not exist in array | RuntimeException thrown in file /var/www/typo3/typo3_src-8.7.22/typo3/sysext/core/Classes/Utility/ArrayUtility.php in line 197. Requested URL: https://preprod.opentalent.fr/typo3/install.php?install[redirectCount]=2&install[context]=standalone&install[controller]=step&install[action]=databaseData\n'
    [Thu Jun 18 15:34:29.994980 2020] [proxy_fcgi:error] [pid 29124:tid 139930525337344] [client 10.8.0.10:45628] AH01071: Got error 'PHP message: https://preprod.opentalent.fr/ - Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1341397869: Path does not exist in array | RuntimeException thrown in file /var/www/typo3/typo3_src-8.7.22/typo3/sysext/core/Classes/Utility/ArrayUtility.php in line 197. Requested URL: https://preprod.opentalent.fr/typo3/install.php?install[redirectCount]=2&install[context]=standalone&install[controller]=step&install[action]=databaseData\n'
    [Thu Jun 18 15:35:40.006308 2020] [proxy_fcgi:error] [pid 29124:tid 139930525337344] [client 10.8.0.10:45630] AH01071: Got error 'PHP message: https://preprod.opentalent.fr/ - Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1460976566: [module-web_func] The option "source" is required and must not be empty | InvalidArgumentException thrown in file /var/www/typo3/typo3_src-8.7.22/typo3/sysext/core/Classes/Imaging/IconProvider/SvgIconProvider.php in line 48. Requested URL: https://preprod.opentalent.fr/typo3/index.php?route=%2Fmain&token=--AnonymizedToken--\n'
    [Thu Jun 18 15:35:47.106044 2020] [proxy_fcgi:error] [pid 29124:tid 139930525337344] [client 10.8.0.10:45632] AH01071: Got error 'PHP message: https://preprod.opentalent.fr/ - Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1341397869: Path does not exist in array | RuntimeException thrown in file /var/www/typo3/typo3_src-8.7.22/typo3/sysext/core/Classes/Utility/ArrayUtility.php in line 197. Requested URL: https://preprod.opentalent.fr/typo3/install.php?install[redirectCount]=2&install[context]=standalone&install[controller]=step&install[action]=databaseData\n'
    [Thu Jun 18 15:38:06.481022 2020] [proxy_fcgi:error] [pid 29124:tid 139930525337344] [client 10.8.0.10:45634] AH01071: Got error 'PHP message: https://preprod.opentalent.fr/ - Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1257246929: Tried resolving a template file for controller action "Standard->index" in format ".html", but none of the paths contained the expected template file (/var/www/typo3/typo3/sysext/install/Resources/Private/Templates/Action/Common/Login.html). No paths configured. | TYPO3Fluid\\Fluid\\View\\Exception\\InvalidTemplateResourceException thrown in file /var/www/typo3/typo3_src-8.7.22/vendor/typo3fluid/fluid/src/View/TemplatePaths.php in line 598. Requested URL: https://preprod.opentalent.fr/typo3/install.php\n'

typo3_src-8.7.22 est encore mentionné.
Une erreur avec les liens symboliques? J'essaie de les regénérer à tout hasard:

    ln -s /var/www/typo3/typo3_src-9.5.19 /var/www/typo3/typo3_src
    ln -s /var/www/typo3/typo3_src/typo3 /var/www/typo3/typo3
    ln -s /var/www/typo3/typo3_src/index.php /var/www/typo3/index.php

J'ai une erreur lors de la dernière commande, disant que le fichier existe.
Pourtant c'est aussi un symlink, il devrait être remplacé?

Je lance:

    rm index.php
    ln -s /var/www/typo3/typo3_src/index.php /var/www/typo3/index.php

J'essaie de nouveau d'accéder à <https://preprod.opentalent.fr/typo3/install.php>
L'erreur persiste.

Un nouveau coup d'oeil aux logs montre que l'erreur est bien celle-ci:

    [Thu Jun 18 15:46:24.999451 2020] [proxy_fcgi:error] [pid 29124:tid 139930525337344] [client 10.8.0.10:45656] AH01071: 
    Got error 'PHP message: https://preprod.opentalent.fr/ - Core: 
    Exception handler (WEB): Uncaught TYPO3 Exception: #1257246929: 
    Tried resolving a template file for controller action "Standard->index" in format ".html", 
    but none of the paths contained the expected template file 
    (/var/www/typo3/typo3/sysext/install/Resources/Private/Templates/Action/Common/Login.html). 
    No paths configured. | TYPO3Fluid\\Fluid\\View\\Exception\\InvalidTemplateResourceException 
    thrown in file /var/www/typo3/typo3_src-8.7.22/vendor/typo3fluid/fluid/src/View/TemplatePaths.php 
    in line 598. Requested URL: https://preprod.opentalent.fr/typo3/install.php\n'

Il semble effectivement que le répertoire
`/var/www/typo3/typo3/sysext/install/Resources/Private/Templates/Action`
n'existe pas. Mais pourquoi est-ce que l'erreur est lanceée depuis la version 8.2?

Une possible explication: https://serverfault.com/questions/294107/apache-php-appears-to-be-caching-symbolic-links-for-60-seconds-how-to-stop-it

En effet, si apache/php a mis les symlinks en cache, tout s'explique.
Je vais essayer de vider le cache de apache et php.

Premier essai en redémarrant le service apache

    sudo service apache2 restart

Sans résultat, les logs sont toujours les même.
Au tour de php-fpm

    sudo service php7.0-fpm restart

Ca corrige l'erreur, mais aïe.
Aïe aïe aïe.

![img](images/13.png)

Effectivement, la version php était en 7.2 sur mon poste, et sur le docker.
Et ça c'est un problème...

Après renseignements, on peut upgrader php vers la 7.2 sur prod-front sans souci.
Le pbm est avec preprod, où cohabitent toutes les applis, y compris opentalent qui ne tourne qu'en 7.0.

Je contacte Tony pour lui demander si possible de faire cohabiter 2 versions de php.
Il me répond que pas de souci avec php-fpm, on peut affecter
des versions de php aux différents virtualhosts.

Le virtualhost concerné est `001-preprod.opentalent.fr.conf`

Tony me suggère de passer directement à la 7.4, puisque la 7.2 ne sera plus supportée fin 2020.
Je valide pour la 7.4
Il s'occupe de faire la modif.

Il règle le souci très vite, nous voilà avec php 7.4.7 pour typo3,
et toujours la 7.0 pour les autres sites.

J'essaie de d'accéder à <https://preprod.opentalent.fr/typo3/install.php>
...Et victoire!

![img](images/14.png)


> Pour mémoire, la procédure qu'a suivie Tony et qu'il m'a transmise est la suivante:
> Upgrade php7.4:

    # add-apt-repository ppa:ondrej/php
    # apt update
    #  apt install php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-dev php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-tidy php7.4-xml php7.4-xsl php7.4-zip php-apcu
    # a2enmod proxy_fcgi setenvif
    # a2enconf php7.0-fpm
    # a2enconf php7.4-fpm
    Modification de /etc/php/7.4/fpm/pool.d/www.conf
    Modification des virtualhosts apache2 et selon les cas indiquer : 
      <FilesMatch ".+\.ph(p[3457]?|t|tml)$">
        SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"
      </FilesMatch>
    Ou 
      <FilesMatch ".+\.ph(p[3457]?|t|tml)$">
        SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost"
      </FilesMatch>
    Reprise du php.ini de la v7.0 pour le recopier en v7.4 de manière a avoir les memes parametre php.ini


J'essaie maintenant d'aller sur le backend pour verifier les extensions installées,
mais une erreur se produit, ce qui n'est pas surprenant.

![img](images/15.png)

Comme le suggère [la documentation](https://docs.typo3.org/m/typo3/guide-installation/9.5/en-us/Upgrade/UpdateReferenceIndex/Index.html),
je commence par mettre à jour les index:

    php7.4 /var/www/typo3/typo3/sysext/core/bin/typo3 referenceindex:update

L'erreur suivante se produit:

    Uncaught TYPO3 Exception Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::requireOnce()
    thrown in file /var/www/typo3/typo3conf/ext/realurl/ext_localconf.php
    in line 32

J'essaie de vider le cache, mais une erreur se produit.

Bon, je commence par m'assurer que les droits sur les répertoires sont bons.

L'outil 'Directory Status' relève les problèmes suivants:

    File /typo3temp/index.html does not exist
    Directory /typo3temp/assets does not exist
    Directory /typo3temp/assets/compressed does not exist
    Directory /typo3temp/assets/css does not exist
    Directory /typo3temp/assets/js does not exist
    Directory /typo3temp/assets/images does not exist
    Directory /typo3temp/assets/_processed_ does not exist
    File /typo3temp/var/.htaccess does not exist
    Directory /typo3temp/var/charset does not exist
    Directory /typo3temp/var/lock does not exist

Pas de problème sérieux, je clique sur 'Try to fix file and folder permissions'
Tout se passe bien.

Le wizard signale aussi que les permissions de certains répertoires ne sont pas
les permissions par défaut, je lance donc les commandes suivantes:

    chmod 2770 /var/www/typo3
    chmod 2770 /var/www/typo3/typo3temp
    chmod 2770 /var/www/typo3/typo3conf
    chmod 2770 /var/www/typo3/typo3conf/ext
    chmod 2770 /var/www/typo3/typo3conf/l10n
    chmod 2770 /var/www/typo3/fileadmin
    chmod 2770 /var/www/typo3/fileadmin/_temp_
    chmod 2770 /var/www/typo3/fileadmin/user_upload
    chmod 2660 /var/www/typo3/.htaccess

Il signale aussi que le contenu de deux fichiers diffère du contenu par défaut, je lance donc:

     rm /var/www/typo3/fileadmin/_temp_/index.html
     rm /var/www/typo3/fileadmin/user_upload/_temp_/importexport/index.html

Je rafraichis l'outil Directory Status, et je clique sur 'Try to fix file and folder permissions'.

Tout est au vert du côté des fichiers.

Avec Mysql Workbench, je lance les requêtes:

    TRUNCATE `cf_cache_hash`;
    TRUNCATE `cf_cache_hash_tags`;
    TRUNCATE `cf_cache_imagesizes`;
    TRUNCATE `cf_cache_imagesizes_tags`;
    TRUNCATE `cf_cache_news_category`;
    TRUNCATE `cf_cache_news_category_tags`;
    TRUNCATE `cf_cache_pages`;
    TRUNCATE `cf_cache_pagesection`;
    TRUNCATE `cf_cache_pagesection_tags`;
    TRUNCATE `cf_cache_pages_tags`;
    TRUNCATE `cf_cache_rootline`;
    TRUNCATE `cf_cache_rootline_tags`;

Le cache est vidé, mais l'erreur persiste lors de l'accès au backend (pas étonnant).

Je lance l'upgrade wizard, qui me donne les erreurs suivantes:

![img](images/16.png)

Un contrôle via l'outil 'Check for broken extensions' révèle le problème suivant:

![img](images/17.png)

Je vais essayer de desactiver l'extension fautive (sans la désinstaller complètement)
J'en profite pour remarquer qu'il y a beaucoup de fichiers inutiles ici aussi,
donc je commence par un peu de ménage:

    cd /var/www/typo3/typo3conf
    rm "How to install Matomo.html"
    rm realurl_autoconf.php.auto.save
    rm realurl_autoconf.php.copy
    rm realurl_autoconf.php.save
    rm tx_mmforum_config.ts
    rm domains_list.php.save

Pour les répertoires matomo, piwik, autoload, et les fichiers extTables.php, domains_list.php,
realurl_autoconf.php et realurl_autoconf.php.auto: je ne suis pas sûr, donc j'y reviendrai plus tard.

J'ouvre en édition le fichier PackageState:

    nano /var/www/typo3/typo3conf/PackageStates.php

Je modifie le fichier en commentant les trois lignes suivantes:

        #'realurl' => [
        #    'packagePath' => 'typo3conf/ext/realurl/',
        #],

Je relance l'outil de contrôle des extensions.
Tous les fichiers ext_localconf.php sont ok.
Le fichier ext_tables.php de ot_cms pose problème.

Je desactive cette extension:

    nano /var/www/typo3/typo3conf/PackageStates.php

Je commente:

    #'ot_cms' => [
    #    'packagePath' => 'typo3conf/ext/ot_cms/',
    #],

Je relance l'outil de contrôle des extensions: tout est au vert.

Je relance l'upgrade wizard, une erreur se produit, mais différente de celle de tout à l'heure.

![img](images/18.png)

Pour en savoir plus, j'ouvre l'outil "configuration presets", et je le passe du mode actuel (voir image)
au mode debug

![img](images/19.png)

En relancant l'ugrade wizard, j'obtiens une erreur plus explicite:

![img](images/20.png)

Il s'agit donc d'installer le module apcu pour php7.4.
Ce qui est étrange, c'est que je lance l'outil 'Environment Status', et qu'il ne signale pas l'erreur
(tout est ok, sauf des HTTP warning conernant des fichiers temporaires. je néglige)

Je suis le guide ici: https://serverpilot.io/docs/how-to-install-the-php-apcu-extension/
et je lance

    sudo pecl7.4-sp install apcu

Ce qui me donne:

    -bash: pecl7.4-sp : commande introuvable

Je contacte Tony, qui l'installe avec apt
et corrige la commande apt-get (modifié dans les notes plus haut).

Je relance l'upgrade wizard, qui cette fois m'affiche une liste
de tables et champs à créer dans la DB:

    Table: pages, Field: rowDescription
    Table: pages, Field: sys_language_uid
    Table: pages, Field: l10n_source
    Table: pages, Field: l10n_state
    Table: pages, Field: l10n_diffsource
    Table: pages, Field: slug
    Table: pages, Field: legacy_overlay_uid
    Table: pages, Field: l10n_parent
    Table: sys_history, Field: actiontype
    Table: sys_history, Field: usertype
    Table: sys_history, Field: userid
    Table: sys_history, Field: originaluserid
    Table: sys_history, Field: workspace
    Table: tx_scheduler_task, Field: deleted
    Table: tt_content, Field: filelink_sorting_direction
    Table: pages, Index: language_identifier
    Table: pages, Index: slug
    Table: pages, Index: translation_source
    Table: sys_file, Index: parent
    Table: sys_file_reference, Index: t3ver_oid
    Table: tt_content, Index: translation_source
    Table: tx_extensionmanager_domain_model_repository, Index: parent
    Table: tx_extensionmanager_domain_model_extension, Index: parent
    Table: tx_news_domain_model_news, Index: t3ver_oid
    Table: tx_news_domain_model_link, Index: t3ver_oid

Je clique sur 'Créer les tables'

Le wizard propose d'autres corrections:

1. Rename form definition file extension from .yaml to .form.yaml
2. Add the default Extension Manager database tables
3. Update backend user setting "startModule"
4. Migrate bullet content element rendering selector from layout to bullets_type
5. Migrate upload content element rendering from layout to uploads_type
6. Install compatibility extension for TYPO3 7 compatibility
7. Install extension "form_legacy"
8. Install extension "rtehtmlarea" from TER
9. Install extension "typo3db_legacy" from TER
10. Install extension "func" from TER
11. Migrate pages.urltype to pages.url
12. Migrates existing sys_log entries into sys_history
13. Merge be_groups access rights from pages_language_overlay to pages
14. Install system extension "redirects" if a sys_domain entry with redirectTo is necessary
15. Install extension "adminpanel"
16. Introduce URL parts ("slugs") to all existing pages
17. Reminder to verify live system supports argon2i
18. Update backend user configuration array
19. Updates slug field "path_segment" of EXT:news records

J'exécute l'étape 1.
Une erreur se produit, il faut renommer manuellement:

    mv /var/www/typo3/typo3conf/ext/theme_gallery/Resources/Private/Forms/Contact.yaml /var/www/typo3/typo3conf/ext/theme_gallery/Resources/Private/Forms/Contact.form.yaml

Une foir relancé, l'upgrade wizard mentionne de nouveaux index manquants:

Table: sys_file, Index: parent
Table: sys_file_reference, Index: t3ver_oid
Table: tt_content, Index: translation_source

Je clique sur "Create missing tables and fields"

Je ré-exécute l'étape 1.
Ok.

    Etape 2: ok
    Etape 3: ok
    Etape 4: ok
    Etape 5: ok
    
    Etape 6: je clique sur execute, puis laisser à "no do not execute", puis perform
    Etape 7: je clique sur execute, puis laisser à "no do not execute", puis perform
    Etape 8: je clique sur execute, puis laisser à "no do not execute", puis perform
    Etape 9: je clique sur execute, puis laisser à "no do not execute", puis perform
    Etape 10: je clique sur execute, puis je clique à "Yes, execute", puis perform

Une erreur se produit:

![img](images/21.png)

Je desactive l'extension `ot_migration_typo8` dans PackageStates

    nano /var/www/typo3/typo3conf/PackageStates.php

Je modifie le fichier en commentant les trois lignes suivantes:

        #'ot_migration_typo8' => [
        #    'packagePath' => 'typo3conf/ext/ot_cms/',
        #],


Je rouvre l'upgrade wizard, il me redemande de créer les champs suivants:

Table: sys_file, Index: parent
Table: sys_file_reference, Index: t3ver_oid
Table: tt_content, Index: translation_source

Il n'arrive sans doute pas à créer ces index. Je clique quand même sur 'Create missing fields'

Je relance l'étape 10:

Etape 10: je clique sur execute, puis je clique à "Yes, execute", puis perform

Une nouvelle erreur de dependance, cette fois avec ot_portail.

Je desactive donc toutes les ext opentalent, en commentant:

        #'ot_portail' => [
        #    'packagePath' => 'typo3conf/ext/ot_portail/',
        #],
        #'ot_portail' => [
        #    'packagePath' => 'typo3conf/ext/ot_portail/',
        #],
        #'theme_gallery' => [
        #    'packagePath' => 'typo3conf/ext/theme_gallery/',
        #],
        #'typo3_api' => [
        #    'packagePath' => 'typo3conf/ext/typo3_api/',
        #],

Je rouvre l'upgrade wizard, il me redemande de créer les champs suivants:

Table: sys_file, Index: parent
Table: sys_file_reference, Index: t3ver_oid
Table: tt_content, Index: translation_source

Il n'arrive sans doute pas à créer ces index. Je clique quand même sur 'Create missing fields'

Je relance l'étape 10:

Etape 10: je clique sur execute, puis je clique à "Yes, execute", puis perform

L'exécution reste en cours un long moment sans se terminer
Puis se termine correctement.

Etape 11: ok

L'etape 12 sera trop longue en l'état, j'en profite pour nettoyer les vieux enregistrements
de sys_log avec mysql workbench:

    DELETE FROM sys_log WHERE tstamp < UNIX_TIMESTAMP('2020-01-01 00:00:00');
    DELETE FROM sys_history WHERE tstamp < UNIX_TIMESTAMP('2019-01-01 00:00:00');
    DELETE FROM sys_log WHERE details LIKE 'User %s has cleared the cache%';
    DELETE FROM sys_log WHERE details LIKE 'Core: Error handler%';
    DELETE FROM sys_log WHERE details LIKE 'Core: Exception handler%';


Etape 12: ok
Etape 13: je clique sur execute, puis je clique à "Yes, execute", puis perform => ok
Etape 14: je clique sur execute, puis je clique à "Yes, execute", puis perform => ok
Etape 15: je clique sur execute, puis je clique à "Yes, execute", puis perform => ok
Etape 16: Une erreur se produit

![img](images/22.png)

L'erreur vient d'une page "orpheline" (uid: 563). En effete, sa page parent a été supprimée,

Un contrôle sur mysql WB avec la requête:

    select p.uid, p.deleted, p.pid, t.deleted from pages p 
    INNER JOIN pages t ON p.pid = t.uid
    WHERE p.deleted = 0 AND t.deleted = 1;

retourne 102 pages concernées: la page n'est pas deleted mais sa page parente l'est.

on lance donc dans mysql wb:

    UPDATE pages SET deleted = 1
    WHERE uid IN (520, 563, 606, 864, 907, 950, 999, 5159, 1044, 1087, 1172, 1221, 1394, 1484, 1527, 1570, 1613, 1656, 1699, 1742, 1785, 1828, 1869, 1913, 1960, 2003, 2046, 2094, 2139, 2182, 2224, 3092, 2265, 2317, 2361, 2520, 2566, 2611, 2657, 2740, 2786, 2832, 2878, 2924, 2970, 3016, 3062, 3116, 3164, 3210, 3256, 3302, 3348, 3394, 3484, 3530, 3578, 3624, 3670, 3716, 3762, 3819, 3865, 3911, 3957, 4003, 4049, 4095, 4141, 4262, 4311, 4358, 4405, 4605, 4656, 4705, 4754, 4803, 4852, 4901, 4950, 5000, 5049, 5232, 5279, 5326, 5373, 5467, 5514, 5561, 5608, 5655, 97765, 119555, 118038, 124625, 118690, 124790, 118691, 124791, 118881, 124855);

Je relance l'étape 16, l'erreur se présente à nouveau.
En effet, la requête précédente n'était pas récursive.

Je poursuis l'upgrade, je reviendrai sur dce point plus tard.

Etape 17: "Yes I understand" => ok
Etape 18: ok

Il reste les etapes 16 et 19, sur lesquelles je reviendrai.

Sur install:

* Flush TYPO3 and PHP Cache => ok
* Rebuild PHP Autoload Information => ok
* Reset Backend User Preferences => ok

Ensuite: Analyze Database Structure

Je coche les 5 corrections suivantes:

	DROP INDEX `deleted_hidden` ON `sys_file_storage`
    DROP INDEX `sys_log_uid` ON `sys_history`
    DROP INDEX `uid_foreign_tablenames` ON `sys_category_record_mm`
    DROP INDEX `tx_realurl` ON `sys_domain`
    DROP INDEX `tx_realurl` ON `sys_template`

puis Apply

En relancant l'uypgrade wizard, on constate qu'on a plus les
demandes de suppr d'indes: c'est tout bon.

Je me rend sur le BE, menu extensions, liste déroulante: "ajouter des ext"
Je met à jour l'index

Je reviens sur les ext installées, 3 ext ont besoin d'une update:

* frontend_editing: 1.9.4
* news: 8.3.0
* rte_ckeditor_image: 9.0.4

Je vérifie le 'Compare database': pas de nouvelle tabkle ou de nouveau champs.


A ce niveau, on a une version de typo3 v9.5 presque migrée.

Il reste à:

1. Passer le script python qui va

* corriger certaines erreurs de la base (pages orphelines entre autres)
* générer les fichiers yaml de conf des sites
* maj les id des structures (/!\ ot_templating nécessaire ici, il faudra peut-être créer le champ manuellement)
* mettre à jour les slugs, /!\ il faut retirer cette partie pour l'instant, les slugs doivent d'abord être repris depuis realurl
* maj les gabarits (il faut d'abord installer ot_templating!)
* (re)génerer les fichiers constants.txt
* repositionnement du contenu (il faut d'abord installer ot_templating! pas fonctionnel?)
* création des raccourcis 'accueil' (pas fonctionnel?)

2. basculer vers le mode composer
3. installer flux, vhs, ot_connect, ot_templating, ot_widgets


**Checkpoint 1**: Je commence par faire un dump de la DB.

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt1.sql

Je créé un dépot gitlab dédié pour remettre de l'ordre dans la doc et
les outils de l'upgrade: https://gitlab.2iopenservice.com/olivier/upgrade_typo8

Je vais maintenant refactoriser le script gen_sites.py pour le scinder
en un fix_db_95.py qui réparera les erreurs de la DB, et un script
conf_typo_95.py qui achèvera de configurer typo3 dans sa nouvelle version.

La refactorisation est faite, je créé un premier correctif dans fix_db_95.py qui
doit mettre à jour comme deleted les pages filles d'un parent deleted.

Ok, c'est fait, environ 380 pages concernées.

Je réessaye maintenant de lancer les deux dernières étapes de l'upgrade wizard (ex 16 et ex 19)
Etonnament, il y a de nouvelles étapes dispnibles, sans doute dûes au fait que j'ai
mis a jour des extensions, news en particulier.

1. Introduce URL parts ("slugs") to all existing pages
2. [Optional] Migrate realurl alias to slug field "path_segment" of EXT:news records
3. Updates slug field "path_segment" of EXT:news records
4. Introduce URL parts ("slugs") to all sys_categories

Je lance les étapes dans l'ordre:

Etape 1: (dure une bonne dizaine de minutes)
L'opération s'arrête sur un timeout, arf.

Je lance l'opération en ligne de commande pour éviter ce problème:

    php7.4 /var/www/typo3/typo3/sysext/core/bin/typo3 upgrade:run pagesSlugs

... qui s'avère être inutilisable, à cause d'apcu:

    The APCu backend cannot be used because apcu is disabled on CLI. 

J'essaie de relancer l'étape via l'interface, au cas où
les lignes déjà traitées ne seraient pas retraitées...
Mais non: l'erreur se produit à nouveau.

J'essaie d'activer apcu pour la ligne de dommande:

    nano /etc/php/7.4/cli/php.ini

J'ajoute la ligne:

    apc.enabled = 1
    apc.enable_cli = 1

Je redémarre php-fpm

    sudo service php7.4-fpm restart


Je relance l'update:

    php7.4 /var/www/typo3/typo3/sysext/core/bin/typo3 upgrade:run pagesSlugs

Ca fonctionne, mais pour une raison inconnue, l'upgrade est extrêmement lente
(à peine 13300 lignes traitées sur 129000, en presque 5 heures.)

Je trouve la localisation du code exécutée
(voir [ici](https://github.com/TYPO3/TYPO3.CMS/blob/8cb2b2437f9dea277a1d2fb2463bb025754e03bb/typo3/sysext/install/Classes/Updates/PopulatePageSlugs.php#L108))

Voilà ce que fait la fonction officielle:

1. Selection des lignes de la table pages où le champs slug est une chaine vide ou null
2. récupère d'éventuels slug existants de realurl (voir [ici](https://github.com/TYPO3/TYPO3.CMS/blob/8cb2b2437f9dea277a1d2fb2463bb025754e03bb/typo3/sysext/install/Classes/Updates/PopulatePageSlugs.php#L222)):
* dans la table `tx_realurl_pathdata` si la table existe
* dans le champs `cache_id` de la table `tx_realurl_pathcache` si la table existe
3. Parcourt les enreg de la selection (1)
4. Si le champs alias est renseigné, construit le slug a partir de là
5. Si ni alias, ni valeur depuis realurl: génère un nouveau slug (voir la [classe SlugHelper](https://github.com/TYPO3/TYPO3.CMS/blob/8cb2b2437f9dea277a1d2fb2463bb025754e03bb/typo3/sysext/core/Classes/DataHandling/SlugHelper.php#L157)):
* si page `is_siteroot`: le slug est '/', la fonction s'arrête là
* sinon, récupère ou reconstruit le slug du parent
* recupere la première valeur non vide dans: tx_realurl_pathsegment, title
* sanitize le slug
6. Vérifie les contraintes d'unicité du slug dans le site
7. Met à jour l'enregistrement


Visiblement, elle n'a pas été concue pour de si gros volumes de données...

Je vais essayer de réécrire la fonction: voir `populate_slugs_95.py`
J'ignore la table tx_realurl_pathcache, pour la raison qu'elle est vide.

Une première version du script est exécutée, mais elle n'a indexé que 122.964 pages, contre 129.017 présentes en base.
Aprés verification, c'est normal: les pages absentes sont les pages de type 'Folder'

Après relecture et correction le script semble ok.
Selon sa vitesse de progression observée sur mon poste, le script durera environ 3h30
(ce qui est long, mais toujours préférable aux plus de 50heures du scipt typo3)

Une petite évolution permet de passer à environ 1h30 de traitement.

Cependant, je constate que pour une grande partie des slugs (ceux hérités de realurl)
il manque le '/' en première position.

Je corrige donc le script pour que ce caractère soit ajouté automatiquement la prochaine fois,
puis je corrige "manuellement" en exécutant dans mysql WB:

    UPDATE pages SET slug = '/' + slug
    WHERE doktype != 254 AND slug NOT LIKE '/%'; 

Je constate aussi que certaines pages (112 pages) ont des titres vides et pas d'alias. Le script
est maintenant corrigé pour leur donner le slug 'no-title'.
Pour l'instant, je corrige lignes dans mysql WB:

    UPDATE pages SET slug = slug + 'no-title'
    WHERE doktype != 254 AND slug LIKE '%/' AND slug != '/'; 

Enfin, je note que 6677 pages ont encore un slug null.
Certaines de ces pages sont supprimées et n'ont pas de page racine (ex: uid 4)

En revanche, certaines autres devraient avoir des slugs... (ex: 26439, dont la page parent est 25530)
Après contrôle, je me rend compte que la page 25530 n'est pas indéxée, alors qu'elle existe dans la base...

La solution est toute simple:  25530 est un dossier! (doktype: 25530)
En revanche, la page parent de ce dossier est une page root (25529)
Que faire dans ce cas, dois-je générer des slugs pour ces cas particuliers?
Je laisse pour l'instant, mais il faudra en rediscuter.


Je vais maintenant générer les fichiers de configuration des sites.
Je vais créer un nouveau script `gen_sites_yaml.py`.

Le script est créé, je l'exécute.
Je dois le corriger pour gérer les sites sans domaines, voire sans titre.

Une fois les fichiers générés, je les transfère sur le serveur de preprod en me
servant de filezilla.
Je place donc tous les sous-répertoires qui contiennent les fichiers config.yaml dans le répertoire:

    /var/www/typo3/config/sites/...

Le transfert est trés lent, j'annule, je compresse le répertoire des sites:

Sur mon poste:

    tar czf sites.tar.gz sites/

J'exécute le transfert via filezilla (qui ne dure que qq secondes)

Sur preprod:

    cd /var/www/typo3/config/
    tar xzvf sites.tar.gz
    rm sites.tar.gz
    mv sites/* .
    rm -r sites

Je me rend sur le backend typo3, à l'onglet Sites pour constater le résultat.
Aucun des fichiers n'a été reconnu pour l'instant...
A tout hasard, je vide le cache et je rafraichis, mais sans résultat.

Je me suis trompé, les répertoires des sites doivent être dans /config/sites/, pas dans /config/
Je corrige avec:

    cd /var/www/typo3/config/
    mkdir ../sites
    mv * ../sites/
    mv ../sites .

Côté backend, je rafraichis la page sites, sans résultat.
Je reviens sur mes notes de l'upgrade du docker.
Effectivement, preprod est encore dans l'ancienne architecture.
Les sites doivent être dans typo3conf, pas dans conf

    mv /var/www/typo3/config/sites /var/www/typo3/typo3conf/
    rm -r /var/www/typo3/config

Je rafraichis le backend.
Une erreur se produit, qui semble assez sérieuse:

![img](images/23.png)

J'en apprend plus sur l'erreur ici:
https://stackoverflow.com/questions/14748499/fatal-error-too-many-open-files

Effectivement, la commande:

    ulimit -n

Renvoie 1024.

J'exécute donc la commande suivante:

    ulimit -n 10000

J'essaie d'abord de lancer cette commande en tant que root, mais ça ne modifie pas la limite pour exploitation.
J'essaie ensuite en tant que exploitation, mais ça ne corrige pas le pbm.
J'essaye en tant que root avec:

    sudo -u www-data ulimit -n 10000

Je reçois l'erreur `sudo: ulimit: commande introuvable`.

J'essaie:

    service php7.4-fpm restart

Mais le problème persiste.

Je contacte Tony à ce sujet.

Il corrige le problème de la manière suivante:

    root@preprod /etc/php/7.4 $ grep rlimit /etc/php/7.4/fpm/pool.d/www.conf
    ; Set open file descriptor rlimit.
    rlimit_files = 50000
    
    root@preprod /etc/php/7.4 $ grep exploitation /etc/security/limits.conf
    exploitation	  hard nofile 50000
    exploitation	  soft nofile 50000
    
    ; puis restart php-7.4-fpm

Le correctif fonctionne bien, le BE est de nouveau accessible (merci Tony)

Cette fois, les sites sont bien pris en compte.

![img](images/24.png)

Cela dit, il reste quelques sites non reconnus:

* Ecole Municipale de Musique [ID: 49408]
* Ecole Municipale de Musique [ID: 49063]
* Ecole de Musique La Clé de Sol [ID: 39115]
* Union Musicale [ID: 40195]
* Union Musicale [ID: 42358]
* Ecole Municipale de Musique [ID: 17162]
* Les Amis de la Musique [ID: 57493]
* Société Musicale [ID: 70352]
* Ecole de musique [ID: 19828]
* Société Musicale [ID: 70307]
* Accordéon club [ID: 54853]
* Accordéon Club [ID: 85652]
  ...Etc

Je suppose que le problème est dû aux noms en doublon,
les fichiers de l'un sont remplacé par le suivant du même nom.

Pour corriger le pbm, je modifie le script python pour ajouter l'uid à la suite du nom du répertoire.

Je relance le script, puis je répète la procédure de tar / filezilla / untar

Je réactualise la page 'Sites' du BE, mais les nouveaux fichiers ne sont pas pris en compte.
Un 'flush cache' plus tard, et tout est ok.

Tous les sites sont maintenant bien configurés.
Quelques configuration sont cependant marquées comme non-assignées, à vérifier plus tard:

![img](images/25.png)



Je vais maintenant tenter le switch vers composer.

Il faut d'abord que je fasse le point sur les extensions qui doivent être conservées, parmi celles-ci:

* news
* frontend_editing
* func
* mediace [outdated]
* rte_ckeditor_image
* piwik et piwikintegration

D'après ce que je vois dans la base, ces plugins sont inutilisés:

* impexp
* scheduler

Je ne vais reprendre que `news` dans un premier temps.


Je commence par

Sur preprod:

En tant que root:

    mv /var/www/typo3 /var/www/typo3_95
    mkdir /var/www/typo3
    chown -R exploitation:www-data /var/www/typo3

En tant que exploitation:

    cd /var/www/typo3
    
    composer require "typo3/cms-about:^9.5" "typo3/cms-adminpanel:^9.5" "typo3/cms-backend:^9.5" "typo3/cms-belog:^9.5" "typo3/cms-beuser:^9.5" "typo3/cms-core:^9.5" "typo3/cms-extbase:^9.5" "typo3/cms-extensionmanager:^9.5" "typo3/cms-felogin:^9.5" "typo3/cms-filelist:^9.5" "typo3/cms-filemetadata:^9.5" "typo3/cms-fluid:^9.5" "typo3/cms-fluid-styled-content:^9.5" "typo3/cms-form:^9.5" "typo3/cms-frontend:^9.5" "typo3/cms-info:^9.5" "typo3/cms-install:^9.5" "typo3/cms-lowlevel:^9.5" "typo3/cms-recycler:^9.5" "typo3/cms-redirects:^9.5" "typo3/cms-reports:^9.5" "typo3/cms-rte-ckeditor:^9.5" "typo3/cms-scheduler:^9.5" "typo3/cms-seo:^9.5" "typo3/cms-setup:^9.5" "typo3/cms-t3editor:^9.5" "typo3/cms-tstemplate:^9.5"

Je reçois l'erreur suivante:

![img](images/26.png)

Il est probable que composer ne soit pas à jour sur preprod.
En effet:

    exploitation@preprod:/var/www/typo3$ composer --version
    Composer version @package_branch_alias_version@ (1.0.0-beta2) 2016-03-27 16:00:34

Je lance donc:

    php7.4 -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
    php7.4 -r "if (hash_file('sha384', 'composer-setup.php') === 'e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1e613307e16318854d24ae64f26d17af3ef0bf7cfb710ca74755a') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
    php7.4 composer-setup.php
    php7.4 -r "unlink('composer-setup.php');"

Je relance ensuite:

    php7.4 composer.phar require "typo3/cms-about:^9.5" "typo3/cms-adminpanel:^9.5" "typo3/cms-backend:^9.5" "typo3/cms-belog:^9.5" "typo3/cms-beuser:^9.5" "typo3/cms-core:^9.5" "typo3/cms-extbase:^9.5" "typo3/cms-extensionmanager:^9.5" "typo3/cms-felogin:^9.5" "typo3/cms-filelist:^9.5" "typo3/cms-filemetadata:^9.5" "typo3/cms-fluid:^9.5" "typo3/cms-fluid-styled-content:^9.5" "typo3/cms-form:^9.5" "typo3/cms-frontend:^9.5" "typo3/cms-info:^9.5" "typo3/cms-install:^9.5" "typo3/cms-lowlevel:^9.5" "typo3/cms-recycler:^9.5" "typo3/cms-redirects:^9.5" "typo3/cms-reports:^9.5" "typo3/cms-rte-ckeditor:^9.5" "typo3/cms-scheduler:^9.5" "typo3/cms-seo:^9.5" "typo3/cms-setup:^9.5" "typo3/cms-t3editor:^9.5" "typo3/cms-tstemplate:^9.5"
    php7.4 composer.phar require fluidtypo3/flux fluidtypo3/vhs georgringer/news helhum/typo3-console:^5.7

    cp -R /var/www/typo3_95/fileadmin ./public/
    cp -R  /var/www/typo3_95/uploads ./public/
    
    cd /var/opentalent/git
    git clone git@gitlab.2iopenservice.com:olivier/ot_typo3.git
    ln -s /var/opentalent/git/ot_typo3/ot_connect /var/www/typo3/public/typo3conf/ext/ot_connect
    ln -s /var/opentalent/git/ot_typo3/ot_templating /var/www/typo3/public/typo3conf/ext/ot_templating
    ln -s /var/opentalent/git/ot_typo3/ot_widgets /var/www/typo3/public/typo3conf/ext/ot_widgets
    
  
    mkdir /var/www/typo3/config
    cp -R /var/www/typo3_95/typo3conf/sites /var/www/typo3/config/
    cp /var/www/typo3_95/typo3conf/LocalConfiguration.php /var/www/typo3/public/typo3conf/LocalConfiguration.php
    mkdir /var/www/typo3/public/typo3temp
    
    cp /var/www/typo3/public/typo3/sysext/install/Resources/Private/FolderStructureTemplateFiles/root-htaccess /var/www/typo3/public/.htaccess
    
    chown -R exploitation:www-data /var/www/typo3/
    touch /var/www/typo3/public/FIRST_INSTALL

J'ajoute les sections `scripts` et `psr-4` au fichier composer.json:

    nano /var/www/typo3/composer.json

et j'ajoute les lignes suivantes entre l'avant-dernière ligne et la dernière:

    ,
	"scripts":{
		"typo3-cms-scripts": [
			"typo3cms install:fixfolderstructure",
			"typo3cms install:generatepackagestates"
		],
		"post-autoload-dump": [
			"@typo3-cms-scripts"
		]
	},
	"autoload": {
		"psr-4": {
			"Opentalent\\OtWidgets\\": "public/typo3conf/ext/ot_widgets/Classes",
			"Opentalent\\OtConnect\\": "public/typo3conf/ext/ot_connect/Classes",
			"Opentalent\\OtTemplating\\": "public/typo3conf/ext/ot_templating/Classes"
		}
	}

Puis je lance la commande:

    cd /var/www/typo3
    php7.4 composer.phar dumpautoload

Enfin, je met à jour le virtualhost apache pour pointer vers le répertoire `public`

En tant que root:

    nano /etc/apache2/sites-available/001-preprod.opentalent.fr.conf
    nano /etc/apache2/sites-available/001-preprod.opentalent.fr-le-ssl.conf

Dans ces deux fichiers, je remplace:

    DocumentRoot /var/www/typo3

Par:

    DocumentRoot /var/www/typo3/public

Enfin, je lance:

    /etc/init.d/apache2 reload


Enfin, je me rend à https://preprod.opentalent.fr/typo3/install.php
puis je poursuis vers le BE

Tout va bien, et le mode composer est bien affiché à l'écran des extensions:

![img](images/27.png)

**Checkpoint 2**: Je fais un dump de la DB.

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt2.sql

Je me rend à la page 'maintenance'
Je clique sur 'Flush cache'
Une erreur se produit, mais la base n'est pas en phase avec les extensions, c'est donc normal.

J'ouvre ensuite l'outil 'Database compare', j'exécute les commandes de création / modification de champs et de tables.
**ATTENTION**: je ne fais aucune suppression pour l'instant!

Il y a:

* 5x create table
* 47x add fields
* 2x alter fields

Je clique sur 'Apply changes'
Tout se passe bien.

Je vais maintenant mettre à jour le champs pages.tx_opentalent_structure_id

Le lien entre la page et la structure se fait au moyen du champs cmsId et du nom de domaine,
ce qui fait que ce champs risque d'être incomplet pour certains sites...

Je vais créer le script `update_struct_ids.py`
Je lance le script.
Il dure une bonne dizaine de minutes,
mais pourrait si besoin être accéléré en regroupant les requêtes.

Je contrôle résultat en base en lancant la requête suivante dans mysql WB:

    SELECT uid, pid, title, tx_opentalent_structure_id, deleted, is_siteroot, slug 
    FROM pages;

Puis:

    SELECT uid, pid, title, tx_opentalent_structure_id, deleted, is_siteroot, slug 
    FROM pages
    WHERE is_siteroot=1 AND tx_opentalent_structure_id=0 OR tx_opentalent_structure_id IS NULL;

Il semble y avoir des erreurs, et le script est trop long.
Quelques corrections plus tard et un affichage de la progression, je relance le script.

Cette fois les résultats semblent bons,
même s'il faut encore compter au moins 2h pour l'exécution du script complet.

J'essaye en ne committant les requêtes qu'une fois tous les 25 sites.
Ce n'est pas bcp mieux.

J'essaye de générer un fichier sql que j'exécuterai directement dans mysql.
Le fichier est généré très vite, mais la requête est toujours relativement longue...
Il va falloir compter 1h30 à 2h, difficile de faire mieux...

Après le script, il reste '27834' pages non renseignées, dont 1030 pages root.

On y reviendra au moment du nettoyage et de la consolidation, cette donnée est facultative.


## Templating et contenu

Il va falloir mettre à jour les templates de chaque site.
Je créé un script 'update_templates.py'

Je le lance, en prenant le parti de faire des update en masse, ce qui permet un sacré gain de temps.

En revanche, de nombreuses pages (966) avec 2 ou 4+ colonnes sont identifiées,
il va falloir faire un travail sur la question,
et sans doute faire correspondre le template précédent à un nouveau...

De plus, de trés nombreux sites (3884) n'ont pas de page évènements (obligatoire?)


On va maintenant générer le champs des constants de chaque site.

Je créé un script `update_constants.py`.
A terme, il serait intéressant de regrouper certains
de ces scripts pour grouper les requêtes.

Je lance le script.
Il faut compter environ 15min.

Une fois terminé, je retourne sur le backend typo3, et je vide le cache.

J'essaie d'accéder à https://preprod.opentalent.fr/ohcluses/
Une erreur se produit:

![img](images/27.png)

Il 'agit d'une erreur issue de ot_templating,
quand aucun thème n'est choisi dans la conf flux.
Je vais corriger cette erreur directement dans l'extension.

Une fois le pbm corrigé et le commit pushé sur gitlab,
je lance la commande:

    cd /var/opentalent/git/ot_typo3
    git pull


Après un flush cache, je rafraichis la page https://preprod.opentalent.fr/ohcluses/

La page s'affiche bien.
Premier bilan:

* les contenus sont mal positionnés
* le formulaire de contact ne s'affiche pas.


Le problème de placement des contenus est dû au changement de templates.

Pour mieux faire la correspondance, je liste d'abord
les anciens templates ainsi que leur nombre de colonnes
et l'ordre d'affichage de celles ci de gauche à droite.

Je lance la commande suivante sur mysql WB:

    SELECT count(*) FROM openassos.backend_layout;

Il y a 16 layouts définis.
Leur configuration est définie en typoscript dans le champs config.

    SELECT DISTINCT backend_layout FROM openassos.pages;

Certains layouts sont issus de la table backend_layout:

    SELECT DISTINCT l.uid , l.title
    FROM openassos.pages p INNER JOIN openassos.backend_layout l
    ON p.backend_layout = l.uid 
    ORDER BY l.uid;

// uid, title
'1', 'Fluid 1 colonne'
'2', 'Diapo-bc-3col'
'4', 'Diapo-bc-3col'
'5', 'fullSizeTemplate'
'6', 'Portail 2 Colonnes'
'7', 'Portail Pleine Page'
'8', 'Login'
'9', 'Modèle 3 colonnes boite droite, menu gauche'
'10', 'Modèle 2 colonnes avec des boites'
'11', 'Modèle 1 colonne'
'12', 'Modèle 1 colonne pour l\'agenda'
'13', 'Modèle 2 colonnes avec les menus'
'14', 'Modèle 3 colonnes avec les boites'
'15', 'Modèle 3 colonnes boite'
'16', 'Modèle 1 colonne PB'



D'autres mentionnent l'extension 'theme_gallery'

    SELECT DISTINCT backend_layout 
    FROM openassos.pages
    WHERE backend_layout LIKE 'theme%'
    ORDER BY backend_layout;

// backend_layout
'theme_gallery__activity_report'
'theme_gallery__admin_commitee'
'theme_gallery__administration'
'theme_gallery__advanced_user_manual'
'theme_gallery__agenda'
(et 50 de plus...)


Ce second système est défini dans ces fichiers:

* [fluidtemplate.ts](https://gitlab.2iopenservice.com/developper/typo3/blob/master/typo3extension/theme_gallery/Resources/Private/Typoscript/Library/fluidtemplate.ts)
* [ThemeGalleryController](https://gitlab.2iopenservice.com/developper/typo3/blob/master/typo3extension/theme_gallery/Classes/Controller/ThemeGalleryController.php)
* [fluidtemplate.ts](https://gitlab.2iopenservice.com/developper/typo3/blob/master/themes/BlueSky/Templates/typoscript/fluidtemplate.ts)

Une part des templates correspondants se trouvent ici (templates FE):
https://gitlab.2iopenservice.com/developper/typo3/tree/master/themes/BlueSky/Templates

Une autre part ici (conf BE):
https://gitlab.2iopenservice.com/developper/typo3/tree/upgrade-v8/themes/BlueSky/BackendLayout

Mais seuls 11 templates sont définis, contre 56 backend_layout différents
dans 'pages'?

Ainsi qu'on le voit dans le fichier fluidtemplate.ts, pour chacun de ces templates
les colonnes sont définies ainsi:

      # Bloc de contenu central
      colContent < styles.content.get
      colContent.select.where = colPos = 0

      # Colonne de gauche
      colLeft < styles.content.get
      colLeft.select.where = colPos = 1

      # Colonne de droite
      colRight < styles.content.get
      colRight.select.where = colPos = 2

On peut donc établir le tableau suivant:

From

| template | colContent | colLeft | colRight |
| --- | --- | --- | --- |
| association_spectacle |  |  |  |
| ca_members |  |  |  |
| contact |  |  |  |
| default | x | x | x |
| events |  |  |  |
| home | x | x | x |
| login |  |  |  |
| members_list |  |  |  |
| news |  |  |  |
| site_map |  |  |  |
| structures |  |  |  |
| members_list_fede |  |  |  |
| page | x | x | x |

On le voit, seuls deux utilisent les contenus des colonnes.
En revanche, où sont définies les autres?

Une nouvelle requête permet de constater qu'une bonne part d'entre eux
n'est utilisé qu'une seule fois, ce qui semble désigner des reliquats de tests ou autre...

    SELECT backend_layout, count(backend_layout)
    FROM openassos.pages
    WHERE backend_layout LIKE 'theme%'
    GROUP BY backend_layout
    ORDER BY backend_layout;

Ainsi, des 56 enregistrements, seuls 20 ont 2 enregistrements ou +,
et seuls 15 ont plus de 200 enreistrements.

Ces chiffres chutent encore lorsqu'on filtre les pages supprimées.


Voilà ceux dont la définition manque encore:

* history (6042 fois)
* on_going_season (6042 fois)
* who_are_we (6041 fois)
* legal_mentions (5573 fois)
* contact_tks (5542 fois)
* commissions (4089 fois)
* association_gm (171 fois)
* association_other_events (171 fois)

On va les ignorer pour l'instant, car leur définition est introuvable
dans le code de la précédente version de typo3.

Par ailleurs::

    SELECT count(*) FROM pages
    WHERE backend_layout IN ('theme_gallery__home', 'theme_gallery__default')
    
    SELECT uid, pid, title, backend_layout FROM pages
    WHERE is_siteroot=1 AND backend_layout NOT IN ('theme_gallery__home', 'theme_gallery__default');

Ces deux sont utilisés par 6043 pages, soit toutes les pages 'root'
sauf 7:

    # uid, pid, title, backend_layout
    '1', '134830', 'Opentalent - La plateforme du spectacle vivant', '14'
    '12333', '94495', 'Union Musicale St Nizier-Curciat', '15'
    '94433', '94495', 'Support Opentalent', '1'
    '94464', '134830', 'Support Opentalent', '1'
    '94496', '94495', '2iopenservice.com', '14'
    '94507', '13', '2iopenservice.com', '4'
    '95142', '0', 'Opentalent - La plateforme du spectacle vivant', '6'


Pour revenir aux layouts issus de la table 'backend_layout',
ceux-ci sont peu utilisés (entre 1 et 309 fois):

    SELECT l.uid , l.title, count(l.uid)
    FROM openassos.pages p INNER JOIN openassos.backend_layout l
    ON p.backend_layout = l.uid 
    GROUP BY l.uid , l.title
    ORDER BY l.uid;

En revanche, les configs sont trop complexes pour être reprises de manière automatique,
et devront être traitées au cas par cas.


Voilà les évolutions qu'on pourra apporter au process de migration:

* Pour les pages ayant du contenu sur 3 colonnes,
  le contenu en position 0 passe en 1 et vice-versa
* On appliquera le nouveau template Events aux pages dont le template est 'theme_gallery__events'
* On appliquera le nouveau template Contact aux pages dont le template est 'theme_gallery__contact'
* On appliquera un nouveau template News (à créer) aux pages avec le template 'theme_gallery__news'
* On étudiera la nécessité de reprendre les templates suivants:
  * association_spectacle
  * members_list_fede

J'apporte ces évolutions au script `update_templates.py`
(en ignorant pour l'instant le dernier point, on y reviendra)

Je relance ce script. Il dure environ 10min .

Je vide le cache et reactualise la page https://preprod.opentalent.fr/ohcluses/
Les contenus ont l'air à leur place, tout va bien.

Je vais maitnenant générer les raccourci 'Accueil' pour chaque site.
Je créé un script 'generate_welcome_shortcuts.py'

Je le lance, il dure environ 20min.



Je teste différents sites, et je note les erreurs suivantes:

1. <https://preprod.opentalent.fr/eml/>
* pbm avec le footer
* toutes les pages du menu renvoient des erreurs 404 / pbm de slugs?

2. <https://preprod.opentalent.fr/emdt-forterre-val-d-yonne/>
* une erreur se produit: assets/style/theme-.css does not exist

Pour le problème 2, je corrige le plugin ot_templating.

Pour le 1, je constate que les slugs affichés dans le BE sont invalides ('0')?

Bon, c'est un vrai souci: la requête suivante

    SELECT count(uid) 
    FROM typo3.pages 
    where slug = '0';

Révèle que 66203 pages ont un slug valant '0'
C'est par exemple le cas d'une bonne partie des pages de 'Hoenheim - Harmonie'

// uid, pid, is_siteroot, deleted, title, slug, doktype, tx_opentalent_structure_id
'20966', '20965', '0', '0', 'DS oh-hoenheim', '/ds-oh-hoenheim', '254', '0'
'20968', '20965', '0', '0', 'Saison en cours', '/saison-en-cours', '1', '20966'
'20969', '20967', '0', '0', 'Qui sommes-nous ?', '0', '1', '20966'
'20970', '20967', '0', '0', 'Historique', '0', '1', '20966'
'20971', '20967', '0', '0', 'Les membres du CA', '0', '1', '20966'
'20972', '20967', '0', '0', 'Les adhérents', '0', '1', '20966'
'20974', '20965', '0', '0', 'Footer', '/footer', '116', '20966'
'31777', '20967', '0', '0', 'Contact', '0', '4', '20966'
'100018', '20967', '0', '0', 'Actualités', '0', '1', '20966'
'100021', '20965', '0', '0', 'Login', '0', '1', '20966'
'120119', '20965', '0', '0', 'Page introuvable', '0', '1', '20966'
'20965', '94495', '1', '0', 'Hoenheim - Harmonie', '/', '1', '20966'
'20967', '20965', '0', '0', 'Présentation', '/presentation', '1', '20966'


On constate par ailleurs qu'environ 150 autre pages ont des valeurs numériques à la place
d'un slug...

    SELECT count(uid), slug  FROM typo3.pages
    WHERE slug NOT LIKE '/%'
    GROUP BY slug;

Il s'avère qu'un grand nombre de ces valeurs numériques vient de l'ancien realurl, mais pas le 0.
On laisse tel quel (les url doivent se maintenir.)

    SELECT count(page_id), pagepath 
    FROM tx_realurl_pathdata
    WHERE mpvar = '' AND pagepath REGEXP '^[0-9]+$'
    AND (expire = 0 OR expire > CURRENT_TIMESTAMP())
    GROUP BY pagepath;

Je lance donc une requête delete sur ces valeurs, et je relance le script `update_slugs.py`
en mode déboguage pour chercher la cause.

    UPDATE pages SET slug = NULL WHERE slug='0';

Je relance le script, qui semble faire son boulot correctement.
Peut-être les '0' sont ils issus d'une mauvaise manipulation en amont,
et n'ont donc pas été remplacés par le script (que j'avais lancé en mode NO_REPLACE)


Un nouveau bug (erreurs 404 sur des pages existantes)
provient du fait qu'un certain nombre de slugs ne commence pas par '/'

Je lance la requête:

    UPDATE pages SET slug = CONCAT('/', CAST(slug AS CHAR)) WHERE slug NOT LIKE '/%';

et je corrige le script 'populate_slugs.py'.

Aprés une nouvelle exécution de ce script (3100sec.), je constate toujours les erreurs suivantes, normales au vu de la conception
du script:

* slugs se terminant par '/': 3 (avec des titres comme '.', '..', et '?')
* slugs null: 6677

Pour le premier point, je corrige le script 'populate_slugs.py'.
Pour le second, je lance cette fois l'outil d'upgrade typo3, puisqu'il ne reste "que" 6677 lignes.

Sur le BE, onglet Upgrade, j'ouvre l'Upgrade Wizard et je mark as undone
l'entrée 'Introduce URL parts ("slugs") to all existing pages'
Puis je lance la commande:

    php7.4 /var/www/typo3/typo3/sysext/core/bin/typo3 upgrade:run pagesSlugs

Cette fois, le process se termine vite.
Le nombre de pages avec `slug is null` est descendu à 1462.
Je suppose que c'est le mieux qu'on pourra obtenir...


Je fais une passe sur tous les scripts pour déplacer les infos de connexion
à la DB dans un fichier constants.py; il faudra faire attention avant
de relancer ces scripts...

Après de nouveaux tests, je constate que le `constants.ts`
de certains sites n'ont pas été remplis.
Ex:

![img](images/29.png)

La requête suivante montre que c'est le cas de 1043 sites!

    SELECT t.uid, t.pid, p.title, p.deleted, t.deleted, t.title
    FROM sys_template t INNER JOIN pages p ON t.pid = p.uid
    WHERE p.is_siteroot AND (t.constants IS NULL OR t.constants = '');


Cela semble correspondre à peu près aux 1030 pages pour
lesquelles l'id de la structure n'a pas pu être déterminé...
Après concertation, il semble que ces sites soient majoritairement
d'anciens clients dont les sites n'ont plus lieu d'être.
On va les ignorer pour le moment, il faudra trouver une solution
pour les desactiver, voire pour les supprimer.



## Tests, bugs et solutions

#### Contenus mal positionnés

> https://preprod.opentalent.fr/cmfrgl/pole-documentaire/lettre-dinformation

Analyse

Il s'agissait d'une page avec le template theme_gallery__page,
mais qui n'avait du contenu que dans la colonne centrale.
Le contenu est sur deux colonnes (0 et 2, donc centre et droite)

Pour une raison inconnue, l'update de la table tt_content n'a pas déplacé le contenu
de la colonne 0 à la colonne 1, alors que le template de la page est bien 3Col.
De même, la colonne 2 a été ramené en position 0...

Solution envisagée

1. Reinitialiser le champs colPos des pages qui avaient anciennement les templates
   'theme_gallery__page' et 'theme_gallery__default' pour reprendre leur ancienne valeur.
2. Repositionner le contenu de ces pages
3. Mettre à jour les pages ayant le template '3Col' pour les pages filles aient le template '1Col'

Avec la requête:

    SELECT count(c.uid)
    FROM typo3.tt_content c 
    INNER JOIN typo3.pages p ON c.pid = p.uid
    INNER JOIN openassos.pages o ON p.uid = o.uid
    WHERE o.backend_layout IN ('theme_gallery__page', 'theme_gallery__default');

On constate que dans l'état actuel, 20536 pages sont concernées.
Seules 236 ont du contenu dans une autre colonne que la colonne 0 (colonne centrale)
Seules 14911 ont le nouveau template fluid 'OpenTalent.OtTemplating->3Col'

On va d'abord remettre le champs colPos de toutes les lignes à leur valeur initiale:

    UPDATE typo3.tt_content t 
    INNER JOIN openassos.tt_content o ON t.uid = o.uid
    SET t.colPos = o.colPos;

Nous avons désormais 2574 contenus dont la colonne est différente de 0.

On va ensuite appliquer le template 'OpenTalent.OtTemplating->3Col' à toutes les pages ayant
le backend_layout égal à 'theme_gallery__page' ou 'theme_gallery__default':

    UPDATE typo3.pages p INNER JOIN openassos.pages o ON p.uid = o.uid
    SET p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->3Col'
    WHERE o.backend_layout IN ('theme_gallery__page', 'theme_gallery__default');

On va ensuite repositionner les contenus: la colonne 1 devient 0 et vice-versa.

* Colonne de gauche (1) passe à 100 temporairement:

  UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
  SET c.colPos = 100
  WHERE p.tx_fed_page_controller_action IN ('OpenTalent.OtTemplating->3Col',
  'OpenTalent.OtTemplating->home')
  AND c.colPos = 1;

* Colonne centrale (0) devient 1:

  UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
  SET c.colPos = 1
  WHERE p.tx_fed_page_controller_action IN ('OpenTalent.OtTemplating->3Col',
  'OpenTalent.OtTemplating->home')
  AND c.colPos = 0;

* Colonne temporaire (100) devient 0:

  UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
  SET c.colPos = 0
  WHERE p.tx_fed_page_controller_action IN ('OpenTalent.OtTemplating->3Col',
  'OpenTalent.OtTemplating->home')
  AND c.colPos = 100;

Je me rend sur https://preprod.opentalent.fr/cmfrgl/pole-documentaire/lettre-dinformation
Le problème est corrigé.

J'en profite pour lancer la requête suivante, afin de corriger le défaut
qu'avait le script update_templates.py quand il a été lancé la première fois.

    UPDATE typo3.pages
    SET tx_fed_page_controller_action_sub = 'OpenTalent.OtTemplating->1Col'
    WHERE tx_fed_page_controller_action ='OpenTalent.OtTemplating->3Col';


#### Rendus partiels et orgId non trouvé

> Voir: https://preprod.opentalent.fr/emdt-forterre-val-d-yonne/

On constante d'abord que le site (uid: 93772) n'a aucun enregistrement dans sys_domain.

    select * from typo3.sys_domain where pid = 93772;

En revanche, il avait un enregistrement dans l'ancienne table:

    select * from openassos.sys_domain where pid = 93772;

L'explication tient a priori à la migration: le système de redirection
a changé, et les redirections qui étaient auparavant dans sys_domain
sont maintenant dan la table sys_redirect.
Le champs redirectTo de la table sys_domain est d'ailleurs bien marqué
comme 'à supprimer' par l'outil d'analyse de la DB.

Le souci, c'est que les pid n'ont pas été repris, et sont tous égaux à 0... Est-ce une erreur?

![img](images/30.png)

J'ignore si c'est normal que les pid ne soient pas remplis,
mais pour les besoins de l'upgrade, je vais mettre à jour les pid avec la requête suivante:

    UPDATE typo3.sys_redirect t 
    INNER JOIN openassos.sys_domain o 
    ON CONCAT('/', o.domainName, '/') = t.source_path
    SET t.pid = o.pid;

Je vais ensuite faire évoluer la librairie
`typo3_82.py` pour qu'elle suive ces redirections.

Un nouveau scan montre un nombre d'erreurs largement diminué:

| err | avant | aprés |
| --- | --- | --- |
| Aucun sous-domaine trouv\xE9 pour le site dans openassos.sys_domain | 842 | 24 |
| Contents with no pages | 1906 | 1906 |
| Le sous domaine de la table openassos.sys_domain ne respecte pas les contraintes de forme | 23 | 206 |
| Le sous-domaine pr\xE9sent dans la table opentalent.Parameters n'existe pas dans sys_domain | 830 | 10 |

Les nouvelles erreurs 'sous-domaines invalides' sont normales:
les anciens sous-domaines redirigés et qui ne sont plus valides sont aussi testés.
Je met à jour le script pour ne plus lever d'erreur s'il s'agit de redirections.

Le nombre d'erreurs de validité des noms de domaine redescend à 23.

Je relance les scripts pour vérifier que la correction a réglé le pbm initial.
Avant de lancer les scripts, il y a 5021 sites sur 6051
qui ont le champs tx_opentalent_structure_id renseigné.

Je lance donc dans l'ordre:

* update_struct_ids.py
* update_templates.py

Nous sommes passé de 5021 à 5841 sites sur 6051
qui ont le champs tx_opentalent_structure_id renseigné.
C'est bien mais peut mieux faire. Poursuivre les efforts.

Cela dit, le problème avec https://preprod.opentalent.fr/emdt-forterre-val-d-yonne/ est bien réglé.


#### Erreurs lors du scan

Autant achever de corriger ces différentes erreurs, tant que j'y suis.

##### Aucun sous-domaine trouvé pour le site dans openassos.sys_domain

Aprés concertation, on convient de supprimer les sites 'deleted'.
Je créé un nouveau script `delete-old-sites.py`

Avant de l'exécuter, je vais faire un nouveau dump.


**Checkpoint 3**: Je fais un dump de la DB.

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt3.sql


Je lance le nouveau script:
5 sites sont supprimés, avec 111 pages et leurs contenus:

* 12333 - Union Musicale St Nizier-Curciat
* 91599 - MAIRIE DE CLERMONT FERRAND
* 94433 - Support Opentalent
* 94496 - 2iopenservice.com
* 96010 - OPÉRA PASSION

Un nouveau scan révèle l'évolution suivante:

| err | avant | aprés |
| --- | --- | --- |
| Aucun sous-domaine trouv\xE9 pour le site dans openassos.sys_domain | 24 | 19 |
| Contents with no pages | 1906 | 1918 |
| Le sous domaine de la table openassos.sys_domain ne respecte pas les contraintes de forme | 23 | 23 |
| Le sous-domaine pr\xE9sent dans la table opentalent.Parameters n'existe pas dans sys_domain | 10 | 10 |

Les cinq sites supprimés n'apparaissent plus en erreur, reste 19.

Sur ces 19, un certain nombre sont des organisations supprimées dont les sites n'ont pas été supprimés:

* 'Association Musicale Chalonnaise (uid: 15983)'
  x "Brass-band 1084 \xB0C (uid: 16009)"
  x "Ecole de musique Intercom. Loire et C\xF4teaux (uid: 16087)"
  x 'Orchestre M.J. Harmonie (uid: 16412)'
  x 'Ecole de Musique TEMPO (uid: 16798)'
  x "Union Musicale C\xF4te de Lumi\xE8re - L'Aiguillon sur Mer (uid: 17058)"
  x 'Ecole Municipale de Musique (uid: 17162)'
  x "Association Musicale Rez\xE9enne Cool Musique (uid: 17331)"
  x "Echo de Saint S\xE9bastien sur Loire (uid: 17461)"
  x 'La Gessienne (uid: 18696)'

Je les passe en deleted avec la requête suivante:

    UPDATE typo3.pages SET deleted=1
    WHERE uid IN (15983, 16009, 16087, 16412, 16798, 17058, 17162, 17331, 17461, 18696);

Je relance le script `delete-old-sites.py`.

D'autres sites en erreur ont plusieurs enregistrement dans sys_redirect,
hors un seul est pris en compte dans le scan actuel.
Je vais faire évoluer mon script pour prendre en compter toutes les redirections.
Je vais aussi retirer le contrôle de validité des sous-domaines qui viennent de sys_redirect.

On en arrive à:

| err | avant | aprés |
| --- | --- | --- |
| Aucun sous-domaine trouv\xE9 pour le site dans openassos.sys_domain | 19 | 2 |
| Contents with no pages | 1918 | 1978 |
| Le sous domaine de la table openassos.sys_domain ne respecte pas les contraintes de forme | 23 | 13 |
| Le sous-domaine pr\xE9sent dans la table opentalent.Parameters n'existe pas dans sys_domain | 10 | 2 |

On a donc bien progressé.

---------------

En apparté, pour permettre de comparer complètement les sites entre
la preprod et la prod, je vais essayer de remplacer le répertoire
`/var/www/typo3/public/fileadmin/user_upload` par un symlink vers
`/var/www/typo3_82/fileadmin/user_upload`

Visiblement, les seuls fichiers créés par typo3 et susceptibles d'avoir
changé durant l'upgrade sont `index.html` (vide dans les 2 versions)
et _temp_.

Je vais donc remplacer user_upload par un symlink, en conservant le
nouveau répertoire _temp_

    cd /var/www/typo3/public/fileadmin
    mv user_upload user_upload_test1
    ln -s /var/www/typo3_82/fileadmin/user_upload ./user_upload
    mv ./user_upload/_temp_ ./user_upload/_temp__orig
    cp -R ./user_upload_test1/_temp_ ./user_upload/
    chown -R exploitation:www-data user_upload

Je teste avec le site https://preprod.opentalent.fr/emtbn/presentation/qui-sommes-nous
Les images sont bien accessibles, c'est tout bon.

---------------

Quant aux erreurs, l'existence de ces deux domaines dans la db opentalent
qui sont absents de la base typo3 est normale, on peut ignorer:

- fleurdesl
- emsgc

Pour ce qui est des 13 noms de domaine qui ne respectent pas les contraintes de forme:

- www.cmf-musique.org [pid 12055]
- www.edmlouhanschateaurenaud.fr [pid 29610]
- swingparisisorchestra.fr [pid 62908]
- www.cfbf-rhonealpes.fr [pid 86407]
- fbf74.com [pid 86540]
- conservatoire-ciol.fr [pid 90987]
- abelia.asso.fr [pid 93529]
- www.2iopenservice.com [pid 94507]
- www.emtbn.fr [pid 96548]
- stageyogafrance.fr [pid 127540]
- cerclevocalameno.com [pid 128778]
- musique-et-art-ferrette.fr [pid 129962]
- ecole-musique.cc-dufrontonnais.fr [pid 130513]

Tous ces sites possèdent des alternatives en *.opentalent.fr, ce qui fait que ces erreurs ne sont pas bloquantes.

> **/!\ Il faudra en revanche modifier le scan pour qu'il prenne cette valeur
>       comme nom de domaine dans la conf du site, et qu'il ne l'ignore pas comme on le fait pour l'instant en preprod...

Il ne reste donc que les deux erreurs de scan suivantes:

    "Aucun sous-domaine trouvé pour le site dans openassos.sys_domain":
    - '2iopenservice.com (uid: 94507)'
    - 'Opentalent - La plateforme du spectacle vivant (uid: 95142)'

Si j'essaie de visualiser la page 95142, cad à l'adresse
https://preprod.opentalent.fr/opentalent-la-plateforme-du-spectacle-vivant/

J'obtiens l'erreur suivante:

![img](images/32.png)

Une réference circulaire donc.

Si j'essaie d'éditer la conf du site depuis le backend, j'obtiens une erreur
de droits sur le répertoire _processed_

J'essaie de supprimer le raccourci 'accueil' qui
pourrait être responsable de lé référence circulaire et je flush le cache.

L'erreur est effectivement résolue, mais de nouvelles erreurs se produisent,
liées à l'absence de l'organisation_id.

Je m'arrête là: on décide de conserver ces deux sites en version 8.2,
car ils seront fusionnés et réécrits en dehors de cette instance de typo3
dans les mois à venir.

On va donc ignorer ces deux erreurs pour l'instant.

#### Erreurs lors de la mise à jour des constantes et des org_id

Je vais essayer de relancer les script `update_struct_ids.py` et
`update_constants.py`, en laissant REPLACE_EXISTING à False.

##### Id des structures

Je lance `update_struct_ids.py`.

Bilan:

* 187 ids non trouvés
* 187 cmsId qui ne correspondent pas.

Comme on pouvait s'y attendre, il s'agit des même structures.

Je vais commencer par contrôler la structure Ecole de musique de Vacheresse [ID: 4976]

    select * from sys_domain where pid=4976;

La même requête dans sys_redirect ne renvoie aucun résultat.

Le nom de domaine est ecoledemusiquedevacheresse.opentalent.fr
Je cherche le sous-domaine correspondant dans la base opentalent.

La requête suivante ne renvoie effectivement aucun résultat:

    SELECT o.id, o.name, p.subDomain, o.cmsId
    FROM opentalent.Parameters p 
    INNER JOIN opentalent.Organization o 
    ON o.parameters_id=p.id
    where subDomain='ecoledemusiquedevacheresse' OR
    cmsId = 4976 OR
    o.name like '%vacheresse%';


Je réessaye avec la structure suivante: 'Groupement des Batteries-Fanfares (uid: 5259)'
Nom de domaine: batteriesfanfares-ain.opentalent.fr
Aucun résultat non plus.

Et enfin, même résultat pour 'Strasbourg  (uid: 22239)'

Il s'avère qu'un certain nombre de ces structures (peut-être toutes) ont été supprimées.

Michel m'a fourni une liste de ces organisatiuons deleted (cf. deleted_structures.csv)

Je vais compléter le script delete_old_sites.py pour qu'il supprime ces sites, leurs pages, contenus, et sys_domain.

Je lance lescript une première fois en mode simulation, ce qui donne:

183 sites deleted
3603 pages deleted
2539 contents deleted

Les nombres semblent cohérents, car les sites ont généralement 20 pages.

Je relance le script sans le mode SIMULATE.

Enfin, je relance le script `update_struct_ids.py`

Il ne reste plus que 4 erreurs:

- 'Opentalent - La plateforme du spectacle vivant (uid: 1)'
- 'Support Opentalent (uid: 94464)'
- '2iopenservice.com (uid: 94507)'
- 'Opentalent - La plateforme du spectacle vivant (uid: 95142)'

Ce sont des erreurs normales, tout va bien.

#### Couleurs des thèmes

Certains sites avaient choisi une autre couleur pour leur site, via l'onglet de l'extension theme_gallery.
Je vais essayer de retrouver quels sites et quelles couleurs sont concernés.

Exemple: https://emtbn.opentalent.fr/
Uid: 96548

En affichant la ligne correspondant à cette page:

    SELECT * FROM openassos.pages where uid=96548;

On trouve les champs suivants:

backend_layout = 'theme_gallery__home'
tx_theme_gallery_theme_name = 'BlueSky'
tx_theme_gallery_theme_style = 'color1=#dd453f
color2=#3fd7dd
color3=#3f87dd
color4=#453fdd
color5=#d7dd3f
'

Je vais tacher de trouver les différents jeux de couleurs utilisés.

    SELECT count(uid), tx_theme_gallery_theme_name, tx_theme_gallery_theme_style 
    FROM openassos.pages
    GROUP BY tx_theme_gallery_theme_name, tx_theme_gallery_theme_style;

J'obtiens les résultats suivants:

* 59895 sites sans couleurs personnalisées
* 53 sites, tous avec des couleurs différentes (sauf 4 qui partagent les même couleurs)

Je vais les identifier avec la requête suivante:

    SELECT p.uid, d.domainName, p.tx_theme_gallery_theme_style 
    FROM openassos.pages p INNER JOIN sys_domain d ON p.uid = d.pid
    WHERE p.is_siteroot=1 AND length(p.tx_theme_gallery_theme_style) > 0
    ORDER BY p.uid; 

> attention, certains sites ont plusieurs domaines...

La gestion de ces cas va être compliquée... Dans l'idéal, il va faudrait créer autant de thèmes,
mais ce n'est bien sûr pas envisageable.

La liste complète est dans le fichier customized_templates.csv

Je vais créer un script 'summarize_custom_themes.py' pour créer une représentation visuelle de
ces thèmes custom.

Le résultat est présenté dans le fichier theme_colors.html

On décide de rassembler ces couleurs en 5 ou 6 thèmes.
Je fais la correspondance dans le fichier new_theme_colors.html

Je dégage 8 thèmes de couleur:

* grey  #8c8c8c
* orange  #e4611b
* light-red  #dd453f
* red  #df0009
* light-blue  #0aa5ec
* blue  #3259d7
* purple  #a5377e
* green  #04a04c

Je constate au passage que la couleur du thème du site
https://ecole-musique-blou-brain-varennes-vivy-longue.opentalent.fr/
ne correspond plus aux couleurs listées dans la base...
Une vérification sur les DB de prod-front et preprod
montre que la couleur a été changée depuis que la base a été clônée.

Au moment de la migration, il faudra sans doute traiter manuellement les cas où le thème a été modifié.


En attendant, je vais faire la correspondance manuellement et mettre à jour les sites
en question avec un nouveau script `update_theme_colors.py`

Je garde la trace de ces correspondances dans le fichier `theme_colors_mapping.yaml`

La configuration des sites par flu est stockée dans les champs `tx_fed_page_flexform`
et `tx_fed_page_flexform_sub` , exemple:

    <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
    <T3FlexForms>
        <data>
            <sheet index="options">
                <language index="lDEF">
                    <field index="settings.themeColor">
                        <value index="vDEF">green</value>
                    </field>
                    <field index="settings.displayCarousel">
                        <value index="vDEF">1</value>
                    </field>
                    <field index="settings.staticDonors">
                        <value index="vDEF">0</value>
                    </field>
                    <field index="settings.eventsLimit">
                        <value index="vDEF">5</value>
                    </field>
                    <field index="settings.eventsPeriod">
                        <value index="vDEF">8</value>
                    </field>
                </language>
            </sheet>
        </data>
    </T3FlexForms>

Le script va mettre à jour les 53 sites concernés en remplaçant la ligne:

    <value index="vDEF">green</value>

Par le nom du thème correspondant.

Je lance le script, qui s'exécute en quelques secondes.
Je créé aussi les thèmes correspondants dans ot_templating.

Pour commencer, la requête suivante:

    SELECT COUNT(uid), tx_fed_page_flexform, tx_fed_page_flexform_sub 
    FROM typo3.pages
    GROUP BY tx_fed_page_flexform, tx_fed_page_flexform_sub;

semble donner des résultats cohérents.

Je vais maintenant tester les thèmes avec les sites suivants:

| Thème | Site | URL |
| --- | --- | --- |
| grey | harmonieduranceluberon.opentalent.fr [64847] | preprod.opentalent.fr/harmonieduranceluberon |
| orange | guise-art-musical.opentalent.fr [36092] | preprod.opentalent.fr/guise-art-musical |
| light-red | www.emtbn.fr [96548] | preprod.opentalent.fr/emtbn |
| red | cmfvendee.opentalent.fr [23933] | preprod.opentalent.fr/cmfvendee |
| purple | cerclevocalameno.opentalent.fr [128778] | preprod.opentalent.fr/cerclevocalameno |
| light-blue | cmf.opentalent.fr [12055] | preprod.opentalent.fr/cmf |
| blue | cmm.opentalent.fr [18956] | preprod.opentalent.fr/cmm |
| green | union-musicale-suippes.opentalent.fr [7630] | preprod.opentalent.fr/union-musicale-suippes |

> A noter que je teste à la fois la page d'accueil et une sous-page à chaque fois

Tout a l'air ok.



#### Paramétrage et extensions

##### Nouvelles extensions

Je vais installer 2 nouvelles extensions:

* https://extensions.typo3.org/extension/image_autoresize
* https://extensions.typo3.org/extension/bp_pagetree

J'exécute donc:

    cd /var/www/typo3/
    php7.4 composer.phar req causal/image_autoresize
    php7.4 composer.phar req bueroparallel/bp-pagetree

Je retourne dans le BE, onglet extensions, et je constate que les
extensions sont bien installées et activées.

Côté BE, l'affichage de l'arbre ne semble guère accéléré, malheureusement.

Côté FE en revanche, la taille de la page d'accueil de https://preprod.opentalent.fr/ohcluses
est passée de 20Mo à 6.88MB.

##### Langue du BE

Pour passer la langue du backend en français, j'ouvre l'onglet 'Maintenance', bouton
'Manage Language Packs', et je clique sur 'update all'.



#### Corrections diverses en base

##### backend_layout

On a plus besoin des 16 layouts définis dans la table backend_layout.

J'exécute donc la requête:

    DELETE FROM backend_layout;

##### sys_redirect

On a constaté une erreur dans la manière dont la table sys_redirect a été remplie
par typo3.

En effet, le champs rempli est `source_path`, qui est sensé contenir des
chemins relatifs à une url, alors que ce devrait être le champs `source_host`...

Pour voir:

    SELECT uid, pid, source_path, source_host, target FROM typo3.sys_redirect;

J'exécute la requête suivante:

    UPDATE sys_redirect
    SET source_host = REGEXP_REPLACE(source_path, "\/(.+)\/", '\\1');

Puis:

    UPDATE sys_redirect SET source_path = '';


#### Corrections suite aux tests

En corrigeant les erreurs au niveau des plugins, je constate et corrige un certain nombre de pbm.

##### Guzzle n'est pas installé

Je lance:

    php7.4 composer.phar require guzzlehttp/guzzle:^6



##### Une image est manquante

L'image `/fileadmin/_migrated/RTE/RTEmagicC_Logo_artist_w200_02.png` manque sur la page d'accueil
de https://preprod.opentalent.fr/artist-premium

Je n'ai pas récupéré ce dossier d'images...
De plus, l'image n'est pas référencée dans la table sys_file.

Je constate qu'elle est insérée manuellement dans le contenu, sous la forme d'une balise <img>

La requête suivante révèle que 1380 lignes de tt_content sont concernées.

Je reviendrai sur le sujet des fichiers dans un second temps.

##### Le site 'Opentalent artist Premium' a un network du nom de 'OUT_OF_NET'

Le site 'Opentalent artist Premium' a un network affiché du nom de 'OUT_OF_NET'
dont le logo est None et l'url est None

En effet, la requête suivante:

    SELECT DISTINCT n.name, n.logo, n.url 
    FROM opentalent.Network n
    INNER JOIN 
        (opentalent.NetworkOrganization l
        INNER JOIN opentalent.Organization o
        ON l.organization_id = o.id)
    ON l.network_id = n.id
    WHERE l.endDate is NULL;

Révèle que 4 des 5 réseaux n'ont ni logo ni url.

Je corrige le script `update_constants.py`

Je le relance.

##### Erreur FLUID due à un contenu

Lorsque qu'on essaie d'accéder à la page https://preprod.opentalent.fr/harmonieraismes/,
une erreur se produit:

![img](images/33.png)

La désactivation du contenu suivant règle le problème.

![img](images/34.png)

Il faudrait pouvoir identifier d'autres sites présentant des problèmes de ce genre,
ce sera le rôle du script behat.

La requête suivante:

    SELECT * FROM tt_content WHERE pid=80747 AND deleted=0;

nous apprend que le contenu a un CType 'list'.
Je poserai la question à Yohann Cerdan.

##### Sorting du raccourci 'Accueil'

La page Accueil apparait à la fin du menu.

La requête suivante montre effectivement que le champs 'sorting' la place en fin de liste...

    SELECT uid, pid, title, sorting FROM pages WHERE pid=54493 AND deleted=0;

Et la requête suivante nous montre que la majorité des pages ont pour sorting 256,
ce qui aurait dû être corrigé plus tôt. En revenant sur mes notes,
je constate que j'ai bien modifié le script python, mais que je n'ai pas corrigé les lignes déjà
renseignées.

J'exécute donc la requête:

    UPDATE pages SET sorting=0 WHERE dokType=4 AND title='Accueil';


##### Gabarits manquants

Certains sites comme https://preprod.opentalent.fr/orchestresens/ n'ont pas le gabarit
Contact affecté à la page https://preprod.opentalent.fr/orchestresens/footer/contact  (uid: 54505),
ni le gabarit Events affecté à
https://preprod.opentalent.fr/orchestresens/saison-en-cours/les-evenements  (uid: 54502)

Je vais lancer les requêtes correctives suivantes:

    UPDATE pages SET tx_fed_page_controller_action = 'OpenTalent.OtTemplating->events' 
    WHERE dokType=1 AND title='Les évènements';

    UPDATE pages SET tx_fed_page_controller_action = 'OpenTalent.OtTemplating->contact' 
    WHERE dokType=1 AND slug='/footer/contact';

Le problème est corrigé pour les deux sites testés.

##### Organization ids

Je constate que le gabarit du site https://preprod.opentalent.fr/yoga-relaxation-et-gym-douce/
est erroné.

En effet, la valeur du champs constants est:

    plugin.tx_ottemplating {
        settings {
            organization {
                id = None
                name = YOGA, Relaxation et Gym douce
                is_network = False
                email = spectacles@ville-meze.fr
                logoid = 90273
                twitter = 
                facebook = 
            }
            ... etc.

Non seulement l'id est None, mais l'email est faux.

Je corrige le script `update_constants.py`, et le relance.

C'est tout bon.



#### Reprise des fichiers

Je créé un script `fix_files_refs.py` qui devra lister tous les fichiers utilisés, et comparer
cette liste aux fichiers qui se trouvent dans les répertoires fileadmin et uploads.

Il s'avère qu'une grande majorité des sous-répertoires sont utilisés...
Le script parait délicat à monter.

Pour être sûr de chercher dans toutes les tables potentiellement concernées, je créé
un nouveau script `list_tables_with_files` qui va parser le dernier fichier de dump.

Voilà les tables qui ressortent:

* matomo_option
* pages
* pages_with_original_pidroot
* sys_be_shortcuts
* sys_file
* sys_filemounts
* sys_file_collection
* sys_file_reference
* sys_file_storage
* sys_history
* sys_log
* sys_registry
* sys_template
* tt_content
* tx_extensionmanager_domain_model_extension
* tx_news_domain_model_news
* tx_realurl_pathdata
* tx_realurl_urldata

Je conserve les tables suivantes:

* pages (dans url)
* sys_file  (dans identifier)
* sys_file_reference  (dans link)
* tt_content  (dans bodytext)
* tx_news_domain_model_news  (dans bodytext)

Le résultat montre:

    server files 565314
    db refs 88970
    matched server files 77864
    unmatched server files 487450
    unmatched db refs 11106

Pour le nettoyage, j'y reviendrai.

Pour l'instant, je vais reintégrer les répertoires suivants au moyen de sylinks:

    ln -s /var/www/typo3_82/fileadmin/_migrated /var/www/typo3/public/fileadmin/_migrated
    ln -s /var/www/typo3_82/fileadmin/stockage /var/www/typo3/public/fileadmin/stockage

Etrangement, l'image attendue n'apparait toujours pas sur la page
https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2012-2013-festival-des-musique-planet-earth-chatillon/planet-earth-6-avril

Pour m'assurer que le changement soit appliqué, je supprime les images dans _processed_: dans
le BE, onglet maintenance, Remove Temporary Assets, je clique sur delete x processed images.

Je rafraichis la page https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2012-2013-festival-des-musique-planet-earth-chatillon/planet-earth-6-avril,
c'est bon l'image apparait.

Je vérifie aussi les 5 ou 6 autres images signalées comme manquantes.


#### Pages Membres du CA et adhérents

Les pages membres du CA et liste des adhérents sont manquantes.

Je vais d'abord mettre à jour ot_widgets pour ajouter ces deux fonctionnalités.

Une fois les deux nouveaux layouts créés, je vais mettre à jour les sites pour
utiliser ces templates .

Je fais évoluer le script `update_templates.py`, et j'exécute les requêtes suivantes:

    UPDATE pages 
    SET tx_fed_page_controller_action='OpenTalent.OtTemplating->members',
    tx_fed_page_controller_action_sub='OpenTalent.OtTemplating->1Col'
    WHERE slug LIKE '%/liste-simple' OR slug LIKE '%/les-adherents' OR slug LIKE '%/adherents';

    UPDATE pages 
    SET tx_fed_page_controller_action='OpenTalent.OtTemplating->membersCa',
    tx_fed_page_controller_action_sub='OpenTalent.OtTemplating->1Col'
    WHERE slug LIKE '%/les-membres-du-ca';

Apparemment, tout est ok.

#### Corriger les constants.ts

Certains sites n'ont pas l'id de structure renseigné,
comme https://preprod.opentalent.fr/yoga-relaxation-et-gym-douce/

Je relance le script update_constants.py
Sans résultat...

Je créé le script list_missing_org_ids.py
839 sites n'ont pas d'organization's id (!)

Ils semblent correspondre à la liste d'erreurs
"Aucun sous-domaine trouvé pour le site dans openassos.sys_domain"

Je corrige le scipt, et le relance.

Seulement 11 items retournés par le script list_missing_org_ids.py
On est ok.

J'en profite pour exécuter la requête suivante:

    UPDATE sys_template t INNER JOIN pages p ON t.pid = p.uid 
    SET t.sitetitle = t.title
    WHERE p.is_siteroot = 1;


#### Restaurer les contenus de type carroussels

Pour restaurer le mode caroussel sur les contenus de type Images, je modifie
le TCA.
Je me rend dans le BE, onglet Maintenance, 'Analyse Database Structure'

Je sélectionne le seul choix dispo:

    ALTER TABLE `tt_content` ADD `tx_opentalent_carousel` SMALLINT UNSIGNED DEFAULT 0 NOT NULL

Apply changes.

En revanche, je n'arrive pas à implémenter la chose côté de l'extension,
j'y reviendrai avec Yohann Cerdan.
---

Aprés réflexion et analyse de l'existant, je décide de créer un nouveau content pour le carousel.

Une fois ce contenu développé, il me faut convertir les galeries existantes ayant le CType
`image` et le champs tx_opentalent_carousel à 0 (dans openassos)

Les requêtes

    SELECT count(*) FROM openassos.tt_content 
    WHERE CType='image' AND tx_opentalent_carousel=1;
    
    SELECT count(*) FROM openassos.tt_content 
    WHERE CType='image' AND tx_opentalent_carousel=1 AND deleted=1;

montrent que 461 contents sont concernés, dont 163 supprimés.

Je créé un script `regen_carousel_contents.py`

Avant de le lancer, je fais un dump de la base:

**Checkpoint 4**: Je commence par faire un dump de la DB.

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt4.sql

Je lance le script, qui s'exécute en environ 10 minutes.

Le résultat est bon pour les deux carousels à l'adresse
https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2013-2014-pinocchio-films-danimation

En revanche, pas pour
https://preprod.opentalent.fr/laphilharmoniquedevillelaure/saisons-passees/saison-2013-2014/concert-a-cucuron-22062014
(uid: 94316)

Je corrige et relance le script.
Cette fois, je vais stocker l'uid original dans le champs `t3ver_oid`, qui vaut 0 partour.

> **Je devrais réinitialiser cette valeur plus tard.**

Etrangement, les images apparaissent dans le BE, mais pas sur le front?

J'essaie de supprimer les images __processed, de vider le cache, puis de rafraichir la page
sans résultat

Etrangement, certains caroussels fonctionnent et d'autres non, sans différence apparente...

Ex: https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2013-2014-pinocchio-films-danimation

Le 1er carrousel n'affiche rien, le second si.

J'essaie de nouveau de supprimer les images __processed,
de vider le cache depuis l'onglet maintenance, puis de rafraichir la page.
Toujours pas...

Je cherche d'éventuelles différences entre le contenu 145943 qui ne fonctionne pas
et le contenu 145842 qui fonctionne.

En dehors de la valeur width que j'ai moi-même modifié dans pas de différence.

J'exécute à tout hasard la requête suivante:

    UPDATE typo3.tt_content SET t3ver_oid = 0;

Stupeur, c'était ça! Ca fonctionne à la fois sur:

* https://preprod.opentalent.fr/laphilharmoniquedevillelaure/saisons-passees/saison-2013-2014/concert-a-cucuron-22062014
* et https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2013-2014-pinocchio-films-danimation

Il reste quelques petites erreurs de positionnement:

* https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2016-2017-starmania-la-clate
* https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2014-2015-rencontre-sallanches-2nd-guerre-mondiale

Les carousels ne sont pas dans la bonne colonne.
En effet, la colonne 0 et 1 sont inversées maitnenant...

Mais ce pbm n'aura plus lieu dans le futur, lorsque j'aurais inversé la colonne 0 et 1.



#### Errors with contents of type media

Une erreur se produit avec certains type de contenus, comme à la page:
https://preprod.opentalent.fr/ohcluses/nos-precedents-concerts/saison-2018-2019-this-is-michael-jackson-the-kid

![img](images/33.png)

Effectivement, la requête suivante montre que le CType est 'media'

    SELECT uid, pid, CType FROM tt_content WHERE uid = 140019;

J'envisage de remplacer l'extension 'media' par l'extension suivante
https://extensions.typo3.org/extension/youtubevideo/

Non, en fait un nouveau type existe CType='textmedia', le lien est créé sous forme
de fichier dans user_upload, ex: abcd.youtube

Les requêtes

    SELECT count(*) FROM typo3.tt_content WHERE CType='media';
    SELECT count(*) FROM typo3.tt_content WHERE CType='media' AND deleted=1;

montrent que 611 contents sont concernés, dont 406 supprimés.

Je créé un script `regen_media_contents.py`

Compliqué. La référence à la vidéo est incorporée dans le champs pi_flexform

Plusieurs cas différents:

* des vidéos ou fichiers audio uploadés dans fileadmin/user_upload
* des vidéos sous forme d'url vers youtube, dailymotion...Etc
* des vidéos youtube dans des iframe
* des fichiers référencés p ar l'uid
* des vidéos facebook
* des liens vers google drive (/!\)

Je commence par parser ce champs pour en extraire les références.

Les champs pi_flexform d'une partie des références sont vides ou
ne contiennent pas de référence (204)

En revanche, certains enregistrements ont ddes références dans sys_file_reference...

On devrait pouvoir avoir une vue d'ensemble avec la requête:

    SELECT c.uid, c.pid, c.CType, c.pi_flexform, c.deleted, r.fieldname, f.identifier
    FROM typo3.tt_content c 
      LEFT JOIN sys_file_reference r ON c.uid = r.uid_foreign 
      LEFT JOIN sys_file f ON r.uid_local = f.uid
    WHERE c.CType = 'media';

Je constate aussi qu'il existe aussi des contenus de type
textmedia (320), il faudra en tenir compte.

Je propose de ne pas reprendre:

* les contenus sans références
* les contenus supprimés

On pourra les traiter au cas par cas en cas de besoin.
Ce qui laisse 178 contenus medias.

On va traiter ensuite séparément les cas suivants:

1. Contenu de type lien externe, exemple avec uid=104773: `http://www.youtube.com/watch?v=mBtcQXAQhck`
2. Contenu de type fichier uploadé, ex uid=102172: `fileadmin/user_upload/12097/images/FORMassos/V02 utilisation.qt`
3. Référence directe à un fichier (?), ex uid=107409:  `file:9682`

Ces formulations sont parfois entourées d'autres caractères,
comme `file:22973 _top - &quot;Lonely Beach&quot;`
Mais ça ne concerne qu'un enregistrement parmi les contenus valides
et non supprimés, **je le corrige manuellement dans MysqlWB**.

Un autre problème: les liens dailymotion ne sont plus supportés (2 enregistrements concernés),
ainsi que les videos facebook (1 enregistrement) et wetransfer (1 enregistrement).
On ignore pour l'instant.

Le fichier en .youtube semble ne contenir qu'une chaine aléatoire de 11 caractères?
ex: `RSQRZdlGYg8`, `109500535`, `ihjdQ9CrLds`

Ah non! c'est l'id youtube qui est stocké, pas l'url complète...

Pour les contenus de type 1, on va procéder ainsi:

1. Créer un fichier `fileadmin/user_upload/[orgId]/[filename].youtube`
2. Créer un enregistrement dans tt_content avec le type 'textmedia' (pi_flexform reste vide)
3. Créer un enregistrement dans sys_file
3. Créer un enregistrement dans sys_file_reference faisant le lien


Pour les contenus de type 2, on va procéder ainsi:

1. Vérifier si le fichier existe dans sys_file via le champs `identifier`.
2. si non: on vérifie si le fichier existe. si non, on passe. si oui, on créé l'enregistrement dans sys_file.
2. Récupérer l'id dans sys_file
2. Créer un enregistrement dans tt_content avec le type 'textmedia' (pi_flexform reste vide)
3. Créer un enregistrement dans sys_file
3. Créer un enregistrement dans sys_file_reference faisant le lien

Pour les contenus de type 2, on va procéder ainsi:

1. Vérifier si le fichier existe dans sys_file via le champs `uid`. si non: on passe
2. Créer un enregistrement dans tt_content avec le type 'textmedia' (pi_flexform reste vide)
3. Créer un enregistrement dans sys_file
3. Créer un enregistrement dans sys_file_reference faisant le lien


Je fais d'abord un dump de la DB:

**Checkpoint 5**:

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt5.sql

Je lance le script une première fois avec un roolback, pour corriger d'éventuelles erreurs sql.
Une fois les quelques erreurs de syntaxe corrigées, je lance le script (en croisant les doigts)

Le script met 10 minutes à s'exécuter.

A priori c'est ok.


#### Inverser les positions des colonnes 0 et 1

Je commence par corriger les templates 3Col et Home

Puis j'exécute les requêtes suivantes:

    UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
    SET c.colPos = 100
    WHERE c.colPos = 0 
    AND (p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->3Col'
         OR p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->home');
    
    UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
    SET c.colPos = 0
    WHERE c.colPos = 1 
    AND (p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->3Col'
         OR p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->home');
         
    UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
    SET c.colPos = 1
    WHERE c.colPos = 100 
    AND (p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->3Col'
         OR p.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->home');

Je flush le cache via l'onglet maintenance.

Je corrige aussi le positionnement des carousels avec la requête suivante:

    UPDATE typo3.tt_content c INNER JOIN typo3.pages p ON c.pid = p.uid
    SET c.colPos = 0
    WHERE c.colPos = 1 AND c.CType = 'ottemplating_carousel';

#### Ajout des templates Structures

Un nouveau template a été ajouté suite aux tests: 'structures adhérentes'

On peut identifier les pages ayant ce template de la façon suivante:

    SELECT * FROM openassos.pages where backend_layout='theme_gallery__members_list_fede'; 


> ex: page 9037

Je lance donc la requête suivante:

    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid  
    SET t.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->structures',
        t.tx_fed_page_controller_action_sub = 'OpenTalent.OtTemplating->1Col',
        t.backend_layout = 'flux__grid'
    WHERE o.backend_layout = 'theme_gallery__members_list_fede';


#### Ajout des templates Evènements des structures

Un nouveau template a été ajouté suite aux tests: 'Evènements des structures'

On peut identifier les pages ayant ce template de la façon suivante:

    SELECT * FROM openassos.pages where backend_layout='theme_gallery__association_spectacle'; 

> ex: page 5802, 9032

Je lance donc la requête suivante:

    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid  
    SET t.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->structuresEvents',
        t.tx_fed_page_controller_action_sub = 'OpenTalent.OtTemplating->1Col',
        t.backend_layout = 'flux__grid'
    WHERE o.backend_layout = 'theme_gallery__association_spectacle';

La requête se déroule sans erreur, 166 pages mises à jour (le nombre est cohérent rapport au nombre de fédés)

#### Galerie de thèmes

Suite au dévelopement de la galerie de thèmes, quelques changements sont à apporter:

* 2 nouveaux champs dans la table page
* un changement dans le script update_theme_colors.py

Je corrige le premier à l'aide de l'outil 'Analyse database' du backend

Je met à jour le script, puis je le relance.
Le script s'exécute en quelques secondes.

Tout a l'air de fonctionner correctement.


#### Gabarits non appliqués

Au moins une page devrait avoir le templates Events et ne l'a pas: uid=64856

Je constate que cette page avait ceci de spécial dans l'ancien système:

    backend_layout='theme_gallery__events'

La requête suivante montre que c'est a priori le cas de toutes les pages évènement.
Je lance la requête corrective suivante:

    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid
      SET t.tx_fed_page_controller_action = 'OpenTalent.OtTemplating->events'       
      WHERE o.backend_layout='theme_gallery__events';

Le problème est corrigé.

### Noms des champs ajoutés par ot_connect

Pour des raisons de cohérences, je renomme les champs ajoutés par l'extension ot_connect de
'tx_otconnect_***' en 'tx_opentalent_***'

Je supprime les comptes auto-generes:

    DELETE FROM typo3.be_users WHERE tx_otconnect_opentalentId > 0;
    DELETE FROM typo3.fe_users WHERE tx_otconnect_opentalentId > 0;

Une fois l'extension mise à jour, je me rend sur le BE:

maintenance > analyse DB

je créé les nouveaux champs (pas de suppr), et je supprime définitivement les champs obsolètes


### Fichiers manquants

Les logs font état des erreurs suivantes:

    [ERROR] "newsletters", error: Base path "/var/www/typo3/public/uploads/newsletters/" does not exist or is no directory. 
    [ERROR] "Ressources Partagées", error: Base path "/var/www/typo3/public/fileadmin/shared_folder/" does not exist or is no directory. 
    [ERROR] "websites", error: Base path "/var/www/typo3/public/websites/" does not exist or is no directory. 

Bon tant pis, on va reprendre tous ces fichiers, on verra si on peut faire du ménage plus tard.

On va faire des liens symboliques pour l'instant:

    ln -s /var/www/typo3_82/uploads/newsletters/ /var/www/typo3/public/uploads/newsletters
    ln -s /var/www/typo3_82/fileadmin/shared_folder/ /var/www/typo3/public/fileadmin/shared_folder
    ln -s /var/www/typo3_82/websites/ /var/www/typo3/public/websites


## Nettoyage

Je vais maintenant passer à l'étape de nettoyage de la base.

Je fais d'abord un dump de la DB:

**Checkpoint 6**:

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt6.sql

Je commence par lancer l'outil d'analyse de base du backend.

![img](images/36.png)

Je ne lance pas tous les correctifs d'un coup, je le lance par bloc dans cet ordre:

1.  Remove tables (rename with prefix)

Des erreurs, certaines de ces tables existent déjà (celles de realurl).

Changement de programme, je fais dans cet ordre:

1. Drop tables (really!)
2. Remove tables (rename with prefix)
3. Encore: Drop tables (really!)
4. Remove unused fields (rename with prefix)
5. Drop fields (really!)

Tout s'est bien passé.

Je vais maintenant lancer un nettoyage avec
les outils décrits ici: https://github.com/TYPO3-CMS/lowlevel/blob/master/README.rst

Je lance:

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:orphanrecords

Le script dure 30min et se déroule sans pbm.

Le résultat est le suivant:

     ! [NOTE] Found 235 orphan records in table "pages" with following ids: 5024, 5258, 5305, 5399, 5493, 5540, 5587, 5634, 
        (...)
     ! [NOTE] Found 47 orphan records in table "sys_file_reference" with following ids: 303, 305, 353, 367, 368, 487, 516,  
        (...)
     ! [NOTE] Found 14 orphan records in table "sys_domain" with following ids: 486, 492, 502, 915, 919, 931, 981, 1039,    
        (...)
     ! [NOTE] Found 547 orphan records in table "sys_template" with following ids: 2443, 2445, 2446, 2447, 2448, 2449, 2450,
        (...)
     ! [NOTE] Found 227 orphan records in table "tt_content" with following ids: 6191, 6538, 6590, 6694, 6798, 6850, 6902,  
        (...)
     ! [NOTE] Found 1 orphan records in table "sys_redirect" with following ids: 360  
        (...)

Je lance ensuite:

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:multiplereferencedfiles

Le script me demande si je dois nettoyer le refindex avant, je répond 'yes'

Le script dure (2h40)


Je lance:

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:deletedrecords

Le script dure environ 1h.

Je lance:

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:missingrelations

Le script me demande si je dois nettoyer le refindex avant, je répond 'no'

En cours de script, une erreur se produit:

    In ResourceFactory.php line 383:
                                          
      No file found for given UID: 57940  

La doc prévient à propos de possibles erreurs de ce genre, je relance le script.
La même erreur se produit.

Je relance, cette fois en mettant à jour le refindex.


Le script dure longtemps, environ 4h, à voir si nécessaire. Il plante de nouveau sur un pbm de fichier.


Je lance:

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:flexforms

Le script dure extrêmement longtemps (au moins 6h)

Je laisse et passe au suivant (sans maj de l'index):

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:missingfiles

Le script se déroule quasi-instantanément et mentionne 3 "soft-references" à corriger manuellement (?)

     ! [NOTE] Found 3 soft-referenced files that need manual repair.                                                        
    
     * uploads/RTEmagicC_logo-cmf.jpg.jpg - 7b915ce3a16c921b1454b1ec297501d1 - tt_content:43694:bodytext::images
     * uploads/RTEmagicC_logo_ville_de_nyons_04.png.png - 82e922dd190127d1561e506091e8c9c2 - tt_content:18642:bodytext::images
     * uploads/RTEmagicC_130407_Concert_de_printemps_OHV__58_redim_.JPG.jpg - c868635e44dc72dab003b7547a5ea538 - tt_content:10241:bodytext::images

On y reviendra peut-être.

Je lance

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:lostfiles

Le script dure quelques secondes, et supprime 4047 enregistrement correspondant
à des fichiers introuvables, tous dans les répertoires suivants:

    /var/www/typo3/public/uploads/tx_news/
    /var/www/typo3/public/uploads/pics/
    /var/www/typo3/public/uploads/newsletters/
    /var/www/typo3/public/uploads/media/

Ces suppressions sont peut-être liées à des dossiers non repris,
on verra au moment de la prochaine migration.



A terme, on pourra plutôt lancer:

    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:orphanrecords -vv
    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:multiplereferencedfiles -vv --update-refindex
    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:deletedrecords -v
    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:missingrelations -vv --update-refindex
    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:flexforms -vv
    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:missingfiles --update-refindex
    php7.4 /var/www/typo3/public/typo3/sysext/core/bin/typo3 cleanup:lostfiles -vv --update-refindex

> Il serait d'ailleurs intéressant de créer un alias ou un symlink qui pointe vers le binaire typo3

## Centralisation des fichiers

Je cherche une solution pour simplifier la gestion des fichiers uploadés.

Dans l'ancienne install, ils sont répartis dans ces répertoires:

* /var/www/typo3/fileadmin/_migrated
* /var/www/typo3/fileadmin/_shared_folder
* /var/www/typo3/fileadmin/stockage
* /var/www/typo3/fileadmin/user_upload
* /var/www/typo3/uploads
* /var/www/typo3/websites

Dans la nouvelle install:

* /var/www/typo3/public/fileadmin/_migrated
* /var/www/typo3/public/fileadmin/_shared_folder
* /var/www/typo3/public/fileadmin/stockage
* /var/www/typo3/public/fileadmin/user_upload
* /var/www/typo3/public/uploads
* /var/www/typo3/public/websites

Pour l'instant, une partie de données sont stockées dans le répertoire de l'ancienne install,
une autre partie dans la nouvelle.

A l'avenir, on déplacera tous ces dossiers dans répertoire `/var/www/typo3_files` et on créera des
symlinks dans les répertoires de l'install.

## Corrections diverses

Pbm de templates, je lance:

    UPDATE typo3.pages t INNER JOIN openassos.pages o ON t.uid = o.uid
    SET t.tx_fed_page_controller_action='OpenTalent.OtTemplating->membersCa',
        t.tx_fed_page_controller_action_sub='OpenTalent.OtTemplating->1Col'
    WHERE o.backend_layout='theme_gallery__ca_members';

## Performances

On constate des problèmes de performances, avec des pages qui prennent environ 10s pour se charger.
On va explorer plusieurs pistes pour corriger le pbm.

Je commence par désactiver toute les options de debug de l'instance en preprod, pour être sûrs
d'être dans des conditions de prod.

Sur le BE, onglet settings:

* Configuration Presets > Live (déjà activé)
* `[BE][compressionLevel]` > 0 passe à 5
* `[FE][compressionLevel]` > 0 passe à 5
* `[SYS][systemLog]` > passe à false
* `[SYS][systemLogLevel]`  > WARNING passe à ERROR

### Blackfire

J'installe blackfire sur la preprod, en tant que root:

    # Register the packagecloud key
    wget -q -O - https://packages.blackfire.io/gpg.key | sudo apt-key add -
    
    # Add the repository to Debian source list
    echo "deb http://packages.blackfire.io/debian any main" | sudo tee /etc/apt/sources.list.d/blackfire.list

    # Update the repositories
    sudo apt update
    
    # Install the blackfire-agent package:
    sudo apt install blackfire-agent
    
    # Configure the server agent credentials
    sudo blackfire-agent --register --server-id=76fe1b18-5287-46db-8cf3-cb3579caa984 --server-token=ac8b209d7dc4c69ffaa81883388c2b7f1856013071eb1a993ec16f15cadc5fbb
    
    # Restart the agent service
    sudo /etc/init.d/blackfire-agent restart
    
    # Install the blackfire-php package
    sudo apt install blackfire-php
    
    # restart php-fpm
    service php7.4-fpm restart

### Bug

A ce niveau le BE a un pbm: le css ne se charge plus...

Je lance:

    touch /var/www/typo3/public/typo3conf/ENABLE_INSTALL_TOOL

J'accède à https://preprod.opentalent.fr/typo3/install.php

Je vide le cache

J'essaie de réaccéder au BE, le pbm persiste.
Je supprime tous les 'temporary assets', le pbm persiste.

Je redémarre le service php-fpm, en tant que root:

    service php7.4-fpm restart

Dans mon navigateur, je supprime tous les cookies, session storage...Etc.

Je constate alors que c'est la compression du css qui pose pbm, il est reçu encore gzippé!

Aprés les suppressions de cookies et cache, j'arrive sur l'écran de connexion, toujours
sans le css, avec un message me demandant d'autoriser les cookies...

Dans l'outil d'install, j'ouvre l'outil Directory Status
Je lance le 'try to fix'

Le BE est toujours HS.

Trouvé!
Je modifie le fichier .htaccess:

    nano /var/www/typo3/public/.htaccess

Je décommente les lignes suivantes:

    #<FilesMatch "\.js\.gzip$">
    #       AddType "text/javascript" .gzip
    #</FilesMatch>
    #<FilesMatch "\.css\.gzip$">
    #       AddType "text/css" .gzip
    #</FilesMatch>
    #AddEncoding gzip .gzip

J'enregistre, je réessaie d'accéder au BE: c'est bon!

### GtMetrix

Je lance une analyse gtmetrix sur ohcluses/: [rapport.pdf](images/gtmetrix_20200915_no_cache.pdf)

> NOTE: ohcluses est configuré avec l'ancien template (classic)

La page s'est chargée en 4.5s, pour un poids total de 1.18MB, la compression a fait du bon boulot.

Le serveur a mis 3.06s à générer la réponse, ce qu'on essaiera d'améliorer avec blackfire.

Les fichiers '0x60', '1', '365' ont mis entre 800 et 910ms à être chargés depuis api.opentalent.fr!
Je lance une seconde analyse pour voir l'impact de la mise en cache:
[rapport2.pdf](images/gtmetrix_20200915_test_2.pdf)

Pas de différence du point de vue de la waterfall.

Je commence par appliquer les recommandations.

#### Defer le JS

Je passe les fichiers JS des deux templates en mode defer.

#### Browser caching

J'ouvre le .htaccess:

    nano /var/www/typo3/public/.htaccess

Le cache est déjà configuré, je ne change rien.

### Serve scaled images

Je corrige la façon dont les images sont insérées pour qu'elles
soient redimensionnées au niveau du serveur.

Je vais essayer de remplacer toutes les balises <images/> par <f:image/>
Il est possible que typo3 gère mieux le cache et les redimensionnement de cette façon?
Pour ce qui est des images extérieures, mystère.

#### Avoid bad requests

j'ajoute un fichier favicon.ico, et je le copie à la racine du site:

    cp /var/opentalent.git/ot_typo3/ot_templating/Resources/Public/Icons/favicon.ico

#### Minify JS and CSS

Je minifie quand c'est possible.

#### Compression

Je suis les conseils écrits dans le .htaccess, et passe la compresison à 9:

Sur le BE, onglet settings:

* `[BE][compressionLevel]` > 5 passe à 9
* `[FE][compressionLevel]` > 5 passe à 9

### Nouvel essai

Je relance un test après avoir appliqué toutes les corrections.

[rapport3.pdf](images/gtmetrix_20200915_test_3.pdf)

Rien de trés concluant.

Je désactive les contenus externes de la page ohcluses, et je vide le cache:

Trés bien, on est à 97% avec Pagespeed!

[rapport4.pdf](images/gtmetrix_20200915_test_4.pdf)

Je relance une deuxième fois, maintenant que le cache est chargé.

[rapport5.pdf](images/gtmetrix_20200915_test_5.pdf)

Le cache ne change pas grand chose, finalement...

Je lance le test après avoir changé le template pour le nouveau, et vidé le cache.

[rapport6.pdf](images/gtmetrix_20200915_test_6.pdf)

Enfin, je relance avec le carousel d'images:

[rapport7.pdf](images/gtmetrix_20200915_test_7.pdf)


Les résultats sont mauvais.

Je procède aux corrections.

#### Carousel

D'abord, les images du carousel sont beaucoup trop lourdes, de l'ordre de 3 à 3.5Mb
Je rétablit la compression pour le nouveau template.


### 404

Je corrige les appels css pour éviter l'import de toute une liste de fichiers inutilisés.

J'exécute:

    cp /var/opentalent/git/ot_typo3/ot_templating/Resources/Public/Icons/favicon.ico /var/www/typo3/public/

### Nouvel essai

Je relance un test après avoir appliqué toutes les corrections.

[rapport3.pdf](images/gtmetrix_20200915_test_8.pdf)

Les choses se sont bien améliorées!



## Blackfire

Le reste du travail va se faire avec blackfire.

### Resolution des pages

Le premier problème vient de la manière dont la méthode Typo3 résout l'URL:

TYPO3\CMS\Core\Routing\PageRouter\getPagesFromDatabaseForCandidates

en effet, la requête sql filtre la page demandée par son slug, puis itère sur le résultat de la requête
pour tester si la page est contenue dans le site actuel.

Dans notre cas, il y a plus de 5800 itérations, qui consomment au total	6.29 s!

A première vue, le système de résolution des url change avec la V10,
la solution la plus indiquée serait donc de migrer vers cette dernière...


### Lenteur des appels à l'API

Une autre observation est le temps mis par les requêtes à l'API.
On y reviendra quand le pbm précédent sera résolu


## Rollback




Maintenant que l'upgrade est complète, je vais archiver la nouvelle install et
essayer de reprendre l'upgrade de zéro.

Je fais d'abord un dump de la DB:

**Checkpoint 7**:

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt7.sql


Je lance les commandes suivantes (en tant que root):

    mkdir /var/www/archives
    mkdir /var/www/archives/upgrade1
    mv /var/www/typo3 /var/www/archives/upgrade1/
    mv /var/www/typo3_95 /var/www/archives/upgrade1/
    mv /var/www/typo3_82 /var/www/typo3
    rm -r /var/opentalent/git/ot_typo3

Je modifie le fichier de conf apache:

    nano /etc/apache2/sites-available/001-preprod.opentalent.fr.conf
    nano /etc/apache2/sites-available/001-preprod.opentalent.fr-le-ssl.conf

Dans ces deux fichiers, remplacer:

    DocumentRoot /var/www/typo3/public

Par:

    DocumentRoot /var/www/typo3

Enfin, je supprime la base typo3:

    DROP DATABASE typo3;

Supprimer le user typo3

Je synchronise les bases openassos (en tant que root):

    python3 /var/opentalent/git/clonedb/clonedb.py -y openassos

Je lance (en tant que root):

    service apache2 reload


J'essaie de me rendre à l'adresse: https://preprod.opentalent.fr/typo3/
Le BE s'affiche correctement.

Je me rends à: https://ohcluses.opentalent.fr/index.php?id=499

La page s'affiche correctement.

Je considère le rollback comme réussi.


## Upgrade

> Tony fait un snapshot: preprod@olivier.2020-09-16


J'essaie de lancer la procédure d'upgrade comme décrit dans UPGRADE_GUIDE.md

Je démarre à mercredi 15:35

Une erreur s'est produite. Je rejoue le rollback, et je recommence.

Je relance l'upgrade à jeudi 09:15

Une erreur s'est produite. Je rejoue le rollback, et je recommence.

Je relance l'upgrade à jeudi 11:15

Au cours de ces deux derniers essais, je me retrouve bloqué au moment d'afficher l'upgrade wizard.
De la même façon, la commande:

    php7.4 -d memory_limit=-1 /var/www/typo3/typo3/sysext/core/bin/typo3 upgrade:list

Tourne "à vide", et n'affiche rien...

J'essaie à tout hasard de lancer:

    php7.4 -d memory_limit=-1 /var/www/typo3/typo3/sysext/core/bin/typo3 cleanup:orphanrecords

Le script tourne en moins de 1h30, mais sans effet sur le upgrade wizard.

Tant pis, j'essaie un (13:40):

    php7.4 -d memory_limit=-1 /var/www/typo3/typo3/sysext/core/bin/typo3 referenceindex:update

Le pbm venait de l'upgrade des forms.yaml, qui scannait tous les répertoires uploads et user_upload.
Corrigé, je relance une upgrade.

Tony restaure le snapshot preprod@olivier.2020-09-16

Je relance l'upgrade jeudi à 16:30

Encore un souci.

Je relance vendredi 15:10

Terminée le lundi suivant à 16:00, pour un total de 360min , soit 6h


## Bilan

Les choses se sont bien passées, reste quelques erreurs.

### Images manquantes

Les images uploadées manquent. Première hypothèse: les symlinks vers /var/www/typo3_files.

Effectivement, les liens vers les dossiers dans fileadmin sont absents!

Je vais revoir la procédure, et abandonner cette idée de symlinks.


Je rapatrie ces répertoires:

    mv /var/www/typo3_files/fileadmin/_migrated /var/www/typo3/public/fileadmin/
    mv /var/www/typo3_files/fileadmin/shared_folder /var/www/typo3/public/fileadmin/
    mv /var/www/typo3_files/fileadmin/stockage /var/www/typo3/public/fileadmin/
    rm -r /var/www/typo3/public/fileadmin/user_upload
    mv /var/www/typo3_files/fileadmin/user_upload /var/www/typo3/public/fileadmin/
    rm /var/www/typo3/public/uploads
    mv /var/www/typo3_files/uploads /var/www/typo3/public/
    rm /var/www/typo3/public/websites
    mv /var/www/typo3_files/websites /var/www/typo3/public/

Je relance le script `10_regen_media_contents.py`

Le problème des images est presque résolu.

Je remarque encore quelques images manquantes, par exemple à la page:
https://preprod.opentalent.fr/conservatoirethouarsais/

L'image /fileadmin/user_upload/72843/images/fichiers/Visuel_couverture_agenda_19.png manque par ex.

Je pense que c'est dû au fait que les répertoires fileadmin et uploads n'ont pas été synchronisés
depuis un certain temps.


### Formulaire de contact

L'implémentation des formulaires de contact est defectueuse.

Je vais créer un site nommé 'DO_NOT_DELETE',
qui contiendra une page nommée 'contact', qui elle même contiendra
un formulaire de contact.

C'est ce contenu que je référencerai dans le plugin.


### Formulaires

Les formulaires n'ont pas été renommés correctement en raison du bug avec l'upgrade
wizard.

Ils sont en doublons, c'est un peu le bazar.
Je laisse pour l'instant, mais à la prochaine upgrade, il faudra lancer manuellement
l'opération de renommage.




## Upgrade 10

Enfin, on va procéder à l'upgrade finale, vers la v10.

Je fais un dump de la DB

**Checkpoint 8**:

    mysqldump --single-transaction -u root --password=mysql2iopenservice369566 typo3 > /home/exploitation/typo3_chkpnt8.sql

### Upgrade


Je fais une svg du répertoire actuel:

    mkdir /var/www/typo3_95c
    cp -p /var/www/typo3/composer.json /var/www/typo3_95c/
    cp -p /var/www/typo3/composer.lock /var/www/typo3_95c/
    cp -p /var/www/typo3/composer.phar /var/www/typo3_95c/
    cp -rp /var/www/typo3/config /var/www/typo3_95c/
    cp -rp /var/www/typo3/var /var/www/typo3_95c/
    cp -rp /var/www/typo3/vendor /var/www/typo3_95c/
    mkdir /var/www/typo3_95c/public
    cp -p /var/www/typo3/public/.htaccess /var/www/typo3_95c/public/
    cp -p /var/www/typo3/public/index.php /var/www/typo3_95c/public/
    cp -rp /var/www/typo3/public/typo3 /var/www/typo3_95c/public/
    cp -rp /var/www/typo3/public/typo3conf /var/www/typo3_95c/public/
    mkdir /var/www/typo3_95c/public/fileadmin
    mkdir /var/www/typo3_95c/public/typo3temp

Je lance (!! en tant que exploitation):

    cd /var/www/typo3
    php7.4 composer.phar require typo3/cms-backend:^9.5 typo3/cms-core:^9.5 \
     typo3/cms-extbase:^9.5 typo3/cms-extensionmanager:^9.5 \
     typo3/cms-filelist:^9.5 typo3/cms-fluid:^9.5 typo3/cms-frontend:^9.5 \
     typo3/cms-install:^9.5 typo3/cms-recordlist:^9.5 \
     causal/image_autoresize:^2.0 helhum/typo3-console:^5.7 \
     georgringer/news:^8.4 fluidtypo3/vhs:6.0 fluidtypo3/flux:^9.4 \
     --update-with-dependencies

    php7.4 composer.phar remove bueroparallel/bp-pagetree
    php7.4 composer.phar require "typo3/cms-about:^10.4" "typo3/cms-adminpanel:^10.4" \
        "typo3/cms-backend:^10.4" "typo3/cms-belog:^10.4" "typo3/cms-beuser:^10.4" \
        "typo3/cms-core:^10.4" "typo3/cms-dashboard:^10.4" "typo3/cms-extbase:^10.4" \
        "typo3/cms-extensionmanager:^10.4" "typo3/cms-felogin:^10.4" "typo3/cms-filelist:^10.4" \
        "typo3/cms-filemetadata:^10.4" "typo3/cms-fluid:^10.4" "typo3/cms-fluid-styled-content:^10.4" \
        "typo3/cms-form:^10.4" "typo3/cms-frontend:^10.4" "typo3/cms-info:^10.4" \
        "typo3/cms-install:^10.4" "typo3/cms-linkvalidator:^10.4" "typo3/cms-lowlevel:^10.4" \
        "typo3/cms-recordlist:^10.4" "typo3/cms-recycler:^10.4" "typo3/cms-redirects:^10.4" \
        "typo3/cms-reports:^10.4" "typo3/cms-rte-ckeditor:^10.4" "typo3/cms-scheduler:^10.4" \
        "typo3/cms-seo:^10.4" "typo3/cms-setup:^10.4" "typo3/cms-t3editor:^10.4" "typo3/cms-tstemplate:^10.4" \
        "typo3/cms-viewpage:^10.4" "helhum/typo3-console:^6.3"


    php7.4 composer.phar dumpautoload
    touch /var/www/typo3/public/typo3conf/ENABLE_INSTALL_TOOL

En tant que root:

    chown -R exploitation:www-data .    


Je me rend à https://preprod.opentalent.fr/typo3/install.php
On est bien en v10.4.8, super.

J'ouvre l'outil d'analyse de la DB, et je créé les tables et champs demandés.
Je vide le cache, puis je lance l'upgrade wizard:

L'outil me suggère les correctifs suivants:

1. Install extension "rsaauth" from TER if the site is still not secured using HTTPS
2. Install outdated extension "feedit" from TER if editors used this extension in earlier core versions
3. Install extension "taskcenter" from TER
4. Install extension "sys_action" from TER
5. Execute database migrations on single rows
6. Migrate felogin plugins to use prefixed flexform keys

Je procède ainsi:

1. No, do not execute > perform
2. No, do not execute > perform
3. No, do not execute > perform
4. No, do not execute > perform
5. Perform
5. Perform > Failed! (j'y reviendrai)


Je vérifie l'outil Directory status, c'est tout bon.
Je vérifie les extensions broken, tout bon.
Je scanne les extensions pour les deprecated: ouhla, c'est tout rouge partout. On y reviendra.

Je reset le BE User
Je maj les languages packs

Je lance l'outil "remove temporary assets"
Je vire les assets uniquement.
J'ai une erreur pour assets/__processed__, tout va bien pour les autres.
Je les supprime manuellement:

    rm -r /var/www/typo3/public/typo3temp/assets/_processed_/*

Je me rend sur le BE.

Tout a l'air de s'être bien passé.
J'ouvre: https://preprod.opentalent.fr/ohcluses/


### Tests et corrections

J'ai une erreur avec le viewhelper FalViewHelper de VHS:

![img](images/38.png)

Ce VH est utilisé pour le carousel.

Je met à jour VHS, qui n'est qu'en 6.0.0 (la dernière est la 6.0.3)
Finalement, j'irais jusqu'à la version dev:

    php7.4 composer.phar require fluidtypo3/vhs:dev-development


NB: il est possible qu'il faille ajouter cette section au composer.json, à vérifier

    "repositories": [
        {
          "type": "composer",
          "url": "https://composer.typo3.org"
        },
        {
          "type": "vcs",
          "url": "https://github.com/FluidTYPO3/vhs"
        }
      ]


J'ai maintenant cette erreur:

![img](images/39.png)

Cela correspond à l'issue et à la pull request suivante: https://github.com/FluidTYPO3/vhs/pull/1676/files

J'applique les changements manuellement en attendant aux fichiers:

* Classes/Service/AssetService.php
* Classes/ViewHelpers/Iterator/ExtractViewHelper.php

Ca fonctionne en local!

J'envoie les 2 fichiers en question sur la preprod avec filezilla, et je les range ici:

    /home/exploitation/patch_vhs_6.0.3/...

Je patche l'instrall actuelle avec les commandes:

    cp /home/exploitation/patch_vhs_6.0.3/Service/AssetService.php /var/www/typo3/public/typo3conf/ext/vhs/Classes/Service/AssetService.php
    cp /home/exploitation/patch_vhs_6.0.3/ViewHelpers/Iterator/ExtractViewHelper.php /var/www/typo3/public/typo3conf/ext/vhs/Classes/ViewHelpers/Iterator/ExtractViewHelper.php

J'arrive à afficher la page, mais le pbm de perfs reste.

Je pense qu'il vaut mieux éviter d'aller jusqu'à la v10 pour l'instant...


## Correction du pbm de perfs

Je modifie en local les fichiers:

    /var/www/typo3/public/typo3/sysext/core/Classes/Routing/PageSlugCandidateProvider.php
    /var/www/typo3/public/typo3/sysext/core/Classes/Domain/Repository/PageRepository.php

/!\ Ce correctif n'est valable que pour la v10.4.8

Je vérifie le résultat, en envoyant ce correctif avec filezilla sur le serveur.

Je lance:

    cp /home/exploitation/patch_typo3core_10.4.8/Routing/PageSlugCandidateProvider.php /var/www/typo3/public/typo3/sysext/core/Classes/Routing/
    cp /home/exploitation/patch_typo3core_10.4.8/Domain/Repository/PageRepository.php /var/www/typo3/public/typo3/sysext/core/Classes/Domain/Repository/

Ca fonctionne. Je reproduirai ce patch pour la v9.5.


## Retour à l'upgrade v9

Je vais procéder de nouveau à l'upgrade vers la v9.

Tony vient de restaurer le snapshot.
Je joue le rollback, me voilà revenu à la version 8.7.

Je vais essayer de monter un script plus efficace.
Il va s'articuler autour des étapes suivantes:

1. Contrôle les prérequis: version de php, user exploit dans le groupe www-data, présence du rep typo3...etc
2. Créé la nouvelle DB et le nouveau db_user si besoin
3. Lancer les correctifs en base
4. Opérations sur les répertoires
5. Lancer les préparatifs à d'upgrade via la console (broken ext, cache, tempfiles...etc.)
6. CHK - vérifier l'existence de la db, la version de la nouvelle instance
7. Lancer les scripts d'upgrade Typo3 via la console
8. Lancer le script python post-upgrade
9. Faire les modifications fichier pour la passage vers composer
10. Lancer le script python post-upgrade
11. Derniers correctifs: droits des be_users, flush cache...Etc.
12. CHK - Verifier le passage vers composer
13. Lancement du grand nettoyage


A chaque étape, le script devra informer et s'auto-contrôler.
Il devra aussi garder une trace des étapes déjà accomplies, en cas d'erreur
et s'il faut le relancer plusieurs fois.
Enfin, chaque étape doit être transactionnelle,
donc pouvoir être relancée autant de fois qu'on veut sans risque de conflit.









TODO: reprendre la moulinette de création d'organisation
TODO: voir ce que fait la setting `[BE][cookieSameSite]`, `[FE][cookieSameSite]`, `[SYS][cookieSecure]`?
TODO: préparer la liste des tests a effectuer pour la recette en prod
TODO: remettre au propre les images (non reprises, non utilisées...Etc.)
TODO: nettoyage du repertoire uploads
TODO: recherche d'erreurs et correction dans la DB:
* cmsId erronés
* org_id manquants
* pages sans contenu (hors events)
* presence des pages events, contact, footer...

TODO: faire un script avec behat ou en python pour tester tous les sites


Notes de michel:

    Je viens de regarder uploads/manual, il ne faut pas reprendre
    idem uploads/openassos
    pour uploads/newsletter faut reprendre tel quel et faudra demander aux commerciaux de faire le ménage
    idem /uploads/opentalent faut pas reprendre
    idem /uploads/template_emails faut pas reprendre
    idem /uploads/tf faut pas reprendre


## Déploiement en prod

### Prévisions des corrections avant de démarrer

Les corrections suivantes doivent être apportées au serveur prod-front avant de procéder à l'upgrade.

Changer le user php-fpm et apache2 pour mettre 'exploitation' à la place de 'www-data', et faire un:

    chown -R exploitation:www-data /var/www/typo3

Corriger le fichier php.ini pour régler la timezone sur Europe / Paris

    [Date]
    ; Defines the default timezone used by the date functions
    ; http://php.net/date.timezone
    ;date.timezone =

Tony fera un upgrade mariadb 10.3 sur prod-back avec patch ci dessous + switch mysql5.7
vers mariadb10.3 sur prod-front (repo: source.list):

    /lib/systemd/system/mariadb.service:   Your workaround is working but it seems that removing only these 3 lines
    is sufficient:
    > ProtectSystem=full
    > PrivateDevices=true
    > ProtectHome=true


