Plantage de l'administration ?

**RobertG** · 05/10/2021, 07h17

Bonjour,

La restauration de la base, sauvegarde d'hier matin, n'a eu aucun effet. Le site étant chez OVH, j'ai demandé une restauration du serveur à J-1, mais ça traîne.
Alors j'ai voulu savoir si l'activation du débogage et le rapport d'erreurs au maximum m'apporteraient des informations. Miracle, ça a remis l'administration en route !
Après nouvel essai, il est indispensable que le débogage soit activé pour que l'administration fonctionne !

Tant que la restauration du serveur par OVH ne sera pas terminée, je suis bloqué dans mes recherches. Depuis un peu plus d'une heure, la tâche de restauration de snapshot est "planifiée"...

Si quelqu'un a une idée de la raison d'une telle anomalie au niveau du débogage, je suis preneur !

**RobertG** · 05/10/2021, 07h55

En complément : le débogage n'affiche strictement rien, mais côté site, la console affiche

Uncaught TypeError: PhpDebugBar.Widgets.InfoWidget is not a constructor

Et côté administration, en plus de ce message :

La ressource à l’adresse « https://w ww.*************.com/.../css/uikit.css » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff).
index.php
La ressource à l’adresse « https://w ww.*************.com/...t3/js/uikit.js » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff).
index.php
La ressource à l’adresse « https://w ww.*************.com/...uikit-icons.js » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff)

Je m'aperçois que le plus important peut-être dans ces erreurs UIkit, c'est la recherche des fichiers dans "nom_de_domaine/administrator/plugins"
Reste à trouver la cause de cette erreur de chemin...

**RobertG** · 05/10/2021, 09h18

Bien, en remplaçant JURI::base() dans le plugin UIkit par JURI::root(), les fichiers sont bien cherchés où il faut et l'erreur a disparu de la console.

Il teste celle de debugbar !

Curieusement, sur une copie locale du site, cette erreur debugbar n'apparaît pas !

**RobertG** · 05/10/2021, 10h33

Pour résumer :
- en ligne, le site fonctionne ; l'administration ne fonctionne que si le débogage est activé, mais lorsqu'il est activé, il y a cette erreur de widget debugbar ;
- en local, le site fonctionne, l'administration fonctionne que le débogage soit activé ou désactivé

La seule différence étant le fichier .htaccess (aeSecure en ligne, standard en local), j'ai désactivé puis fait quelques tests en supprimant tous les backups de ce fichier en ligne. Il n'y a que la désactivation d'aeSecure qui règle le problème. Je ne comprends vraiment pas ce qui peut s'être si brutalement passé pour que cela survienne.

**RobertG** · 06/10/2021, 07h48

Bonjour,

Suite et colère !
Alors que le site fonctionnait, il n'était plus nécessaire de restaurer le serveur OVH, d'autant qu'après plus de 4 heures, ça n'avait toujours pas démarré. L'assistance interrogée m'a répondu qu'une restauration prenait entre 12 et 72 heures : ne comptez donc pas sur cette fonctionnalité si vous devez rapidement remettre en route un site chez OVH !
A ma demande, puisqu'on ne peut pas le faire depuis le Manager, le technicien a bien voulu annuler cette restauration.
Quelques heures plus tard, le site renvoyait une erreur 500 alors que personne n'y avait touché depuis la fin de matinée... Première chose : je supprime le fichier .htaccess, bien qu'il n'ait pas généré d'erreur quelques heures plus tôt. Je mets un fichier pour seulement tester la version de PHP : erreur 500.
Je crée un nouveau dossier, j'y transfère ce fichier et le favicon, et je modifie le pointage du nom de domaine : toujours une erreur 500 !
J'ouvre un ticket en expliquant ce qui se passe et qu'il n'y a que ces deux fichiers dans le dossier, et je reçois une réponse issue d'une base de connaissance à propos des erreurs 500, sans aucun rapport avec la situation !
Qu'ont-ils fait malgré cette réponse ? Je l'ignore, mais vers 23 heures, l'erreur 500 avait disparu et j'ai pu restaurer le site ce matin.
Encore un mystère OVH !

**herve** · 28/02/2022, 14h20

Salut
Merci d'avoir évoqué la piste du htaccess
J'avai le même problème d'affichage et de gestion du backoffice seulement !
j'ai enlevé

Code:

## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip

# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

et tout fonctionne bien

Seul truc contrariant, je n'ai pas compris purquoi, j'ai plusieurs sites qui ont à priori la même configuration (et je n'ai pas modifié qq chose chez l'hébergeur) et pourquoi celui là?

Plantage de l'administration ?

[RÉGLÉ] Plantage de l'administration ?

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association