J’ai l’habitude de référencer des pages Viméo comme documents joints. De manière très usuelle, dans un article, «Joindre document», onglet «Sur l’internet», je colle par exemple: https://vimeo.com/304775757
et hop, ça me met la page en tant que document distant joint à l’article, avec le titre récupéré.
Sauf que depuis quelques jours, ça ne fonctionne plus.
- En local sur ma bécane, ça fonctionne.
- Sur un serveur Web en ligne, ça déconne, le document n’est «pas trouvé»:
Je suis allé jouer avec inc/distant.php, mais je n’arrive pas à trouver où ça foire avec Viméo (avec Youtube, par exemple, pas de problème).
Il me semble qu’on arrive à récupérer le contenu de la page, et on se retrouve à la ligne 447 avec:
} elseif ($res) {
$result['page'] = &$res;
$result['length'] = strlen($result['page']);
}
Là j’ai quelque chose que je ne comprends pas: on renseigne le $result[‘page’], mais on laisse $result[‘status’] à 0. Du coup, dans recuperer_page, un résultat obtenu de cette façon là est jeté avec le test sur status!==200 de la ligne 625:
if ($res['status'] !== 200) {
return false;
}
J'ai eu exactement le même problème en début de semaine (voir mon message du 17/12)
- en local aucun problème
- sur le web, impossible d'ajouter les vidéos de vimeo en document distant
Le patch que tu proposes fonctionne bien.
Cela permet de rétablir la fonction et d'ajouter la vidéo en tant que document distant (il manque juste encore la vignette de prévisualisation de la video)
Euh ya oembed pour ça, beaucoup plus fiable à priori, et fonctionnant
sur plein de fournisseurs, que ce soit direct dans les contenus ET comme
décrit ici en tant que document distant. Ça reste quand même la
procédure à conseiller quand on veut ajouter une vidéo (ou autre)
distante en tant que document joint, à mon avis.
Il y a deux difficultés (pour ce que j’en vois) avec mon patch:
- ça n’identifie pas où est le problème avec Viméo, et pourquoi ça fait que SPIP passe désormais par la procédure de «secours» de inc/distant pour récupérer le contenu. Or c’est pas super-viable de patcher à un endroit si on n’identifie pas pourquoi tout d’un coup on a changé de comportement.
- autant pour status=200, ça me semble logique, autant forcer le content-type à text/html, je suis beaucoup moins sûr. Si on récupère d’autres types de documents via cette fonction, que se passe-t-il? Comment le mime-type est-il identifié?
Euh, justement, c'est en combinaison avec Oembed que c'est merveilleux.
Quel plugin prend en charge quelle partie du processus ?
Ce qui m'intéresse c'est qu'en ajoutant un lien Vimeo comme document
j'obtiens une entrée dans la médiathèque avec son Image de
prévisualisation comme Vignette et son titre de chez Vimeodans le champ #TITRE du document. Après c'est évidemment oembed qui se charge
d'afficher le player.
AH ! le problème de départ ça serait pas qu’ils ont activé TLS 1.2 (ou plutôt désactivé les vieux SSL/TLS) et du coup ça marche ou pas :
* selon que ton php est suffisament récent et supporte TLS 1.2
* selon que tu as ou non le patch https://core.spip.net/projects/spip/repository/revisions/24018
du coup le bug sur TLS fait foirer et ensuite ça passe par la procédure de secours qui elle même est bancale et ne peuple pas le status ni le mime type, et enfin oembed utiliser le vieux recupérer_page qui renvoit false dès qu’on a pas le status 200
(pas mal de choses à patcher séparemment les unes des autres donc)
Mais je suis d’accord qu’on ne peut pas renseigner arbitrairement le Content-Type ici : dans ce cas on a pas les en-têtes, on ne sait pas ce qu’on récupère, et c’est à l’appelant de se débrouiller avec si il sait à quoi s’attendre ou non - ce qui donc ne réparera pas le document distant dans ton cas…
A defaut on pourrait faire une fonction de détection du type de contenu, qui repère a minima html, xml, json et éventuellement utilise l’extension de l’URL, mais est-ce que ça en vaut vraiment la peine ?
