• #Plugin_SPIP #scssphp
    téléchargeable sur http://plugins.spip.net/scssphp.html
    compile en CSS et mets en cache les fichiers .scss
    grace à http://leafo.net/scssphp

    Permet d’utiliser #SASS, un #préprocesseur_CSS et ses diverses possibilités dans #SPIP,
    voir les discussions poursuivies sur seenthis à ce propos
    http://seenthis.net/messages/199765
    http://seenthis.net/messages/204846

    Les @import sont surchargeables dans les squelettes sans avoir à toucher aux originaux des éventuels #frameworks qui disposeraient de fichiers sass, par exemple #knacss
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/knacsss

    Le code de ce plugin a été pompé de celui déjà existant pour less
    http://plugins.spip.net/lesscss.html

    • Merci @rastapopoulos et @nicod_, car nos diverses discussions m’ont permis de concrétiser un peu les choses avec scss.
      Le but après avoir tenté de comprendre les imbrications actuelles entre html5/elasticité/grille/css/jsforIE, est de pouvoir simplifier la méthode de fabrication d’un site mais aussi, tenter d’échapper à Bootstrap, et faire que dans tout ce joyeux bordel l’#artisan-web (que je suis) ne se retrouve pas juste bouton pressoir ou assembleur de cascades à la chaine ;)
      Pas sûr cependant que SASS permette de faire du simple, facile pour tous, dont la relecture soit aisée, sans attaches à un framework lourd, et entre autres rêves d’indépendance, autorise à se passer des class le plus possible.
      J’ai aussi très envie d’une optimisation en légèreté avec une css de maximum… 25ko, ce qui devrait être suffisant pour : faire un beau site, alléger le poids des fichiers envoyés au serveur/client et faciliter la prise en main et la maintenance.
      Avec des structures HTML adéquates, et ta piste d’échafaudage @rastapopoulos http://seenthis.net/messages/204846#message205077 que tu nous expliqueras hein ! ça risque d’être bien sympa.

  • Modif sur mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Cette fois, c’est très spécifique : on peut appeler la fonction charger_image_lazy, qui se charge de décider s’il faut charger les images (en mode « lazy load »), en lui passant la valeur du scrollTop.

    Ça sert dans le cas où l’on a un script qui intercepte le scroll pour le gérer à la main. C’est le cas, uniquement sur interface touch, avec Skrollr. Dans ce cas, je déclenche skrollr en lui indiquant de faire ceci lors du « render ».

    var sk = skrollr.init({
       render: function(data) {
           charger_image_lazy(data.curTop);
       }
    });

    Oui, c’est un peu spécial, mais je prépare un site avec de très longues pages en mode « long form » (ou « parallax »), chargement des images en responsive et lazy load, et du coup, viili voilou.

  • About:IPFuck

    pour voir “Fire in the Blood” <http://seenthis.net/messages/201429> diffusé sur la chaîne norvégienne NRK2 j’ai utilisé, sur une suggestion de @cerdic, le #plugin #IPFuck pour #Firefox, écrit par @Paul_Da_Silva.

    Configuration : j’ai cherché une plage d’IP norvégiennes, vu sur google que les 2.151.x.x seraient identifiées comme appartenant à telenor, et lancé "about:config" pour restreindre la plage d’adresses utilisée par le plugin.

    • autre approche, finalement plus simple, pour voir un autre documentaire (toujours sur la NRK norvégienne), j’ai cherché « ip norway » sur gogogl et puis j’ai lancé la commande
      youtube-dl http://tv.nrk.no/program/KOID35000015/snowdens-store-flukt --add-header X-Forwarded-For:2.148.0.1

    • ah le son était tout pourri (il sautait toutes les 4 secondes), j’ai été obligé d’aller le chercher à part, pour ensuite l’inclure dans le fichier vidéo :

      curl -H "X-Forwarded-For: 2.148.0.1" "http://nordond10a-f.akamaihd.net/i/no/open/d6/d622370ee1f8944ce868fd5e9ca3cdd26b09a5dd/2bf18318-6991-4475-80a7-88dfdb30f422_,141,316,563,1266,2250,.mp4.csmil/index_0_a.m3u8" | grep ^http | while read i; do curl $i  -H "X-Forwarded-For: 2.148.1.1" >> sound.mp4; done
      ffmpeg -i Snowdens\ store\ flukt-KOID35000015.avi -i sound.mp4   -map 0 -map 1 -codec copy -bsf:v h264_mp4toannexb snowden.avi

      au passage j’ai découvert l’option --list-formats de youtube-dl

    • pour savoir il faut essayer — car en fait ça dépend du système qu’ils utilisent pour restreindre l’accès des visiteurs

  • Grosse modif de mon #plugin #SPIP image_responsive : il permet désormais de choisir de charger les images en lazyload
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    L’idée, c’est de transformer un des inconvénients de ce système (lancer le chargement des images après un premier rendu de la page) en avantage, et d’intégrer directement un système de lazyload : c’est-à-dire ne charger que les images qui sont réellement affichées dans les limites visibles de l’écran.

    Le plugin change de syntaxe : la deuxième variable permettait de désactiver le chargement des images haute définition, je décide de l’éliminer parce que ça ne sert à rien avec les modifs récentes (calculs et compression plus efficaces), et à la place, la seconde variable permet d’activer (si elle est mise à la valeur « 1 ») le lazyload sur cette image.

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL
            |image_proportions{16,9}
            |image_responsive{0,1})
    ]

    Ici, |image_proportions va recadrer l’image selon les proportions 16/9e, sans réduire cependant la taille de l’image.

    Et |image_responsive va fabriquer les éléments permettant le chargement d’une image responsive. Ici, la première variable (« 0 ») est la taille de la vignette chargée par défaut (avec la valeur 0, je décide de ne pas intégrer de vignette : je charge « rien.gif » à la place). La seconde variable (« 1 ») indique donc qu’il ne faut charger cette image que si elle se situe dans la fenêtre visible.

    Au passage, le javascript de lazyload est assez marrant, j’ai privilégié l’efficacité des calculs, du coup la « position » verticale de l’image dans la page est calculé une seule fois (au chargement et au redimensionnement) et stocké dans un « data-top », puis effacé. Ça évite de faire des calculs à chaque fois qu’on scrolle. En revanche, on perd potentiellement en précision (images qui se déplaceraient dans la page, ou blocs affichés/masqués).

    À noter qu’il y a évidemment une tolérance : ça charge un peu plus que l’écran visible, c’est pas la peine que les gens voient trop que les images n’ont pas été chargées.

    Enfin, il y a désormais un calcul en javascript de la hauteur des images tant qu’elles sont en "rien.gif", ça permet de calculer plus précisément le lazyload.

    Comme d’habitude, je l’utilise sur Orient XXI :
    http://orientxxi.info

    • Je me posais la question au sujet du Lazyload, si y’avait pas une autre approche envisageable (c’est peut-être la tienne et j’ai pas compris) :
      – afficher en priorité les images visibles
      – puis aller chercher et « afficher » les autres images (sans attendre que la personne scroll, donc « en-dessous » de la ligne de flottaison)

      J’ai l’impression qu’en terme de rapidité d’affichage c’est équivalent quand on arrive sur le site, mais que cette solution est plus agréable quand on scroll parce qu’on donne une chance pour que les images aient le temps de s’afficher avant (en tous cas forcément plus qu’avec le lazyload).

      C’est peut-être au niveau de la consommation de la bande passante que la solution lazyload est plus avantageuse, mais je ne sais pas quand elle situation elle est vraiment utile.

      Après je dis tout ça un peu comme ça, je sais pas précisément comment ça marche en javascript, peut-être que ce que je propose n’est tout simplement pas possible.

      Une dernière remarque : y’a déjà un plugin LazyLoad dans SPIP.
      http://contrib.spip.net/jQuery-Lazy-Load-pour-SPIP

      Il ne fonctionne pas sur les mêmes principes, mais peut-être pourrait-il être amélioré, en lui donnant des options et tout ? Ou peut-être autonomiser cette fonction si des gens veulent l’utiliser sans le reste du plugin (là encore, tout ça est peut-être trop imbriqué...) ?

      En tous cas merci pour toutes ces contributions autour des images et du #RWD.

    • En gros, ce que fait LazyLoad, c’est de lancer le script jquery Lazy Load, très connu. Mon script est très différent, et son principe de fonctionnement est également très différent, j’ai essayé d’optimiser (limiter les recalculs de positionnement) et ça doit fonctionner en responsive (donc je ne fixe pas les dimensions des images a priori).

      Ensuite, le principe du lazy load n’est pas idéal non plus dans l’absolu (notamment parce qu’il bloque le pré-chargement des images). En tout cas, le fait de charger des images progressivement avant de les afficher, c’est l’assurance de ne pas afficher toutes les images en même temps. Si on a de grosses images, ce n’est pas grave (il y a une image par « écran », plus ou moins), mais si c’est une multitude de petites vignettes (c’est le cas de Flip-Zone), la page est redessinée plusieurs fois (à chaque vignette) et c’est pénible ; en changeant d’un coup toute une série complète de « img src », j’ai bien l’impression que les navigateurs sont optimisés et assez souvent, toute une série de vignettes s’affichent d’un seul coup. Avec un preloading individuel, ça n’a pas l’air de faire pareil (une de mes versions faisait ça : préloading puis affichage). Le preloading avant d’afficher, c’est pas mal sur tout petit écran, mais ça m’a semblé au contraire très pénible sur écran normal.

      Sinon, un preloader de toutes les images, c’est une idée, mais c’est encore un autre principe à mon avis. Je n’y suis pas favorable pour l’instant : charger des trucs « en trop », c’est justement ce qu’il s’agit d’éviter avec les image_responsive (parce qu’on est sans la 3G, parce que le smartphone n’est pas très vaillant…), alors pour le coup, ne charger que si les gens scrollent réellement. Et si tu veux faire ça, à mon avis, le mieux est encore de ne pas utiliser l’option « lazyload » de mon plugin : tu laisses le comportement normal, et je suspecte que c’est plus ou moins le principe de base d’un navigateur a qui on indique tous les « img src » d’une page – il commence par les premiers et/ou les éléments visibles.

  • Je continue avec mon #plugin #SPIP « Image responsive » :

    – je sauvegarde la taille de l’image d’origine dans le code HTML (data-l, data-h) ; dans le Javascript, ça me permet d’éviter d’appeler des images à une dimension supérieure à l’image d’origine (ça marchait, mais ça fabriquait des fichiers identiques avec des noms différents) ;

    – (si je ne me suis pas raté) je détruis l’image intermédiaire après l’avoir renommée (faudrait voir à faire « rentame », plutôt, tiens… mais en faisant gaffe à pas renommer l’image d’origine) ;

    – si on a le mod Apache XSendFile (et correctement configuré) c’est désormais pris en compte et, au lieu de faire un readfile, l’action qui expédie l’image passe par X-SendFile. J’ignore à quel point ça va jouer sur la réactivité du scripte et/ou la charge du serveur. (Attention, le code à insérer dans le htaccess doit être modifié pour pouvoir utiliser XSendFile.)

  • Administrer les plugins d’un site en ligne de commande - Le blog Nursit
    http://blog.nursit.net/Administrer-les-plugins-d-un-site.html

    Deux scripts PHP utilisables en ligne de commande qui permettent de voir les plugins actifs, et d’activer ou désactiver les plugins d’un site avec quelques petites options bien utiles.

    => cf plugin [spipenconsole->http://zone.spip.org/trac/spip-zone/browser/_plugins_/spipenconsole/trunk/paquet.xml]

    #spip #serveur #administration #plugin #script #bash #commande

  • QgisCadastrePlugin/doc/index.rst at master · 3liz/QgisCadastrePlugin
    https://github.com/3liz/QgisCadastrePlugin/blob/master/doc/index.rst

    Import des données EDIGEO et/ou MAJIC (format 2012 et 2013) dans PostGIS ou Spatialite

    Chargement des données dans une projet (vierge ou existant) avec mise en forme automatique de la symbologie, étiquettes, etc. (2 styles disponibles : classique comme #cadastre.gouv.fr et orthophoto)

    Interrogation des données fiscale : recherche par lieux, adresse et propriétaire

    Édition de relevé de parcelles et de relevé de propriétaire https://vimeo.com/75004889

     (...)

    #map #qgis #plugin

  • Amélioration de mon #plugin #SPIP image_responsive : introduction d’une fonction image_reduire_net (qu’on peut extraire, parce qu’elle est très générique) : elle réunit dans une seule passe les 3 fonctions graphiques dont j’ai besoin dans ce plugin :
    – elle effectue la réduction (équivalent à image_reduire)
    – elle fait passer un filtre de netteté selon la taille de l’image (équivalent à image_renforcement, mais en utilisant la nouvelle fonction imageconvolution de PHP 5.1, certainement beaucoup plus rapide)
    – et sauvegarde directement à la qualité désirée (puisque sur Retina je sauvegarde une image très compressée).

    Du coup, on doit gagner en temps de calcul mais, surtout, en qualité d’image finale, puisqu’au lieu de 3 sauvegardes JPEG successives je n’ai plus besoin que d’une seule.

    Note : je continue à sauvegarder une version renommée de l’image finale, pour éviter de lancer la cavalerie de _image_valeurs_trans à chaque hit sur l’image.

  • Énaurme modif sur mon #plugin #SPIP « Image responsive » (oui, je suis content) :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Ça concerne le chargement des images sur écran haute définition (Retina chez Apple, mais je teste actuellement avec un Nexus 7).

    Sur un écran « normal », en admettant qu’on affiche l’image sur 512 pixels de large, le plugin va charger l’image « xxx-resp512.jpg » :


    elle pèse 22ko.

    Si on a un écran haute définition (densité 2), le javascript précédent chargeait la même image, mais en 1024 pixels de large « xxx-resp1024.jpg » (512x2) :


    et là, gros souci : elle pèse 169ko.

    J’ai déjà évoqué ces deux buts contradictoires des images reponsives :
    – ne plus charger les grandes images quand on est sur petit écran, parce que ça ne sert à rien (généralement, sur smartphone avec connexion lente),
    – mais aussi, pouvoir charger les images en haut définition sur écran haute définition. Malheureusement, le plus grand nombre d’écrans haute déf pour le moment, ce sont les smartphones.

    Donc sur smartphone, on a connexion (plutôt) lente et écran haute définition, du coup on charge des images plus grosses là où on pensait en charger des plus légères.

    La solution : si écran haute définition, alors je charger bien une image de 1024 pixels, mais en compressant le JPEG de manière beaucoup plus importante « xxx-resp512-2.jpg » :


    L’image pèse… 34ko. Ouéééé !

    Par défaut, les images JPEG traitées par SPIP sont sauvegardées avec un taux de compression de 85%, de façon à avoir de belles vignettes. Avec un taux de 50%, on gagne donc énormément en poids de fichier. Mais évidemment, on détruit largement la qualité de l’image. Sauf qu’ici, on affiche l’image sur un écran haute définition : l’œil est à ce niveau de définition incapable de percevoir la différence.

    Note : la compression à 50% n’est appliquée que si l’image d’origine est suffisamment grande par rapport à la taille cible. Avec le plugin, il n’est pas rare qu’on n’affiche finalement pas une image beaucoup plus grande que ce qu’on ciblait à l’origine (si mon image d’origine fait 800 pixels de large, que je l’affiche sur 600 pixels de large sur un écran Retina, je ne pourrai évidemment pas expédier d’image de 1200 pixels sur-compressée… donc dans ce cas je ne sur-compresse pas pour éviter que la dégradation ne devienne perceptible).

    Alors, ça ressemble à la logique des « compressive images » :
    http://filamentgroup.com/lab/rwd_img_compression
    l’article prétend qu’une image sauvegardée à un taux JPEG de 10%, affichée deux fois plus petite, est perçue comme de même qualité qu’une image sauvegardée à un taux normal. C’est peut-être vrai quand on affiche cette image sur un écran « normal » (l’image est à nouveau lissée par le fait qu’on affiche 4 pixels de l’image d’origine en un seul à l’écran) ; mais sur écran haute définition, c’est très perceptible, et on perd à mon avis carrément l’intérêt de balancer une image haute définition sur un écran retina.

    Bon, c’est en fonctionnement sur OrientXXI :
    http://orientxxi.info
    Sur écran « normal », il n’y a logiquement aucune différence. En revanche, sur écran haute définition, on charge des images visiblement beaucoup plus « nettes », « définies » (« sharp »), parce qu’avec quatre fois plus de pixels, mais quasiment de même poids (environ un tiers de plus, alors que dans la version précédente, l’écran Retina provoquait le chargement d’images 7 fois plus lourdes…).

    Je trouve que ça commence à devenir sympa.

    (Pour ceux qui avaient déjà installé/testé le plugin, penser à remodifier le fichier .htaccess, la redirection a été modifiée.)

  • Ajout à mon #plugin #SPIP image_responsive, une fonction |image_proportions
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL|image_proportions{16,9})]

    L’intérêt par rapport à image_recadre, c’est qu’il s’agit ici de modifier retailler l’image sans en diminuer la taille à des dimensions arbitraires, mais de conserver l’image aussi proche de sa taille initiale que possible.

    C’est rendu nécessaire et utilisable par le principe même du plugin image_responsive, qui va ensuite charger l’image à la taille qui va bien dans tous les cas.

  • Quelques nouveautés pour mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Que l’on utilise par exemple ainsi :

    [(#LOGO_ARTICLE_NORMAL|image_responsive{160})]

    ou :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{160,0})]

    ou :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{0,0})]

    Comme il fonctionne bien, je l’ai désormais systématisé sur Flip-Zone :
    http://www.flip-zone.net
    Si l’on affiche le site avec plusieurs tailles d’écran, on pourra voir que les images qui sont chargées sont de tailles différentes.

    Les deux nouveautés :

    – la première variable désigne la taille de l’image par défaut ; a priori, on choisit la taille minimale d’affichage (sur mobile) ; on peut désormais fixer cette valeur à 0, et dans ce cas l’image par défaut sera « rien.gif » ; au chargement de la page, donc, rien ne se déclenche, on ne charge les images que via javascript. C’est pratique si, comme sur Flip-Zone, on peut avoir des dizaines d’images sur la page ; dans ce cas, limiter le nombre de hits est sensible.

    – la seconde variable est optionnelle, et la seule option est de la mettre à zéro. Si on la fixe a zéro, cela signifie qu’on ne chargera pas les images en haute définition (écran Retina…). En effet, l’intérêt des images responsive est double : (a) charger l’image en fonction de la maquette dans laquelle elle s’affiche à l’écran (selon la taille de l’écran, une image s’affichera par exemple sur 70 pixels de large, 160 ou 524 pixels…) ; (b) charger une image de double définition si on détecte qu’on est sur un écran haute définition (dans ce cas, on a une maquette qui affiche l’image sur « 70 » pixels, mais on affiche une image de 140 pixels puisqu’il y a deux fois plus de points affichés).

    Les deux objectifs sont parfois contradictoires :
    – le point (a) permet de limiter la taille des images chargées sur petit écran,
    – le point (b) force à charger une image deux fois plus larges, donc avec 4 fois plus de pixels, sur affichage à haute définition (souvent des smartphone…).

    Du coup, on peut décider que certaines images se chargent à leur taille d’affichage, mais sans prendre en compte le fait qu’on est sur écran haute définition. Le but du plugin dans ce cas est, essentiellement, d’accélérer l’affichage sur le site.

    Sur Flip-Zone, toutes les vignettes de navigation, qui sont des images, restent en définition normale ; certes ça se voit, mais comme ce sont des photos, je pense que c’est très acceptable vu le poids gagné sur smartphone (la situation de connexion la pire). En revanche, le logo du site, lui, se charge en haute définition sur écran haute déf… parce que c’est une image qui n’est pas très lourde, et parce que c’est un lettrage, dont l’affichage est très sensible à la haute définition.

  • Un nouveau #plugin pour #SPIP, destiné à gérer des images en #responsive : Image Responsive
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Le plugin est actuellement installé sur Orient XXI :
    http://orientxxi.info

    Pour se faire une idée des problématiques :
    http://mobile.smashingmagazine.com/2013/07/08/choosing-a-responsive-image-solution

    Aucune des solutions évoquées ne me plaît, et je me suis dit qu’on a déjà dans SPIP ce qu’il faut pour s’en sortir, du coup voici une solution qui me semble intéressante.

    Notez que je suis particulièrement intéressé, ici, par des retours et des commentaires. C’est une solution très expérimentale (je l’ai codée aujourd’hui), et comme elle est du coup directement intégrée à SPIP, je pense que c’est une piste très intéressante à développer.

    Le problème à résoudre :
    – en responsive, selon la taille de l’écran, une image va s’afficher en différentes tailles ; sur la page d’accueil d’Orient XXI, c’est même très important (une même image s’affiche sur 160 pixels de large ou 460 pixels de large selon l’écran) ;
    – de plus, sur un écran haute définition, il faudrait afficher des images encore deux fois plus grandes.

    Du coup, dès qu’on commence à faire du design responsive, on a tendance à charger des images plus lourdes que ce qu’on va réellement afficher. Et ça commence à peser sur une connexion mobile pourrie.

    Noter que c’est un aspect désormais lourdement pénalisé par le calcul du PageSpeed.

    Ma solution avec ce plugin :
    – on fait passer une image (ou, si je ne me suis pas raté, un texte complet contenant plusieurs images) par le filtre |image_responsive{120}
    – cela va modifier le tag <img> :
    + le src va appeler une version réduite de l’image (ici, à 120 pixels de large),
    + l’image d’origine (celle qui est donc dans la version initiale du src) est stockée dans un data-src
    + j’ajoute une classe « image_responsive » à l’image.

    Initialement, quand on charge la page, on va charger une version déjà réduite de l’image et, idéalement, on indiquera la taille d’affichage pour smartphone.

    Une feuille de style est associée au plugin, qui force l’affichage de toutes les images de classe .image_responsive à 100% de la largeur. Attention, c’est le point vraiment important et un peu contraignant : c’est le conteneur de l’image (par exemple un <span class="logo"><img></span>) qui va déterminer la largeur d’affichage de l’image, parce que de toute façon l’image sera affichée sur 100% de cet espace. (La feuille de style va donc styler .logo éventuellement de manière responsive…)

    Une fois la page chargée, un javascript va scanner chaque .images_responsive, récupérer la largeur à laquelle elle est affichée, éventuellement multiplier par la densité de l’écran (2 pour un écran retina), et remplacer l’image par la version de cette nouvelle largeur.

    On charge donc une vignette, puis on remplace par une version de l’image à la taille exacte d’affichage.

    L’idée c’est de faire du responsive, pas du fluide. Si votre image peut s’afficher en 1000 largeurs différentes, ce plugin va finir par fabriquer 1000 fichiers graphiques différents, ce qui n’est pas forcément génial…

    – Assez simplement, là où mettait un [(#LOGO_ARTICLE_NORMAL|image_reduire{320})]
    on met maintenant un :
    [(#LOGO_ARTICLE_NORMAL|image_responsive{120})]
    (en considérant, par exemple, que 120 est la taille d’affichage usuelle de cette vignette sur un smartphone).
    Le reste des automatismes du système se charge automatiquement via le #INSERT_HEAD, donc il n’y a rien à faire, si ce n’est vérifier que les CSS sont adaptées pour forcer le dimensionnement du conteneur de l’image plutôt que l’image elle-même.

    – Important : si votre site repose sur le .htaccess (URL sans query string), il faut absolument y insérer une ligne supplémentaire. Cela permet de traiter les images derrière des URL de fichiers JPG, ce qui devrait faciliter les mises en cache.

    Avec ça, le score PageSpeed de la page d’accueil d’Orient XXI est passée de 76/100 à 94/100. Et l’impression de vitesse sur smartphone est très très nettement améliorée.

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

  • Administrer les plugins d’un site en ligne de commande - Le blog #Nursit
    http://blog.nursit.net/Administrer-les-plugins-d-un-site.html

    Deux scripts PHP utilisables en #ligne-de-commande qui permettent de voir les #plugins actifs, et d’activer ou désactiver les plugins d’un site avec quelques petites options bien utiles.

    Chez Nursit nous hébergeons plein de sites #SPIP. Et parfois nous avons besoin de modifier la configuration d’un site en activant ou désactivant un plugin sans avoir d’accès au back-office. Nous avons mis au point pour cela deux petits scripts bash qui permettent de faire cela avec un œuf de pâques bien sympathique pour migrer un site d’un serveur à un autre !

    #cli