Julien FALCONNET, Informaticien Indépendant

SPIP : Migrer une alteration de la dist vers Spip3

Julien Falconnet — 2014-10-12T12:43:11Z

La "dist" est l'ensemble de squelettes qui va avec SPIP. C'est un travail exceptionnel dont on doit l'essentiel à Romy. Ce canevas présente beaucoup d'avantages : il est disponible tout de suite, il est très bien référencés par les moteurs de recherche, il est standard, couvre tous les aspects de SPIP, certains plugins se basent sur des choix qui y sont proposés, etc...

Et en cherchant un peu, il est facile de l'altérer au niveau CSS pour avoir rapidement un site personnalisé. Par contre, la structure de la DIST a beaucoup changé en passant de SPIP2 à SPiP3.

Voici donc pour ceux qui étaient habitués à travailler sur la DIST quelques remarques !

CSS

Tout d'abord les css ont évoluées, elles ont une structure complètement différentes. Exit habillage.css et ses copines. Pour plus de détails : http://romy.tetue.net/la-methode-daisy-appliquee-a-spip

Pour aller vite, disons que les modifications que l'on était habituées à mettre dans une copie d'habillage (squelettes/habillage.css) vont maintenant dans perso.css (squelettes/css/perso.css)

#page devient .page
#entete devient .header
#pied devient .footer

Squelettes

Plugins et traceurs

Si vous aviez l'habitude d'insérer vos traceurs dans inc-pied.html, il faudra les mettre désormais dans inclure/footer.html

Bonnes pratiques SVN

Julien Falconnet — 2014-09-01T12:41:00Z

Après quelques mois d'utilisation de SVN sur divers projets, dans différentes situations : seul, à plusieurs, en pilotage, etc. j'ai fini par me faire une liste de petites recettes pour que cela marche mieux.

Quand utiliser SVN ?

– au delà d'un jour de travail prévu.
– Dès qu'on atteint trois jours de dépassement

Quand utiliser Track/Redmine

– au delà d'une semaine de travail
– dès qu'on est deux à travailler dessus et qu'une analyse est nécessaire
– dès qu'une recette est prévue.

Comment soumettre (ou 'commiter' en bon franglais)

– dès que le code est stable.
– dès que l'on peut dire "J'ai fait ça !"

Plus précisément, dans la plupart des cas, pour une nouvelle fonctionnalité, il faudra soumettre :
– Quand on a créé la(les) fonction(s) vide(s) (de préférence commentée). En effet en créant les fonctions vides d'abord, on limite les risques que les modifications touchent celles des autres, et donc qu'il y aie conflit.
– Dès qu'on a finit une fonction. En commençant par les fonctions de bibliothèque. En effet les fonctions de bibliothèques doivent être développées avant d'être intégrées, de sorte à ce que l'intégration ne provoque pas d'erreur en attendant d'être développées.
– Quand l'intégration sera finie. Il est important de soumettre l'intégration en toute indépendance pour permettre d'annuler cette intégration en une seule annulation de commit. Si on mélange intégration et débogage on risque de perdre le débogage en annulant l'intégration.

Pour un débogage
– une soumission par bug, sauf si le bug est complexe, c'est à dire composé de plusieurs bugs, alors on fera une soumission par sous-bug.

Pour une amélioration
– soumettre à chaque fois que l'amélioration est stable.

...

Migrer un serveur de production

Julien Falconnet — 2013-10-31T11:48:02Z

Ca y est ! L'heure fatidique est arrivée, votre serveur web de production doit migrer vers un nouveau serveur. Quelques nuits blanches en perspective et une bonne dose d'adrénaline dans le sang vous décidez enfin de prendre le taureau par les cornes.

Voici quelques étapes que j'ai du mettre en place.

Cadre

La migration s'effectue entre deux serveurs chez online.net. L'ancien (que l'on appellera Aragorn) part à la décharge, ils m'en ont gracieusement proposé un nouveau (que l'on appellera Elessar) plus puissant sensiblement au même prix. Par contre, c'est un serveur dédié donc à moi le cambouis de la migration.

Au niveau système d'exploitation, on en profite pour passer de Debian 6.0.7 à Debian 7.2

Aragorn : GNU/Linux 2.6.32-5-amd64
Elessar : GNU/Linux 3.2.0-4-amd64

Etape 1 : installer le nouveau serveur

installer le nouveau serveur(Elessar) ici un Debian 7.2

Pour online, l'installation se fait par l'interface l'hébergeur.
Ensuite première connexion en ssh root
Mise à jour des paquets
```
apt-get update
apt-get upgrade
```

Prendre quelques informations sur la machine (et bien les garder quelque part)

uname -a
more /etc/debian_version cat /proc/cpuinfo free
free -h
more /etc/debian_version
/sbin/ifconfig df df -h
netstat -ltp

Sécuriser ssh
- Installer un accès par clef sur un des utilisateur (Attention ne pas sauter cette étape sinon vous n'aurez plus accès à votre machine)
```
ssh-copy-id utilisateur@000.000.000.000
```
- Modifier l'accès ssh pour : changer le port par défaut, empêcher le login root et empêcher le login par mdp.
```
vi /etc/ssh/sshd_config >>Port {XXXX} (ou XXX est un port non standart)
...
>>PermitRootLogin {{no}} ...
>>PasswordAuthentication {{no}}
```
- Relancer le serveur ssh pour que les modifications soient prisent en compte
```
/etc/init.d/ssh restart
```
- modifier en local dans .ssh/config le numéro du port
- Tester une connexion par clef.
  PS : pourquoi sécuriser tout de suite ? Parce que si vous vous trompez vous êtes bon pour recommencer l'installation.
Vérifier le bon fonctionnement d'exim
- Reconfigurer pour permettre à vos site d'envoyer des mails
```
 dpkg-reconfigure exim4-config
```
- Pour tester :
```
echo "Un message de test" | mail -s "sujet de test" vous@mail.tld
```

Installer les paquets nécessaires :

LAMP : jouer sur les dépendances pour installer le nécessaire
```
apt-get install mysql-server phpmyadmin
```

NodeJS :

apt-get install mongodb build-essential git
wget http://nodejs.org/dist/v0.10.18/node-v0.10.18.tar.gz
tar xvf node-v0.10.18.tar.gz pushd node-v0.10.18/
make
make install

Sécuriser les applications serveurs

PhpMyadmin : changer au moins la ligne d'alias

vi /etc/apache2/conf.d/phpmyadmin.conf >> Alias /unnomquinarienavoiravecphpmysql /usr/share/phpmyadmin

Apache : modifier les lignes

vi /etc/apache2/conf.d/security
...
>> ServerSignature Off
...
>> ServerTokens Prod vi /etc/php5/apache2/php.ini ...
>> expose_php = Off

ps : attention il existe des guides bien plus sérieux de sécurisation d'un serveur, je n'indique ici que ce dont j'ai eu besoin.

Étape 2 : en faire le plus possible sans toucher à rien d'important

faire un maximum de sauvegardes de l'ancien (Aragorn), un Debian 6.0.7.
- tar -cvzf backup_etc.tar.gz /etc/
- tar -cvzf backup_var.tar.gz /var/ (on peut faire mieux)
- tar -cvzf backup_web.tar.gz /sites/ (pour moi le répertoire où sont stockés mes sites)
Préparer les noms de domaine
- Modifier la zone pour que ww.ndd.tld (avec 2w) redirigent sur le nouveau serveur (Elessar). Faire cela pour tous les sites qui tournent normalement sous www. Si vous avez d'autres sous domaines trouvez une variantes proche (avec un 2 à la fin par exemple).
- Pour chaque registrar impliqué (gandi, phpnet,etc)
- Si possible, préparez vos nouveaux "fichiers de zone DNS" pour ne plus avoir qu'à les activer. (ou les www dirigent sur le nouveau serveur, Elessar )

Ramener la configuration des sites
- établir un lien ssh entre les deux.
- les vhosts récupérer scp -r aragorn.dom.tld:/etc/apache2/sites-available/ /etc/apache2/sites-available/
- les fichiers des sites scp -r aragorn.dom.tld:/sites/* /sites/
- corriger les vhost htaccess pour qu'ils supportent les ww.
- comparer les /etc/apache2/mods-enabled/ pour réactiver tous les modules nécessaires (rewrite, proxy, etc)
- Remettre en place un système de sauvegarde !!!

Faire une première importation temporaire des bases de données pour pouvoir tester que les sites fonctionnent
- ssh aragorn.dom.tld 'mysqldump -q --skip_trigger -u root -p --database db1 --database db2 --database etc | mysql -u root -p
- Si vous avez importé la base mysql (important pour les user et leur droits sur les bases), les passwords risquent de ne plus fonctionner si comme moi vous passez d'une version 5.1 à une version 5.5. Vous pouvez utiliser la commande mysql_upgrade -u root -p pour résoudre ce problème.
- Recopier les crontab de tous les utilisateurs
Tester TOUS les sites sur ww. (ou les sous domaines modifiés).

Étape 3 : bascule

Il va falloir ramener les informations les plus fraîches du serveur de production vers le nouveau. Idéalement, couper l'ancien et tout rediriger sur le nouveau, pour limiter le temps ou une partie des gens seront sur l'ancien.

Donc il faut faire dans un temps le plus court possible (si ce temps es trop important, il faut mettre les sites en travaux) ;

RE migrer les bases de données
RE migrer les fichiers qui bougent (attention aux droits)
sur l'ancien serveur utiliser les htaccess pour rediriger tout le trafic du www vers le ww.
Changer les dns pour y faire disparaître l'ancien serveur.
tester, tester, tester et encore tester

Étape 4 : finaliser

La question du temps de propagation des DNS, c'est à dire le temps que les noms de domaines redirigent sur les bons serveurs est toujours une question épineuse. Il vaut mieux laisser quelques heures, idéalement 24h. Puis :

Éteindre l'ancien serveur pour vérifier si tout continue d'être ok.
remplacer le ww par www dans les htaccess locaux
Rallumer l'ancien serveur et effacer toutes les données possibles.

SPIP + OVH = ecrire cassé

Julien Falconnet — 2012-03-11T20:25:00Z

Symptomes

L'administration est toute cassée, avec le menu en liste à puce.

Quand on étudie le code on s'apperçoit qu'il n'arrive pas à charger une feuille de style calculée. En d'autres termes impossible d'afficher

http://.../spip.php?page=style_prive

On a un beau

500 Internal Server Error

Solution

Après beaucoup de recherches j'ai fini par trouver qu'il suffisait d'ajouter

SetEnv PHP_VER 5

dans le .htaccess

Et hop, Résolu

Ajouter une langue à SPIP

Julien Falconnet — 2010-10-15T11:47:56Z

Pour un site SPIP, nous voulions pouvoir avoir des traductions même rares en de nombreuses langues, dont :
– hébreux
– hindi
– swahili

Or ces trois dernières langues ne sont pas intégrées, faute de traduction complète, dans SPIP. Mais des embryons existent qui seront bien suffisants pour nos besoin. Mais comment les ajouter à spip ?

Préambule

On considère que l'on a déjà des articles en plusieurs langues et que le multilinguisme est installé, mais que pour certains articles on ne trouve pas les langues appropriées dans SPIP. On cherche donc à ajouter une nouvelle langue.

Justification

Après quelques recherche, il s'avère difficile de trouver une aide concrète pour un site SPIP en version 2.1. Il y a des questions similaires pour d'anciennes versions, il y des question et des réponses sur le multilinguisme et sur le fait d'aider à la traduction de SPIP. Mais je n'ai rien trouvé de synthétique sur l'ajout en tant que tel d'une nouvelle langue en SPIP 2.1. Et surtout google ne nous sort rien de pertinent sur la requête "ajouter une langue à spip".

Le périple

En cherchant on voit que l'on a besoin de 3 fichiers pour chaque langue :
– ecrire_lang.php
– public_lang.php
– spip_lang.php

où lang est le code langue. Par exemple, pour le français c'est 'fr' (ecrire_fr.php, public_fr.php, spip_fr.php), pour l'anglais c'est 'en', pour l'italien c'est 'it', etc. Il existe plusieurs standards pour définir une langue, celui utilisé ici semble être le ISO 639-1 (voir liste exhaustive) avec, parfois, une variante pays (pt_br).

Je trouvais un tableau très prometteur avec la liste des traductions en cours : http://www.spip.net/rubrique4.html

Mais encore fallait il pouvoir récupérer les fichiers correspondant.

Dans cette quête de fichiers, un certain nombre de liens semblent brisés, notamment dans spip-contrib (la gestion des langues semble avoir été gérée dans spip-contrib). D'autre sur spip.net semblent au contraire amener sur une mailing liste ou l'interface privée (inaccessibles sans inscription).

Finalement la meilleure piste semble le suivi de développement en cours :
– http://core.spip.org/trac/spip/browser/ecrire/lang
Après tout on sait bien qu'on va chercher quelque chose qui n'est pas finit mais qui est déjà bien mieux que rien.

On y trouve en particulier he (hébreux), mais aucun des autres qui m'intéressent.

Après beaucoup de recherches et un peu de chance je trouve une adresse magique : http://www.spip.net/fichier_langue.php

Cette petite adresse permet de récupérer n'importe quel fichier de langue pour peu qu'il existe et qu'on soit capable de deviner son nom.

Dans mon cas, je cherchais :
– spip_sw.php, ecrire_sw.php, public_sw.php
– spip_hi.php, ecrire_hi.php, public_hi.php
– spip_he.php, ecrire_he.php, public_he.php

Et par exemple pour récupérer le premier, j'ai pu utiliser l'adresse :

http://www.spip.net/fichier_langue.php?f=spip_sw

Une fois cela n'a pas résolu tous mes problèmes puisque je n'ai pu récupérer qu'une partie des fichiers dont j'avais besoin :

spip_sw.php
spip_hi.php
spip_he.php
public_he.php
ecrire_hi.php
ecrire_he.php

De plus en les parcourant, on remarque que :
– pour l'hébreu ça semble ok même si dans écrire, il reste des traductions à faire.
– pour l'hindi, rien ne semble fait ou presque. (outre qu'il manque un fichier)
– pour le swahili, c'est en fait une base en anglais. (outre qu'il manque deux fichiers)

Il aurait fallu que je puisse traduire les fichiers manquants ou incorrects. Mais n'ayant ni les compétence, ni le temps, je décidais plutôt de mettre en place des artifices approximatifs qui permettrait quand même de profiter de l'extraordinaire moteur multilingue de SPIP. Donc, j'utilisais les fichiers les plus adaptés (l'anglais) pour remplacer les fichiers manquants ou erronés.

Je récupérai donc spip_en.php, ecrire_en.php et public_en.php et les copiais/renommais pour obtenir

spip_hi.php
ecrire_hi.php
public_hi.php
ecrire_sw.php
public_sw.php

Ensuite restait à mettre tout ça en place dans /ecrire/lang .

Mais, grande déception, les nouvelles langues n'apparaissent pas dans la liste des langues disponibles. On vérifie rapidement ecrire/inc/lang_liste.php pour voir que, pourtant, elles ont été prévues.

En cherchant dans l'interface d'administration, on trouve dans Configuration>Gestion des langues>Multilinguisme la liste des langues à activer.
Au passage on note que les langues soulignées sont celles qui ont des fichiers spécifiques (pour les autres, on utilisera la langue par défaut)

Procédure Synthétique

1. Trouver le code langue de la langue recherchée

Soit dans spip dans le fichier ecrire/inc/lang_liste.php
Soit sur le site : http://www.loc.gov/standards/iso639... colonne ISO 639-1 mais attention certains ajustements sont fait par spip.
A partir de là, on sait que l'on aura besoin de :

spip_<_code>.php
ecrire_<_code>.php
public_<_code>.php

Par exemple pour l'allemand, ce serait spip_de.php, ecrire_de.php, public_de.php

2. Récupérer les fichiers des langues qui nous intéressent

On utilise l'adresse http://www.spip.net/fichier_langue.php?f= pour récupérer les fichiers de langue (en remplacant par le nom du fichier recherché sans le ".php"

Par exemple pour l'allemand ce serait :

http://www.spip.net/fichier_langue.php?f=spip_de
http://www.spip.net/fichier_langue.php?f=ecrire_de

http://www.spip.net/fichier_langue.php?f=public_de

2bis. Inventer ceux qui nous manquent

Si par hasard, les fichiers ne sont pas disponibles ou sont erronés, il faut :
– soit les traduire (et je vous y invite fortement si vous avez les compétences et à participer à l'effort de traduction de SPIP)
– soit choisir une langue disponible la plus proche ou la plus appropriée (souvent l'anglais). Une fois la langue choisit on trouve les trois fichiers dans /ecrire/lang et on les copie en les renommant pour qu'il semblent représenter la langue voulue.

Par exemple, si on ne trouve pas l'hindi et qu'on décide de le remplacer par l'anglais, on copie /ecrire/lang/spip_en.php en /ecrire/lang/spip_hi.php, /ecrire/lang/public_en.php en /ecrire/lang/public_hi.php et /ecrire/lang/ecrire_en.php en /ecrire/lang/ecrire_hi.php

3. Mettre en place leur utilisation

Une fois les fichiers en place il reste à les activer dans l'administration de spip : Configuration>Gestion des langues>Multilinguisme . Cette page propose, en dessous des options de configuration linguistiques générales, la liste des langues disponibles et activables. Il ne reste plus qu'à cliquer votre nouvelle langue pour l'activer et qu'elle soit disponible dans l'interface.

3bis. Mettre en place leur utilisation, langue rare

Si d'aventure, la langue n'apparaissait pas dans la liste de la page Configuration>Gestion des langues>Multilinguisme, il faudrait la rajouter à la main dans le fichier : ecrire/inc/lang_liste.php

Ressources

Voici les ressources qui m'ont bien aidé :
– http://forum.spip.org/fr_208428.html (ajout du chinois non-simplifié en 2008)
– http://www.eklesia.net/spip.php?article75
– http://www.spip.net/rubrique4.html (ou l'on trouve l'état d'avancement des traductions.

Notes

On s'occupe bien ici de rajouter une nouvelle langue à SPIP. La gestion d'un site multilingue (avoir des articles/ rubriques/pages etc.) est un sujet extrêmement bien documenté. Par exemple :
– http://www.spip.net/fr_article1972.html
– http://www.spip.net/fr_article2128.html

La version que j'utilise de spip propose 40 langues dans l'interface privée. Pourtant étrangement il y a 45 fichiers de langues dans /ecrire/lang. Et on trouve 189 code langues dans ecrire/inc/lang_liste.php.
Cela tient au fait que 189 langues ont été prévues. 45 sont livrées par défaut mais 5 ne sont pas activées par défaut :

asturianu [ast]
Indonesia [id]
Cambodian [km]
Burmese [my]
svenska [sv]

Installation Trac sur hébergement dédié

Julien Falconnet — 2009-11-24T13:17:33Z

Ça faisait des années que je tournais autour. On m'en avais parlé, j'en avais vu quelques uns... Mais TRAC était toujours resté la "bonne idée qu'on adopterai dès qu'on aurait le temps". D'un autre côté, l'essentiel de mes projet n'impliquaient que moi, donc je m'en sortais très bien avec mon cahier. A deux, ça passait encore. Mais à quatre, j'ai amèrement regretté de n'avoir pas un suivi de projet connecté à subversion. Je me suis finalement ressaisit et voici le résultat de mes recherches.

Choix

A titre de préambule, voici les choix que j'ai fait :
– version : tracd 0.11.1
– Subversion (SVN) comme gestionnaire de version
– trac est utilisé en serveur 'standalone' (indépendant d'un serveur apache)
– plusieurs projets sont gérés simultanément
– accès privé
– gestion des temps de développement (estimation et décompte)
– thème personnalisé
– le serveur sera lancé par un utilisateur particulier

Initialisation

Sur ma dédibox avec une installation Debian. Voici le protocole que j'ai suivi.

En tant qu'administrateur :

apt-get install trac apt-get install trac-spamfilter

Puis en tant qu'utilisateur normal (j'en créé un spécialement pour trac)

# création des environnement qui serviront à trac pour gérer chaque projet trac-admin repertoire_projet1 initenv trac-admin repertoire_projet2 initenv # génération des mots de passe et des utilisateurs htpasswd -c .htpasswd_projet1 user1 htpasswd .htpasswd_projet1 user2 ... htpasswd -c .htpasswd_projet2 user1 htpasswd .htpasswd_projet2 user3 ... # Ajout des droit admin à au moins un utilisateur trac-admin repertoire_projet1/ permission add user1 TRAC_ADMIN trac-admin repertoire_projet2/ permission add user1 TRAC_ADMIN # pour vérifier que l'identification (et l'accès admin) fonctionne tracd -p 8000 --basic-auth=repertoire_projet1,/home /TRAC/.htpasswd_projet1,TRAC_PROJ1 --basic-auth=repertoire_projet2,/home/TRAC/.htpasswd_projet2,TRAC_PROJ2 /home/TRAC/repertoire_projet1/ /home/TRAC/repertoire_projet2/ #ctl-c pour sortir

Dans un navigateur, on peut ensuite tester avec http://adressDuServeur:8000

Une fois que tout semble opérationnel on peut passer aux plugins

Plugins

J'avais besoin de trois fonctionnalités qui demandaient des plugins supplémentaire :
– La gestion des temps de développement.
– Un accès privé par défaut.
– Une interface un peu plus sympathique

J'ai donc récupéré les plugins suivants :
– TimingAndEstimation, qui permet d'estimer et de décompter le temps ticket part ticket.
– NoAnonymous, qui permet d'interdire l'accès si on est pas identifié
– GnomeBR un thème plus (trop ?) coloré.
– ThemeEngine, nécessaire pour pouvoir installer des thèmes (et nécessaire pour le précédent).

Après la procédure est assez pénible, il va falloir régénérer les plugins avec la version de python du serveur. Ce que j'ai trouvé de plus simple c'est de mettre tous les plugins récupéré dans un répertoire spécialement créé pour ça sur le serveur et d'exécuter dans ce répertoire (ATTENTION !!! pas ailleurs) le script suivant

find . -iname '*.zip' -exec unzip {} \; for setup in <code class='spip_code spip_code_inline' dir='ltr'>find . -iname 'setup.py'</code> do start=<code class='spip_code spip_code_inline' dir='ltr'>pwd</code> chmod -R 777 <code class='spip_code spip_code_inline' dir='ltr'>dirname $setup</code> cd <code class='spip_code spip_code_inline' dir='ltr'>dirname $setup</code> python setup.py bdist_egg cd $start echo <code class='spip_code spip_code_inline' dir='ltr'>dirname $setup</code> done find . -iname '*.egg' -exec cp {} . \;

Ensuite il ne reste plus qu'à déplacer, les .egg (attention de bien choisir ceux liés à la version de trac (pour moi 0.11) dans le répertoire plugins de mes environnement (repertoire_projet1 et repertoire_projet2)

Ensuite on peut tester chaque projet séparément et on devra sans doute mettre à jour la base de donnée :

trac-admin /home/TRAC/repertoire_projet1 upgrade trac-admin /home/TRAC/repertoire_projet2 upgrade

Petits réglages complémentaire

Dans trac.ini

les logs

log_level = DEBUG log_type = file

les mails

always_notify_owner = true always_notify_reporter = true mime_encoding = quoted-printable smtp_enabled = true base_url = http://mon.site.com:port/projet/

Mise en route

Il reste en suite à lancer pour de vrai l'application (notament pour qu'elle continue de fonctionner quand on se déloguera du ssh).

# le -d pour lancer le programme comme un daemon tracd -d -p 8520 --basic-auth=lunastars_v2,/home/TRAC/.htpasswd_luna,TRAC_LUNA --basic-auth=enov_bix,/home/TRAC/.htpasswd_enov,TRAC_ENOV /home/TRAC/lunastars_v2/ /home/TRAC/enov_bix/ &

puis quand on voudra l'arréter :
– ps aux |grep tracd
– kill le pid trouvé

Voilà, maintenant il ne reste plus qu'à explorer les fonctionnalités extraordinaire de cette application.

En espérant que cela aidera d'autres à gagner un peu de temps.

[edit : 2/12/2009] Pour pouvoir clore et ajouter du temps sur les tickets directement par les messages des commits SVN, il faut appliquer la procédure indiquée ici : http://trac-hacks.org/wiki/TimingAn...

Subversion : export des fichiers depuis une révision en bash

Julien Falconnet — 2009-11-11T17:59:11Z

Lorsqu'on travaille avec Subversion (SVN) la mise en production demande de passer par la commande svn export. Mais qu'en est il des mises à jour ? La procédure recommandée est de passer par diff et patch. Mais que faire lorsqu'il est impossible de passer par patch parce que l'on est limité à l'utilisation d'un FTP, par exemple ?

Et bien, on est bien embêté. En tout cas, c'était mon cas. Après quelques recherches sur Internet, difficile de trouver une solution satisfaisante. Aucun utilitaire ne semblant faire référence, et les scripts maison ne correspondant pas à mes besoin, j'ai décidé de mettre au point un petit utilitaire bash que je vous livre ici en GPL.

Comment exporter tous les fichiers qui ont changé depuis ma dernière livraison ? Voici une question qui a du tarauder un certain nombre de développeur au moins une fois. C'est vrai, après tout, on investit du temps sur l'utilisation d'un système de suivi de version (ici svn), si c'est pour en perdre encore lorsqu'il faut livrer, où est l'intérêt ? Pourquoi livrer la bibliothèque monstrueuse qu'on a du ajouter en révision 132 alors qu'on est révision 683 et qu'on fait une livraison en r650. Et je passe sur la question du client qui se demande pourquoi on lui renvoie une archive de 60 Mo alors qu'il n'a demandé que quelques corrections d'orthographe et de typographie ( si ! si ! ça pèse super lourd une virgule !).

En effet, svn export exporte toute le projet à une révision donnée. Et svn diff qui affiche bien les différences entre deux révisions ne produit que des sorties au format patch (il n'indique que les lignes qui ont été modifiées).

Après un certain nombre de recherches, j'ai été bien désespéré de voir que non seulement je n'étais pas le seul à buter sur ce problème, mais qu'en plus aucune solution ne semblait faire consensus. J'ai trouvé quelques solutions maisons et même des scripts entiers, mais aucuns ne correspondait à ce que je voulais faire, c'est-à-dire un simple export différentiel qui ressemblerait à un svn export (donc en bash).

J'ai donc décidé de me lancer et de créer cette perle rare. Comme j'en étais content et que je me suis dit que ça pourrait resservir, je vous la sert donc ci-dessous (en gpl). Vous noterez que je suis tellement persuadé de la dimension universelle de ce problème que j'ai décidé de le coder (et de le commenter en anglais).

Voici le code bash desvnxport.sh.

#!/bin/sh # svnxport.sh #Export only modified files in SVN # # Copyright (C) 2009 by Julien Falconnet # http://www.falconnet.fr # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # any later version. # # #BEWARE : This script does not operate correctly with files whose filename contains spaces # tests for parameters if [ ! $1 ];then echo "svnxport : No source specified. Needs : source revision target_directory";exit;fi if [ ! $2 ];then echo "svnxport : No revision specified. Needs : source revision target_directory";exit;fi if [ ! $3 ];then echo "svnxport : No target_directory specified. Needs : source revision target_directory";exit;fi # check if the target_directory allready exists if [ -d $3 ];then echo "svnxport : target_directory '$3' allready exists. Remove it or change target_directory parameter.";exit;fi echo "Processing : source($1), revision($2), target_directory($3)" # we use svn diff to select changed files and only keep those updated or added. # Then the 'for' separate status from filename (here is the problem with file with blanks) for myfile in <code class='spip_code spip_code_inline' dir='ltr'>svn diff -r $2:HEAD --summarize $1 | grep -e '^M ' -e '^A '</code> do if [ "$myfile" = "M" -o "$myfile" = "AM" -o "$myfile" = "A" -o "$myfile" = "." -o -d $myfile ] then # we ignore the status, and the directory to update continue else #we focus on true changed files #first we create needed directories for the current file #note that we use a relative directory system outfile=<code class='spip_code spip_code_inline' dir='ltr'>echo $myfile |sed "s|$1||g"</code> dir="$3/$outfile" mkdir -p $(dirname $dir) #then we export the file svn export $myfile $3/$outfile >> /dev/null echo "export $3/$outfile " fi done # List other files. Changed but not exported. Mainly the deleted ones. # Usefull to know which files should be removed and follow weird comportment echo "Watch for : " svn diff -r $2:HEAD --summarize $1 | grep -v -e 'M ' -e 'A ' |sed "s|$1||g"

Pour ceux que ça intéressent, deux points ont été compliqués. D'abord, le fait qu'en bash le for découpe sur les espaces (et non pas sur les retours à la ligne) : Un coup sur deux j'avais le statut, ce qui était pénible puisque je ne voulais traiter que les A et les M et pas les D. J'ai faillit passé par un marqueur et finalement j'ai trouvé plus élégant de passer par un grep (qui s'intercale avant le découpage du for).

L'autre soucis a été la création de l'arborescence. En effet j'ai été déçu de voir que ni touch, ni mkdir, ni svn export n'étaient capables de créer des sous répertoires en même temps que le répertoire père. Du coup j'ai été obligé de rajouter cette boucle toute laide de mkdir. [edit ; grâce au post de Rodney Amato j'ai put trouver le paramètre -p de mkdir qui remplace avantageusement la boucle en question]

Par contre, du coup, les espaces dans les noms de fichiers sont découpés par le for et les fichiers correspondants ne sont pas exportés par le script. Il faudrait remplacer les espaces dans les fichier à la volée avant le for et les re-remplacer après mais c'était tellement inélégant que je m'y suis refusé. D'autant que cela ne me sert pas puisque je ne mets jamais d'espace dans mes noms de fichiers (c'est trop laid). Par contre si quelqu'un à une solution élégante pour contourner ce problème je suis preneur.

A bientôt...

Parmi les scripts intéressant que j'ai trouvé, celui ci est celui qui m'a le plus inspiré. Hélas il était en php et faisait plus que ce que je voulais. Mais pour ceux qui cherchent une solution en php plutôt qu'en bash, je pense qu'elle est valide :http://forum.phpfrance.com/vos-contributions/export-fichier-depuis-subversion-pour-mise-production-backup-inclus-t241495.html

Les hooks SVN auraient pu être une autre piste intéressante mais demandent de modifier le dépot, donc des droits étendus. (une présentation rapide en français)

Merci aussi à ce post de Rodney Amato qui m'a apporté la révélation du mkdir -p.

Préfixer les tables spip avec le spip_loader

Julien Falconnet — 2008-04-16T17:57:16Z

L'installation de plusieurs spip dans la même base est parfois nécessaire ou pratique. Malheureusement l'installation ne propose pas de modifier le préfixe par défaut de spip qui est "spip". Si on essaie d'installer deux SPIP dans la même base, le second écrase le premier.

J'ai trouvé quelques contributions pour préfixer les tables dans une base, en particulier :http://www.spip-contrib.net/Comment... mais elles reposent sur une installation par décompression et transfert de l'arborescence, hors j'ai un amour particulier pour le très efficace spip_loader.php.

Aussi, en m'inspirant des méthodes ci-dessus, j'ai trouvé une astuce pour installer un spip avec le spip_loader tout en préfixant les tables comme je voulais. Je vous le livre ci-dessous :

Lors de l'installation par spip_loader, on commence par l'installer dans le répertoire du ftp où l'on souhaite installer le site. Ensuite, on y accède par une interface web où l'on peut renseigner au fur et à mesure les différentes informations dont il a besoin.

L'astuce consiste à surveiller l'étape qui affiche le texte suivant :

Installation du système de publication...

Troisième étape : Choix de votre base AIDE

Choisissez votre base : Le serveur MySQL contient plusieurs bases de données.

Sélectionnez ci-après celle qui vous a été attribuée par votre hébergeur : ...

C'est-à-dire juste avant qu'il ne crée les tables pour de bon.

A ce moment là, on crée un fichier mes_options.php, qui contient les lignes suivantes :

où monprefixe est le préfixe que vous voulez utiliser à la place de "spip" (attention le préfixe ne doit pas commencer par spip)

Et, par ftp, vous déposez ce fichier dans le répertoire /ecrire/ de spip.

Je vous livre cette astuce, "telle quelle", elle a fonctionné pour moi, mais elle peut peut être poser des problèmes, notamment si les préfixes sont bizarrement constitués. A utiliser à vos risques et périls donc.

Conseil en stratégie Internet

Julien Falconnet — 2008-02-20T18:23:53Z

Quels objectifs ? Quels moyens ? Internet est devenu un univers riche et complexe, où il est parfois difficile de distinguer les modes des tendances profondes. En fonction de votre situation et de votre projet, il est parfois nécessaire de prendre du recul et de faire le point pour définir ou préciser votre stratégie Internet.

Il y a dix ans, avoir un site sur l'Internet était un avantage, on démontrait ainsi qu'on était à la pointe de la technologie. Aujourd'hui, avoir un site web est commun au point que ne pas en avoir est un handicap. Entre les deux, il reste le site approximatif qui peut être catastrophique.

Julien FALCONNET vous proposer d'auditer votre site, d'étudier avec vous votre projet, de vous aider à préciser vos objectifs et de chercher les meilleurs moyens de les atteindre.

Réalisation de sites Web

Julien Falconnet — 2008-02-20T11:00:00Z

La communication sur le web repose presque toujours sur un site Web. Avec la démocratisation d'Internet, les visiteurs sont de plus en plus exigeants, les technologies évoluent de plus en plus vite et les sites se doivent d'être toujours plus réactifs.

Julien FALCONNET vous accompagne pour réaliser le site qui vous correspond. A partir des objectifs que vous vous fixez, les meilleures solutions sont étudiées. Une expertise des tendances à long terme du Web assure que les situations finalement retenues soient pérennes.

La prestation de réalisation est faite avec un suivi régulier pour que le projet reste cohérent avec l'idée que vous vous en faite, jusqu'au bout.

Julien FALCONNET a propose aussi une expertise sur SPIP. Cet outil de gestion de contenu permet de faire face à la plupart des besoins classiques d'un site. Fruit de plusieurs années d'expérience, c'est aujourd'hui un produit efficace soutenu par une communauté active.