Changer d'hébergeur et passer en https - un tuto ?

[ghazal]

Hello de nouveau,
j'ai assisté un utilisateur du forum qui venait de changer d'hébergeur tout en passant en https et qui a fait toutes les erreurs possibles concevables.
J'ai cherché sur KB un tuto sur ce type de cas, mais je n'ai rien trouvé.
Cela dit, je suis peut-être blonde.
Cependant, il faudrait peut-être faire un tuto sur le sujet.

Je vais qd même décrire le cas, un modèle du genre.

- Avant de changer d'hébergeur
* pas de mises à jour des extensions
* une tripotée d'extensions qu'il n'utilisait plus, désactivées
* des extensions qui faisaient double emploi, genre 2 composants SEO
* on a qd même réussi un truc, joomla était à jour
* résultat des courses, un site à +400 mb - beaucoup d'images, mais je n'ai pas osé regardé leur poids - lol

Je me demande encore comment le site est passé, il avait juste une petite erreur JS.

Je lui ai dit de commencer par désinstaller les extensions désactivées. Erreur !
Site down.
Evidemment pas de sauvegarde Akeeba. Je ne suis pas sure que Akeeba aurait pu fonctionner dans ces conditions.

Heureusement, il savait au moins modifier configuration.php

* donc site en maintenance

Actions
* activation du debug dev, ça peut toujours servir
$error_reporting à development

* après vérification

public $live_site = ' ';

était encore en http
Boooon. Encore un truc à recommander de vérifier.

* désactivation de .htaccess, généré par aesecure, pour voir

* l'erreur de départ indiquée après le site tombe en rade concernait le dossier Akeeba /fof30/ dans /libraries/
donc écrasement de ce dossier en le remplaçant par un nouveau /fof30/ téléchargé du site Akeeba

A partir de ce moment-là, on a de nouveau accès au site, back and front.

Akeeba ne fonctionne pas.
Je lui dis de désintaller, réinstaller Akeeba.

Mais mon support s'arrête là.

Si ce post pouvait nous servir à lister et limiter les erreurs dans ce genre de cas, et bien, tant mieux.

On pourrait probablement découpler les 2 approches:
* changement d'hébergeur
* passer en https

Voili, voilou

PS : pas un remerciement du gars. Rien . Mais ça, on connait tous.

[electrocity]

J'ai aussi eu des cas similaires.
Souvent les sites auto gérés ont se problème par méconnaissance ou manque de motivation.
Installation de plein de modules et plugins mais jamais désinstallé par peur d'erreur ou ne savent pas comment désinstallé proprement.
Pour la configuration, idem, quand çà fonctionne, on n'y touche plus puis 6 mois plus tard, on ne sais plus comment modifier.
Je vous dit pas le CSS et les javascript, souvent c'est pire ! Plein de teste de rajout de regle et de petit script, mais jamais on en supprime à la fin,1Mo de plus à chargé pour rien(dans le meilleur des cas).
Pour moi, le sujet n'est pas changé d’hébergeur ou en https mais être rigoureux surtout lorsqu'on utilise des tutos et des forums pour faire son site. Car 6 mois après, on ne sais plus ce qu'on à fait.

[RobertG]

Bonjour,

Sauf adresses en dur, le changement d'hébergeur devrait être on ne peut plus simple si ce n'est pas une ancienne version de Joomla! (et encore).
Le plus simple est la sauvegarde/restauration par Akeeba, ou même (mais je n'aime pas) l'outil de transfert de site inclus dans Akeeba backup. J'imagine que sur le site d'origine, Akeeba devait déjà avoir des soucis.

Personnellement, je n'ai jamais renseigné la variable "live_site" sur les sites dont je me suis occupé...

En effet, il ne faut jamais conserver le .htaccess d'origine (sauf changement de serveur chez le même hébergeur), surtout s'il y a des instructions créées par aeSecure ou un autre système de protection qui inclurait des adresses précises (comme pour tmp et logs dans la configuration).

Autre point : si le site était déjà en https, il faut le désactiver dans la configuration et recréer un certificat tenant compte de ce changement de serveur. Akeeba lors de la restauration propose d'ailleurs par défaut de revenir au htaccess d'origine et permet de désactiver le https.

Il est étonnant que la désinstallation d'une extension déjà désactivée puisse mettre le site HS. Peut-être un plugin résiduel de cette extension n'a-t-il pas été désactivé ni désinstallé dans l'opération ?

Toutes les manipulations concernant les extensions auraient pu (dû) être faites avant, et sauf changement de version de PHP d'une vieille 5.3 vers une 7.x, le site devrait alors fonctionner dès ces manipulations faites : htaccess de base, http en attendant le certificat SSL, correction du fichier de configuration (par Akeeba, à la main ou avec MoovJla).
Je fais souvent ce type de manips pour cloner des sites de production vers mon serveur, afin d'y tester des modifications, ceci sans incident.

Utilisant la version pro d'Akeeba backup, je dispose dans kickstart Pro d'une fonction très pratique : la récupération à distance par http des sauvegardes, qui n'a donc pas à passer par mon PC avant de repartir, au ralenti, vers le nouveau serveur...

[ghazal]

Merci à tous les deux.
L'idée de ce post est justement de rassembler toutes nos pratiques et nos expériences et d'en faire un tuto complet (en tous les cas le plus complet possible) et point par point sur KB, qui nous permettrait ainsi de rediriger les propriétaires/gestionnaires de site ayant des soucis ou pas, d'ailleurs, vers un tableau des procédures à suivre.

Personnellement, je n'ai jamais renseigné la variable "live_site" sur les sites dont je me suis occupé...

Pff .. cette variable ne m'a causée que des soucis en cas de refonte de site, par exemple.
Mais, en vérifiant ce matin, j'ai réalisé que c'est encore courant comme recommandation dans les forums et autres site concernant joomla.

Je ne sais pas qui contribue encore à KB. Je sais que @manu93 et @garstud y ont participé. Ce serait dommage que ce projet soit laissé de côté.
Sous une autre forme, c'est une alternative conséquente et plus récente à help.joomla.fr, dont la suppression (du noyau de joomla) mal préparée a causé la panique sur les sites français lors de la dernière mise à jour (3.9.7).

[crapouille63]

Hello,

Modeste contribution pour le point changement d'hébergeur + Akeeba
>> attention à la version de php activée + version de Akeeba ayant servi à faire le backup + version Joomla de la sauvegarde.

Dans un cas, j'ai dû faire une régression de version php pour pouvoir relancer la réinstallation d'une sauvegarde faite à partir d'un Akeeba et d'un joomla moins récents.
Autre astuce: je me suis sortie de situations épineuses en désactivant les composants et plugins additionnels via base de données

NB: Certains hébergeurs sont "complexes" pour la version de php site par site, si on en a plusieurs sur un même hébergement (genre OVH ou Amen: pas user friendly du tout du tout pour les noobs dans mon genre.. ou fausse brune peut-être?)

Sinon, j'aurais à préconiser de faire les choses en 2 temps.
C'est mieux pour tracker la source d'un problème :-p

D'abord migrer le site et vérifier que tout fonctionne bien dans son protocole http
Ensuite seulement passer à la mise en place de https://
Là je n'ai pas encore d'expérience désolée, sauf celle-ci >> je vois très souvent des sites devenus inaccessibles à cause du certificat https devenu obsolète / invalide (message erreur rendu par le navigateur).
Par conséquent si le https n'est pas d'un vital extrême, ma politique actuelle est de ne pas le mettre en place si je n'ai pas le temps ni les ressources pour le suivre.
Ce qui n'empêche pas du tout une très bonne indexation des sites à l'heure actuelle, contrairement à ce que Google veut nous inculquer.

Je gère le SEO de plusieurs sites qui sont tous en 1ère page sur les requêtes cœur de métier les concernant (hors secteurs hyper concurrencés par l'achat de mots clés genre assurance ou immobilier)