[WIP] Toujours pointer vers #FICHIER quand on attend à coup sûr un fichier physique #26

Corrige le ticket #4645.

J'ai corrigé pour ce qui est de l'admin, et ça marche alors dans tous les cas.

Cependant j'ai en questionnement pour tous les modèles qui valent partout, et qui sont tous pétés en fait quand on décide d'avoir des pages HTML de présentation des documents.

Ce n'est pas du tout une histoire d'admin vs public.

Car dès lors qu'on a des vraies pages HTML pour les documents (et le plugin prévoit lui-même le cas, en fournissant un exemple dans squelettes/ à la racine !) et bien toutes les insertions seront pétées puisque scr=#URL_DOCUMENT ou data=#URL_DOCUMENT ne voudront plus RIEN dire.

Ce sont seulement certains liens, certains href, qui doivent contenir #URL_DOCUMENT, et dans ce cas soit ça pointera sur le document lui-même (cas par défaut), soit une page de présentation du document (cas déclarable facilement). Mais dans la majorité des cas, que ce soit les insertions directes (src, etc) ou des liens explicitment vers une image pour afficher en box, etc, ça DOIT être le fichier physique en étant certain, sans que ça puisse jamais être une page HTML.

Du coup je fais un deuxième commit pour tous les modèles ?

D'accord sur le principe :)

et le plugin prévoit lui-même le cas, en fournissant un exemple dans squelettes/ à la racine !

Si tu parles bien de ce squelettes https://git.spip.net/spip/medias/src/branch/master/squelettes/document.html il n'est pas fonctionnel du tout (ça semble être un reliquat de Z) et le log de commit qui l'introduisait indique [en cours] merge avec le plugin mediatheque (les documents ne sont plus fonctionnels en l'etat, ne pas mettre a jour dans cette version hors contexte developpement).

@b_b le log de commit que tu pointes n'a pas de rapport avec ce fichier en particulier, c'est un énorme commit avec mille intégrations qui déplace dans le plugin-dist tout ce qu'il y avait dans mediatheque, et ce log dit juste que ce déplacement n'était pas fini, que c'était WIP.

Mais ce squelette est parfaitement fonctionnel, dès lors qu'on décide que l'objet document a des vraies pages publiques (page=document dans la déclaration + en revenant à la génération par défaut plutôt que la surcharge de medias).

Au pire on peut déjà intégrer ces modifs dans l'admin, et voir les modèles plus tard mais c'est un entre-deux pété : si on décide d'avoir des pages HTML pour les documents, la plupart des modèles d'insertion sont totalement cassés. Et vu que tout objet SPIP a le droit d'avoir une page déclaré (même si c'est pas le cas par défaut), on va pas demander à surcharger 100% des modèles et alors ne plus profiter des mises à jour, si on veut avoir des pages.

Mais ce squelette est parfaitement fonctionnel

Je me répète, mais il n'est fonctionnel qu'en Z si je ne me trompe pas cf son contenu <INCLURE{fond=structure} :)

Ah ça oui, c'est un squelette pour Z bien sûr, donné comme exemple d'utilisation, mais il n'est pas "pas fonctionnel du tout". Dans mon tout premier message, peu importe le type de squelettes, je montrais en disant ça que le fait d'avoir des vraies pages HTML pour cet objet était une chose possible et prévue quoi, pas un hack dont il ne faudrait pas s'occuper.

On en est où avec cette PR ?

Toujours la même question : il me semble plus complet de modifier aussi tous les modèles pour s'assurer que quand on attend l'URL du fichier ça doit bien toujours l'URL du fichier, et jamais une page HTML quand on décide que cet objet a une page.

Je pense que le choix d'utiliser #URL_DOCUMENT est lié à la fonction de protection des accès au documents.

Si on met un #FICHIER dans les modèles media, tous les documents protégés se retrouvent non accessible car le modèle contient un simple chemin vers un nom de fichier qui est protégé par un htaccess.

Alors que #URL_DOCUMENT contient normalement une url vers action avec une cle d'accès si on a le droit.

Cela dit il doit aussi être possible de gérer ça via la balise #FICHIER sauf qu'alors on aura plus au aucun moyen de distinguer le cas où l'on veut le chemin du fichier et le cas où l'on veut une URL vers le fichier.

Du coup je pense qu'il serait plus sain d'ajouter une balise #URL_FICHIER (ou #FICHIER_URL pour éviter toute collision avec un objet editorial fichier ?) qui donnerait l'url pour accéder au fichier du document concerné (par défaut le path vers le dit fichier, mais éventuellement une url chargée de la protection de l'accès).

Cela permettrait de se tirer d'affaire dans le cas où le document a une page avec une url propre (#URL_DOCUMENT faisant alors le job) et de continuer à avoir accès au path du #FICHIER dans tous les cas

Ça a l'air une très bonne idée !

#FICHIER c'est vraiment le chemin brut
#FICHIER_URL c'est l'URL d'accès au fichier (direct ou protégé suivant la config et plugins)
et #URL_DOCUMENT c'est l'URL du fichier par défaut (donc redirection vers ce que fait #FICHIER_URL sans autre traitement) OU l'URL d'une page HTML quand on le désire

trop bien !

@rastapopoulos tu as pu avancer sur le sujet suite aux derniers commentaires ?

non pas remis le nez dedans du tout pour l'instant

+1 pour #FICHIER_URL, je me repose à chaque fois la même question dans les squelettes persos (« Je mets #FICHIER ou bien #URL_DOCUMENT si jamais c'est protégé ? »).