Recherche avancée

Sur d’autres sites (4188)

• Evolution #3449 : Intégrer le comportement du plugin medoc dans le core

  12 janvier 2017, par tetue tetue

  nico d_ a écrit :

  Dans les aspects intéressants, il y a aussi

  • le côté responsive (avec le plugin image_responsive),
  • et éventuellement le point 7 : "supprimer le float quand l’image devient proportionnellement trop large par rapport à sa colonne d’affichage", même si on peut considérer que c’est lié au squelette.

  Attention à ne pas confondre désir de faire évoluer l’affichage des modèles et débug ! Medoc n’est qu’un patch (grossier) qui corrige un bug ergo (hyper chiant quand on y confronté, imperceptible pour les autres). En tant que tel, il s’utilise avec n’importe lequel de ces autres plugins proposant des variantes d’affichage des modèles, responsive ou pas, float ou pas, toussa, toussa… (ce sont d’autres besoins, donc autres plugins, autres tickets). Il n’aura plus de raison d’être lorsque le « mode » (« image » ou « document ») aura disparu de la table spip_documents ainsi que ses implications (différence entre portfolio et hors portfolio)… chose que je suis infichue de savoir faire, d’où cet affreux petit sparadrap appelé Medoc ;)

  Intégrer Medoc au core, c’est juste vouloir corriger l’inconstance d’affichage des images et documents selon qu’elles sont dans ou hors du portfolio. Soit « salement » en y reversant le code grossier de Medoc, plouf (l’avantage c’est que c’est prêt et que ça marche), soit plus proprement en touchant à la table spip_documents (plus complexe)… ce que semble avoir fait @arno :) dans son plugin (qui embarque aussi beaucoup d’autres choses).

• Evolution #4740 (Nouveau) : API CVT Configurer : savoir gérer les champs "file"

  20 avril 2021, par RastaPopoulos ♥

  Une évolution intéressante serait que l’API automatique de configuration sache gérer les champs fichiers.

  Actuellement on n’a pas de mécanisme simplifié permettant d’enregistrer des fichiers sans rapport avec l’éditorial, donc sans rapport avec la médiathèque (pas en spip_documents), sans coder soi-même à chaque fois une implémentation dédiée en PHP.

  Le cas d’utilisation vraiment très courant me paraitre être pour les formulaires de config des plugins, notamment pour des images (mais pas que, ça pourrait être un son à jouer ou que sais-je).
  Exemple IRL :
  - pouvoir configurer le plugin Favicon avec une image dédiée
  - pouvoir configurer un webmanifest pour une appli, qui attend aussi une icône dédiée
  - pouvoir configurer un squelette/thème qui attend telles et telles images propres à l’ergo/graphisme de ce thème (image d’entête, image de pied, etc)

  Ma piste serait une augmentation de l’API CVT Configurer, pour qu’il sache aussi enregistrer les champs "file" et non pas juste les champs qui envoient un scalaire. Dans ce cas, ça enregistrerait le fichier dans un dossier permanent et public, donc dans IMG. Par exemple dans IMG/configurer/nom_du_form/fichier.png.
  Possiblement une ou deux fonctions/balises permettrait de les récupérer facilement, que ce soit pour ré-afficher ce qui est déjà uploadé à côté du champ de config, ou pour les utilisations réelles ensuite dans le site.

  Une personne NON dev, juste intégrateurice, serait donc capable en 5min de pouvoir configurer aussi des fichiers, pour son squelette/thème.

• Evolution #4148 : Augmenter la largeur de l’espace privé

  23 juin 2018, par RastaPopoulos ♥

  +1 donc, le but de la demande de départ, c’est vraiment d’avoir la place nécessaire à plein de choses dans la partie contenu. Pas d’augmenter la lisibilité, ce qui est très bien aussi hein et totalement nécessaire, mais ce n’est pas l’objet du ticket. Si on augmente seulement légèrement la largeur, et qu’on augmente la taille du texte (ce qui est bien encore une fois), au final en terme de proportions, on aura pas gagné énormément de place pour y loger des contenus plus larges[*]. Alors oui, il y a plus de choses à caler pour garder un texte lisible et des formulaires pas absurdement grands ou trop petits.

  Le but est d’arriver
  - à ce que le contenu de base d’un CMS soit bien proportionné (relecture de texte et édition de formulaires)
  - tout en permettant sans bidouille d’avoir de l’espace quand on en a besoin. Et cela y compris pas sur ses propres pages qu’on controle à 100% mais quand on insère des blocs dans des pages existantes.

  [*] Tableaux avec plus de colonnes, liste de vignettes avec plus que 3-4 par lignes, afficher des images plus grandes tout en ayant du texte à côté, avoir une colonne de facettes/filtrage tout en ayant encore beaucoup de largeur pour le contenu qui liste les résultats, etc… on peut en trouver un paquet des choses qui ont besoin de largeur [**]

  [**] Cela dit, c’est "quand c’est possible", car dans tous les cas il faut aussi prévoir comment ces contenus vont s’afficher en petit écran. Par exemple si on a un tableau d’objet avec 10 colonnes, comment on affiche ça responsivement.