Vous n'êtes pas identifié(e).
13 février 2024 Sortie de Dotclear 2.29
Bonjour,
lorsque je passe le flux atom de mon blog au validateur W3C, le validateur rapporte une recommandation (pas une erreur) :
Recommendations
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.line 8, column 91: Self reference doesn't match document location [help]
En effet, le flux est sur une adresse en https (https://casperlefantom.net/feed/atom) tandis que le flux indique une adresse en http :
<link href="http://casperlefantom.net/feed/atom" rel="self" type="application/atom+xml"/>
Dans l'interface d'admin, l'url du blog est pourtant en https (https://casperlefantom.net/). Donc c'est à la construction de l'adresse du flux que http est imposé par défaut.
J'ai donc lancé quelques grep à la volée...
$ grep -r atom+xml
themes/ductile/tpl/home.html: <link rel="alternate" type="application/atom+xml" title="Atom 1.0" href="{{tpl:BlogFeedURL type="atom"}}" />
BlogFeedURL ressort dans le flot de résultats.
$ grep -r BlogFeedURL
inc/public/class.dc.template.php: $this->addValue('BlogFeedURL',array($this,'BlogFeedURL'));
inc/public/class.dc.template.php: <!ELEMENT tpl:BlogFeedURL - O -- Blog Feed URL -->
inc/public/class.dc.template.php: <!ATTLIST tpl:BlogFeedURL
inc/public/class.dc.template.php: public function BlogFeedURL($attr)
Là par contre, il y a un fichier qui ressort, c'est inc/public/class.dc.template.php. Dans le fichier, on voit que l'url est basée sur le core :
<!ELEMENT tpl:BlogFeedURL - O -- Blog Feed URL -->
<!ATTLIST tpl:BlogFeedURL
type (rss2|atom) #IMPLIED -- feed type (default : rss2)
>
*/
public function BlogFeedURL($attr)
{
$type = !empty($attr['type']) ? $attr['type'] : 'atom';
if (!preg_match('#^(rss2|atom)$#',$type)) {
$type = 'atom';
}
$f = $this->getFilters($attr);
return '<?php echo '.sprintf($f,'$core->blog->url.$core->url->getURLFor("feed","'.$type.'")').'; ?>';
}
Et malheureusement c'est ici que la piste disparait, je n'ai rien trouvé de probant par la suite.
J'aimerais juste trouver la raison de cette url en http alors que l'adresse du blog est en https. Si quelqu'un pouvait m'aiguiller je lui en serais reconnaissant :-)
Hors ligne
Étrange, je viens de vérifier le mien (thème Berlin qui s'appuie sur le jeu de template dotty) et l'URL est correcte :
<link href="https://open-time.net/feed/atom" rel="self" type="application/atom+xml" />
Quant à la fonction BlogFeedURL(), elle utilise simplement $core->blog->url qui est utilisé partout dès qu'on a besoin de l'URL du blog et qui correspond à celle enregistrée dans les paramètres du blog.
Du coup je penche pour un thème qui incluerait son propre template de flux, ou un cache de template à reconstruire.
Dotclear addicted since 2004
Hors ligne
Suite…
En fait le template utilisé pour le flux utilise tpl:SysSelfURI qui utilise Clearbricks pour retrouver l'URL du flux et c'est peut-être là que ça coince.
Dotclear addicted since 2004
Hors ligne
Et Clearbricks s'appuie sur les globales $_SERVER['HTTPS'] et $_SERVER['SERVER_PORT'] pour récupérer les infos.
Tu peux me dire ce qu'elles contiennent dans ton contexte ?
Dotclear addicted since 2004
Hors ligne
Bonjour
Je ne parviens pas à reproduire ce bug : je viens d'installer et d'activer le thème ductile sur le blog de mon profil. L'url du flux qui est générée est bien sécurisée :
<link rel="alternate" type="application/atom+xml" title="Atom 1.0" href="https://www.dissitou.org/feed/atom" />
avec la même balise dans home.html
En revanche, par défaut, les étiquettes proposées dans la configuration du thème sont en http, mais je ne sais pas si ce n'est pas un reste d'installation de Ductile chez moi...
Quoi qu'il en soit, dans inc/public/class.dc.template.php on peut voir que l'URL générée par BlogFeedURL est à la base la même que celle de la balise BlogURL dans ce même fichier, qui commence par $core->blog->url, soit avec le protocole http(s) dedans.
Je ne vois donc pas ce qui peut clocher. Quelle est ta version de Dotclear ?
Hors ligne
Philippe le pb est dans le flux ATOM, pas dans le header d'une page du blog.
Quant aux URLs des étiquettes, y'a un blème en effet. Mais peut-être qu'un passage par la config du thème règle ça, sinon y'a un (autre) bug :-)
Dotclear addicted since 2004
Hors ligne
Et Clearbricks s'appuie sur les globales $_SERVER['HTTPS'] et $_SERVER['SERVER_PORT'] pour récupérer les infos.
Tu peux me dire ce qu'elles contiennent dans ton contexte ?
$_SERVER['HTTPS'] est vide
$_SERVER['SERVER_PORT'] renvoie 80
https://casperlefantom.net/contextes.php
Pour le 80, c'est peut-être dû à l'architecture :
- dc est dans un container docker apache-2.4.27 qui écoute sur le 80/tcp et n'a aucune config de virtualhost, et aucune config SSL. La seule config qu'il a, c'est pour php-fpm.
- container docker php-fpm
Vient se placer devant le reverse proxy squid, qui tape sur l'apache en http (car les deux sont sur la même machine). Squid sert le site en https sur un port quelconque.
Et vient se placer encore devant le reverse proxy caddy qui tape sur le squid en https (car les deux ne sont PAS sur la même machine) et sert le site sur le port standard https.
Dernière modification par C@sp€r (2018-05-10 08:58:34)
Hors ligne
Ouch ! Je ne viendrai pas te conseiller là-dessus :D
En revanche pour ton problème d'url, si tu remplaces l'url du flux dans ton fichier de template par
{{tpl:BlogURL}}feed/atom
ça devrait fonctionner
Hors ligne
Franck a écrit :Et Clearbricks s'appuie sur les globales $_SERVER['HTTPS'] et $_SERVER['SERVER_PORT'] pour récupérer les infos.
Tu peux me dire ce qu'elles contiennent dans ton contexte ?
$_SERVER['HTTPS'] est vide
$_SERVER['SERVER_PORT'] renvoie 80
https://casperlefantom.net/contextes.phpPour le 80, c'est peut-être dû à l'architecture :
- dc est dans un container docker apache-2.4.27 qui écoute sur le 80/tcp et n'a aucune config de virtualhost, et aucune config SSL. La seule config qu'il a, c'est pour php-fpm.
- container docker php-fpmVient se placer devant le reverse proxy squid, qui tape sur l'apache en http (car les deux sont sur la même machine). Squid sert le site en https sur un port quelconque.
Et vient se placer encore devant le reverse proxy caddy qui tape sur le squid en https (car les deux ne sont PAS sur la même machine) et sert le site sur le port standard https.
Ok donc CB ne voit que du HTTP vu les variables. Faudra que j'explore ça un peu plus, mais pas tout de suite, j'suis en balade (moto) et je serai de retour dans une dizaine de jours…
Dotclear addicted since 2004
Hors ligne
Vous n'êtes pas identifié(e).