Vous n'êtes pas identifié(e).
13 février 2024 Sortie de Dotclear 2.29
Bonjour,
Comme indiqué dans un autre post, j'ai installé avec succès un Dotclear 2.14.3 à partir de l'image Docker préparée par darkano - https://github.com/darknao/docker-dotclear
Hier, j'avais immédiatement accepté l'upgrade vers 2.15.3 puis restauré le contenu de mon blog en provenance de GandiBlog, et c'est à ce moment que je me suis rendu compte que dans l'interface d'admin, dès que je voulais éditer un billet ou un commentaire, je recevais le message "Erreur : Ce billet n'existe pas."...
Je me suis dit que c'était peut-être causé par ma bidouille d'import, donc aujourd'hui, je viens de repartir de zéro :
- drop de la base de données et effacement de mon container Docker
- nouvelle création d'une DB vierge
- nouvelle création d'un container Docker
- initialisation et configuration du blog via l'assistant de Dotclear
Là, je parcours immédiatement l'installation par défaut et c'est idem :
Page d'admin (OK) :
https://www.screencast.com/t/OqacsolT
Click sur "Billets" à gauche (OK) :
https://www.screencast.com/t/q656NLGjzHu
Click sur le billet "Bienvenue sur Dotclear !" (pas OK) :
https://www.screencast.com/t/WcRcfNT9e
:-(
C'est étrange parce que le billet existe bien : si on clique sur la flèche à gauche du nom du billet, la prévisualisation qui s'ouvre est OK :
https://www.screencast.com/t/Tbe3bfRtdVY
Idem si je visite le blog, le billet préinstallé est visible :
https://www.screencast.com/t/uLZOOjQe
En fait, il n'y a que l'édition qui est impossible :-(
Et j'ai donc le même comportement quand je vais sur "Commentaires" à gauche et que je clique sur le commentaire de démo de l'équipe Dotclear ("Erreur : Aucun commentaire") ou quand je vais sous "Pages" à gauche et que je clique sur "Ma première page" ("Erreur : Cette page n'existe pas.")
Une idée de la cause ?
Merci,
Vicne
Dernière modification par Vicne (2020-01-25 13:52:55)
Hors ligne
Bonjour. Je n'ai pas la solution, mais cette erreur est levée par dotclear/admin/post.php dans cette portion de code
if (!empty($_REQUEST['id'])) {
$page_title = __('Edit entry');
$params['post_id'] = $_REQUEST['id'];
$post = $core->blog->getPosts($params);
if ($post->isEmpty()) {
$core->error->add(__('This entry does not exist.'));Dans la page d'édition du billet, l'url contient-elle l'id du billet et cet id existe-t-il dans la base de données ? En effet, normalement tu devrais avoir une URL de type :
https://domain.tld/dotclear/admin/post.php?id=xxx (xxx est le numéro d'id du billet)
Ce numéro est-il présent dans l'URL et est-ce le bon ?
Edit : accessoirement il nous faudrait un peu plus de détails sur ton installation : url même locale, version de php, type de base de données...
Hors ligne
Hello Philippe,
Merci pour ta réponse.
Si j'ai le temps demain, j'essayerai de modifier le fichier admin/post.php (merci pour le pointeur) pour essayer de comprendre ce qui coince (parsing du dictionnaire $params ou accès à $core ou erreur lors de l'appel de getPosts()...)
Sinon, je vais essayer de répondre avec tous les détails :
Je suis sur mon réseau local pour le moment. Le serveur tourne sur http://192.168.0.48:8880
La liste des billets est donc sur http://192.168.0.48:8880/admin/posts.php et quand je clique sur le titre du billet d'exemple "Bienvenue sur Dotclear!", l'url de la page d'édition du billet qui est appelée est http://192.168.0.48:8880/admin/post.php?id=1 (ça colle donc).
Dans la DB, si je fais un "select post_id, post_title from dc_post", il retourne bien deux lignes :
1 | Bienvenue sur Dotclear !
2 | Ma première page
L'identifiant 1 correspond donc bien au premier billet, l'URL me semble correct.
Plus de détails sur l'installation :
C'est donc une image docker de dotclear 2.14.3 - https://github.com/darknao/docker-dotclear que j'ai déployée sur un NAS Synology DS1812+
La base de données est une MariaDB (fork de MySql) version 5 hébergée sur le même NAS.
phpversion() retourne 7.2.11
L'installation est "out of the box", j'ai juste créé la DB, déployé l'image et lancé l'assistant Dotclear auquel j'ai donné les coordonnées de la DB.
L'assistant a créé sans erreur toutes les tables (et y a injecté le premier billet, le premier commentaire et la première page de démo), et a créé le fichier de config php.
L'interface d'administration a l'air de fonctionner en tous points, y compris la prévisualisation, seule l'édition (d'un billet, d'un commentaire ou d'une page) renvoie un message d'erreur.
Le blog lui-même (hors interface d'admin) a l'air de fonctionner et le billet de démo y est visible.
Est-ce que ça éclaire un peu la situation ?
Merci,
Vicne
Hors ligne
Merci pour les précisions. Si l'url d'édition du billet est http://192.168.0.48:8880/admin/post.php?id=1 et que cet identifiant correspond bien au billet installé par défaut, voilà ma première piste qui s'évapore ;)
Deuxième piste : le plugin related est-il installé, et si oui peux-tu le désactiver ? D'une manière plus générale, essaie de désactiver tous les plugins qui ne sont pas installés par défaut par dotclear.
Mais si l'installation est neuve, sans plugins ajoutés, je ne vois pas ce qui peut clocher. Je signale ce fil aux autres modérateurs, quelqu'un aura peut-être plus d'idées que moi.
Hors ligne
PS
Merci pour les précisions. Si l'url d'édition du billet est http://192.168.0.48:8880/admin/post.php?id=1
Pour tester plus avant, dans la console du navigateur, il est possible de voir les paramètres qui sont passés dans la requête sur l'url admin/post.php?id=1. La chaîne de requête passée dans la superglobale $_GET doit contenir la paire de clés-valeurs id : 1
Sinon post.php ne trouve pas $_REQUEST['id'] et renvoie le message "Erreur : Ce billet n'existe pas." car l'id du billet n'est pas passé en paramètre.
Ci-dessous les en-têtes de la requête HTTP pour post.php?id=70 chez moi :
GET /dotclear/admin/post.php?id=70 HTTP/1.1
Host: www.dissitou.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: fr,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://www.dissitou.org/
Connection: keep-alive
Cookie: dcxd=791bf377f84c7f69b24596fb0f49179e11c6a064
Upgrade-Insecure-Requests: 1Hors ligne
Bonjour,
Merci pour les recommandations, je viens de refaire quelques essais :
Deuxième piste : le plugin related est-il installé, et si oui peux-tu le désactiver ? D'une manière plus générale, essaie de désactiver tous les plugins qui ne sont pas installés par défaut par dotclear.
Je n'ai pas installé manuellement de plugin, et je ne vois pas "related", mais sous la section "Plugin", il y a 5 entrées (peut-être pré-intégrés dans l'image Docker ?).
Il s'agit de Antispam, Import/Export et Maintenance (sur lesquels je n'ai pas vu d'option de désactivation) ainsi que dcCKEditor et dcLegacyEditor, que j'ai désactivés et...
MIRACLE, l'éditeur fonctionne ! :-) Billets, commentaires, pages, tout est OK.
Pour connaître le coupable, j'ai réactivé dcLegacyEditor (et ça fonctionne toujours) puis dcCKEditor (et ça fonctionne toujours !!!).
Pour en avoir le coeur net, j'ai fait un arrêt et redémarrage du container, et les symptômes reviennent.
Malheureusement, cette fois, j'ai retenté le même coup (un plugin après l'autre)... et c'est de nouveau en drapeau :-(
Impossible de revenir à la situation fonctionnelle... plugins désactivés, plugins activés, container redémarré, nouveaux cycle... rien.
Bon, voyons le bon côté, on avance :-)
Merci déjà pour ça, je continue avec les tests suggérés dans ton message suivant.
Vicne
Hors ligne
Pour tester plus avant, dans la console du navigateur, il est possible de voir les paramètres qui sont passés dans la requête sur l'url admin/post.php?id=1. La chaîne de requête passée dans la superglobale $_GET doit contenir la paire de clés-valeurs id : 1
Tout à l'air OK côté navigateur. Voici les détails de la console Chrome pour l'url post.php?id=1 : https://www.screencast.com/t/npaUGpCD
J'ai l'impression que c'est l'appel suivant qui coince :
$core->blog->getPosts($params);Je vais essayer ajouter du debug dans la page post.php pour voir où ça coince... si tu as un conseil ou l'autre, n'hésite pas...
[Edit]
J'ai ajouté une ligne de debug comme suit :
# Get entry informations
if (!empty($_REQUEST['id'])) {
$page_title = __('Edit entry');
# DEBUG
$core->error->add($_REQUEST['id']);
$params['post_id'] = $_REQUEST['id'];
$post = $core->blog->getPosts($params);Et le résultat est :
Erreurs :
- LwfZ1v5VQPYUkC6K6N01592
- Ce billet n'existe pas.!!
Donc quelque chose remplace l'id numérique (1) par une clé alphanumérique (LwfZ1v5VQPYUkC6K6N01592) dans le traitement des paramètres.
Alors bien sûr, ce billet n'existe pas...
----
Test suivant :
J'ai remplacé la ligne de debug ci-dessus par le code:
#DEBUG
foreach ($_REQUEST as $key => $value){
$core->error->add($key . " = " . $value);
}Résultat :
Erreurs :
- id = LwfZ1v5VQPYUkC6K6N01592
- dcxd = 89f9dde61ef04cf9db3b232af6371c215661765d
- stay_login = 0
- smid = 6lZWZN2CkFGwfZrGbkhptiHFWwtPnXdwSdXDgCyqDVnN5ofrOG4hgUa_DtRZ6o7bGtR4dSIFIeMq1ofUY1jBMg
- Ce billet n'existe pas.Bon, donc on retrouve tous les cookies du screenshot plus haut et (je ne l'avais pas vu tout à l'heure), un des cookies s'appelle "id" et a une valeur "LwfZ1v5VQPYUkC6K6N01592"
Je n'ai aucune idée de ce qui ajoute ce cookie "id" (dotclear ? plugin ? docker ? ) mais c'est assez surprenant.
Bizarre aussi que le cookie soit prioritaire sur le paramètre en query string...
Une idée ?
A+
Vicne
Dernière modification par Vicne (2020-01-24 20:29:38)
Hors ligne
Encore moi...
Bon, après recherches, la priorité donnée aux différentes sources pour la variable $_REQUEST est gérée par PHP en suivant le paramètre "request_order" du fichier php.ini.
Dans mon container, d'après mon fichier /usr/local/etc/php/php.ini-production , "request_order" vaut "GP". Autrement dit, PHP devrait remplir $_REQUEST d'abord avec les paramètres GET, et ensuite avec les paramètres POST, et les cookies ne devraient pas y être...
Et d'après la documentation, c'est la volonté par défaut de ne pas inclure les cookies.
Alors pourquoi les cookies y sont-ils quand même ? Aucune idée...
Bon, je commence à me demander si utiliser Docker était une bonne idée... :-/
Vicne
Hors ligne
Bon, ben désolé de monopoliser le sujet.
Je viens de faire un essai avec une installation directement sur le Synology, et ça fonctionne parfaitement.
On a toujours les mêmes cookies dans l'échange HTTP:
https://www.screencast.com/t/1qA7RS0pwXiP
Mais ici le paramètre "id" de la requête prend la priorité sur le cookie dans la variable $_REQUEST, et tout se passe bien.
Bon une installation locale, c'est moins portable qu'un container Docker, mais finalement pour un jeu de fichiers statiques, Docker est peut-être un marteau pour écraser des mouches...
Cela dit, je ne comprends pas où est le problème dans le cas de Docker. En théorie, à part la redirection de port, ça devrait être transparent. Je ne comprends pas comment l'ID en paramètre est perdu et remplacé par l'ID provenant des cookies.
Et ce qui est surréaliste, c'est que pendant quelques secondes ça a fonctionné en jouant avec les plugins (je découvre maintenant que les 5 inclus dans l'image Docker sont tout à fait standards) puis de nouveau plus après un redémarrage...
J'en ai profité pour upgrader le dotclear dans le container Docker vers la dernière version (2.15.3), et il partage bien la DB avec l'installation locale, mais le comportement d'erreur persiste.
Bon, si quelqu'un a une idée, je suis prêt à tenter toute proposition.
Je vais aussi tenter de contacter l'auteur de l'image Docker pour voir s'il a une piste.
Sinon, je crois que je resterai sur une installation locale...
Merci,
Vicne
Hors ligne
Intéressant ce problème avec Docker ; va falloir que je teste ça tranquillement …
Merci pour les investigations Vicne !
Stay tuned…
Dotclear addicted since 2004
Hors ligne
Hello,
Problème résolu :-)
tl;dr;
La config php dans l'image Docker laissait la priorité au cookie, et le cookie "id" de l'interface Synology prenait la priorité sur le paramètre "id" de la requête. L'auteur de l'image a fixé le problème en un temps record - Merci darknao :-)
En détail:
J'y étais presque. J'avais trouvé la variable de config php à changer mais :
- n'étant pas un pro du PHP, je pensais que l'installation était configurée quelque part pour utiliser "/usr/local/etc/php/php.ini-production" au lieu de "php.ini", mais en fait le fichier php.ini-production n'est qu'un modèle qu'il faut renommer (ou recopier) en php.ini pour qu'il soit pris en considération. L'image tournait donc sans php.ini, càd avec les paramètres par défaut dans lesquels les cookies sont plus prioritaires que les paramètres
- je n'avais pas compris ce qui créait ces cookies, mais darknao a déterminé qu'ils étaient mis par l'interface web d'administration du NAS Synology (DSM). Du coup, comme dotclear et le DSM tournaient sur la même machine (juste sur des ports différents), les cookies étaient partagés entre dotclear et DSM.
Note : la seule raison pour laquelle ça a fonctionné un moment n'avait rien à voir avec les plugins, mais simplement avec le fait que j'avais fait ce test avant de lancer le DSM. Le cookie "id" était donc absent, et le paramètre de l'URL passait. Puis j'ai voulu relancer le container Docker et j'ai donc dû passer par le DSM, ce qui a créé le cookie, et dès lors le paramètre id était "masqué".
Bref, l'image est désormais plus sûre (il n'est pas conseillé de donner priorité aux cookies pour des raisons de sécurité), et d'autre part, on pourrait se demander si dotclear ne pourrait pas utiliser la variable $_GET plutôt que $_REQUEST, ce qui rendrait impossible les éventuels conflits de paramètres dans le même genre.
Quoi qu'il en soit. Problème résolu.
Merci à Philippe et Franck et bonne journée à tous.
Vicne
Dernière modification par Vicne (2020-01-25 21:20:17)
Hors ligne
GET à la place de REQUEST, ça réduit le champ vu que REQUEST inclut aussi COOKIE et POST ; je regarderai tout de même…
cela dit, utiliser un cookie de nom "id", aussi peu explicite (ou aussi générique), n'est probablement pas une bonne idée de la part de DSM
Merci pour les détails Vicne !
Dotclear addicted since 2004
Hors ligne
Vous n'êtes pas identifié(e).