Tag

svn

Browsing
wordpress-svn-logo

De temps en temps, je mets mes plugins WordPress sur le dépôt officiel mais j'utilise assez rarement subversion - connu également sous le doux nom svn - et j'ai tendance à en oublier la syntaxe.

Voici donc un petit aide-mémoire pour l'utilisation de subversion avec les plugins WordPress.

Ajouter un plugin sur le dépôt officiel WordPress

1. On crée un répertoire local sur notre machine pour y accueillir notre projet:

mkdir my-local-dir

2. On synchronise le dépôt avec un check-out en donnant le slug du plugin:

svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir

Résultat:

> A	my-local-dir/trunk
> A	my-local-dir/branches
> A	my-local-dir/tags
> Checked out revision 1135625.

Subversion vient d'ajouter ( "A" signifie "add" ) tous les répertoires du dépôt central à notre copie locale.

3. On copie tous les fichiers du plugin dans le répertoire trunk/:

cd my-local-dir/
my-local-dir/$ cp ~/my-plugin.php trunk/my-plugin.php
my-local-dir/$ cp ~/readme.txt trunk/readme.txt

4. On prépare l'ajout des fichiers du plugin au dépôt central:

my-local-dir/$ svn add trunk/* assets/*
> A	trunk/my-plugin.php
> A	trunk/readme.txt

5. On donne un message à notre check-in et on envoie les fichiers au dépôt central :

my-local-dir/$ svn ci -m 'Adding first version of my plugin'
> Adding	trunk/my-plugin.php
> Adding	trunk/readme.txt
> Transmitting file data .
> Committed revision 1135626.

Voilà, vous venez d'ajouter votre plugin au dépôt officiel de WordPress !

Supprimer un fichier sur le dépôt

Pour supprimer un fichier sur le dépôt, il faut supprimer le fichier avec svn delete puis commettre les changements avec svn commit. C'est lors du commit que le fichier est supprimé du dépôt :

svn delete myfile
> D         myfile

svn commit -m "Deleted file 'myfile'."
> Deleting       myfile
> Transmitting file data .
> Committed revision 1135629.

Notre serveur ayant besoin de mettre les données en cache pour plus d'efficacité, il peut s'avérer intéressant de maintenir APC à jour via SVN, histoire d'être sous une version "bleeding-edge".

Méthode automatique : installation d'APC via Dotdeb

Commencez par ajouter les dépôts Dotdeb à la configuration APT.

Ensuite, il suffit d'installer APC avec :

apt-get install php5-apc

Configuration d'APC

J'ai un peu tweaké ma configuration d'APC par rapport au précédent article. Éditez apc.ini :

nano /etc/php5/conf.d/apc.ini

et ajoutez-y :

extension=apc.so
apc.enabled=1
apc.shm_size=128M
apc.stat=0
apc.ttl=7200
apc.user_ttl=7200
apc.enable_cli=1
apc.max_file_size=10M
apc.rfc1867 = On

Et on relance Apache :

/etc/init.d/apache2 restart

Voilà, vous possédez la dernière version d'APC sur votre serveur. L'opération est à renouveler de temps à autre, histoire d'être toujours à jour.

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d'Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d'un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d'utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d'APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d'un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d'une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l'erreur "fatal: www-data(33): message file too big"
  28. Serveur dédié : mise en place de l'IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l'authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. J'ai planté le serveur... ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d'OpenSSL sous Debian
  44. Serveur dédié : activer l'IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d'entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d'or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l'inode perdue ou comment résoudre le problème "no space left on device"
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Le problème : une notification de mise à jour pour la version localisée

WordPress vérifie périodiquement ses mises à jour et vous indique par une notification lorsqu'une nouvelle version est disponible. C'est bien pratique mais lorsque l'on met le site à jour par SVN ou en utilisant Trac, ce sont les fichiers en version originale (non traduite) que l'on récupère. Du coup, vous pouvez très bien avoir votre installation de WordPress à jour et avoir une notification de mise à jour vous poussant à télécharger la dernière version localisée (fr_FR dans notre cas).

Exemple en image :

WTF WordPress ?!?
WTF WordPress ?!?

Mise à jourJe viens de mettre à mettre WordPress vers la version 1.5.3. Apparemment toutes les versions étaient touchées par certaines failles de sécurité qui ont été brièvement mentionnées sur le blog de développement WP mais il est impossible de trouver une référence précise sur les failles concernées. D'un autre côté, je comprends qu'ils veulent épargner leurs utilisateurs de possibles attaques. C'est plutôt souhaitable d'ailleurs. J'espère que cela éloignera le Bielorusse qui tente divers appels de scripts étranges depuis ce matin... il est bloqué à la porte du site par .htaccess en attendant.

J'ai fait la mise à jour par SVN en suivant la première partie de ce tutoriel (trouvé via WTC) : le tout est de récupérer les dernières versions des fichiers patchés (rev. 3643) qui se trouvent sur :

http://svn.automattic.com/wordpress/branches/1.5/

Ensuite, faîtes un backup de vos fichiers et de votre base de données. Personnellement, j'ai copié tout mon répertoire vers un autre répertoire - cela évite les tracasseries et je peux ainsi tout remettre comme avant en deux clics de souris. J'ajoute que la copie de répertoire ne semble pas être possible avec Filezilla ou CuteFTP Pro : mieux vaut utiliser Cpanel, cela fonctionne d'enfer et c'est instantané.

Backup effectué ? Mettez à jour vos fichiers : j'ai tout mis à jour excepté le répertoire /wp-content/ parce que j'ai passé pas mal de temps à modifier mes fichiers de thèmes et que je n'ai certainement pas envie de les perdre... Une fois les fichiers copiés, rendez-vous sur /wp-admin/upgrade.php.

Voilà, mon votre blog est mis à jour et de nouveau sécurisé.

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :