Les projets git pour SPIP
▻http://git.spip.org/gitphp
▻https://twitter.com/webelys/status/469494198459457537
Merci @azerttyu ;-)
Les projets git pour SPIP
▻http://git.spip.org/gitphp
▻https://twitter.com/webelys/status/469494198459457537
Merci @azerttyu ;-)
Oui c’est un scandale, le contributeur principal ne respecte pas les règles de commit :
–* ▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/crayons
Il faut à minima un #trunk pour avoir du #git
On peut supposer que c’est lié à l’utilisation de l’outil de migration #git-svn qui peut faire des choses très sympa en récupération de l’historique avec l’une des options ’’’—stdlayout’’’ ou ’’’-T’’’ mais bon, ça peut être aussi autre chose, je fais que supposer... c’est souvent long à procéder, et le résultat n’est pas toujours à la hauteur, surtout quand les dev n’ont pas utilisé svn « comme il faut » pour gérer tags et branches ...
ô toi qui aime l’anglais, lis donc ça : ▻https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Yop
@fil tout #VCS recommande à minima la logique trunk/branches/tags, certains plugins suivent cette recommandation, d’autres non.
Il est parfois bon d’être rationnel et si possible de suivre les bonnes pratiques.
Autre point où copierons nous la branches créée depuis git dans la version svn ?
@james #git-svn n’est pas utilisé car ne fait pas le boulot voulu. Le « layout » utilisé permet d’être bijectif :
on peut contribuer indifféremment sur la copie git ou svn c’est pareil.
Question piège : à quoi ressemblerait le « layout » pour les plugins core ? :)
Est ce qu’on doit vraiment en passer par là, je dirais oui car il nous faut être cohérent pour ne pas se mettre des traverses dans les pieds, on a assez de bâtons pour le moment.
Je regarde pour que ce soit le plus transparent possible même pour ces plugins, mais ce n’est pas trivial.
Je viens d’installer sur #spip-zone un #plugin #SPIP que j’utilise systématiquement pour mes sites en #HTML5 et #responsive : HTML5 responsive
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/html5_responsive
Il s’agit d’une petite trousse à outil des choses dont j’ai systématiquement besoin lors du démarrage de squelettes HTML5 et responsive. (Si on ne veut pas faire de responsive, ce n’est pas une bonne idée d’installer ce plugin.)
Une fois activé, le plugin ajoute directement ce qu’il faut dans #INSERT_HEAD, il n’y a rien à faire de spécifique dans les squelettes.
– D’abord, intégration de html5shiv (pour activer la prise en compte des balises HTML5 par internet explorer), et de css3-mediaqueries (pour la prise en compte des #mediaqueries par internet explorer).
– Insertion des meta-tags habituels pour un site responsive :
+ définition du viewport (attention : j’ai l’habitude d’interdire le zoom sur mes sites responsive, parce que souvent j’ai besoin de pouvoir utiliser les gestures pour autre chose dans le site – bon, si on a besoin, c’est facile à désactiver) ;
+ refuser la détection des numéros de téléphone, ça m’a toujours posé plus de soucis qu’autre chose ;
+ activer la possibilité de transformer le site Web en webapp.
– Pour l’aspect Webapp, intégration d’un petit script perso qui transforme tous les liens internes du site en action javascript, ce qui fait qu’on peut naviguer entre les pages du site sans cliquer la Webapp (sans cela, dès qu’on suit un lien du site, ça lancerait Safari).
– Comme c’est chiant à faire à chaque fois, j’intègre le meta du charset systématiquement à cet endroit.
– Et quelques lignes de CSS…
+ désactiver la « correction » de la taille des caractères ; c’est logique sur un site qui n’est pas optimisé, mais en responsive c’est pénible ;
+ tiens, désactiver le zoom sous Internet Explorer ;
+ forcer le lissage des images réduites sous IE7, parce qu’en responsive on le fait souvent.
+ et puis mes minimums : pas de marge pour le body, et pas de cadre autour des images. C’est pas directement lié au responsive, mais ce sont les seuls choses du genre « reset » que j’utilise systématiquement (je n’utilise jamais de reset.css).
Je sais qu’il y a déjà des choses dans la Zone, mais c’est un vieux truc à moi que j’utilise absolument tout le temps, et qui est bien pratique. Alors autant le partager.
(attention : j’ai l’habitude d’interdire le zoom sur mes sites responsive, parce que souvent j’ai besoin de pouvoir utiliser les gestures pour autre chose dans le site – bon, si on a besoin, c’est facile à désactiver) ;
OOOOoooooh ooouuuuh ouuuuuuh
Tu sais, quand on montre du doigt et qu’on dit « ouh ouh ». Enfin nous en maternelle on faisait ça.
Ah, je dois avoir honte, donc ? :-)
Bon, c’est pour cela que je le signale explicitement, parce que je sais bien que ce n’est pas ce qu’on fait normalement. Mais je le justifie : j’utilise le zoom pour autre chose.
Par exemple, sur Flip-Zone, si j’accepte le zoom dans la page, la navigation dans les collections ne fonctionne plus du tout :
▻http://www.flip-zone.net/fashion/ready-to-wear/fashion-houses-42/basil-soda-4242
Sur Orient XXI, le zoom doit être détecté pour zoomer la carte, pas la page :
►http://orientxxi.info/cartographie/palestine-janvier-2000,0346
Pour la Chapelle d’Écouen, pareil, si on zoom dans la page HTML, l’animation devient totalement incompréhensible :
▻http://www.musee-renaissance.fr/chapelle/tour3.html
Donc j’en ai un besoin légitime, et je préfère l’avoir par défaut, pour moi c’est plus facile de le sucrer que de devoir retrouver ce qu’il faut ajouter sinon (le code n’est pas évident évident, c’est une CSS peu connue dans IE…).
Je comprend tout à fait la logique de ton truc mais j’avoue que quand je peux pas zoomer ça m’énerve autant que quand certains trucs sont désactivés (type clic droit ou copier)…
Je viens d’installer sur #Spip-Zone les deux #javascript que j’ai modifiés pour gérer #oembed sur #Seenthis :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis/lazyoembed
Il s’agit de :
– jquery.oembed.mod.js (jquery.oembed.js modifié), qui est le script qui gère l’intégration des documents distants (vidéos Youtube, images Flickr, etc.) ;
– jquery.lazyoembed.js, qui est une version modifiée de jquery.lazyload.js : c’est ce script qui déclenche les oembed, au fur et à mesure de leur apparition dans la page, plutôt que de déclencher le truc d’un seul coup.
Je viens de poster un nouveau #plugin #SPIP sur #spip-zone : Microcache
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis/microcache
– à la base, c’est la fonction de @fil pour ►http://rezo.net,
– mais comme le nom du #microcache est facilement accessible, elle est complétée par une fonction de suppression du cache.
Sur Seenthis, c’est le système qui me permet de travailler avec des squelettes SPIP, tout en ayant à la fois :
– un système de cache statique et persistant,
– des mises à jour en temps réel (il me suffit d’effacer les fichiers microcache qui vont bien quand on poste un message).
Ah oui, ça s’utilise ainsi :
[(#ID_AUTEUR|microcache{inc/truc_auteur})]
où inc/truc_auteur.html est un squelette tout à fait classique. La valeur de l’#ID_AUTEUR est à récupérer, dans ce squelette, avec la variable #ENV{id}.
Pour effacer ce microcache, a priori ça se fait directement dans du PHP (à la validation d’un formulaire, certainement) :
effacer_microcache($id_auteur, « inc/truc_auteur ») ;
Si tu regardes le fichier /inc, tu verras qu’il y a déjà une fonction :
_esi_microcache()
qui fait exactement cela.
Mais je n’arrive pas à faire fonctionner les fonctions ESI.
Sinon, ça serait intéressant :
– puisqu’il s’agit d’un plugin, il sera sans doute possible de détecter la présence du code <esi : dans le source, et d’ajouter un header destiné à Varnish pour que celui-ci parse cette page spécifiquement ;
– ensuite, dans supprimer_microcache, être capable de forcer la purge pour cette adresse.
Et, au final, faire que ça tourne directement sur la fonction microcache, sans modification, uniquement sur une variable de configuration (pour que les mêmes squelettes fonctionnent avec ou sans ESI Varnish).
Je viens d’installer sur #spip-zone un autre #plugin #SPIP tiré du code de #Seenthis :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis/detecter_langue
Il fournit la fonction detecter_langue($texte), qui répond avec le code de la langue dans laquelle est rédigé le $texte.
L’originalité, ici, est d’avoir deux passes :
– d’abord voir dans quel alphabet le texte est rédigé majoritairement (latin, cyrillique, grec, arabe, hébreu...) ; cela permet de limiter le nombre de langues possibles ;
– ensuite une classique analyse par tri-grams, limitée aux langues déterminées par la passe précédente.
#GPL
C’est ce plugin qui indiquait l’autre jour « allemand » pour un texte en français, juste parce qu’il parlait de Berlin ? ;-)
Plus sérieusement, pourquoi mettre ces plugins dans un dossier « plugins_seenthis » sur la zone ?
J’ai déjà répondu là :
►http://seenthis.net/messages/12782
Je viens d’installer sur #spip-zone deux plugins réalisés pour Seenthis :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis
– #date_relative_dynamique est le plugin qui permet d’afficher les dates des forums sous la forme « il y a... », dynamiquement en Javascript ;
– #lien_court est le plugin qui permet de raccourcir les URL affichées. Il a deux caractéristiques marrantes : (a) l’URL est raccourcie en priorité en sucrant des éléments au milieu plutôt qu’à la fin comme on le fait d’habitude, (b) les éléments supprimés sont en réalité seulement masqués en CSS, ce qui permet de préserver l’intégralité du lien lors d’un copier-coller.
Super cool ce début d’ouverture, merci !
Par contre, pourquoi les avoir mis dans un sous-dossier « seenthis » s’ils peuvent être utilisées indépendamment, génériquement ? (Oui j’pouvais pas m’empêcher de la poser celle-là...)
Comme je disais plus tôt, là où tu lis la date au format unix
Math.floor($(this).attr("title"))
tu pourrais lire aussi la décoder si elle est au format datetime
►http://seenthis.net/messages/8747
ce qui rendra les choses plus #microformats
– parce que j’ai besoin de les identifier comme tels : ceux-là, je ne souhaite pas qu’on me les pourrisse sans me demander mon avis ; je n’ai pas le temps de suivre tous les plugins que j’ai installés sur la Zone, mais suivre un sous-dossier, ça je dois pouvoir y arriver ;
– parce que je ne suis pas encore certain que tout sera livré sous forme de plugins bien finalisés, alors un sous-dossier générique pourrait s’avérer utile.
jQuery Flot API
►http://people.iola.dk/olau/flot/API.txt
#spip #spip-zone #jquery #graphs #javascript
Lightweight markup language - Wikipedia
►http://en.wikipedia.org/wiki/Lightweight_markup_language
#spip #spip-zone #microformats #html
Compte rendu : « La typographie pour le web » | L’édition électronique ouverte
►http://leo.hypotheses.org/3002
très intéressant (mais quel donc est ce plugin SPIP qui serait trop lent ?)
#spip #spip-zone #typographie #web #font
Webmonkey Supported Microformats
►http://developer.yahoo.com/searchmonkey/smguide/supported-microformats.html
#microformats #spip #spip-zone
Mais où est passée la médiatheque de spip (projet de romy)
http://docs.google.com/present/view?skipauth=true&id=dccr995j_512m2pj7fq
#spip #spip-zone
L’une des alternatives en partie gratuite à Typekit, similaire à Google Webfonts mais bien plus complète. La prévisualisation des polices est par contre lourdingue.
#typographie #font-face