Re: SPIP 3.3, logos et images/documents

Hello,

Dans un contexte de spip mutualisé, avec SPIP3.3 j'ai un soucis avec une
fonction de réécriture de chemin appliquer via declarer_filtres_squelettes.

/**
 * RECRIRE URL FICHIERS STATIQUES MUTUALISATION
 *
 * ex: https://site.com/sites/site.com/local/gd2/image.jpg =>
https://site.com/local/gd2/image.jpg
 * /!\ Necessite règle réécriture sur serveur web
 *
 * @param string $flux
 *      flux html
 * @return string
 *      le flux html modifié
 */
function rewriteAssetMutu($flux){

    if (!defined('_URL_IMG'))
        define('_URL_IMG', strstr(_SPIP_PATH, '::', TRUE) .
_NOM_PERMANENTS_ACCESSIBLES);
    // local
    if (!defined('_URL_VAR'))
        define('_URL_VAR', strstr(_SPIP_PATH, '::', TRUE) .
_NOM_TEMPORAIRES_ACCESSIBLES);

    return str_replace(array(_URL_VAR, _URL_IMG),
array(_NOM_TEMPORAIRES_ACCESSIBLES, _NOM_PERMANENTS_ACCESSIBLES), $flux);
}

Je l'utilise depuis pas mal de temps en spip3.1 et 3.2 mais sur 3.3 avec
l'arrivé de  modeles/logo.html  ça ne fonctionne plus vraiment :
Le chemin est bien réécrit, mais je perds le chemin vers la ressource
modifié par GD au profit de la source originale.

En chemin j'ai ça
IMG/logo/scrat-ice-age-9135926-1024-768.jpg?1575968565

alors que theoriquement je devrais avoir:
local/cache-gd2/e0/f2f9ba32f026d2e321bb723fae611e.jpg?1577019107

J'ai survolé le code de la balise logo_.php afin de comprendre  les
changements mais je n'ai pas vraiment saisie le nouveau fonctionnement..

Le sam. 20 juil. 2019 à 16:47, Cerdic <[email protected]> a écrit :

> Hello,
>
> c’était au programme de la 3.3, mais on a rien fait jusqu’ici, et comme
> tout le sujet est englué depuis des années (décénies ?), je vous fais donc
> la proposition suivante :
>
>
>    - la version 3.3 sera une version de transition
>
> Pour les logos :
>
>    - les logos sont intégrés dans la table spip_documents avec
>    mode=‘logo’, mais sans modification de l’interface, et sont toujours dans
>    le dossier IMG/ pour ne pas casser trop les plugins de restrictions d’acces
>    (cf https://core.spip.net/issues/3719)
>    - Aucune modification de l’utilisation des balises LOGO ni des boucles
>    documents desquelles ces images seront exclues par défaut comme les
>    vignettes de document
>
> Pour les images et documents :
>
>    - le champ `mode` est conservé dans la table spip_documents, mais il
>    n’est plus utilisé pour différencier le format d’affichage dans les modèles
>    documents
>    - la notion de portfolio disparait de l’interface par défaut :
>       - dans l’espace privé toutes les images apparaissent dans
>       ‘illustrations’, tous les autres documents dans ‘document’
>       POUR CETTE VERSION UNIQUEMENT un define permets de le réactiver
>       pour les sites historiques qui pourront ainsi gérer leur transition de
>       façon smooth via un plugin
>       - dans la dist, dans la zone document joints s’affichent les
>       documents joints à l’article (vu ou non dans le contenu l’article) et les
>       images jointes à l’article non vues dans le corps de l'article
>    - les raccourcis <img>, <doc> et <emb> n’appellent plus directement
>    les modèles img, doc et emb, qui disparaissent, mais une couche de routage
>    regarde le type du document et affecte vers le bon modèle en fonction du
>    media
>       - image.html, audio.html, video.html, file.html
>       - possibilité de décliner par mime type : file_text.html ou par
>       extension : video_mp4.html, file_text_csv.txt
>    - Ainsi tous les modèles img,doc,emb bidouillés dans la nature sont
>    bypassés et ignorés et on repart sur une base saine pour tous les sites
>    avec les modèles par défaut
>    - On peut utiliser <doc> partout comme le propose le plugin mesdoc (
>    https://contrib.spip.net/Modele-doc-unifie), ou continuer à utiliser
>    les syntaxe différenciées, sans aucune espèce d’importance
>    - L’interface ne proposerait que le raccourci <doc> partout
>    - POUR CETTE VERSION UNIQUEMENT un define permet de rétablir la prise
>    en compte des modèles img,doc,emb existant — pour le meilleur et pour le
>    pire
>    - Le fonctionnement du modèle <image> reprend ce que propose le plugin
>    insertions images avancées (
>    https://23forward.com/Plugin-SPIP-Insertion-avancee-d-images) : image
>    plein pot, clicable si faisant plus de 800 px(modifiable via define), avec
>    titre, descriptif, credit si présents (on ne veut jamais ne pas les
>    afficher !), balisage en <figure>, <figcaption>.
>    Les modificatifs |left |right |center restent utilisables, ajoutant
>    principalement une class
>    Les modificateurs |largeur=300 ou |hauteur=250 ou |ratio=16:9 sont
>    utilisables (extension de ce que propose les plugins suscités)
>    On peut mettre un lien sur l’image comme actuellement
>    - Les modèles audio et video sont inchangés par rapport à l’existant
>    - Le modèle file reprend donc la présentation de tous les autres types
>    de document hors image, audio et video
>    Il est aussi en figure/figcaption, mais sinon pour l’essentiel reprend
>    le fonctionnement du modele doc actuel, qui est affichage d’un lien vers le
>    doc avec une vignette éventuellement personnalisée, titre, descriptif,
>    credit
>
>
>
> On propose donc un fonctionnement de base simple et compréhensible, sans
> complexité biscornue, un bypass de tous les modèles img/doc/emb surchargés
> dans la nature pour que la migration se passe bien, et chaque type de
> modèle image, audio, video, file ne gérant qu’un type de document sera plus
> simple, lisible et compréhensible
>
> 2 define permettent de rétablir le portfolio dans l’espace privé et le
> fonctionnement des modèles img, doc, et emb. Un plugin de
> retrocompatibilité pourra être proposé POUR CETTE VERSION UNIQUEMENT
> (contenant en gros les define, et les modèles de la 3.2)
>
> Et pour la version suivante on prend ensuite le temps de faire évoluer le
> code plus en profondeur :
>
>    - en simplifiant les squelettes de l'interface privée pour supprimer
>    totalement la gestion du portfolio
>    - la suppression complète du mode dans les documents
>    - l’unification de la gestion documents et logos via les rôles
>    - et tout ce a quoi on aura pensé d’ici là
>
>
> Est-ce que vous êtes
>
> [ ] Ok on y va ça a trop duré, on affinera la proposition en faisant
> [ ] est-ce qu’on peut faire ça sur une branche pour tester avant ?
> [ ] est-ce qu’on peut réfléchir encore un peu ?
>
> Bises
>
> --
> Cédric
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip