[RÉGLÉ] Les liens internes du back office ne marchent pas.

[Slixis]

Bonjour,
J'ai demandé à mon hébergeur de déplacer un site Joomla d'un compte d'hébergement vers un autre compte d'hébergement. Les liens du front office fonctionnent très bien. Mais quand on se connecte au back office, aucun lien interne ne marchent. Vous cliquez sur n'importe quel lien, rien ne marche. On n'a pas accès aux articles, ni aux plugins. Rien.
Je précise qu'avant la migration sur un autre serveur, j'avais sauvegardé le site avec Akeeba. J'ai essayé de rétablir la sauvegarde, mais l'installation tournait en boucle avec l'erreur "Serveur introuvable".
Nous n'avions plus accès au back office, mais grâce à Cavo789 nous avons pu y accéder, sauf que les liens internes dans le back office ne fonctionnent pas.
Quelqu'un sait-il à quoi cela pourrait être dû?

Merci de votre assistance.

[RobertG]

Bonjour,

Je n'ai jamais rencontré ce type d'erreur, les liens étant tous de type relatif, et pas en dur, surtout dans l'administration.
Regarde dans les informations système, onglet "permission des dossiers" si tous sont modifiables (en principe, seul le fichier "configuration.php" peut être verrouillé, par sécurité).
Si tu constates que les dossiers logs et tmp ne le sont pas, c'est parce que le chemin physique vers les fichiers a changé avec le changement de serveur. Dans ce cas, tu peux utiliser un script type "whereami" qui te donnera le bon chemin, que tu pourras reporter à la main dans les deux onglets système et serveur. Tu peux aussi, après avoir modifié les droits du fichier de configuration en "644", utiliser MoovJla (voir ma signature) et simplement valider sans rien modifier toi-même.
Mais le fait que le site lui-même ne pose pas de problème me fait douter...

[Slixis]

Bonjour RoberG,
Merci pour ton intervention. Mais je ne peux aller nulle part sur le back office. Je ne peux pas aller dans les informations système.Aucun lien ne marche.
Autre précision: mon hébergeur pensait que c'était un problème de base de données qui devait être corrompue. Vu que j'ai la sauvegarde du site, je l'ai restauré en local. Tout marche très bien autant back office que front office. Ensuite nous avons importé la base de donnée sur le site défaillant. Mais le problème persistait.

[RobertG]

Vérifie les chemins de logs et tmp dans le fichier "configuration.php", puis teste avec MoovJla sans enregistrer, juste pour voir s'ils correspondent. Si c'est le cas, supprime MoovJla, sinon, valide pour corriger ces chemins.
As-tu essayé de voir avec un autre navigateur si le problème de l'administration se produit aussi ?

Au fait, as-tu redonné accès à l'administration au super utilisateur ou utilises-tu encore le script dont a parlé cavo789 ?

PS : que se passe-t-il au juste ? Que devient l'adresse dans la barre d'adresse du navigateur ? Change-t-elle selon le lien de menu ? Est-ce pareil depuis l'accueil de l'administration et les liens dans la colonne de gauche ?

[Slixis]

J'ai vérifié les chemins de logs et tmp dans le fichier "configuration.php" et j'ai testé avec MoovJla. Ils correspondent.
J'ai essayé avec un autre navigateur. Le problème persiste.
Pour me connecter j'utilise le script de Cavo789. Mais vu que le lien User ne fonctionne pas, je ne peux pas créer un nouvel utilisateur pour lui attribuer les droits de Super User.
PS: Quand je clique sur un menu, l'adresse sur la barre d'adresse change, mais la page ne s'affiche pas.
Exemple: Quand je clique sur Menus > Manage j'obtiens administrator/index.php?option=com_menus&view=menus
Quand je clique sur Users > Manage > Add New User j'obtiens: administrator/index.php?option=com_users&task=user.add

La barre d'adresse change, mais la page demandée ne s'affiche pas. Je reste toujours sur le tableau de bord (control Panel) de l'admin.

[RobertG]

Change manuellement les valeurs de ces deux paramètres dans le fichier configuration.php pour celles-ci :

public $debug = '1';
public $error_reporting = 'development';

Tu auras peut-être alors un message d'erreur ou des infos sur la cause du blocage.

[Slixis]

En modifiant ces valeurs, sur le back office rien ne bouge, aucun message d'erreur. Sur le front office du site, tout disparait. Il y a juste le message ci-dessous qui apparait:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 325971 bytes) in /home/public_html/plugins/system/debug/debug.php on line 1213

[RobertG]

Remets debug à "0", le débogage utilise trop de mémoire sur ce site.

J'aurais tendance à te conseiller de vider le serveur pour réinstaller la sauvegarde Akeeba qui fonctionne après restauration en local, mais je ne comprends pas cette erreur "Serveur introuvable" que tu as rencontrée. C'était à quel moment ? la décompression ou le lancement de la restauration ?

[Slixis]

J'ai mis la sauvegarde Akeeba dans le FTP ainsi que le fichier kickstart.php pour activer l'installation.
Quand je lance l'installation en saisissant www.monsite.com/kickstart.php les fichiers devraient se décompresser, mais il ne passe rien. Le loader mouline longtemps puis affiche serveur iintrouvable.

En test en local, avec la même procédure la sauvegarde est rétablie sans problème. J'ai testé sur un autre serveur du même hébergeur avec la même procédure. Cela marche.
Mais sur le compte actuel la sauvegarde ne marche pas. J'obtiens serveur introuvable en essayant de rétablir la sauvegarde.
C'est la première fois que cela m'arrive depuis plus de 10 ans que j'utilise joomla.

[RobertG]

Il y a une chose que tu peux tenter si ta sauvegarde est en zip et pas en jpa (ou en en refaisant une depuis le site local), c'est soit avec le gestionnaire de fichiers de ton hébergeur s'il le permet, soit avec un fichier unzip.php (par exemple https://gist.github.com/irazasyed/5870360) de décompresser.

Je ne vois pas quel serveur est recherché par kickstart.

PS : garde une copie du fichier configuration.php distant actuel ; puisque ta base est déjà existante, une fois la sauvegarde décompressée, renomme le dossier installation (tu le supprimeras plus tard, quand le site fonctionnera bien) et remplace le fichier de configuration par celui que tu as mis de côté.

[Slixis]

Oops, nos messages se sont croisés... Oui je peux tester ta méthode.
L'idée que j'avais, vu que la sauvegarde fonctionne en local. Vider le serveur comme tu me le recommandes. Ensuite j'importe manuellement la base de donnée et les fichiers du site en sauvegardant configuration.php

[RobertG]

Oui, tu peux faire ça, le risque étant que des fichiers s'altèrent pendant le transfert.
Tu peux aussi commencer par envoyer un pack complet (sauf le dossier "installation" et en faisant attention au template, si tu en utilises un standard que tu as modifié) de Joomla! de la même version que celle du site, au cas où justement ce serait des fichiers altérés.

[Slixis]

Je teste et je reviens vous dire ce qu'il en est. Merci RobertG.

[Slixis]

Re,
J'ai vidé le serveur j'ai uploadé les fichiers de la sauvegarde puis j'ai importé la base de donnée. Au départ j'ai obtenu la fameuse "Error: Impossible to connect to Mysql" que j'ai corrigé en uploadant configuration.php.
Mais le problème persistait (connexion avec le script de cavo789 et liens internes du back office qui ne fonctionnent pas).

Je me suis dit qu'il faut peut-être installé un joomla natif pour voir. Et là, impossible d'installer un joomla natif. Le site bloque sur la première page (voir lien: https://monsite.com/installation/index.php ). J'ai mis le nom du site, l'e-mail, l'identifiant, le mot de passe. Je clique sur suivant rien ne se passe.

En déduction: je dirais que le serveur n'est pas configuré pour fonctionner avec du joomla. C'est bête, mais je ne trouve rien d'autre comme explication.

[RobertG]

En effet ! Il n'y a que l'hébergeur qui peut régler ça. Quelles versions de PHP et de MySQL utilise ce serveur ?
Ce qui est curieux, c'est que la première page d'installation s'affiche, donc a priori compatibilité PHP OK, je pense, et j'imagine que le test de MySQL ou de PostgreSQL disponible se fait dans l'étape suivante.