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

Open
rastapopoulos wants to merge 2 commits from dev/issue_4645_lien_fichier into master
Owner

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 ?

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 ?
rastapopoulos added 1 commit 2 years ago
b_b commented 2 years ago
Owner

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).

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)`.
Poster
Owner

@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.

@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.
b_b commented 2 years ago
Owner

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} :)

> 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}` :)
Poster
Owner

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.

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.
b_b added 1 commit 1 year ago
b_b commented 1 year ago
Owner

On en est où avec cette PR ?

On en est où avec cette PR ?
Poster
Owner

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.

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.
Owner

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

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
Poster
Owner

Ç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 !

Ç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 !
Owner

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

@rastapopoulos tu as pu avancer sur le sujet suite aux derniers commentaires ?
b_b added the
amélioration
label 11 months ago
b_b added this to the spip-4.2 milestone 11 months ago
Poster
Owner

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

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

+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é ? »).

+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é ? »).
This pull request has changes conflicting with the target branch.
modeles/document_desc.html
prive/squelettes/inclure/mediatheque-galerie.html
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.