Iconduck - Free open source icons, illustrations and graphics
▻https://iconduck.com
#icone #svg
SPIP Core (Forge de développement)
/issues
-
-
Y a pas mal de ressources partagées ici, si on les recensait ? :)
►https://orioniconlibrary.com
►https://www.flaticon.com
►https://flaticons.net par
►https://icons.pixsellz.io
►https://icongr.am
►https://remixicon.com
►https://www.svgrepo.com
►https://danklammer.com/bytesize-icons(par @monolecte, @b_b, @cy_altern, @rastapopoulos)
#Icons #ressource_graphique #webdesign #pictos #graphisme #ergonomie #web #intégration #interface
-
-
-
-
unDraw - Open source illustrations for any idea
The design project with open-source illustrations for any idea you can imagine and create. Create beautiful websites, products and applications with your color, for free. -
Dans mon idée, on partait plus sur les icônes ici pour s’y retrouver et les outils dans d’autres fils :) et avec un #Ressources_graphisme ou #Ressources_integration pour tout lier.
Mais à voir. -
des nouveaux
– ▻https://feathericons.com
– ▻https://github.com/primer/octicons
– ▻https://fonts.google.com/icons?selected=Material+Icons
– ▻https://icons.coreui.io/icons
– ▻https://github.com/danklammer/bytesize-icons
– ▻https://useiconic.com/open
– ▻https://forkaweso.me/Fork-Awesome/iconsSource + avis : ▻https://core.spip.net/issues/4727
How to Design Better Icons
▻https://blog.prototypr.io/how-to-design-better-icons-869d067fddbf -
-
-
J’ai une question #SPIP : où faut-il installer sa propre définition de
define('_ECRAN_SECURITE_LOAD', ma_valeur);Dans
mes_options.php, ça ne me semble pas pris en compte. Du coup je ne vois pas ce qui passerait avant l’écran de sécurité.-
Pour l’instant tu n’as pas d’autre solution que de modifier l’écran directement et il y a un bug ouvert à ce sujet : ▻https://core.spip.net/issues/4242
-
Oui, il faut absolument inclure un fichier séparé s’il existe, c’est pas possible une lib où tu dois modifier son propre fichier pour personnaliser.
-
-
Guzzle, PHP HTTP client — Guzzle Documentation
▻http://docs.guzzlephp.org/en/stableGuzzle is a PHP HTTP client that makes it easy to send HTTP requests and trivial to integrate with web services.
– Simple interface for building query strings, POST requests, streaming large uploads, streaming large downloads, using HTTP cookies, uploading JSON data, etc...
– Can send both synchronous and asynchronous requests using the same interface.
– Abstracts away the underlying HTTP transport, allowing you to write environment and transport agnostic code; i.e., no hard dependency on cURL, PHP streams, sockets, or non-blocking event loops.(en relation avec le ticket ▻https://core.spip.net/issues/3973 de SPIP)
-
JavaScript Markdown Editor - SimpleMDE
▻https://simplemde.comUn éditeur Markdown en javascript qui propose une vue « quasi » WYSIWYG tout en gardant le code des raccourcis syntaxiques visible. Le concept mi-chèvre mi-choux semble pertinent pour les débutants comme pour les « power-users »
Le dépôt Github : ▻https://github.com/sparksuite/simplemde-markdown-editor#éditeur #WYSIWYG #javascript #markdown #SPIP
-
Il y a 3 ans… avec détails et roadmap des choses à faire dans l’ordre :
►https://core.spip.net/issues/3720 -
-
-
Retour d’experience sur le developement d’un éditeur rich text, axé rédaction digital, pour le NYT.
manipulation DOM, Utilise ProseMirror, intéressant pour la structuration des blocs imbriqués de contenu…Building a Text Editor for a Digital-First Newsroom
▻https://open.nytimes.com/building-a-text-editor-for-a-digital-first-newsroom-f1cb8367fc21
-
►https://seenthis.net/messages/693664
C’est exactement ce qu’il faut et que j’attends depuis des années, même après que Wikipedia ait codé son éditeur wysiwyg mais qui enregistre en une autre syntaxe après (càd ça ne produit pas du html). Sauf que wikimedia l’a codé que pour eux, pas en lib générique.
Or là Prosemirror est vraiment une lib générique qui montre à l’utilisateur un éditeur #wysiwyg MAIS qui produit un format pivot intermédiaire en JSON, de données structurées, qui peut donc ensuite être utilisé pour produire n’importe quoi, et alors enregistrer en SPIP en Markdown ou n’importe quoi d’autre…
This is the future !
-
Le site officiel du « moteur » sous ce projet : ProseMinor
►http://prosemirror.netEt pour en rajouter une couche sur les possibilités de ProseMinor vis à vis des fonctionnalités d’édition de SPIP : ▻https://prosemirror.net/examples/dino
qui donne un exemple d’intégration d’un nouvel objet éditorial (ici un dinosaure) tout à fait similaire aux modèles SPIP...#json #ProseMirror #éditeur #SPIP
-
@rastapopoulos paye ton ticket ? (tant que core.spip.net tourne toujours ^^)
-
J’avais fait un ticket sur le développement d’un éditeur basé sur CodeMirror déjà, mais pour faire du WYSIWYM donc. Là c’est une autre piste du coup. Donc autre ticket… ou bien transformation du précédent en complétant pour présenter les deux pistes (et peut-être même que les deux pourraient être bien à la fois, car quand on a un éditeur WYSIWYG, il faut toujours avoir aussi un éditeur de source en parallèle, et alors autant qu’il soit WYISWYM tant qu’à faire…)
-
le ticket de @rastapopoulos est maintenant ici : ▻https://git.spip.net/spip/porte_plume/issues/3720
-
-
Anomalie #4097 : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal configurés - SPIP - SPIP Core (Forge de développement)
▻https://core.spip.net/issues/4097le contournement nécessaire dans mes_options.php pour les serveurs mal configurés ($_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"] absents ou faux)
-
Tiens, Apercite ne répond plus depuis plusieurs jours. Est-ce que c’est mort ? (Étonnant, ces outils typiquement « Web 2.0 » – au sens de ses outils en ligne qui te fournissaient des briques de « services » pour ton propre site Web – qui disparaissent, et apparemment tout le monde s’en fout. Je n’ai trouvé aucune mention en ligne.) Moi pas, ça me sert bien sur Orient Palms, et il n’y a quand même pas des caisses d’alternatives…
-
Tu peux te monter un truc perso pour faire la même chose, @ben devrait pouvoir t’en dire plus ;)
-
-
Je relance : SPIP utilise Apercite pour fabriquer les vignettes de prévisualisation des liens entrants. #SPIP est donc actuellement un peu cassé (même si Apercite répond à nouveau, mais avec une vignette générique qui annonce apparemment un passage au payant). :-(
Et sinon, oui, je suis très très preneur pour un mode d’emploi de comment qu’on se fabrique un tel service sur son propre serveur… :-))
-
On en cause ici justement ▻https://core.spip.net/issues/4124
-
-
Dis @SPIP, on me demande de répondre à des critères de sécurité « ANSSI », est-ce que tu peux me renseigner sur ces trois points ?
– R19 - Les identifiants de session sont aléatoires et d’une entropie d’au moins 128 bits.
– R21 - Les attributs HTTPOnly et, dans le cas d’un site en HTTPS, Secure sont associés à l’identifiant de session.
– R29- Définition d’une politique de journalisation précisant notamment les modalités et les durées de conservation des différents journaux ainsi que les méthodes d’analyse et de corrélation des données produites.
-
-
On me les a collés dans un appel d’offre, mais la source est ici :
▻https://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Securite_Web_NoteTech.pdf -
Pour R21, je vois que le httponly est passé par
spip_setcookie()pour le cookie spip_session. -
-
@arno oui pour le cookie :
▻https://core.spip.net/projects/spip/repository/revisions/19183
▻https://core.spip.net/projects/spip/repository/revisions/20501Reste une amélioration en attente ici : ▻https://core.spip.net/issues/3821
-
-
Authentification par mot de passe : les mesures de sécurité élémentaires
▻https://www.cnil.fr/fr/authentification-par-mot-de-passe-les-mesures-de-securite-elementaires« Dans tous les cas, le mot de passe ne doit pas être communiqué à l’utilisateur en clair par courrier électronique. Ces exigences sont des règles minimales. »
-
N’est-ce pas #SPIP ? :(
-
@rastapopoulos comme tu le sais, tout existe pour palier au problème, il ne reste plus qu’à l’intégrer dans la core :)
-
Bah euh je sais j’ai fait plugin pour ça déjà avant ce ticket (que G0uZ utilise maintenant cf les commentaires).
Mais d’une il faudrait que ce soit dans le noyau (Cédric proposait de carrément tout refaire et utiliser en priorité des emails avec des liens, et les mots de passe seulement en option pour celleux qui l’activent dans leur compte => mais c’est un beaucoup plus gros chantier, donc plus long et ça va trainer, et donc ça serait déjà bien de au moins les demander à l’inscription et ne plus les mettre dans les emails, ça c’est rapide et déjà codé).
Et de deux, ya eu un ajout au printemps d’un envoi d’email en clair supplémentaire par les admins, qui n’a pas vraiment été discuté, et qui du coup ajoute un truc pas cool supplémentaire au lieu d’améliorer l’existant. Cf le ticket ▻https://core.spip.net/issues/2250 qui d’ailleurs ne demandait pas à envoyer le mot de passe dans l’email justement. -
En même temps, on découvre une nouvelle fonctionnalité qui est apparue « magiquement » dans SPIP 3.2 : « Générer un nouveau mot de passe et l’envoyer par email » (par texte en clair).
-
-
GitHub - darylldoyle/svg-sanitizer : A PHP SVG/XML Sanitizer
►https://github.com/darylldoyle/svg-sanitizerUtilitaire PHP de « sanitization » des fichiers SVG
Voir aussi : ►https://github.com/darylldoyle/svg-sanitizer (qui ne semble pas maintenu depuis 2013...)
Mise à jour 11/2018 : le développement semble repris depuis quelques moisUtilisé par le plugin Wordpress ▻https://wordpress.org/plugins/safe-svg
et le plugin Drupal ▻https://www.drupal.org/project/svg_sanitizerEn relation avec le ticket du core de SPIP ▻https://core.spip.net/issues/3482
#svg #svg-sanitizer #SPIP
-
-
-
Je l’ai ajouté dans le plugin #logo_svg de #SPIP ici : ▻https://github.com/cahri/spip-logo-svg
-
pour mémoire : un aperçu des failles possibles lors de l’utilisation de SVG dans une page web :
▻https://www.blackhat.com/docs/us-14/materials/us-14-DeGraaf-SVG-Exploiting-Browsers-Without-Image-Parsing-Bugs.pdf
-
-
Je viens d’uploader un de mes plus importants #plugin pour #SPIP (au sens où c’est un de ceux que j’utilise le plus désormais, et qui change le plus l’aspect des sites que je développe) : Insertion avancée d’images
►https://zone.spip.org/trac/spip-zone/browser/_plugins_/medias_responsive_modC’est vraiment un gros truc, avec beaucoup de choses, je vais le documenter au fur et à mesure…
-
1. Refonte du raccourci
<img>Fondamentalement, c’est une modification complète du fonctionnement du raccourci <img> : l’image est affichée « en grand », et jamais sous forme de vignette. Elle peut être évidemment placée au centre, à gauche ou à droite, mais l’utilisation première est d’afficher l’image sur toute la colonne de texte disponible.
Une idée vraiment importante est de se débarrasser totalement de la différence entre les images du portfolio et les images hors du portfolio : les images s’affichent de la même façon dans tous les cas, et jamais sous forme de vignette.
2. Si on a mis un titre, un descriptif et/ou des crédits, ils s’affichent avec
<img>. C’est dans la continuation de la logique précédente : si on met un titre, c’est qu’on veut un titre. Donc <img> affiche toujours le titre (quand il est renseigné).3. C’est responsive, évidemment.
-
Outre le fait que personne ne comprend vraiment la logique
<img>,<doc>ou<emb>, la question qui prime est le fait que les usages qui ont justifié ces différents raccourcis ont disparu.– Quand on a conçu SPIP en 2000, la bande passante utilisée par les images restait une question importante : on affichait les images en petit dans les articles, et on proposait de cliquer dessus pour que l’utilisateur puisse les charger uniquement s’il en a envie. Clairement, plus personne ne fait ça… On veut des images en grand et puis c’est tout. C’est aussi pour cela qu’on affiche le type et le poids du fichier dans <doc> (pour que l’utilisateur ait une idée de ce qui l’attend s’il clique sur ce terrifiant fichier de… 160ko) ; mais aujourd’hui, en dehors de fichiers spécifiques, genre gros PDF ou fichier d’image monstrueux, ça n’a pas de sens de continuer à le faire pour des images…
Bref, le coup d’insérer des petites vignettes cliquables au lieu de grandes images, ça ne se fait plus du tout.
À l’inverse, insérer de belles grandes images qui occupe toute la largeur de la colonne, c’est la norme désormais.
– Une habitude (étrange…) qu’on avait était d’insérer des petites images sans légende à l’intérieur des textes. Bon, ça non plus, ça ne se fait plus : quand on met une image, si on a une légende, hé ben on affiche la légende, ça ne coûte pas plus cher…
– Un usage que j’ai supprimé de mes sites : la différence entre portfolio et hors portfolio. Si une image est associée à un article, c’est qu’on veut l’afficher dans tous les cas (si on veut conserver des images dans le site, mais sans les associer à un article, on a maintenant la
médiathèque). Donc une image s’affiche toujours de la même façon avec le raccourci <img>, et si elle n’est pas affichée dans l’article, on la mettra dans le portfolio en dessous, sans se demander si elle est dans le « portfolio » (au sens technique SPIP) de l’article, parce que c’est une notion incompréhensible pour les usagers.Je ne l’ai pas encore fait dans ce plugin, mais je pense qu’il faudrait complètement réserver l’utilisation de <doc> à des présentations de documents à télécharger, genre grosses images ou fichiers PDF, et ne plus du tout l’utiliser pour insérer des images dans le texte. Du coup, sur mes sites, j’utilise désormais uniquement <img> pour insérer des images, et plus jamais <emb> ni <doc>.
-
4. Balisage moderne avec
<figure>et<figcaption>.5. Une image est cliquable (pour afficher le grand format) automatiquement si elle fait plus de 800 pixels dans une de ses dimensions. Pas de considération de la notion SPIP de « portfolio » ici (voir ci-dessus : c’est une notion qu’on devrait totalement abandonner je pense) : si une image est assez grande, elle est cliquable et puis c’est tout…
On conserve la possibilité de faire un lien hypertexte « à la main » sur une image, même si je pense que l’usage a également plus ou moins disparu de nos jours (quand on clique sur une image, on s’attend plutôt à la voir en grand, pas à changer de page).
-
6. Possibilité de forcer la largeur d’une image « à la main » :
<img23|right|largeur=300>Noter que techniquement, dans ce cas on aura grâce au plugin
image_responsiveune gestion plus avancée du balisage, mieux adaptée au chargement anticipé des images, puisque ça va utiliser lesrcsetavec les valeurs1xet2x(pour le retina).7. Une subtilité javascript épatante ici : les images flottantes à droite ou à gauche, c’est très joli sur un grand écran, mais sur un téléphone ça détruit généralement complètement la maquette, parce qu’on met une image « flottante » de 250 pixels dans une colonne de 320 pixels, et qu’il reste du coup 70 pixels pour afficher le texte, et généralement c’est une catastrophe.
Le plugin inclue donc un mécanisme #javascript qui vérifie la largeur des images flottantes et de la colonne de texte pour supprimer le
floatquand l’image devient proportionnellement trop large par rapport à sa colonne d’affichage (plus de 60% de la colonne de texte). Dans ce cas l’image est « forcée » en présentation centrée, avec sa légende, et on récupère un affichage optimal même sur petit écran.À l’inverse, on peut aussi se prévoir des styles pour les écran très larges (ça c’est pas directement dans le plugin, mais le balisage le permet facilement) :
-
8. Option de présentation :
rond: ça force l’image à s’afficher dans un cercle. Oui, tout rond. Même si l’image est un JPG, ça se fait en CSS, donc ça évite de recourir à un PNG dix fois plus gros.<img13|center|rond>Ça peut valoir le coup de l’associer à l’option
largeursi on veut faire flotter une grande image à droite ou à gauche :<img13|left|rond|largeur=200>9. Trop mignon avec un navigateur récent : une image arrondie (avec
rond) flottante forcera un habillage irrégulier par le texte : c’est-à-dire que le texte habillera le cercle de façon… circulaire, et non en rectangle. Ça se fait directement en CSS avecshape-outside. C’est automatique quand on utilise ˋrond`, pas besoin d’option supplémentaire.10. Extrêmement puissant : on peut demander un habillage irrégulier automatiquement sur les images JPG dotées d’un fond uni grâce à l’option
shape. Attention, ça n’utilisera pas ma vieille technique de « tranches » (de image_ragged), mais sur la base d’unpolygoncalculé avec une nouvelle fonction : `image_detourer_polygon. Ça c’est carrément spectaculaire. -
11. Une petite animation rigolote : l’option
flippermet de faire tourner l’image sur elle-même lorsqu’elle apparaît dans le viewport (en fonction du scroll, donc). Ça donne l’impression d’une pièce de monnaie qui tourne sur elle-même avant de s’arrêter pour s’arrêter :<img13|center|flip>
ça devient encore plus fun si on force l’affichage dans un rond :<img13|center|rond|flip>ou carrément dans un rond flottant avec le détourage automatique :
<img13|left|rond|flip|largeur=200> -
12. Et enfin l’animation la plus puissante : le zoom sur un détail de l’image (déterminé avec le plugin centre_image) :
<img13|center|kenburns=1.6>Je pense qu’il faudrait renommer l’option simplement
zoom, parce que personne n’arrive jamais à mémoriser ça…C’est une animation volontairement lente, mais alors : extrêmement spectaculaire… Et pour le coup, ça a généralement un véritable intérêt éditorial.
-
13. Et enfin, la possibilité d’afficher plusieurs images sur une même ligne, avec adaptation aux différentes tailles d’écran, avec un nouveau raccourci :
<ligne>:<ligne13>
<ligne14>
<ligne15>Ça c’est vraiment impressionnant… (en revanche, je n’utilises pas le même code HTML que pour les
<img>, alors que je pense que je devrait le faire, pour profiter des raccourcis décrits précédemment).Noter qu’ici encore, s’il y a des titres, descriptifs et/ou crédits, ça s’affiche. Sinon, non.
C’est à la fois très puissant, et assez déstabilisant, parce que la composition est automatique et… responsive. Du coup l’affichage dépend énormément des proportions des images et de la taille de l’écran. Du coup il faut réussir à se faire à l’idée que l’affichage sera variable, semi-automatique, et ne pas chercher à avoir des positionnements absolus qu’on décrète soi-même (ce qui est le « problème » de la mise en page responsive : il faut accepter que ça se recompose).
-
Bon, je dois m’absenter pour la journée, je compléterai avec des copies d’écran plus tard. Mais déjà, j’invite les Spipeurs•ses à jouer avec, parce que c’est un outil que j’installe sur tous mes sites, et qui change radicalement leur fonctionnement. Je suis très très très très preneur de retours à ce sujet.
-
Pas testé, mais sur le principe ça rejoint en partie le plugin Medoc de @tetue, en ajoutant le côté responsive.
Mais il y a beaucoup de gadgets visuels : ça mériterait deux plugins distincts (un plugin = une fonction).Après, la « doc » et la discussion sur seenthis n’engagent pas vraiment la discussions avec la communauté #SPIP.
-
Ma remarque sur le lieu approprié pour le discussion est un peu sèche et pourrait être mal interprétée : pas d’arrière pensée de ma part, juste une remarque pratique sur le fait que tu « invites les Spipeurs•ses à jouer avec ».
-
@nicod_ : yep, attention à ne pas confondre évol d’affichage des modèles et débug ergo.
1) Medoc n’est qu’un patch (grossier) qui corrige un bug ergo (hyper chiant quand on y confronté, totalement imperceptible pour les autres)
2) et (plein) d’autres plugins proposent des variantes d’affichage des modèles, responsive ou pas, toussa, toussa…En tant que patch correctif, Medoc s’utilise avec n’importe lequel de ces autres plugins (dont il doit rester distinct).
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 ;)@arno : je suis ravie à l’idée d’essayer ton plugin prochainement :)
-
Merveilleux ! Super boulot, merci de le partager !
Une remarque sur la notion d’image insérée sans légende, c’est en fait essentiel pour l’accessibilité de pouvoir définir un titre inséré dans le alt de l’image, mais qu’on ne tient pas à afficher en dessous de l’image en légende.Actuellement
–<img>insère l’image avec le titre en alt
–<doc>insère l’image avec le titre en légende en dessousDonc, dans la logique de ce que tu as fait, un paramètre |legend ou |nolegend serait pertinent, non ?
-
@tetue me suis mal exprimé, et trop vite.
Je parlais de
Fondamentalement, c’est une modification complète du fonctionnement du raccourci <img>
qui est le côté très intéressant du plugin de @arno, et qui rejoint ta réflexion sur medoc.
Avec l’ajout du paramétrage de largeur et le côté responsive, ça en fait un travail intéressant qui peut alimenter la réflexion sur la refonte de la gestion des docs dans SPIP (d’où ma remarque également sur le lieu pour en discuter).
-
-
Merci @arno , ce plugin a l’air très bien, et rempli de bonnes idées.
Une remarque sur
<ligneXX>: je vois* que cela crée autant de<ul>que de<ligne>. Est-ce qu’une syntaxe tel que<ligne|XX,YY,ZZ>ne serait pas plus appropriée, ce qui permettrait de n’avoir qu’un conteneur pour les 3 documents ?Le terme « ligne » en lui-même aussi est un peu flou, mais je n’ai pas d’idée là comme ça à part avoir une autre notion tel que
<images|ligne|XX,YY,ZZ>,<images|cases|XX,YY,ZZ>peut être… ce qui deviendrait un « modèle d’affichage d’une liste de documents sélectionnés »* note : le modèle est ainsi fait, mais un pipeline enlève ensuite les ul en trop sur ces lignes…
-
-
Ah ou… si autant de balises
<ligneXX>que de documents à afficher est conservé (plutôt que d’1 pour n documents), pourquoi ne pas utiliser plutôt<imgXX|ligne>ou<docXX|ligne>finalement directement ? ça paraîtrait bien également non ? -
Génial ! Le plugin a l’air très très complet et global. Un grand merci Arno* !
-
Sur
<ligne>…D’abord, je voudrais refaire le code de ce modèle pour qu’il utilise le même code que
<img>pour l’affichage de l’image et des intitulés ; pour l’instant ce n’est ni le même code ni la même logique de fonctionnement, ce qui pose différentes difficultés :– les images de <ligne> s’affichent en background, ce qui fait qu’elles ne sont généralement pas imprimées et/ou difficiles à sauvegarder dans un PDF ; et autres petites difficultés d’utilisation quand les images sont des background…
– le fait d’avoir deux codes à maintenir, c’est un peu chiant (c’est pas dramatique, parce que j’utilise énormément ce plugin, mais c’est chiant)…
– j’aimerais bien avoir les mêmes fonctionnalités (notamment le zoom
kenburnsdans l’image) y compris sur les images en ligne…Du coup, utiliser carrément le même modèle avec
<imgXX|ligne>, ça semble une bonne piste (surtout queligneremplace exactementcenter,leftetrightdans leur logique de positionnement).Difficulté : je pense que certaines fonctionnalités n’ont rien à faire dans
ligne(notamment forcer la largeur), et donc ça va commencer à faire du code un peu complexe.En revanche, je ne pense pas intéressant de fusionner la déclaration de plusieurs images dans le même modèle :
– d’abord parce que c’est chiant à manipuler (quand on fait des articles, on déplace beaucoup les images, surtout qu’avecligneça demande des réglages parce que certaines associations fonctionnent moins bien que d’autres), et du coup le copier-coller d’une ligne pour une image, c’est plus pratique que d’aller éditer le modèle avec plusieurs images,
– parce que je voudrais pouvoir passer des fonctionnalités différenciées sur chaque image (comme l’effet de zoom). -
J’oubliais une option :
14. Ça prend en compte l’option
large:<imgXX|center|large>
qui se contente d’insérer une classe.large. Ça ne sert pas à grand chose pour l’instant, mais c’est extrêmement utile dans un autre de mes plugins (pas diffusé pour l’instant), et chacun pourra de toute façon bidouiller ses feuilles de style soi-même : ça permet d’afficher cette image plus large que la colonne de texte. -
Et donc, il y a aussi une discussion en cours sur la liste « spip-dev » (du noyau) sur ce sujet. Qui parle aussi du modèle <media> qui visait à proposer un modèle unifié aussi.
Ainsi qu’un ticket de discussion autour l’intégration de Medoc (+ de ce plugin aussi maintenant) :
▻https://core.spip.net/issues/3449 -
Hello, :-)
Je viens de faire un test de ton plug pour voir, j’ai un bug avec un SPIP 3.1.4-dev [23345] (php5.6.25), j’ai deux images dans la médiathèque que j’ajoute à un article, je mets donc <img2|left> <img1|left> avec du texte avant chaque image, si je clique sur l’onglet « voir » du porte plume, les images apparaissent et disparaissent d’un coup, quand à l’onglet « plein écran » du porte plume, je ne vois même pas les images, à savoir qu’il n’y a que ton plug et « image_responsive » dans les plugs. A savoir, il faut que je fasse plus de test, mais la première fois, comme il s’agissait d’un spip tout neuf, j’ai activé ton plug avant d’aller dans /ecrire/ ?exec=configurer_avancees et que le résultat, c’est que cette page plante (page blanche) avec juste le logo « infini » et l’url qui s’écrit /ecrire/ ?exec=configurer_avancees&action=tester_taille&i=1&arg=6000-6000 j’ai aussi pas mal de notice dans l’article, mais ça c’est pas grave, cela vient sans doute que dans mes_options, je demande à les voirs -
@francky Avec le plugin image_responsive, si ton site tourne avec des URL « propres », il faut absolument modifier ton fichier
.htaccesspour que les images fonctionnent. C’est peut-être ça. -
-
Je pense avoir compris le problème, par contre, je ne sais si c’est un bug de spip ou du plug :-(
Pour info, pour voir le problème, il est important qu’après l’installation d’un spip neuf, de ne pas faire le choix d’un type d’url dans /ecrire/ ?exec=configurer_urls , donc le laissé comme il est nativement, puis d’aller dans ecrire/ ?exec=depots pour faire l’ajout du dépôt de la zone, enfin, installer le plugin « medias_responsive_mod » en manuel dans le dossier « plugin » et laissé spip installer la dépendance « Filtre image_responsive », télécharger un jpeg dans la médiathèque, activer le plugin « medias_responsive_mod » et faire un article.
Avec ou sans htaccess, il y n’y a pas de changement de mon côté -
Salut @arno
un souci rencontré avec image_responsive (je n’ai pas trouvé le seen dédié, donc je me permet de poster ici) :
Sur un SPIP 3.0.3 avec uniquement ce plugin installé, j’ai cette erreur dans la console de Firefox :
Et quand je regarde ce fichier dans local/cache-js, j’ai (ça donne un a circonflexe majuscule dans le source Firefox)Si je désactive la compression js dans l’espace privé, plus de problème.
La ligne en question se trouve dans ▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/javascript/image_responsive.js#L311
En regardant de plus près, il semble y avoir également un souci là ▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/javascript/image_responsive.js#L388 (carré de couleur rouge matérialisant une erreur ?)
(Le fil sur spip_zone : ▻https://www.mail-archive.com/spip-zone@rezo.net/msg43360.html )
-
@jeanmarie et @arno je viens de corriger le problème, cf :
▻https://zone.spip.org/trac/spip-zone/changeset/103856
@arno avait introduit des caractères chelous (qui semblent être des espaces insécables) au lieu de simples espaces avec la modification suivante :
▻https://zone.spip.org/trac/spip-zone/changeset/89816
wala wala...
-
Salut,
Sur le point n°5 :
Une image est cliquable (pour afficher le grand format) automatiquement si elle fait plus de 800 pixels dans une de ses dimensions.
Ligne 37 du modèle img.html, il y a un test sur la taille pour utilise soit un <span>, soit un <a> mais, dans les 2 cas, il y a un href="#FICHIER" ce qui, dans le cas du span, crée une erreur de validation.
Idem pour le type="#MIME_TYPE" (et pour les class et data-photo ?)cf : ▻https://zone.spip.org/trac/spip-zone/browser/_plugins_/medias_responsive_mod/squelettes/modeles/img.html#L37
Il ne faudrait pas tester si on a un lien ou un span avant de les insérer ?
-
Du coup, ça pourrait donner un truc comme ça :
<[(#GET{a})][(#GET{a}|=={a}|oui) href="#FICHIER"[ title="(#TITRE|supprimer_numero|texte_backend)"] class="fond mediabox" type="#MIME_TYPE" data-photo-w="#LARGEUR" data-photo-h="#HAUTEUR"] >
Après, arrivé là, autant tester les largeur/hauteur et insérer le <a> avec tous les paramètres ou juste le <span>, non ?
-
-
-
Official Google Webmaster Central Blog : Updating our technical Webmaster Guidelines
▻https://webmasters.googleblog.com/2014/10/updating-our-technical-webmaster.htmlIndexation Google : le blocage des css et js par robots.txt bientôt pénalisé :
For optimal rendering and indexing, our new guideline specifies that you should allow Googlebot access to the JavaScript, CSS, and image files that your pages use. This provides you optimal rendering and indexing for your site. Disallowing crawling of Javascript or CSS files in your site’s robots.txt directly harms how well our algorithms render and index your content and can result in suboptimal rankings.
...une modification du générateur de robots.txt de SPIP à prévoir ?
#indexation #google #référencement #robots.txt #webmaster-tools
-
Petites modifications dans le plugin #SPIP ressource
▻http://plugins.spip.net/ressource.htmlrafraîchir des ressources
-- ajouter
?var_mode=reloaddans l’URL d’une page va indiquer au plugin qu’il doit recharger les ressources distantes qu’il a en cache ; ça lance une tâche cron qui appelleracopie_locale()avec l’optionforcer(ce qui fait que la version fraîche de la ressource arrive au bout de quelques secondes, et pas immédiatement).utiliser des ressources #github ou #dropbox
-- si on indique
<url dropbox>ou<url github>, le plugin ira chercher la ressource brute (dldans le cas de dropbox, etraw=truedans le cas de github).-
-
En complément : on peut désormais utiliser un clone en local, ce qui évite d’aller chercher les ressources par https.
▻http://zone.spip.org/trac/spip-zone/changeset/95407et on en discute ici ▻https://core.spip.net/issues/3582
-
Hello, juste une petite question, vous avez un début de doc sur le plug pour savoir ce qu’il fait ? car ►https://contrib.spip.net/Ressource renvoi une 404 et même dans l’espace privé, il n’y a rien :-(
-
-
-
Dis @seenthis, un petit favicon .ico à la racine de seenthis.net, ce serait envisageable pour que ça fasse comme une jolie application dans mon téléphone ?! #seenthis_souhait cc @arno
-
Tu veux dire celui là ?
►http://seenthis.net/favicon.icoUn peu petit pour une appli mobile, mais il est bien là. Pour les mobiles faut ajouter d’autres déclarations en plus je crois, pour faire bien.
-
Ben, ça le fait quand tu bookmarkes seenthis sur ton écran d’accueil...
-
Pour les mobiles, tablettes, iTrucs, Andromachins et autres Winbidules, il ya ce site : ►http://realfavicongenerator.net
-
En fait faudrait uploader un ►http://seenthis.net/favicon.ico plus grand (à 96X96px)pour que ce que décrit @supergeante fonctionne sur tous les périphériques : (là ça prend une image de la home avec beaucoup de blanc) cc @fil
-
#SPIP permet de générer les images nécessaires pour les itrucs en ajoutant la règle qui va bien dans le .htacess du site, cf :
▻http://zone.spip.org/trac/spip-zone/browser/_core_/plugins/filtres_images/apple-touch-icon.png.html
Par contre je ne crois qu’on prenne en charge favicon-96x96.png et favicon-16x16.png qui sont listés sur realfavicongenerator. À ajouter ?
-
-
@b_b je verrais plus cette ligne dans le .htaccess de SPIP directement, mais commentée par défaut, avec un commentaire au-dessus du genre : « Si vous avez le plugin filtres_images et qu’une méthode de retouche a été configurée, vous pouvez décommenter cette ligne. »
Parce que je ne le connaissais pas du tout ce truc à rajouter… alors les non-spipien⋅ne⋅s… -
@rastapopoulos oui c’est bien ce que j’entendais par « à ajouter » ;)
D’ailleurs il y a une discussion en cours à ce sujet sur ce ticket :
-
-
Help users checkout faster with Autofill
▻http://updates.html5rocks.com/2015/06/checkout-faster-with-autofillAutocomplete attributes are a way for you, the developer, to control how the browser should populate a given form field. For example, if you are expecting a street address you can hint to the browser that you are expecting it by using
autocomplete="address-line1". This prevents the browser from incorrectly guessing form fields on your website which can result in a poor user experience.-
Si je comprends bien, le but est surtout d’essayer de normaliser les valeurs des attributs
name=""etautocomplete=""à travers l’ensemble des sites du monde, afin de mettre en commun les contenus gardés en mémoire par les navigateurs clients.Du coup peut-être #idée_pour_spip, afin que nos formulaires (du noyau et de certains plugins) utilisent ces valeurs possiblement standards pour le name et le autocomplete.
Et rajoutons un lien, il y a ici la liste apparemment exhaustive de toutes les valeurs standardisées :
▻https://html.spec.whatwg.org/multipage/forms.html#autofill-field -
J’ai fait un ticket pour le garder en mémoire :
▻https://core.spip.net/issues/3543 -
-
-
Oui en fait ma phrase c’est plutôt : pour le garder dans la mémoire collective plutôt que juste dans ma mémoire perso. :D
-
-
J’ai un gros soucis avec #SPIP-3.1 : il ajoute un timestamp aux fichiers, que ce soient les CSS et les Javascript, mais aussi les images passées par les filtres.
C’est certes épatant pour être certain de bien utiliser la dernière version de chaque fichier, mais en revanche, ça me plante complètement l’aspiration des sites en local (parce qu’en local, le fichier
monimage.jpg?1436899191, ça ne marche pas du tout).Est-ce qu’il y a un moyen prévu (genre une variable) pour pouvoir désactiver cet automatisme ?
-
J’ai l’impression d’avoir plus de timestamps avec le 3.1, par exemple sur des images passées par image_reduire, qui n’en avaient pas en 3.0.
Ce que je veux, c’est aspirer le site en local, pour en avoir une copie totalement statique. Avec les timestamp, ça ne fonctionne pas.
Pour l’instant, ce que je fais, c’est d’avoir un
#FILTRE{mini_html}dans tous mes squelettes, qui me sert déjà à faire différentes bidouilles (essentiellement, supprimer les tabulations et les espaces surnuméraires dans le code source), et donc là-dedans j’ajoute la suppression des timestamp un peu à la hache (chaque fois que je trouve(jpg|gif|png)\?[0-9]+[\'\"], je vire le timestamp). -
C’est dans
image_graver()visiblement et il n’y a pas d’option pour le virer (option à ajouter, problablement). Cela dit il n’y a pas de raison fondamentale que les timestamp fassent foirer ta copie locale. Peut-être le fait qu’ils sont avec un?xxxet ne finissent donc plus par.jpg— mais ça aussi ça pourrait se changer. -
-
@b_b, oui j’ai vu
|supprimer_timestamp, mais ça m’oblige à reprendre tous mes squelettes, alors que l’idée est plus dans le sens de ce que remarque @fil. Ou, plus largement, dans le sens de ce qu’ai fait pourimage_responsive:
►http://seenthis.net/messages/374212Là quand j’ajoute :
define("_SPIP_LIER_RESSOURCES", true);
dansmes_options, le même site se met à me fabriquer des squelettes plus verbeux contenant les liens<link href…>pour permettre l’aspiration du site et des ressources.Là c’est pareil, idéalement on définirait une variable dans
mes_options, et hop terminés les vilains timestamps le temps de faire l’aspiration. -
@speciale : le but du timestamp est juste d’éviter que, quand tu fais les mises à jour de ton site (soit en div, soit pendant que tu mets en ligne des articles) tu sois gêné par le cache de ton navigateur. Un logo
arton1.jpg, remplacé par une nouvelle version, est toujours le logoarton1.jpg; le timestamp ajoute la date de mise en ligne du fichier, et donc ton navigateur ne réutilisera pas la vieille image. Donc c’est bien dans lesrcde l’image que ça doit se trouver, pas dans undata-, qui n’invaliderait pas le cache. -
@arno puisque tu as un
#FILTRE{truc}dans tes squelettes, tu peux y ajouter le filtre supprimer_timestamp non ? -
@b_b : oui c’est ce que j’ai fait (expliqué plus haut), mais pas directement supprimer_timestamp, qui prend un URL en entrée, et pas l’ensemble de la page.
Mais à nouveau, ça oblige à modifier ses squelettes si on n’a pas l’habitude comme moi de mettre un
#FILTRE{mini_html}absolument partout… -
Le problème se pose aussi sur les js et css compactés et agrégés par SPIP qui ont aussi ce timestamp, mais sur lesquels il n’est pas possible de passer le filtre de suppression de ce timestamp.
Sauf erreur de ma part, le nom des fichiers créés dans local/ dépend déjà de la date des fichiers. Le timestamp est alors inutile et contre productif.
Et si le nom du fichier ne dépend pas pas de la date, il suffirait de la rajouter dans le calcul du nom, non ? -
Salut @arno*. Il est bien possible que ▻https://zone.spip.org/trac/spip-zone/changeset/104022 t’intéresse comme réponse à ton problème, d’autant plus que ça se greffe sur #FILTRE{mini_html}
-
-
Mieux qu’une barre d’édition : des raccourcis
▻http://romy.tetue.net/barre-outils-edition-raccourcisLes barres d’outils d’édition ne sont pas accessibles. Pire, elles constituent des obstacles pour certain·e·s. Si elles sont utiles à d’autres, elles ne sont pas la meilleure aide qui soit. Elles ne constituent donc pas une aide suffisante, mais secondaire ; l’aide principale doit être autre. Enfin, dans le cas où une barre d’édition est disponible, celle-ci doit être absente par défaut et affichable à la demande. Et chaque fonctionnalité devrait faire l’objet d’un raccourci documenté.
Même s’ils causent certaines difficultés, les raccourcis clavier standards sont davantage utilisables. Mieux encore, les raccourcis de saisie ou syntaxe de rédaction à balisage léger, de type wiki, sont ce qu’il y a de plus utilisable par tous et toutes. Trop peu mis en avant, ces raccourcis sont méconnus. Ils nécessitent d’être expliqués par l’interface, en contexte. Il suffit d’une phrase explicative, avant chaque champ de saisie.
#toolbar #WYSIWYG #raccourcis #syntaxes_légères
#handicap #accessibilité #a11y #ergonomie #UX #clicodrome-
Et avec une capture de @seenthis en tant que bon exemple !
-
entièrement d’accord pour les virer ; la méthode seenthis est bien mieux :)
sinon je crois qu’@arno aime aussi la barre contextuelle de medium, qui ne s’affiche que lorsqu’on sélectionne une partie de texte, et flottant au-dessus, du moins laisse-t-il ici transparaître un appétit :
▻http://seenthis.net/messages/271377 -
-
-
Industry design trends
▻http://imperavi.com/blog/industry_design_trendsEn 2012, chaque éditeur WYSIWYG était unique, mais la tendance est à l’uniformisation :
-
-
Aucun ne me convient : tous ont des « erreurs », dans le sens où aucun n’offre toutes les possibilités de mise en sens d’un texte (citation, titraille, définitions ?), offrant pourtant des possibilités de mise en forme superficielle (couleurs, retrait).
Je préfère l’approche et l’interface suggérée ici (cf. ▻http://seenthis.net/messages/158560) :
Il est quand même plus aisé de rédiger son texte au kilomètre, les mains sur le clavier, sans devoir s’interrompre tous les trois mots pour cliquer un bouton ! Bref, je préfère les raccourcis clavier aux clicodromes.
Ceci dit, cette approche n’exclut pas l’ajout d’une barre de boutons cliquables. Dans ce cas je préfère sans hésitation la dernière, celle de Redactor : simple, sans filets superflus, en une seule ligne. Ce qui me rappelle le relookage que j’avais fait de la barre typo pour SPIP 3 :
-
En y regardant de plus près, l’éditeur Redactor (dont il était déjà question ici : ▻http://seenthis.net/messages/108537) s’avère assez complet, ce que ne montrent pas les captures précédentes : titraille et citations sont bien disponibles, mais étonnamment cachées en sous-menu dépliant.
L’usage ne dément pas la simplicité apparente, c’est agréable. Par contre, c’est toujours aussi laborieux de faire une simple liste en WYSIWYG, là où des tirets à la ligne suffisent en texte brut… et je n’ai pas trouvé comment faire une liste imbriquée. Recalé ! Mais c’est très réussi pour les tableaux et l’insertion d’image : immédiatement visible, tout en restant simple. Nettement mieux que TinyMCE et CKEditor !
Râh, ça me donne envie de spécifier mon éditeur idéal !
-
Niveau ergonomie peut-être, mais ça génère encore uniquement du HTML, donc problématique quand on ne veut pas enregistrer ça (en base ou en fichier, enfin peu importe le mode de stockage).
Et sinon, la page d’accueil démarre par un livre d’Ayn Rand, #wtf ? :D
-
-
@Rastapopoulos : oui, mes considérations étaient d’ordre ergonomique, d’abord UI puis UX. Le format de contenu stocké est une autre problèmique, sans rapport direct, puisque non dépendant de l’interface (barre typo, syntaxe ou WYSIWYG). Faut pas tout mélanger.
-
@fil Oui, c’est vrai, tant que le HTML est propre, sans imbrications bizarres ni classes utilisées pour des fonctionnalités.
Mais je ne sais pas si c’est vraiment le format pivot idéal (pour générer « pas que du web », à partir de ce qui a été rédigé).
On abandonne la piste Markdown aussi alors, et on revient à du HTML uniquement ?
Bon ça ne résout pas la question des « modèles » (inclusion avec possiblement des paramètres), fonctionnalité qui n’est pas propre à SPIP, utilisée dans d’autres système (entre autre les wikimedias évidemment).
-
@tetue ce n’est pas mélangé, ça a une incidence et un rapport. En effet, un éditeur qui n’édite que du HTML, c’est beaucoup plus facile de faire du wysiwyg (ce dont on parle ici) puisqu’il édite directement ce qui sera produit au final. Alors que quand on veut un autre format, il faut forcément passer à un moment dans un compilateur (que ce soit côté client ou côté serveur) qui va produire le HTML permettant de voir (le what you see).
Ce qui fait que quand on décide que le HTML produit nous suffit, il ne reste « plus que » l’interface, l’ergonomie, à étudier. La partie technique étant à peu près résolue (mise à part pour les inclusions/modèles).
-
Il est initialement question d’interface, pas tant de l’éditeur, plus précisément de la « barre typo » (ici WYSIWYG, mais pas forcément, comme c’est le cas de SPIP, et générant… peu importe). C’est-à-dire des boutons, des pictos (symbolisant les enrichissements possibles), de leur nombre, leur répartition, leur graphisme, etc.
L’article cité montre l’évolution dernière de cet élément d’UI. On remarque une nette tendance à la simplification : moins de couleurs, moins de boutons, moins de lignes, d’encombrement, moins d’effets… Ce qui est frappant dans cette uniformisation, c’est : niveaux de gris avec accentuation du contraste négatif ayant pour conséquence de valoriser le signe, mais aussi la persistance d’un effet de relief discret, façon métal brossé, délicat, presque étonnant en ces temps de flat design. Ça n’est pas anodin.
Quels boutons mettre à dispo dans une barre typo ? Dans quel ordre les ranger ? Comment préserver la simplicité ? Faciliter l’usage ?
-
Peut-être que l’aspect bombé continue de faire consensus pour signifier que ce sont des boutons, qu’on peut appuyer dessus. Mais ça ne marche pas forcément comme explication vu que toute la barre est bombée, alors que seuls les endroits où il y a des pictos sont cliquables.
-
Oui, ça m’intrigue. D’autres exemples contemporains :
Chez Dotclear (avec syntaxe wiki2xhtml) :
Barre typo vue chez Opquast Community :
Aloha Editor (façon Word) :
Dans Redmine (avec Wiki formatting) :
-
-
