migration vers J4 dans un sous-répertoire et suppression template protostar racine

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [RÉGLÉ] migration vers J4 dans un sous-répertoire et suppression template protostar racine

    Bonjour,
    Lors d'une tentative de migration d'un site de J3 vers J4, il est arrivé une chose curieuse que je n'ai pas saisie, mais il doit y avoir une explication.

    - Site J3! en exploitation sur OVH
    - je fais une copie du site dans un sous-répertoire /v2 du même hébergement via akeeba, tout va bien, et je restaure le site dans /v2 via kickstart. A noter que je ne suis jamais arrivé à faire la restauration sur un autre hébergeur (planethoster et o2switch, bloqué à cause des identifiants de la base de données non reconnues ...)
    - je fais le ménage dans les extensions J3 dans le sous-dossier /v2, j'arrive à la migration vers J4, ça se passe bien bon an mal an, l'admin est ok, le frontend n'est pas ok mais c'est normal vu que le template du site en J3 était en protostar qui disparait en J4 au profit de cassiopeia. Jusque là, tout est normal.
    - Mais, et c'est là que je veux en venir, catastrophe, je m'aperçois que le site J3 en exploitation (celui à la racine) est tombé en rade, page d'erreur "template non trouvé". Le passage en J4 dans un site situé dans un sous-dossier modifie donc le site à la racine ! J'ai restauré la sauvegarde hébergeur du site en exploitation, et ai rééssayé la manipulation une 2e fois, idem.
    - il doit y avoir un chemin quelque part dans une variable qui amène au template de la racine, mais laquelle ?

    Dernière édition par romain69 à 15/05/2023, 16h27

  • #2
    Bonjour,

    Si je comprends bien (et ça expliquerait tes blocages chez d'autre hébergeurs), tu as utilisé la même base de données et le même préfixe pour le clone, ce qui explique que ce que tu as modifié sur ce clone s'est répercuté sur le site principal.

    Il est indispensable, si tu utilises la même base, que tu changes le préfixe des tables lorsque tu installes le clone (et que sur un autre serveur tu utilises les paramètres de la nouvelle base de données et pas ceux de la base du site d'origine).

    Et quand tu restaures à partir de ce que l'hébergeur a sauvegardé, il faut que tu le fasses pour les fichiers ET pour la base de données.
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
    MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

    Commentaire


    • #3
      Merci Robert, je pensais au contraire qu'il fallait conserver le préfixe des tables car dans l'installateur de restauration de kickstart, la valeur des préfixes est remontée dans le champ "préfixe de table".

      Commentaire


      • #4
        Tu peux conserver le préfixe seulement si tu utilises une autre base de données, sur le même serveur ou un autre. Si tu utilises la même base et le même préfixe, tu modifies les données du premier site en même temps que celles du second.
        Et dans la page de restauration Akeeba concernant la base, tu peux modifier ce préfixe (e conservant le trait de soulignement terminal)
        "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
        MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

        Commentaire

        Annonce

        Réduire
        Aucune annonce pour le moment.

        Partenaire de l'association

        Réduire

        Hébergeur Web PlanetHoster
        Travaille ...
        X