Bonjour,
lors de la modification d’articles ou ajout de balises dans une champ, je me heurte au fameux « Oups. Une erreur inattendue a empêché de soumettre le formulaire. » L’erreur n’est pas constante : je peux modifier certains articles, mais pas d’autres, ou certains champs, mais pas modifier le même champ sur d’autres articles. Et surtout, il est impossible d’ajouter des balises images ou média ou des formulaires formidable.
Spip en 4.4.2, tous les plugins à jour, désactivé et réactivé tous les plugins, PHP vérifié en diverses versions… J’ai aussi fouillé la littérature et les forums…
Le fichier de logs PHP annonce :
[Thu Feb 20 21:31:58.709111 2025] [authz_core:error] [pid 17629:tid 19612] [client 184.107.116.58:51788] AH01630: client denied by server configuration: adresse du site/tmp/.ok
Bref, je galère sérieusement pour trouver l’erreur et l’équipe peine à travailler sur les contenus du site web.
Il me semble que ce genre de message peut être causé par une configuration erronée du champ Adresse (URL) du site public éditable depuis ecrire/?exec=configurer_identite.
Les adresses depuis l’espace privé sont-elles raccord avec la valeur du champ ?
( protocole http:// ou https:// ? sous-domaine www. ou pas, …)
De manière sibylline, des règles de redirection peuvent garder inaperçu ce problème de configuration. La navigation classique fonctionne, mais la vérification de la signature des requêtes POST en ajax échoue.
J’ai bien essayé, mais l’activation des logs et des messages d’erreur avec mes_options.php dans le dossier config n’affecte en rien le résultat.
Lorsque je tente de modifier certains articles :
En partie privée :
Oups. Une erreur inattendue a empêché de soumettre le formulaire. Vous pouvez essayer à nouveau.
En partie publique (avec crayons) :
« Erreur de communication »
puis
« Forbidden
You don’t have permission to access this resource.
Additionnally, a 403 error was encountered while trying to use an ErrorDocument to handle the request »
Pourquoi je peux modifier certains articles sans problème, alors quel la moindre tentative de modification provoque une erreur sur d’autres articles ?
C’est une piste que j’ai trouvé super intéressante, mais malheureusement tout semble conforme et en accord.
Je n’arrive toujours pas à modifier certains articles : la moindre tentative de modification de texte ou du contenu engendre une erreur. Pour d’autres articles, tout va bien et il n’y a aucune erreur.
Il me semble que ce genre de message peut être causé par une configuration erronée du champ Adresse (URL) du site publicéditable depuis ecrire/?exec=configurer_identite.
Les adresses depuis l’espace privé sont-elles raccord avec la valeur du champ ?
( protocole http:// ou https:// ? sous-domaine www. ou pas, …)
De manière sibylline, des règles de redirection peuvent garder inaperçu ce problème de configuration. La navigation classique fonctionne, mais la vérification de la signature des requêtes POST en ajax échoue.
Voir le sujet ou répondre à cet e-mail pour répondre.
Peut-être songer à vérifier les (éventuelles) règles de redirections personnalisées dans le fichier .htaccess ; et les mettre en commentaires le temps des tests … ?
L’installation est-elle à la racine d’un vhost Apache ou dans un sous-dossier ?
j’ai déjà vu ça, il y avait des caractères spéciaux dans certain article qui ne passait pas : à vérifier l’encodage le la base
et aussi dans connect.php il faut utf8 à la fin
j’ai déjà vu ça, il y avait des caractères spéciaux dans certain article qui ne passait pas : à vérifier l’encodage le la base
et aussi dans connect.php il faut utf8 à la fin
J’ai fait des tests de ce côté et ça ne corrige pas le problème. J’ai temporairement désactivé le cache, et aussi vidé les autres et le fichier temp pour les essais.
J’ai toujours les messages d’erreur à vouloir modifier certains articles (et pas d’autres).
Peut-être songer à vérifier les (éventuelles) règles de redirections personnalisées dans le fichier .htaccess ; et les mettre en commentaires le temps des tests … ?
L’installation est-elle à la racine d’un vhost Apache ou dans un sous-dossier ?
Voir le sujet ou répondre à cet e-mail pour répondre.
Ça va logger les erreurs PHP dans un fichier dédié tmp/log/php.log, à côté des autres logs de SPIP.
Ça peut donner des pistes à suivre si tu y vois passer des choses (et dans ce cas, vient les copier/coller ici).
