Aller au contenu
Tarifs

Guide

Débloquer une mise à jour

Si la mise à jour s'interrompt en annonçant une fonction indisponible, elle n'a rien cassé : elle s'est arrêtée avant d'écrire. Voici comment la reprendre à la main.

Ce qui ne peut pas arriver

Avant de chercher ce qui a raté, sachez ce qui est tenu quoi qu'il arrive. Une mise à jour ne commence pas tant que la signature du paquet et son empreinte ne correspondent pas. Elle sauvegarde vos fichiers et votre base avant d'écrire quoi que ce soit. Elle ne touche que les fichiers de Sillon, jamais votre thème, votre configuration, vos fichiers envoyés ni vos modules maison. Les migrations de base ajoutent, elles ne suppriment ni ne renomment. Et si le contrôle de santé signale une anomalie à la fin, les fichiers reviennent d'eux-mêmes à leur état d'avant.

Autrement dit : dans la grande majorité des cas, une mise à jour qui échoue vous laisse le site qui marchait.

Les refus : rien n'a bougé

Ces messages arrivent avant que le moindre fichier soit touché. Votre site tourne toujours, exactement comme avant.

Ce que vous lisez Ce que ça veut dire Ce que vous faites
La version … demande PHP … au minimum Le paquet a besoin d'un PHP plus récent que celui de votre serveur. La mise à jour ne vous est même pas proposée. Changez la version de PHP dans le panneau de votre hébergeur, puis relancez. Le site continue de tourner en attendant.
… exige d'être au moins en X.Y.Z On ne saute pas les versions : celle-ci a besoin d'une plus ancienne pour poser ses fondations. Appliquez les versions intermédiaires l'une après l'autre. Elles sont toutes sur le dépôt.
SIGNATURE INVALIDE Le manifeste du dépôt n'est pas signé par la clé de Sillon. Le site refuse par prudence, et il a raison. N'insistez pas et écrivez-nous. Ce message veut dire soit un incident chez nous, soit quelque chose qui n'aurait pas dû arriver.
Signature du manifest introuvable Le fichier de signature manque sur le dépôt. Réessayez dans quelques minutes : c'est le plus souvent un dépôt en cours de mise à jour. Si ça dure, écrivez-nous.
EMPREINTE INCORRECTE Le paquet téléchargé ne correspond pas à ce que le manifeste annonce. Presque toujours un téléchargement abîmé. Relancez. Deux échecs de suite, écrivez-nous.
Archive corrompue · Archive illisible Le fichier reçu n'est pas une archive valide. Même chose : relancez, puis écrivez-nous.
Impossible de créer le dossier de travail (backups/) Le serveur n'autorise pas l'écriture là où la sauvegarde doit aller. C'est une question de droits sur le dossier. Votre hébergeur sait la régler, ou écrivez-nous.

Les arrêts en cours de route

Plus rares, parce qu'ils supposent que tout le reste est passé.

Ce que vous lisez Ce que ça veut dire Ce que vous faites
DOCTOR EN ÉCHEC, rollback automatique des fichiers Le site a été remis dans son état d'avant, tout seul. Le message nomme le contrôle qui a fait échouer. Rien dans l'urgence : vous êtes sur la version qui marchait. Envoyez-nous le nom du contrôle cité.
Migration … en échec Un changement de structure de base n'est pas passé. Les migrations étant additives, rien n'a été perdu. Écrivez-nous avec le nom de la migration, tel quel. Ne relancez pas en boucle.
Backup base IMPOSSIBLE (mysqldump introuvable) Ce n'est pas un arrêt : la mise à jour continue. Votre hébergeur ne fournit pas l'outil de sauvegarde de base, et la sauvegarde des fichiers reste le filet. Rien à faire. Si vous voulez la ceinture et les bretelles, exportez votre base depuis le panneau de l'hébergeur avant de lancer.
ROLLBACK IMPOSSIBLE : backup illisible Le seul cas vraiment gênant : le retour en arrière n'a pas pu se faire. Ne touchez à rien et écrivez-nous. La sauvegarde est dans backups/, elle se remonte à la main.
Call to undefined function … shell_exec Votre hébergeur interdit de lancer un programme extérieur. Cela ne concerne que les versions très anciennes de Sillon. La procédure manuelle plus bas pose la version à la main, une fois. Ensuite tout redevient normal.

Quand nous écrire, et avec quoi

Dès que le tableau vous y renvoie, et sans attendre. Pour qu'on réponde du premier coup, joignez trois choses : la version que vous quittez et celle que vous visez, le message complet tel qu'il s'affiche (pas résumé), et le résultat de php cli.php kit:doctor.

Un site bloqué en mise à jour n'est pas une urgence de sécurité : votre site public continue de répondre pendant qu'on regarde.

En dernier recours : poser une version à la main

Cette procédure remplace les fichiers de Sillon sans passer par le mécanisme de mise à jour. Elle sert quand c'est ce mécanisme lui-même qui est en cause. Elle ne s'improvise pas, et elle laisse une trace que la mise à jour normale ne laisse pas : lisez la dernière section avant de commencer.

Ce qu'il vous faut

  • L'archive de la version visée, et sa somme de contrôle.
  • Un accès SSH, ou à défaut le gestionnaire de fichiers de votre hébergeur.
  • Un accès à votre base, par le panneau de l'hébergeur.

La marche à suivre

  1. Sauvegarder la base, d'abord, et par votre hébergeur

    C'est l'étape que la mise à jour aurait faite pour vous ; ici, elle est à votre charge. Passez par l'export de base de votre panneau d'hébergement, ou par phpMyAdmin. Ne comptez pas sur la commande de sauvegarde du kit : si vous en êtes là, c'est qu'elle ne peut pas s'exécuter.

Vérifiez que le fichier obtenu n'est pas vide et qu'il contient bien vos tables. Une sauvegarde qu'on n'a pas regardée n'est pas une sauvegarde.

  • Sauvegarder les fichiers

    Une copie du site, hors du site. En SSH, depuis la racine :

    • tar czf ~/avant-maj.tar.gz --exclude=backups core admin api modules lang library database assets brand cli.php index.php install.php sitemap.php .htaccess VERSION

    On exclut backups pour ne pas s'archiver soi-même. La configuration et vos fichiers envoyés ne sont pas dans cette liste : la mise à jour n'y touche pas.

  • Vérifier l'archive avant de l'ouvrir

    Comparez sa somme de contrôle à celle annoncée. C'est un réflexe de dix secondes qui évite d'installer un fichier abîmé par le transfert :

    • sha256sum kit-X.Y.Z.zip

  • Mettre le site en maintenance

    Un fichier vide nommé .maintenance à la racine suffit. Les visiteurs voient une page d'attente pendant la copie, qui dure quelques secondes.

    • touch .maintenance

  • Ouvrir l'archive par-dessus

    En excluant votre thème et votre configuration, qui ne lui appartiennent pas :

    • unzip -o kit-X.Y.Z.zip -x 'layouts/*' 'config/*'

  • Appliquer les migrations

    • php cli.php migrate

    Elles sont additives : elles ajoutent des colonnes et des tables, elles n'en retirent jamais.

  • Contrôler, puis rouvrir

    • php cli.php kit:doctorrm .maintenance

    Lisez le résultat avant de retirer la maintenance. Tant qu'il reste un échec, le site n'est pas prêt à rouvrir.

    Le piège : ce que l'extraction ne fait pas

    Ouvrir une archive par-dessus REMPLACE les fichiers, mais ne SUPPRIME pas ceux qui ont disparu entre-temps. Le site garde donc des fichiers d'anciennes versions, et parmi eux, parfois, d'anciens écrans d'administration encore atteignables, qui travaillent sur des tables dont la structure a changé.

    C'est le seul écart réel entre cette procédure et une vraie mise à jour. Le contrôle de santé le détecte souvent de biais : il signale une anomalie qui n'existe pas dans la version que vous venez d'installer.

    La bonne nouvelle : ça se répare tout seul, ensuite. La mise à jour normale, elle, compare l'archive à l'installé et retire ce qui n'a plus lieu d'être, en nommant chaque suppression. Vos modules maison, vos médias et votre thème ne sont jamais concernés. Votre prochaine mise à jour normale fera donc le ménage que celle-ci n'a pas pu faire.