Teddy Payet

Automatisation et scripts bash, gagner du temps au quotidien

Teddy Payet — 2024-07-15T07:00:00Z

Salut à tous ! Aujourd'hui, nous allons plonger dans l'univers fascinant de l'automatisation avec les scripts Bash. Que vous soyez un développeur web ou un administrateur système, les scripts Bash peuvent vous faire gagner un temps précieux en automatisant des tâches répétitives. Prêts à découvrir comment devenir plus efficaces au quotidien ? C'est parti !

Pourquoi automatiser avec Bash ?

Comme vous avez pu le voir en parcourant mes différents articles, j'utilise beaucoup de script bash pour automatiser des actions. J'ai une règle : "Si on réalise plus de 2 fois une action, nous pouvons l'automatiser". L'automatisation permet de se concentrer sur les tâches à forte valeur ajoutée en laissant les scripts faire le travail répétitif. Bash, l'un des langages de script les plus couramment utilisés sur les systèmes Unix et Linux, est parfait pour cela. Voici quelques avantages de l'automatisation avec Bash :

Gain de temps : Les scripts exécutent rapidement des tâches qui prendraient beaucoup de temps manuellement.
Réduction des erreurs : Automatiser minimise les risques d'erreurs humaines.
Productivité accrue : Vous pouvez automatiser les sauvegardes, les déploiements et bien plus encore.

Les bases de Bash : comment débuter ?

Pour commencer avec Bash, il suffit d'ouvrir votre terminal et de créer un fichier script. Voici un exemple simple de script Bash pour vous familiariser :

#!/bin/bash echo "Bonjour, monde !"

Enregistrez ce script dans un fichier nommé "bonjour.sh", puis donnez-lui les permissions d'exécution avec la commande suivante :

chmod +x bonjour.sh

Enfin, exécutez le script avec :

./bonjour.sh

Voilà, vous venez de créer et d'exécuter votre premier script Bash !

Automatiser les tâches courantes

Voyons maintenant quelques exemples concrets d'automatisation avec Bash.

Sauvegardes automatiques : Créez un script pour sauvegarder régulièrement vos fichiers importants.
```
#!/bin/bash tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier
```
Ce script crée une archive compressée de votre dossier et y ajoute la date du jour.
Nettoyage de fichiers temporaires : Un script pour supprimer les fichiers temporaires peut libérer de l'espace disque.
```
#!/bin/bash rm -rf /tmp/* echo "Fichiers temporaires supprimés."
```

Déploiement de site web : Automatisez le déploiement de votre site avec un script.

#!/bin/bash cd /chemin/vers/votre/site git pull origin main echo "Site mis à jour avec succès."

Vous pouvez voir aussi sur mes différents articles d'autres utilisations que j'ai avec les scripts Bash :

Meilleures pratiques pour écrire des scripts Bash

Pour que vos scripts soient efficaces et maintenables, voici quelques bonnes pratiques à suivre :

Utilisez des commentaires : Expliquez ce que fait chaque section de votre script.

#!/bin/bash # Ce script sauvegarde un dossier tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier

Vérifiez les erreurs : Utilisez des structures conditionnelles pour gérer les erreurs.

#!/bin/bash if [ -d /chemin/vers/dossier ]; then tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier else echo "Le dossier n'existe pas." fi

Créez des scripts modulaires : Évitez les scripts trop longs en les divisant en fonctions.

#!/bin/bash sauvegarder() { tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier echo "Sauvegarde terminée." } sauvegarder

Outils pour améliorer vos scripts

Plusieurs outils peuvent vous aider à écrire de meilleurs scripts Bash :

ShellCheck : Un linter pour détecter les erreurs dans vos scripts Bash. ShellCheck
Bash-it : Un framework pour améliorer votre configuration Bash avec des plugins et des thèmes. Bash-it

Pour résumer

L'automatisation avec les scripts Bash est un moyen puissant de gagner du temps et d'augmenter votre productivité. En suivant les bonnes pratiques et en utilisant les outils adéquats, vous pouvez simplifier de nombreuses tâches quotidiennes. J'espère que cet article vous a donné des idées pour commencer à automatiser vos propres tâches.

N'hésitez pas à partager vos expériences et vos scripts Bash préférés dans les commentaires. Quels sont les scripts que vous utilisez le plus souvent ? Quels défis avez-vous rencontrés ? Partageons nos astuces et apprenons ensemble !

N'attendez plus, lancez-vous dans l'automatisation et faites de Bash votre allié du quotidien !

L'automatisation avec Bash peut transformer votre façon de travailler. Partagez vos expériences, posez vos questions et construisons ensemble une communauté de développeurs plus efficaces et collaboratifs !

Photo de Gabriel Heinzer sur Unsplash

MagicMirror², configuration scriptée, 2ème partie

Teddy Payet — 2020-04-14T22:55:42Z

Comme vous le savez tous, nous sommes en confinement depuis mi-mars. Pour m'occuper un peu en chômage partiel, en plus de ma vie de famille, je me suis inscris à une groupe d'entraide sur le MagicMirror sur Facebook. J'ai eu l'agréable surprise de voir qu'un article de mon blog était cité. Merci de la confiance de ces utilisateurs !
Après quelques échanges, j'ai proposé d'expliquer plus en détail mon installation scriptée et notamment ce à quoi correspond mes différents principaux scripts.

Tout a été déposé sur github (vous pourrez trouver le lien en bas de l'article). Je reprends ici plus ou moins le contenu du fichier Readme.

Cet article est un exemple d'automatisation de la maintenance de mon installation de MagicMirror. Le dépôt github a pour but de montrer la possibilité d'automatiser la maintenance d'une installation d'un MagicMirror.

Introduction

Le dépôt s'appelle mm_config_automate. Son existence n'est que pédagogique. Il n'est en aucun cas un module de MagicMirror.

De plus, je ne suis pas responsable d'une altération de vos données. Il vous faudra tester et adapter chaque script pour correspondre à VOS attentes.

Liste des scripts

L'ensemble des scripts sont en bash. Ils restent simples à comprendre et à prendre en main avec un peu de patience et de lecture. Voici la liste des scripts :

first_install.sh
mm_reset.sh
mm_update.sh
update_files_config.sh
disk_usage.sh

first_install.sh

Ce script permet d'installer l'ensemble des éléments de base pour qu'un MagicMirror puisse fonctionner. Il est à lancer sur une installation toute belle, toute neuve d'un Raspberry Pi 3. Je n'ai pas testé sur un Raspberry Pi 4 pour le moment. Il prend en compte un Raspbian basé sur un Debian Buster (10) mis à disposition des utilisateurs en février 2020.

Il fera dans l'ordre :

sudo apt update -y : Récupère la liste des mises à jour disponibles
sudo apt upgrade -y : Installe quelques mises à jour, ne supprime pas les packages
sudo apt autoremove -y : Supprime tous les anciens paquets qui ne sont plus nécessaires
sudo apt clean -y : Cette commande de terminal libère de l'espace disque en nettoyant les fichiers .deb téléchargés du référentiel local.

Puis :

On active le son par le HDMI ;
Forcer le HDMI ;
Forcer l'affichage vertical de l'écran ;
Enlever des programmes inutiles ;
Installation de quelques packages ;
Installation de Nodejs et NPM selon la méthode indiquée ici : https://github.com/audstanley/NodeJs-Raspberry-Pi
Ajouter les binaires de node dans le PATH ;
Installation de PM2 ;
Enregistrer les variables d'environnement (le home de MagicMirror, ainsi que de PM2) ;
Création du fichier mm.sh dans /home/pi/ ;
Exécution du script d'installation du MagicMirror ;
Sauvegarder les réglages de pm2 et lancement des scripts au démarrage ;

Et enfin, on enregistre le contenu du fichier crontab.txt dans le crontab de l'utilisateur en cours.

mm_reset.sh

Ce script installe MagicMirror à partir du dépôt github dudit projet. Il s'appelle "mm_reset" au lieu de "mm_install" car il supprime le répertoire /home/pi/MagicMirror/ s'il existe. Donc, il faut faire attention à ce point si vous désirez garder une précédente installation.

A son tour, ce script va lancer une série de commandes :

Arrêt de MM grâce à pm2 stop mm ;
Effacer le répertoire de MagicMirror si existant ;
Récupération du dépôt de MagicMirror ;
Passer sur la branche develop de MagicMirror ;
Création des liens symboliques dans MM (custom.css et config.js) ;
Installation des dépendances de MM grâce à npm ;
Lancement du script d'update des modules de MM (cf. update_files_config.sh) ;
Relancer MM sur pm2.

Liens symboliques

Dans le script mm_reset.sh, il est présumé que le fichier "config.js" et le fichier de personnalisation de css vitaux à MagicMirror soient présents dans votre répertoire /home/pi/mm_config_automate/. Un lien symbolique dans /home/pi/MagicMirror/css/ et /home/pi/MagicMirror/config/ sera fait pointant vers votre répertoire mm_config_automate.

MagicMirror n'y verra que du feu !

mm_update.sh

Ce script est plus rapide. Dans ce dépôt d'exemple, il n'est pas utilisé dans le crontab. Il est à utiliser manuellement lorsque MM doit être mis à jour.

Il arrête MM par pm2, puis va dans le répertoire de MagicMirror. A partir de là, le dépôt git est mis à jour avec les derniers fichiers. Une installation et une mise à jour des packages npm sont lancées.

Cela fait, on relance MM sur pm2.

update_files_config.sh

Ce script bash est le nerf de la guerre. Crontab appellera dans notre exemple le fichier update_files_config.sh tous les jours à 00h15.

Ce script contient 2 fonctions clés :

import_module ;
delete_modules.

Après l'utilisation de ces fonctions, une boucle est lancée pour vérifier l'existence du module MMM-AlarmClock. Ce dernier peut utiliser des fichiers mp3 comme sonnerie d'alarme.

Si vous désirez ajouter des fichiers mp3 à votre convenance, il vous suffira de les copier dans le répertoire sounds de votre dépôt "mm_config_automate". Automatiquement, tous les soirs (selon le crontab mis en place), chaque fichier mp3 présent sera copié dans /home/pi/MagicMirror/modules/MMM-AlarmClock/sounds/. Vous n'aurez plus à vous soucier d'autres choses que sa bonne utilisation dans votre fichier config.js

update_files_config.sh : fonction import_module

Cette fonction bash attend un paramètre : l'url vers le dépôt git du module que vous désirez installer sur votre MagicMirror.

Par exemple, si vous désirez utiliser le module de pages de MM, vous devez indiquer dans le fichier update_files_config.sh la commande suivante :

import_module https://github.com/edward-shen/MMM-pages.git

Elle ira dans le répertoire /home/pi/MagicMirror/modules/, vérifiera si le module existe déjà (en gros l'existence du répertoire "MMM-pages") ou pas. S'il n'existe pas, elle clonera le répertoire. Puis :

Accéder au répertoire du module ;
Si un fichier package.json existe, l'installation des packages npm est lancée.

Il faudra utiliser cette fonction autant de fois que de modules désirés. Vous trouverez des exemples dans ledit fichier.
Cerise sur le gateau, si le module existe déjà, il le mettra à jour avec les derniers fichiers provenant du dépôt que vous avez indiqué en paramètre.

update_files_config.sh : fonction delete_modules

Cette fonction se lance après l'ensemble des appels à import_module. Elle a pour but de supprimer les modules présents dans /home/pi/MagicMirror/modules/ devenus obsolètes.

Comme vous le savez, pour utiliser un module dans MagicMirror, nous devons l'avoir téléchargé d'une part dans /home/pi/MagicMirror/modules/ mais d'autre part l'avoir indiqué dans notre fichier config.js.

Si le répertoire /home/pi/MagicMirror/modules/nom_repertoire/ n'est pas indiqué dans ce fichier, le répertoire sera considéré comme obsolète. Donc, qu'il peut être supprimé. La présente fonction vérifiera chaque répertoire dans modules/ à l'exclusion de :

default/
node_modules/

Cela préservera l'espace disque de votre Raspberry Pi et évitera des erreurs dans votre MagicMirror.

disk_usage.sh

Ce script permet de savoir le pourcentage d'utilisation d'espace disque. Dans le présent exemple, si le taux d'utilisation arrive à 90% de sa capacité, un email est envoyé (je vous laisse le soin de configurer le serveur d'envoi d'emails).

Il faut savoir que pm2 écrit beaucoup d'information dans les logs (cela dépend surtout des applications lancées sous pm2 mais c'est un autre sujet). En prenant cela en compte, si le taux d'utilisation excède les 90%, le script lance en premier lieu la commande pm2 flush pour vider l'ensemble des fichiers logs de pm2. Puis vérifie à nouveau le taux de remplissage. Si la commande n'a pas changé la donne, l'email est envoyé.

crontab.txt

Ce petit bout de fichier vous permet d'indiquer l'heure à laquelle vos routines doivent être mises en place.

Dans le présent exemple, voici les routines :

A 0h00 : On vérifie d'abord l'espace disque
A 0h05 : On met à jour les fichiers de mm_config_automate
A 0h10 : On importe le contenu du fichier crontab.txt dans le crontab à 00h10
A 0h15 : On peut maintenant lancer les scripts de routine (update_files_config.sh)
A 0h20 : On relance MagicMirror pour prendre en compte la configuration à jour.
Tous les mois, on redémarre le Raspberry Pi

Si vous êtes parents et/ou assujetti à des périodes de vacances et un planning différents durant ces périodes, il est possible de mettre en place un fichier de config dédié à cette période.

Dans notre exemple, le contenu de config.js et config_vac.js sont identiques. Le but est d'illustrer l'existence des fichiers selon la période. En ayant en tête les dates de vacances qui vous intéressent, vous pouvez ajouter une ligne dédiée dans crontab pour que le lien symbolique de /home/pi/MagicMirror/config/config.js pointe vers le fichier /home/pi/mm_config_automate/config_vac.js au lieu de /home/pi/mm_config_automate/config.js. Le jour où vous devez revenir au travail (donc la fin de votre période de vacances) à 00h30, il suffira de remettre le lien symbolique vers /home/pi/mm_config_automate/config.js

Exemple pour les vacances de l'Ascension de la zone C :

############### # Vacances Ascension : 20 mai 30 0 20 5 0 cd /home/pi/MagicMirror/config/; rm -rf config.js; ln -s /home/pi/mm_config_automate/config_vac.js config.js; pm2 restart mm # Rentrée : 25 mai 30 0 25 5 * cd /home/pi/MagicMirror/config/; rm -rf config.js; ln -s /home/pi/mm_config_automate/config.js config.js; pm2 restart mm

Voilà. A vous de prendre en main ce projet en le copiant dans un dépôt personnel privé et de le faire vivre.

Le projet sur github

Comme indiqué en début de cet article, les différents fichiers ont été déposé sur github. Ils ont pour but de vous aider à mettre en place votre automatisation :
https://github.com/Ybbet/mm_config_automate

Attention de ne pas mettre le projet en public si vous l'utiliser sur VOTRE installation. Préservez votre vie... privée.

A lire aussi

Plugin « Agrandir la largeur de page »

Teddy Payet — 2015-08-03T07:00:00Z

Ce plugin permet d'agrandir la largeur de la page dans l'espace privé de SPIP. Vous pourrez personnaliser cette largeur si besoin.

Pour informations, le préfixe du plugin est spip_hop. Il vient de l'onomatopée "Hop" qui, selon Wikipedia, signifie une « exclamation suggérant l'exécution d'un saut ou d'une manœuvre habile ». De par sa fonctionnalité principale "les écrans", j'aurais pu l'appeler spip_ecran mais ce terme est trop proche de l'idée "écran de sécurité" induisant ainsi l'utilisateur en erreur.
Mais "Hop" est aussi la réaction des beta-testeurs de ce plugin après son activation. "Et hop !"

Pour plus d'informations :

Créer un trunk sur la zone SPIP

Teddy Payet — 2015-07-30T07:00:00Z

Il arrive parfois que lorsqu'on a créé un plugin sur SPIP-Zone (ou qu'on veuille reprendre le développement d'un plugin sur SPIP-Zone) que ce plugin n'est pas sur la structure trunk/branches/tags. Pour reprendre ce plugin, il est conseillé de mettre le répertoire sous cette structure avant de commencer.

Un script pour les commander tous !

Au lieu de faire cela ligne par ligne, commande par commande, vous pouvez lancer un script à personnaliser selon le besoin. Les lignes de commande à taper ne sont pas forcément très nombreuses mais elles sont répétitives. Je vais de ce fait vous montrer un script bash qui simplifiera cette migration. Mais qui dit "bash", dit être donc sous un environnement UNIX : Linux, Mac OS.

Le script

#!/bin/bash
url_svn=svn://zone.spip.org/spip-zone/_plugins_/
plugin_nom=votreplugin
plugin_numero=0.9.0
svn mv ${url_svn}${plugin_nom} ${url_svn}${plugin_nom}_trunk -m "On commence la migration du plugin ${plugin_nom} en trunk/branches/tags"
svn mkdir ${url_svn}${plugin_nom} ${url_svn}${plugin_nom}/branches/ ${url_svn}${plugin_nom}/tags/ -m "On recrée le nom du répertoire ${plugin_nom} avec le répertoire branches/ et tags/"
svn cp ${url_svn}${plugin_nom}_trunk ${url_svn}${plugin_nom}/branches/v${plugin_numero:0:1} -m "On copie les fichiers du plugin ${plugin_nom} dans sa branche v${plugin_numero:0:1}"
svn cp ${url_svn}${plugin_nom}/branches/v${plugin_numero:0:1} ${url_svn}${plugin_nom}/tags/${plugin_numero} -m "On pose le tag correspondant à la version ${plugin_numero} du plugin ${plugin_nom}"
svn mv ${url_svn}${plugin_nom}_trunk ${url_svn}${plugin_nom}/trunk -m "On déplace enfin le répertoire initial vers le trunk pour le plugin ${plugin_nom} v${plugin_numero}"

Personnalisation

Il faut copier-coller ces lignes de commande dans un fichier qui aura pour extension .sh. Pour votre plugin, vous devez changer 2 valeurs :

plugin_nom : le nom du répertoire de votre plugin
plugin_numero : le numéro du plugin (sous la forme x.y.z) que vous trouverez dans le fichier plugin.xml ou paquet.xml

Vous n'avez pas besoin de changer l'URL du serveur svn de la zone sauf si le plugin que vous désirez reprendre le développement n'est pas dans le répertoire _plugins_.
Ce script va faire 5 commits au final avec les commentaires qui vont bien avec. Pour cela, ouvrez votre terminal et lancer le script que vous avez créé.

J'ai déjà éprouvé ce script à mon travail sur mes différents projets. Il est simple et efficace.

Explications

Même si le script est simple, on peut expliquer ce qui se passe et notamment l'écriture particulière de la syntaxe de bash.

Tout fichier bash commence par la ligne #!/bin/bash. Cela indique (en plus de l'extension .sh) que c'est bien un fichier… bash.
url_svn= : lorsque vous voyez un texte suivi d'un simple signe égal "=", c'est que vous créez une variable avec une valeur ;
Pour rappeler au besoin la variable, vous devez taper $ puis le nom de la variable désirée.
Pour pouvoir mettre du texte collé à votre variable, il faut mettre le nom de la variable entre accolades. Exemple : ${plugin_nom}_trunk donnera votreplugin_trunk
Si vous désirez avoir les premiers caractères de votre variable, dans le rappel de votre variable, vous pouvez utiliser la forme ${nom_variable:debut:longueur} où :
- nom_variable : le nom de votre variable ;
- debut : emplacement où commencer (0 étant le numéro du premier caractère) ;
- longueur : le nombre de caractères que vous désirez récupérer.

Plus de lecture

Le sujet du rangement sur la zone a été abordé à plusieurs reprises :

Image : © By Leroy

Squelettes "Z-core" sous SPIP 3 - astuces

Teddy Payet — 2014-01-14T12:10:10Z

Il n'est plus nécessaire, je pense, de présenter l'architecture des squelettes sous la nomenclature "Z". Beaucoup l'utilise aujourd'hui, moi le premier.

Préambule

Le plugin Z-core est l'héritage du plugin Zpip développé par Matthieu Marcillaud, Cédric Morin, Romy Têtue et un collectif SPIP. Z-core est le moteur offrant le découpage des squelettes. Il ne fournit pas de squelettes. C'est à nous ou au plugin choisi de fournir les pages qui vont bien.
C'est rapide et efficace. Il faut savoir aussi que les noms de blocs/zones ont changé par rapport à Zpip. Presque que chaque zone correspond à un répertoire.
C'est un peu complexe à appréhender au départ. Mais c'est un aspect "vite oublié" au profit de son efficacité.

Remarque

L'un des premiers jeux de squelettes offerts à la communauté SPIP utilisant cette mécanique zcore est le plugin "SPIP-r" développé par Cédric.
Toute la doc sur ce site : http://spipr.nursit.com/

Problématique

Il arrive parfois que l'on désire que la page sommaire ait sa propre architecture, différente du reste des pages classiques.
On pourrait ajouter des balises conditionnelles si on se trouve sur un #ENV{type-page}|=={sommaire} mais ça risque de faire lourd si votre mise en page est complexe.

Voici le code initial de structure.html fournit par Zcore :

[(#VAL{_Z_DOCTYPE}|defined|?{#VAL{_Z_DOCTYPE}|constant}|sinon{})][
(#SET{class,[page_(#ENV{type-page,page})[ #ENV{type-page,page}_(#ENV{composition,''})]][ composition_(#ENV{composition})]})][
(#REM) http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/]






  [ (#REM) Debut du head particulier a chaque page pour inserer un title, des css particulieres(mais surchargees), ou des js *inline* ][ (#REM) Partie commune a toutes les pages, sans env ][ (#REM) Fin du head particulier a chaque page, pour inserer des js specifiques par exemple pour inserer des js *externes* ]

Zcore renvoie vers un body.html unique pour tout le monde.
Comment dire à Zcore/SPIP qu'on veut une mise en page particulière pour le sommaire ?

Astuce

Pour cela, on peut très facilement ajouter 2 ou 3 lignes de codes pour que SPIP sélectionne le body.html approprié pour le sommaire.
Comme dit plus haut et vu dans le code initial, Z-core envoie une variable d'environnement nommé type-page.
Une page sommaire.html aura pour variable type-page=sommaire. Pour un article, nous aurons type-page=article, rubrique type-page=rubrique, etc.

Le code magique

Pour se faire, on va remplacer par ceci :

#SET{body,body}
[(#CHEMIN{body_#ENV{type-page}.html}|?{#SET{body,body_#ENV{type-page}},#SET{body,#GET{body}}})]
[(#CHEMIN{body_#ENV{type-page}-#ENV{composition}.html}|?{#SET{body,body_#ENV{type-page}-#ENV{composition}},#SET{body,#GET{body}}})]

Explications

On initialise une variable body avec pour valeur par défaut "body".
Grâce à la première balise #CHEMIN [1], on va chercher l'existence d'un body_sommaire.html. Mais avec ce code, on va aussi regarder si body_article.html, body_rubrique.html ou autre existent. Sinon, on garde body.html par défaut.
La deuxième balise #CHEMIN va plus loin en regardant s'il existe une composition en plus de notre type de page. Soit pour une composition "ma_super_compo" pour mon article, Zcore/SPIP regardera l'existence de body_article-ma_super_compo.html. Si elle n'existe pas, on garde la valeur précédente de la variable "body".

Erratum du 17/01/2014

Attention
Il n'est pas nécessaire de faire tout cela. Rendons justice en pointant vers l'article de la doc expliquant cela : http://spipr.nursit.com/framework-z...

Grâce au message de Valéry dans le forum ci dessous, j'ai fouillé un peu plus dans le code de z-core et il s'avère qu'il n'est pas nécessaire d'utiliser le code ci-dessus pour le body.html
Z-core va détecter "naturellement" et sans artifice la présence de body-rubrique.html ou body-rubrique-ma_compo.html.

Mais le code ci-dessous est toujours d'actualité :

Aller plus loin

On pourrait étendre ce principe sur les zones de découpage dans notre body.html.
En effet, on pourrait avoir besoin pour un aside, d'une composition de rubrique particulière, un autre contenu que celui donner par aside/rubrique.html. Pour cela, ajouter en début de votre fichier body.html le code suivant :

[(#SET{html,#ENV{type-page}})]
[(#SET{html2,#ENV{type-page}-#ENV{composition}})]

On instancie 2 valeurs :

"html" qui contient le type de page ;
"html2" contient le type de page et la composition associée.

A la place de de body.html, mettre .
Et la ligne juste au dessus, mettre ce code :

[(#CHEMIN{aside/#GET{html2}.html}|?{#SET{aside,#GET{html2}},#SET{aside,#GET{html}}})]

L'astuce est donc la même que plus haut. Pour une composition "ma_super_compo" pour une rubrique, on va chercher l'existence de aside/rubrique-ma_super_compo.html, sinon on prend aside/rubrique.html.

Et voilà !
A vous de tester si cette mécanique vous convient ou pas ! Pour ma part c'est testé et approuvé !

[1] La doc est par ici

Image : © Skitterphoto

SPIP - Lister toutes les tables et leurs entrées

Teddy Payet — 2013-12-06T08:00:00Z

En discutant sur l'IRC de #spip, Charles2 désirait lister une table et toutes ses entrées sur une page. Voici un bout de code qui permet de le faire.

Voici tout simplement le code qui vous permettra de faire cela :

Liste des tables et leurs valeurs
  

[(#ENV**|unserialize|foreach)
]

 [(#SELF|parametre_url{'table',''}|form_hidden)]





[(#GRAND_TOTAL) enregistrement(s) pour #ENV{table}]
#ANCRE_PAGINATION
   []   
  (#VALEUR|unique)  
 
   [(#VALEUR|sinon{' '})]    


[(#PAGINATION)]

[Aucun enregistrement dans (#ENV{table})]

(#VALEUR\|unique)
[(#VALEUR\|sinon{' '})]

Explications

La boucle "lestables" va créer un select contenant toutes les tables connues par SPIP dans sa base de données ;
La boucle "table" va lancer un requête SQL pour avoir toutes ses entrées en base ;
La boucle "thead" s'occupe d'afficher dans un… thead les noms des champs ;
La boucle "valeur" affiche… roulement de tambours… les valeurs de la table. ;-)

C'est bô SPIP !

Encore plus beau

En SPIP 2, nous avions la page ?page=table:nom_de_la_table accessible depuis l'espace public ET en étant authentifié.
Encore mieux en SPIP 3 grâce au plugin Vertèbres (intégré à la dist). Il vous suffit d'aller sur la page ecrire/?exec=vertebres et de cliquer sur la table qui vous intéresse. Et Ô magie ! Un beau tableau apparaît.
Tout cela est expliqué ici : http://www.spip.net/fr_article4453....

Ils sont bô les core-dev de SPIP !

SPIP - Documentation technique : construction des pages

Teddy Payet — 2013-12-02T11:06:17Z

Nous avons vu dans le précédent article la nomenclature pour constituer notre documentation technique. Dans le présent article, nous allons voir comment améliorer un peu les choses.

Rappel

Nous avons construis une page ?exec=vins_doc qui affichera sous forme de tableau notre documentation. La page peut être longue, très longue.
Les chaînes de langue étant construites (n'est ce pas ?), nous allons améliorer un peu l'affichage.

Amélioration

Il serait intéressant de mettre une table des matières sur cette page.

Pour cela, nous allons utiliser le zoning que nous offre les squelettes du back office de SPIP 3. Pour notre page ?exec=vins_doc, nous avons créé prive/squelettes/contenu/vins_doc.html ce qui sous-entend que nous nous sommes occupé de la zone de contenu de notre page. La structure du BO de SPIP fournit une zone d'extra et une autre de navigation.
La table des matières est un "extra" alors créons le fichier adéquate : prive/squelettes/extra/vins_doc.html
On reste sur le nom "vins_doc.html" selon la règle de SPIP.
Voici le code à y insérer :

#SET{tables, #LISTE{'vin','vins_producteur'}}  [(#BOITE_OUVRIR{<:vins:sommaire:>})]  #SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}    [(#_tables:GET{spip_table}|replace{'spip_',''}|ucfirst)]    #CLE
  
  
 
    [(#BOITE_FERMER)]

Bien, une liste est construite mais elle ne servira à rien si nous ne nous occupons pas des identifiants du contenu.

Allons dans prive/squelettes/contenu/vins_doc.html
Recherchons et remplaçons le par
Nous aurons ainsi quelques choses comme
Ça, c'est cool. Mais il faut aussi faire la même chose pour le nom de la table.
Recherchons et remplaçons le par

Voilà ! C'est nettement mieux.

Et une version texte ?

Cette page en tableau est très pratique à la lecture mais on peut avoir le besoin de créer un fichier word avec du texte au kilomètre.
Nous avons la structure de code qu'il faut pour cela. On ne va pas réinventer la roue. Il suffit de renommer la structure html.

Nous n'allons pas perdre le code que nous avons déjà réalisé. Transformons-le en inclure et affichons conditionnellement le type d'affichage désiré.

Coupons-collons le code suivant de notre page contenu/vins_doc.html dans prive/squelettes/inclure/vins_doc_tableau.html

  #SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}      #_tables:GET{spip_table}  [(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]  [(#VAL{#GET{prefixe}}|concat{':definition_mysql'}|_T)]  [(#VAL{#GET{prefixe}}|concat{':label_label'}|_T)]  [(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]  
  #CLE  #VALEUR  [(#VAL{#_tables:VALEUR}|concat{':label_',#CLE}|_T)]  [[(#VAL{#GET{prefixe}}|concat{':aide_a_la_saisie'}|_T)]
 (#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_explication'}|_T)
] [[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]
 (#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_documentation''}|_T)]

#_tables:GET{spip_table}
[(#VAL{#GET{prefixe}}\|concat{':nom_du_champ'}\|_T)]	[(#VAL{#GET{prefixe}}\|concat{':definition_mysql'}\|_T)]	[(#VAL{#GET{prefixe}}\|concat{':label_label'}\|_T)]	[(#VAL{#GET{prefixe}}\|concat{':documentation'}\|_T)]
#CLE	#VALEUR	[(#VAL{#_tables:VALEUR}\|concat{':label_',#CLE}\|_T)]	[[(#VAL{#GET{prefixe}}\|concat{':aide_a_la_saisie'}\|_T)] (#VAL{#_tables:VALEUR}\|concat{':label_',#CLE,'_explication'}\|_T) ] [[(#VAL{#GET{prefixe}}\|concat{':documentation'}\|_T)] (#VAL{#_tables:VALEUR}\|concat{':label_',#CLE,'_documentation''}\|_T)]

Transformons les #GET{prefixe} en #ENV{prefixe} et le #GET{tables} en #ENV{tables}
Dans contenu/vins_doc.html, faisons l'appel à l'inclure vins_doc_tableau.html :

Simple, non ?

Nous avions parlé d'un texte au kilomètre, alors créons sur le même modèle le fichier inclure/vins_doc_texte.html en dupliquant inclure/vins_doc_tableau.html et apportons-y quelques modifications.

Remplaçons

par

Remplaçons

Supprimons les maintenant.
Le ... qui ne sont plus nécessaires.
Normalement, nous ne rencontrons pas de difficultés particulières ici. Ce n'est que du code html. Notre inclure est prêt.

Revenons sur la page contenu/vins_doc.html pour y apporter quelques améliorations. Nous pourrions ajouter un autre inclure pour notre texte pour l'avoir sur la même page. Mais avoir la même information en doublon ne sert à rien. Alors nous allons faire un petit formulaire qui indiquera quel type d'affichage prendre en compte.
Voici le code :

	
 [(#SELF|parametre_url{affichage,''}|form_hidden)]  <:vins:affichage:>

A partir de là, nous modifions l'inclure dans contenu/vins_doc.html :

Avec ce code, SPIP ira chercher l'inclure « tableau » si nous n'avons pas dans l'url le paramètre affichage.

Et voilà, on peut changer l'affichage de notre documentation en 2 coups de cuillère à pot.

Conclusion

Avec cette méthode, il est simple de faire une documentation. Cela ne nous dispense pas de son écriture bien entendu. Mais cela permet d'avoir la documentation directement dans le plugin. Ces différents squelettes et chaînes de langue ne sont que du texte, ce qui ne va pas alourdir à outrance le poids des fichiers du plugin.
On peut même étoffer la documentation annexe avec des inclure pour des éléments qui ne sont pas issus des tables en elles-mêmes mais de fonctions, d'interface, etc.
Je n'ai plus qu'une dernière à vous dire : Bonne documentation ! :-P

Vous pouvez lire aussi :
– SPIP - Documentation technique : nomenclature
– SPIP - Documentation technique : construction des pages
– SPIP - Documentation technique : mise en conformité

SPIP - Documentation technique : nomenclature

Teddy Payet — 2013-12-02T07:02:42Z

Lorsque nous avons l'utilité d'un nouvel objet (éditorial) dans SPIP, il est plus simple et même conseillé de passer par la création d'un plugin.
A force de créer des plugins, je me suis créé une nomenclature d'écriture des fichiers. En fait, je n'ai rien inventé de particulier. La base des fichiers est créée par le plugin "La Fabrique" (merci marcimat !).

Préambule

Malgré un titre "racoleur", cet article ne va pas traiter de la nomenclature d'écriture des fichiers de SPIP mais d'une nomenclature que j'ai mis en place personnellement.
Si vous désirez avoir des informations particulières sur la nomenclature de SPIP (ses API, etc.), je vous conseille quelques sites :
– Programmer avec SPIP ;
– Documentation du code de SPIP ;
– Autodoc de SPIP : une zone particulière de code.spip.net. Il est autoalimenté par le PHPDoc inséré dans le code source de SPIP.
– SPIP-Contrib ;
– L'annuaire des plugins de SPIP.

De plus, je ne traitera pas non plus de l'utilisation du plugin La Fabrique. Sa page de documentation est très complète.

Contexte

Pour l'expression de cette nomenclature, je prendrai pour ligne de conduite la création d'un objet "vins". Cela sera plus parlant. Je me réfèrerai, sauf mention contraire, toujours à cet objet éditorial.
Le but de cet article n'est pas la création d'un plugin mais la méthodologie pour une bonne nomination des fichiers et des chaines de langue associées.
De ce fait, nous partons de zéro pour arriver à la fin de ce cycle à la réalisation de l'affichage de la documentation technique.

Vif du sujet

La Fabrique crée les bons fichiers selon les API de SPIP. Au départ c'est un "clicodrome". Mais il ne nous dispense strictement pas de penser, au préalable, notre structure de données. On ne fonce pas tête baissée dans un projet.

Dans le formulaire "Ajouter un objet éditorial", nous pouvons rajouter tous les champs nécessaires :

nom
millésime
id_producteur
id_couleur
id_appellation
id_region
etc.

Une des premières choses à laquelle je fais attention autant que possible est le respect de "id_objet". La Fabrique créera la table spip_vins (au pluriel) associé à mon objet "vin". De là, il crée un ID : id_vin (mon équivalent à "id_objet" cité en début de paragraphe.)
Surtout, ne modifions pas cela même si la Fabrique nous le permet. Vous comprendrez pourquoi un peu plus loin.

Ici, ce n'est pas tellement le nom et/ou le nombre de champs qui m'intéresse dans "ma" nomenclature. Le but de cette dernière est de générer semi-automatiquement une information technique sur la table et ses champs grâce aux fichiers de langue.

La Fabrique adopte donc la philosophie des API de SPIP. Lorsque nous respectons "id_vin" pour l'objet "vin", la Fabrique créera les fichiers :
– lang/vin_fr.php : toutes les langues liées à l'objet "vin" ;
– lang/vins_fr.php : toutes les chaînes liées au plugin ayant le préfixe "vins" ;
– lang/paquet-vins_fr.php : les chaînes de langues généralement utilisées dans paquet.xml.

Si nous n'avions pas utilisé "id_vin" mais par exemple "ref_vin", la Fabrique aurait créé le fichier lang/ref_vin_fr.php… ce qui ne nous aurait pas arrangé pour la suite. J'ai rencontré ce cas récemment.

Un objet, deux objets, etc.

Pour aller un peu plus loin, nous allons créer une table pour les producteurs de vins. Nous nommerons cette table spip_vins_producteurs, l'objet associé sera "vins_producteur". Laissez-le tel quel.
Lorsque nous serons dans l'espace privé de SPIP sur la fiche d'un producteur, nous aurons une URL de type ?exec=vins_producteur&id_vins_producteur=XX

Remarque

J'aurai pu créer la table spip_producteurs. Mais le soucis est que ce nom est trop générique et pourrait se télescoper avec une autre table qui n'a rien à voir avec notre plugin.

Vous aurez compris que l'ID du producteur est sous la forme "id_vins_producteur". La Fabrique a enlevé le "s" final à producteur.

Normalement, vous m'avez suivi sans trop de soucis jusqu'à maintenant sans pour autant savoir où je voulais en venir. Pas vrai ? ;-)
Alors, continuons :

Pour la chaîne de langue de l'objet "vins_producteur", la Fabrique va créer lang/vins_producteur_fr.php.
Ça ne vous rappelle rien ? Je vous aide un peu : lang/vin_fr.php… lang/objet_fr.php

C'est la règle d'écriture adoptée par la Fabrique.

Rappel

Dans mes précédents articles, je vous avez montré (grâce à b_b, denisb et kent1) comment reconstruire une chaîne de langue pour l'afficher sur notre page :
[(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]

On ne change pas une équipe qui gagne.

Créer les chaînes de langue

Nous allons utiliser cette même règle pour construire notre documentation technique. Une sorte de PHPdoc "linguistique" à la SPIP.

Remarque

Mon but dans cette nomenclature n'est pas de documenter des fonctions (au sens PHP) car il existe des méthodes robustes aujourd'hui. SPIP a adopté, sous l'impulsion de Marcimat, PHPDoc pour cette documentation.

Dans ma documentation technique, en fait, je désire afficher 4 choses dans un tableau :

le nom du champ ;
son label ;
sa définition MySQL ;
son aide à la saisie (explication) ;
et sa documentation.

Pour cela, on va prendre l'habitude d'écrire nos chaînes de langue sous la forme :

label_champ
label_champ_explication
label_champ_documentation
La définition MySQL du champ est directement issu des variables globales de SPIP ce qui rend inutile de créer une chaîne de langue pour elle. Nous aurons alors 3 chaînes de langue par champ.

Donc, soit pour notre objet vin, nous aurons :

label_id_vin
label_id_vin_documentation
label_id_vin_explication
label_nom
label_nom_documentation
label_nom_explication
label_millesime
label_millesime_documentation
label_millesime_explication
etc.

Dans les fichiers de langues adéquates, nous devons y renseigner ce dont nous avons besoin.

Afficher le contenu sur la page de documentation

Bon, tout est prêt maintenant pour construire notre page, y compris le contenu. Nous devons maintenant créer un fichier "prive/squelettes/contenu/vins_doc.html". Voici le code à y insérer :

[(#SET{prefixe,'vins'})]
<h1>[(#VAL{#GET{prefixe}}|concat{':documentation_technique'}|_T)]</h1>
#SET{tables, #LISTE{'vin','vins_producteur'}} <B_tables>
<BOUCLE_tables(DATA) {source table, #GET{tables}} {si #SESSION{webmestre}|=={oui}}>
#SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}
<B_info_table>
<table>
<BOUCLE_info_table(DATA) {source table, #EVAL{$GLOBALS['tables_principales'][#GET{spip_table}]}}{cle==field}> <caption>#_tables:GET{spip_table}</caption>
<thead> <th>[(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':definition_mysql'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':label_label'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]</th>
</thead>
<B_label>
<BOUCLE_label(DATA) {source table, #VALEUR}>
<tr>
<td><strong>#CLE</strong></td>
<td><em>#VALEUR</em></td>
<td>[(#VAL{#_tables:VALEUR}|concat{':label_',#CLE}|_T)]</td>
<td>[<strong>[(#VAL{#GET{prefixe}}|concat{':aide_a_la_saisie'}|_T)]</strong><br/>
(#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_explication'}|_T)<br/>]
[<strong>[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]</strong><br/>
(#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_documentation''}|_T)]</td>
</tr>
</BOUCLE_label>
</B_label>
</BOUCLE_info_table>
</table>
</B_info_table>
</BOUCLE_tables>
</B_tables>

Ce code va construire le tableau comme prévu.
Sur cette page, on peut voir que parfois la chaîne de langue ne s'affiche pas. En tout cas, pas son contenu mais bel et bien la chaîne en elle même sans les underscores. Exemple : label id vin, label id vin documentation, label id vin explication.
La raison en est très simple : nous n'avons pas encore renseigné cette chaîne de langue.
Mais parfois, nous n'avons rien à dire de particulier sur un champ. Il parle de lui même. Alors l'astuce est de créer tout de même cette chaîne de langue dans le bon fichier et de mettre un espace blanc/vide, soit 'label_id_vin_documentation' => ' '.

Astuce

Pour ceux qui ont lu le code ci dessus, vous avez pu voir un [(#SET{prefixe,'vins'})]. En fait, ceci est pour nous simplifier la tâche si on désire mettre ce bout de code dans un autre plugin. Il nous suffira de mettre le préfixe de notre nouveau plugin ici pour que la chaîne de langue se construise.

Remarque

Denisb nous a rappelé l'existence depuis SPIP 3.0.13 d'une nouvelle écriture de construction d'une chaîne de langue. Vous pouvez voir son commentaire ici et ici.

La page étant construite, il nous faut maintenant compléter nos différentes chaînes de langue. Alors à vos claviers et rendez-vous dans mon prochain article.

Vous pouvez lire aussi :
– SPIP - Documentation technique : nomenclature
– SPIP - Documentation technique : construction des pages
– SPIP - Documentation technique : mise en conformité

Afficher les champs d'un objet #SPIP v2

Teddy Payet — 2013-11-26T08:00:00Z

Dans la même trempe que Afficher les champs d'un objet #SPIP, je vais prendre le même principe mais l'étendre en affichant une chaîne de langue… Tout un programme.
J'ai réussi cette performance grâce au code que m'a donné kent1. Merci à lui pour ce code.

L'utilité de cette boucle est de lister les différents champs d'un objet sur sa page de vue. Exemple : ?exec=projet_site&id_site=XX

L'espace privé de SPIP 3 étant géré par des squelettes, il suffit de créer un fichier /prive/squelettes/extra/projet_site.html avec le code suivant :

[(#BOITE_OUVRIR{[(#VAL{#ENV{exec}}|concat{':label_',#ENV{exec},'_champs'}|_T)],'info','titrem'})]
[(#ENV{singulier}|=={oui}|non)
[(#SET{valeurs,#VAL{#ENV{exec}}|concat{'s'}|description_table|table_valeur{field}|array_keys|print})]
][(#ENV{singulier}|=={oui}|oui)
[(#SET{valeurs,#VAL{#ENV{exec}}|description_table|table_valeur{field}|array_keys|print})]
]
[(#SET{tableau,#GET{valeurs}|explode{', '}})]



#VALEUR : [
(#VAL{#ENV{exec}}|concat{':label_',#VALEUR}|_T)]



[(#BOITE_FERMER)]

Structure à respecter

En premier lieu, il faut avoir le fichier de langue nommer sous cette forme : lang/projet_site_fr.php. Puis chaque champ doit avoir son label : label_champ, soit label_id_site, label_logiciel_nom, label_logiciel_version, etc.
Après cela, tout roule !

L'astuce magique de kent1

Je vous avais dit que kent1 m'avait communiqué un code qui permettait de reconstruire une chaîne de langue. Voici ce bout de code :
[(#VAL{#ENV{exec}}|concat{':label_',#VALEUR}|_T)]
L'application du filtre |_T permet de transformer notre variable en chaîne de langue. Magique !

Afficher les globals tout en boucle SPIP

Teddy Payet — 2013-11-15T17:11:41Z

Lorsqu'on fait un développement PHP, on a besoin parfois de savoir ce qu'on a dans nos $GLOBALS. Il en va de même lorsqu'on est en développement avec SPIP. Voici un bout de code qui peut dépanner.

Préambule

Il existe des solutions plus poussées comme les logiciels IDE qui permettent de voir les fonctions appellées dans la page. Malheureusement, on n'a pas toujours la possibilité de coder avec ces logiciels dans l'infrastructure où nous sommes.
Dans SPIP, on peut même utiliser le plugin Test Builder pour créer... nos tests. C'est super pratique quand on a pris le coup de main.

Mais voilà... Ca, c'est dans le meilleur des mondes. Parfois, tout cela n'est pas possible ou on a juste besoin d'une information sans avoir à utiliser un couteau Suisse(c) là où un cure-dent suffirait.

Le code

Pour faire illustrer notre exemple, on va créer dans notre répertoire squelettes l'arborescence suivante :

squelettes/
- prive/
  - squelettes/
    - contenu/
      - globals.html

Le fichier globals.html contiendra, soyons originaux, l'affichage de nos globals. Tout se fera par cette page.

Pour l'appeller, aller à l'adresse ecrire/?exec=globals. Comme le fichier est vide, vous devriez peut-être avoir une erreur ou au mieux une page "blanche".

Voici le code à insérer dans la page globals.html :

 
  #SET{global,$GLOBALS[#ENV{index}]}  #SET{global,$GLOBALS}    Index des $GLOBALS
 
 [(#SELF|parametre_url{'index',''}|parametre_url{'affichage',''}|form_hidden)]     
  [(#SET{nom_index,#VAL{"'"}|concat{#ENV{index},"'"}})] #SET{datatype,$GLOBALS[#GET{nom_index}]} [(#ENV{index}|non) $GLOBALS [ 
(#EVAL{$GLOBALS}|gettype)] 
 ] [(#ENV{index}|oui) [(#GET{datatype}) [ 
(#EVAL{#GET{datatype}}|gettype)] 
] ] [(#ENV{affichage}|=={var_dump}|oui) [(#EVAL{#GET{global}}|print|sinon{'vide'})
] ] [(#ENV{affichage}|=={cles}|oui) [(#EVAL{#GET{global}}|array_keys|foreach|sinon{'vide'})
] ] [(#ENV{affichage}|non) [(#EVAL{#GET{global}}|array_keys|foreach|sinon{'vide'})
] ]

Explications

La boucle "index"
Elle va tout simplement regarder si on a passé un paramètre index dans notre URL. Si oui, on affichera le contenu de $GLOBALS[#ENV{index}]. Sinon, on prend $GLOBALS.

La boucle "form"
Elle va créer un formulaire avec 2 champs select. Le premier select listera tous les "index" de notre super variable PHP $GLOBALS.
Le deuxième select se charge d'indiquer quel type d'affichage désire-t-on avoir pour notre variable :
– var_dump : pour les utilisateurs PHP, cela parle de source : "affiche les informations structurées d'une variable, y compris son type et sa valeur." Sauf que dans notre cas, on n'a pas le type :-P
– cles : affiche le tableau associatif des clés de notre variable.

Les ENV
Les #ENV après notre boucle "form" vérifie la présence du paramètre "affichage" dans notre url. Selon sa valeur, on affichera d'une certaine façon le contenu de notre variable.

Le javascript
Le javascript en fin de page va juste changer la sélection du deuxième select selon le type de variable qu'on aura. Si notre variable est de type array, le select affichage sera "cles". Tous les autres types (Object, string, etc.) auront un affichage "var_dump".

Fini...

Ce code vous permet donc depuis l'espace privé d'avoir les globals. Mais il vous suffit de faire une page accessible sur la partie publique de votre site avec exactement le même code pour avoir les globals dans cet environnement.

Encore une fois, ce n'est qu'une astuce parmis d'autres. Si vous en avez aussi, elles sont les bienvenues en commentaires !
Cela permettra d'avoir d'autres pratiques de développeurs SPIP/PHP.

par un
en gardant le id.
Le premier
devient un et nous lui appliquons aussi le id issu de
de la définition mysql devient un Le	de l'aide de saisie et de la documentation devient un . Devant `#CLE` de la boucle `info_table`, mettons `[(#VAL{#ENV{prefixe}}\|concat{':nom_du_champ'}\|_T) : ]`. Devant `#VALEUR` de la boucle `info_table`, mettons `[(#VAL{#ENV{prefixe}}\|concat{':definition_mysql'}\|_T) : ]`. Tout cela fait, on peut supprimer les lignes

Teddy Payet

Automatisation et scripts bash, gagner du temps au quotidien

Pourquoi automatiser avec Bash ?

Les bases de Bash : comment débuter ?

Automatiser les tâches courantes

Meilleures pratiques pour écrire des scripts Bash

Outils pour améliorer vos scripts

Pour résumer

MagicMirror², configuration scriptée, 2ème partie

Introduction

Liste des scripts

first_install.sh

mm_reset.sh

mm_update.sh

update_files_config.sh

update_files_config.sh : fonction import_module

update_files_config.sh : fonction delete_modules

disk_usage.sh

crontab.txt

Le projet sur github

A lire aussi

Plugin « Agrandir la largeur de page »

Créer un trunk sur la zone SPIP

Un script pour les commander tous !

Le script

Personnalisation

Explications

Plus de lecture

Squelettes "Z-core" sous SPIP 3 - astuces

Préambule

Remarque

Problématique

Astuce

Le code magique

Erratum du 17/01/2014

Aller plus loin

SPIP - Lister toutes les tables et leurs entrées

Liste des tables et leurs valeurs

(#GRAND_TOTAL) enregistrement(s) pour #ENV{table}

Explications

Encore plus beau

SPIP - Documentation technique : construction des pages

Rappel

Amélioration

Et une version texte ?

en gardant le id. Le premier

et nous lui appliquons aussi le id issu de

Conclusion

SPIP - Documentation technique : nomenclature

Préambule

Contexte

Vif du sujet

Un objet, deux objets, etc.

Remarque

Rappel

Créer les chaînes de langue

Remarque

Afficher le contenu sur la page de documentation

Astuce

Remarque

Afficher les champs d'un objet #SPIP v2

Structure à respecter

L'astuce magique de kent1

Afficher les globals tout en boucle SPIP

Préambule

Le code

Index des $GLOBALS

$GLOBALS [ (#EVAL{$GLOBALS}|gettype)]

(#GET{datatype}) [ (#EVAL{#GET{datatype}}|gettype)]

Explications

Fini...

en gardant le id.
Le premier

$GLOBALS [
(#EVAL{$GLOBALS}|gettype)]

(#GET{datatype}) [
(#EVAL{#GET{datatype}}|gettype)]