J'ai été planté en modifiant un article depuis la console d'admin, et depuis
je ne peux plus accéder à cet article, ni en lecture ni depuis l'interface
d'administration : depuis l'admin ça rame et ça bloque sans rien afficher
qu'une page blanche, et depuis le site ça m'affiche l'emplacement du logo et
pouf plus rien, bloqué.
Je suppose que le plus simple serait de détruire manuellement l'article et
de le refaire, mais je ne sais pas quel(s) fichier(s) supprimer sans
risque...
le 6/12/01 18:46, Jean-Philippe HENRY à jean-philippe.henry@wanadoo.fr a
écrit :
Bonsoir à tous,
J'ai été planté en modifiant un article depuis la console d'admin, et depuis
je ne peux plus accéder à cet article, ni en lecture ni depuis l'interface
d'administration : depuis l'admin ça rame et ça bloque sans rien afficher
qu'une page blanche, et depuis le site ça m'affiche l'emplacement du logo et
pouf plus rien, bloqué.
Je suppose que le plus simple serait de détruire manuellement l'article et
de le refaire, mais je ne sais pas quel(s) fichier(s) supprimer sans
risque...
ce n'est pas un fichier, c'est un enregistrement dans ta base de donnée
A moins qu'il y ait un truc plus simple ??
accès direct à ta base par phpMyAdmin à installer dans un dossier à part de
ton site ? tu risques des problèmes de droits d'accès direct au dossier data
si tu as un site local miroir de ton site en ligne (avec apache/php/mysql
installés sur ta machine) tu peux tenter
- sauvegarde de ta base en ligne, il y a un bouton pour ça dans la barre des
outils de la partie privée
- rapatriement par ftp du fichier en résultant (dump qq chose) et
restauration de la base en local avec le même bouton
- ouverture de la base en local par phpMyAdmin (à placer dans un répertoire
actif du site local pour que le php fonctionne) et réparation par
suppression à la mano de l'enregistrement en cause,
- sauvegarde de la base locale propre par spip, retour de la base propre sur
ton site par ftp et restauration de la base propre en remplacement de la
base vérolée..
mais je vois tout de suite une difficulté : il n'y a peut-être pas une seule
table mySQL concernée, mais plusieurs : en fait c'est peut être même le
défaut de cohérence entre les tables à cause du plantage en cours de
rédaction qui cause les plantages ultérieurs. Lorsque l'on crée un article
il y a au moins la table spip_articles et la table spip_auteurs_articles
(qui croise les ID des auteurs et des articles) qui sont modifiées. Donc
regarder qu'il y a bien pour ton article ces deux enregistrements et si
ceux-ci sont corrects en comparant avec d'autres ne posant pas de problème.
À partir de là tu doit pouvoir tenter de réparer à la main, et sinon tu
détruit les enregistrements correspondant à ton article.
le 6/12/01 18:46, Jean-Philippe HENRY à jean-philippe.henry@wanadoo.fr a
écrit :
Bonsoir à tous,
J'ai été planté en modifiant un article depuis la console d'admin, et depuis
je ne peux plus accéder à cet article, ni en lecture ni depuis l'interface
d'administration : depuis l'admin ça rame et ça bloque sans rien afficher
qu'une page blanche, et depuis le site ça m'affiche l'emplacement du logo et
pouf plus rien, bloqué.
Je suppose que le plus simple serait de détruire manuellement l'article et
de le refaire, mais je ne sais pas quel(s) fichier(s) supprimer sans
risque...
ce n'est pas un fichier, c'est un enregistrement dans ta base de donnée
A moins qu'il y ait un truc plus simple ??
accès direct à ta base par phpMyAdmin à installer dans un dossier à part de
ton site ? tu risques des problèmes de droits d'accès direct au dossier data
si tu as un site local miroir de ton site en ligne (avec apache/php/mysql
installés sur ta machine) tu peux tenter
- sauvegarde de ta base en ligne, il y a un bouton pour ça dans la barre des
outils de la partie privée
- rapatriement par ftp du fichier en résultant (dump qq chose) et
restauration de la base en local avec le même bouton
- ouverture de la base en local par phpMyAdmin (à placer dans un répertoire
actif du site local pour que le php fonctionne) et réparation par
suppression à la mano de l'enregistrement en cause,
- sauvegarde de la base locale propre par spip, retour de la base propre sur
ton site par ftp et restauration de la base propre en remplacement de la
base vérolée..
mais je vois tout de suite une difficulté : il n'y a peut-être pas une seule
table mySQL concernée, mais plusieurs : en fait c'est peut être même le
défaut de cohérence entre les tables à cause du plantage en cours de
rédaction qui cause les plantages ultérieurs. Lorsque l'on crée un article
il y a au moins la table spip_articles et la table spip_auteurs_articles
(qui croise les ID des auteurs et des articles) qui sont modifiées. Donc
regarder qu'il y a bien pour ton article ces deux enregistrements et si
ceux-ci sont corrects en comparant avec d'autres ne posant pas de problème.
À partir de là tu doit pouvoir tenter de réparer à la main, et sinon tu
détruit les enregistrements correspondant à ton article.
ce n'est pas un fichier, c'est un enregistrement dans ta base de donnée
accès direct à ta base par phpMyAdmin à installer dans un dossier à part de
ton site ? tu risques des problèmes de droits d'accès direct au dossier data
Je signale à ce propos que pour les Spipeurs sur Multimania, il existe un
interface permettant d'accéder directement à sa base de donnée et de travailler
sur les tables et les enregistrements. C'est succint, mais on peut également y
entrer des requêtes SQL.
le 7/12/01 10:39, Jean-Philippe HENRY à jean-philippe.henry@wanadoo.fr a
écrit :
Merci Henri !
Je ne suis pas sûr de savoir faire tout ça mais bon ... ;-))
oh, c'est plus compliqué à dire qu'à faire
la récupération de la base sur ta machine est très simple il suffit de
suivre le mode d'emploi de SPIP qui est très clair (une petite merveille)
sa sauvegarde sur un site local aussi
