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"

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

Execute

Add the default Extension Manager database tables

Execute

Update backend user setting "startModule"

Execute

Migrate bullet content element rendering selector from layout to bullets_type

Execute

Migrate upload content element rendering from layout to uploads_type

execute

Install compatibility extension for TYPO3 7 compatibility

execute, puis laisser à "no do not execute"

Install extension "form_legacy"

execute, puis laisser à "no do not execute"

Install extension "rtehtmlarea" from TER

execute, puis laisser à "no do not execute"

Install extension "typo3db_legacy" from TER

execute, puis laisser à "no do not execute"

Install extension "func" from TER

execute, puis mettre à "Yes, execute"

Migrate pages.urltype to pages.url

Execute

Migrates existing sys_log entries into sys_history

Execute

Merge be_groups access rights from pages_language_overlay to pages

execute, puis mettre à "Yes, execute"

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

execute, puis mettre à "Yes, execute"

Install extension "adminpanel"

execute, puis mettre à "Yes, execute"

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

Ignore

Reminder to verify live system supports argon2i

"Yes I understand" > Execute

Update backend user configuration array

Execute

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"

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

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.

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)...

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.

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:

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:

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:

Versions de mysql: 5.5.5 sur la preprod, 5.7.3 sur la prod
Nombre de tables /!: 7 tables en plus sur la preprod
Différence entre les droits sur les répertoires: typo3temp et typo3conf
DB n'ont pas le même charset
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:

Les tables en trop viennent d'un souci avec le script de synchro des bases qui ne faisait pas le drop/creat database / corrigé
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.

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.
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:

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.

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:

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.

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!

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.

Comme le suggère la documentation, 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:

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

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.

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

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

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:

Rename form definition file extension from .yaml to .form.yaml
Add the default Extension Manager database tables
Update backend user setting "startModule"
Migrate bullet content element rendering selector from layout to bullets_type
Migrate upload content element rendering from layout to uploads_type
Install compatibility extension for TYPO3 7 compatibility
Install extension "form_legacy"
Install extension "rtehtmlarea" from TER
Install extension "typo3db_legacy" from TER
Install extension "func" from TER
Migrate pages.urltype to pages.url
Migrates existing sys_log entries into sys_history
Merge be_groups access rights from pages_language_overlay to pages
Install system extension "redirects" if a sys_domain entry with redirectTo is necessary
Install extension "adminpanel"
Introduce URL parts ("slugs") to all existing pages
Reminder to verify live system supports argon2i
Update backend user configuration array
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:

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

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 à:

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?)

basculer vers le mode composer
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.

Introduce URL parts ("slugs") to all existing pages
[Optional] Migrate realurl alias to slug field "path_segment" of EXT:news records
Updates slug field "path_segment" of EXT:news records
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)

Voilà ce que fait la fonction officielle:

Selection des lignes de la table pages où le champs slug est une chaine vide ou null
récupère d'éventuels slug existants de realurl (voir ici):
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
Parcourt les enreg de la selection (1)
Si le champs alias est renseigné, construit le slug a partir de là
Si ni alias, ni valeur depuis realurl: génère un nouveau slug (voir la classe SlugHelper):
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
Vérifie les contraintes d'unicité du slug dans le site
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:

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.

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:

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:

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:

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:

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_galleryactivity_report' 'theme_galleryadmin_commitee' 'theme_galleryadministration' 'theme_galleryadvanced_user_manual' 'theme_gallery__agenda' (et 50 de plus...)

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

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:

https://preprod.opentalent.fr/eml/
pbm avec le footer
toutes les pages du menu renvoient des erreurs 404 / pbm de slugs?
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:

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

Reinitialiser le champs colPos des pages qui avaient anciennement les templates 'theme_gallerypage' et 'theme_gallerydefault' pour reprendre leur ancienne valeur.
Repositionner le contenu de ces pages
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_gallerypage' ou 'theme_gallerydefault':

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?

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:

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:

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

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:

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

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:

Il reste quelques petites erreurs de positionnement:

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

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:

Contenu de type lien externe, exemple avec uid=104773: http://www.youtube.com/watch?v=mBtcQXAQhck
Contenu de type fichier uploadé, ex uid=102172: fileadmin/user_upload/12097/images/FORMassos/V02 utilisation.qt
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 - "Lonely Beach" 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:

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

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

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

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

Vérifier si le fichier existe dans sys_file via le champs uid. si non: on passe
Créer un enregistrement dans tt_content avec le type 'textmedia' (pi_flexform reste vide)
Créer un enregistrement dans sys_file
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 'txotconnect' en 'txopentalent'

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.

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

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:

Drop tables (really!)
Remove tables (rename with prefix)
Encore: Drop tables (really!)
Remove unused fields (rename with prefix)
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

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

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 par 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

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

Je relance une deuxième fois, maintenant que le cache est chargé.

rapport5.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

Enfin, je relance avec le carousel d'images:

rapport7.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

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:

Install extension "rsaauth" from TER if the site is still not secured using HTTPS
Install outdated extension "feedit" from TER if editors used this extension in earlier core versions
Install extension "taskcenter" from TER
Install extension "sys_action" from TER
Execute database migrations on single rows
Migrate felogin plugins to use prefixed flexform keys

Je procède ainsi:

No, do not execute > perform
No, do not execute > perform
No, do not execute > perform
No, do not execute > perform
Perform
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:

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:

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:

Contrôle les prérequis: version de php, user exploit dans le groupe www-data, présence du rep typo3...etc
Créé la nouvelle DB et le nouveau db_user si besoin
Lancer les correctifs en base
Opérations sur les répertoires
Lancer les préparatifs à d'upgrade via la console (broken ext, cache, tempfiles...etc.)
CHK - vérifier l'existence de la db, la version de la nouvelle instance
Lancer les scripts d'upgrade Typo3 via la console
Lancer le script python post-upgrade
Faire les modifications fichier pour la passage vers composer
Lancer le script python post-upgrade
Derniers correctifs: droits des be_users, flush cache...Etc.
CHK - Verifier le passage vers composer
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

upgrade_v9.md 155 KB Trvalý odkaz Historie Surový

Upgrade TYPO3 8.2 > 9.5

POC

Programme

14/09

23/09

8:30 => 12:00:

20/10 am, 21/10

15:30 => 18:00

28/09

Switch en mode maintenance

Rollback

Préparation de prod-front

php et apache

scripts

Installation de la 9.5

Switch vers composer

Finalisation et correctifs

Nettoyage

Mise en pratique

POC Upgrade TYPO3 8.2 > 9.5

Notes

Mise en place - 17/06/2020

Essais

Essai 1 - 18/06/2020

Templating et contenu

Tests, bugs et solutions

Contenus mal positionnés

Rendus partiels et orgId non trouvé

Erreurs lors du scan

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

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

Id des structures

Couleurs des thèmes

Paramétrage et extensions

Nouvelles extensions

Langue du BE

Corrections diverses en base

backend_layout

sys_redirect

Corrections suite aux tests

Guzzle n'est pas installé

Une image est manquante

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

Erreur FLUID due à un contenu

Sorting du raccourci 'Accueil'

Gabarits manquants

Organization ids

Reprise des fichiers

Pages Membres du CA et adhérents

Corriger les constants.ts

Restaurer les contenus de type carroussels

j'y reviendrai avec Yohann Cerdan.

Errors with contents of type media

Inverser les positions des colonnes 0 et 1

Ajout des templates Structures

Ajout des templates Evènements des structures

Galerie de thèmes

Gabarits non appliqués

Noms des champs ajoutés par ot_connect

Fichiers manquants

Nettoyage

Centralisation des fichiers

Corrections diverses

Performances

Blackfire

Bug

GtMetrix

Defer le JS

Browser caching

Serve scaled images

Avoid bad requests

Minify JS and CSS

Compression

Nouvel essai

Carousel

404

Nouvel essai

Blackfire

Resolution des pages

upgrade_v9.md 155 KB

Trvalý odkaz Historie Surový