Tag

plugins

Browsing

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites « hériteront » des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Sous WordPress, il est très simple de traduire les thèmes et plugins grâce au logiciel PoEdit et à un fichier de langue au format .pot ou .po – mais qu’advient-il de vos traductions lorsque le plugin ou thème est mis à jour avec de nouvelles chaînes?

PoEdit : mettre à jour les fichiers de traduction de vos thèmes et plugins WordPress photo

Mettre à jour votre fichier de traduction avec PoEdit

Et bien, il suffit tout simplement de resynchroniser votre fichier de traduction avec le fichier de traduction modèle, généralement au format .pot pour ajouter à votre fichier les chaines manquantes.

1. Dans PoEdit, ouvrez votre fichier de traduction au format .po

2. Ouvrez le menu Catalog > Update from POT file et sélectionnez le fichier POT de votre thème ou plugin mis à jour.

Cela ajoute toutes les nouvelles chaines à traduire dans votre fichier de traduction et retire les chaines obsolètes.

3. Traduisez les nouvelles chaines qui viennent d’être ajoutées.

4. Sauvegardez votre fichier et pensez à exporter vos traductions en .mo également. Vous devriez toujours avoir vos traductions en .po et .mo

5. Pour ne pas que vos traductions soient écrasées à la prochaine mise à jour du thème ou plugin, elles sont à placer dans le dossier :

  • wp-content/languages/themes pour les thèmes
  • wp-content/languages/plugins pour les plugins

Voilà, les traductions de votre thème ou plugin sont maintenant à jour.

WordPress : récupérer la liste emails des membres et commentateurs photoLorsque vous installez WordPress en local sur votre machine, il est assez courant que les droits des fichiers et dossiers ne permettent pas d’entrée de jeu d’installer ou de mettre à jour des plugins ou des thèmes.

Voici comment résoudre ce problème en quelques minutes.

Passage au système de fichier direct

1. On commence par éditer notre fichier wp-config.php, qui contient pas mal de constantes primordiales pour WordPress:

nano wp-config.php

2. On y rajoute, vers le haut du fichier, une constante qui passe le système de fichier en mode direct:

define('FS_METHOD', 'direct');

Sauvegardez votre fichier wp-config.php. Les fichiers de thèmes et de plugins seront désormais directement installés sans que la popup demandant des informations FTP ou SSH ne s’affiche.

Vérification des droits des fichiers et répertoires

En local, par contre, ce sera un petit peu différent : l’utilisateur www-data (Apache) doit pouvoir gérer les fichiers mais si vous souhaitez éditer des fichiers, ce qui est quand même le but d’une installation en locale, il faut que votre utilisateur puisse aussi gérer et avoir le droit d’écriture sur les fichiers.

1. Tout d’abord, on donne les droits à Apache à tous les fichiers et dossiers de l’installation WordPress :

sudo chown www-data:www-data -R /home/matt/www/

2. J’ajoute ensuite mon utilisateur de session, matt, dans le groupe www-data (Apache):

sudo usermod -aG www-data matt

3. On vérifie que l’utilisateur matt fait bien partie du groupe www-data :

groups matt

Cela nous retourne la liste de tous les groupes auquel j’appartiens :

matt : matt adm lp dialout fax cdrom floppy tape audio dip www-data video plugdev fuse lpadmin netdev admin sambashare vboxusers usb bluetooth scanner

4. On stipule que l’utilisateur matt est propriétaire de ces fichiers :

sudo chown matt:www-data -R /home/matt/www/

5. On assigne les permissions standard de WordPress, chmod 755 pour les répertoires et chmod 664 pour les fichiers, le tout en mode récursif pour n’oublier personne :

cd /home/matt/www
sudo find . -type d -exec chmod -R 755 {} \;
sudo find . -type f -exec chmod -R 664 {} \;

6. Enfin, on assigne des permissions plus larges (chmod 775) pour le répertoire /wp-content de notre installation qui contient nos plugins et thèmes pour pouvoir les éditer :

 cd /home/matt/www/wp-content
sudo find . -type d -exec chmod -R 775 {} \;
sudo find . -type f -exec chmod -R 664 {} \;

Vous pouvez maintenant installer thèmes et plugins en local et être en mesure d’éditer vos fichiers avec votre utilisateur linux, sans problèmes de droits.

bwp-minifySur le site, j’utilise le plugin Better WordPress Minify pour compresser le contenu des pages (CSS, JavaScript, HTML) pour n’avoir que quelques fichiers à charger pour améliorer les temps de rendement.

Il est très utile d’utiliser headJS, qui permet lui aussi de charger plusieurs fichiers javascript en un seul appel, en les concaténant.

Voici un petit tutoriel qui permet d’allier Better WordPress Minify avec headJS.

Édition de Better WordPress Minify

Il n’y a malheureusement pas d’option ou de filtre pour cela donc nous allons devoir éditer le fichier class-bwp-minify.php :

nano /bwp-minify/includes/class-bwp-minify.php

On recherche ensuite la fonction get_minify_tag.

On remplace, autour de la ligne 2723 :

case 'script':
$return  = "\r\n";
break;

par :

case 'script':
 //MATT - https://www.skyminds.net
$return  = "\r\n";
	break;

Et voilà, tous les fichiers javascript gérés et minifiés par Better WordPress Minify seront maintenant chargés via headJS.

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.

Jusqu’à très récemment, il m’était tout à fait possible d’avoir des caractères accentués dans des blocs de texte sous WordPress en utilisant le plugin Crayon Syntax Highlighter pour coloriser le code.

crayon-syntax-highlighter

Or depuis quelques temps tous les blocs en lang="text" ne permettent plus d’afficher les accents : je me retrouve avec des mots tronqués comme si le texte n’était pas encodé en UTF-8.

Problème : des caractères non-Unicode

Voici ce que donne la phrase « j’ai mangé une tarte à la crème à Noël » avec une colorisation par défaut avec Crayon Syntax Highlighter :

J'ai mangé une tarte à la crème à Noël.

Gloups! C’est totalement illisible, les accents deviennent un caractère mal encodé et certaines lettres adjacentes sont littéralement supprimées. Pas glop.

Solution : créer un alias

La solution que je propose est plus une rustine d’appoint qu’une véritable solution.

Je pense que le problème réside dans l’expression régulière des langages du plugin : certains langages (shell par exemple) n’acceptent pas les accents alors que d’autres (HTML par exemple) oui.

Je me suis rendu compte en changeant la langue du bloc que le langage batch affichait correctement les accents.

Comme je n’allais pas éditer tous mes articles pour changer le langage des blocs texte que j’ai utilisé jusqu’à maintenant, j’ai opté pour la création d’un alias.

(Avec un peu de retard) et après des vacances fort reposantes, voici les quelques derniers ajouts et améliorations du site :

  1. [+] WordPress : transformation des pages en articles. Avec la suppression des dates dans les URLs (link), il n’y a plus aucune raison d’avoir du contenu dans des pages. Le site passe donc de 230 pages à… seulement douze. Je garde juste les pages institutionnelles : contact, à propos etc. Un plugin m’a beaucoup aidé : Vice Versa.
  2. [+] WordPress : réorganisation des contenus du site : les catégories Misc (catégorie un peu fouillis) et Classics (articles marquants) ont été fondues dans Blog. Les anciennes pages ont été ajoutées à de nouvelles catégories : Anglo-American Civilisation regroupe les pages Civilisation et Politics; Littérature les pages American Literature, English Literature, Literatura Española et Littérature. Les articles Economie et Sociologie se retrouvent logiquement dans la catégorie Economie-Sociologie et les articles relatifs à la pédagogie ont été placés, faute de mieux, dans Boulot. Un jour, je trouverai un nom correct pour cette dernière catégorie mais je reste à cours d’idée.
  3. [+] WordPress : remplacement du menu : à la base fait à la main, il utilise maintenant les menus natifs de WordPress.
  4. [*] CSS : quelques modifications pour le nouveau menu.

Prochain changelog en décembre pour les changements automne-hiver !

Voici une petite liste des derniers ajouts, modifications et améliorations du site ces derniers mois :

  1. [*] PHP : déplacement de mes bouts de code du fichier functions.php pour les organiser dans un fichier-plugin.
  2. [*] HTML : ajout des meta Dublin Core sur la page d’accueil, passage des balises H2 en H1 pour les titres des articles, correction du code HTML5 parce que le validateur W3C a changé ses recommandations.
  3. [*] CSS : nettoyage du code CSS. J’ai remplacé les images et les sprites par des gradients CSS et utilisé les dashicons de WordPress au lieu d’images. Ajout de code non-valide sur les gradients pour prendre en charge Internet Explorer. Amélioration du menu.
  4. [+] Serveur : passage du serveur en IPv6.
  5. [+] Serveur : WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod.
  6. [+] Serveur : WordPress : héberger les images sur un sous-domaine.
  7. [+] WordPress : remplacement de mon ancien plugin de colorisation de syntaxe par Crayon Syntax Highlighter. Ajout d’Advanced Code Editor pour éditer les fichiers avec un véritable éditeur de code.
  8. [+] WordPress : les membres peuvent désormais ajouterune photo/avatar dans leur profil. Il est possible de supprimer son compte.
  9. [+] PHP / WordPress : remplacement du plugin de pagination et du plugin qui permet d’afficher des nombres différents d’article selon le type de page par des fonctions natives à WordPress, les liens des articles deviennent cliquables automatiquement, suppression des cookies de commentaires pour améliorer le cache.
  10. [+] CSS : création d’une feuille de style dédiée à l’impression des articles. On imprime uniquement les sections importantes de l’article et l’avatar de l’auteur est remplacé par le QR code qui renvoie vers l’article. Je suis content d’avoir fini de mettre cela en place!

J’ai travaillé sur pas mal de choses invisibles à l’oeil nu mais au final, je suis satisfait du résultat. Je vais bientôt m’atteler au chiffrement SSL et à la sécurisation du serveur mail.

Voici les quelques mises à jour du serveur et du site depuis quelques mois :

J’ai encore pas mal de projets dans les cartons mais actuellement, je manque cruellement de temps :/

Voici les derniers ajouts au site depuis le début de l’année:

  • [+] vous pouvez désormais poster des vidéos en commentaire juste en donnant le lien texte de la vidéo (merci Anne-Gaëlle pour la sugggestion).
  • [+] le javascript est désormais chargé de manière asynchrone grâce à la librairie head.js. En pratique, la page (HTML, CSS, images) se charge et l’utilisateur peut interagir avec immédiatement, le code javascript est lui chargé après. Cela règle le problème que j’avais évoqué en novembre 2012.
  • [+] les gravatars sont désormais chargés depuis le site (et mis en cache par le serveur) au lieu d’être appelés depuis le site gravatar.com, cela limite le nombre de requêtes extérieures. Plugin : GravatarLocalCache.
  • [+] BASH : création d’un script qui répare toutes les tables et bases de données MySQL d’un serveur en cas de crash.
  • [*] réorganisation du fichier sitemap : j’ai retiré les pages archives, tags et catégories du fichier pour ne laisser que les articles et les pages, c’est-à-dire le contenu réel du site. Cela permet d’avoir une idée plus précise de ce qui est réellement indexé par Google : dans Google Webmaster Tools, j’ai maintenant 2,626 pages trouvées dont 2,606 indexées. Le reste ne l’était pas de toute manière.
  • [*] le bug des images corrigé cet hiver ne l’était en fait pas et pour cause : le fichier attachment.php contenait la même routine de vérification que le fichier single.php – celle qui me permet de rediriger quelqu’un qui appelle une page sans contenu (généralement un petit malin). Corrigé cette fois!
  • [*] correction d’un autre bug exotique affectant les images : perte du chemin des images.
  • [*] correction de 1500+ redirections de liens. Avec le temps, les sites changent de structure et les liens aussi. C’est là que l’on se rend compte que beaucoup de sites ferment au fil du temps. Merci Broken Link Checker.
  • [*] le site est intégralement validé en HTML5.
  • [+] Serveur : mise à jour des paquets LAMP avec les dépôts Dotdeb.
  • [*] Serveur : mise à jour vers Debian 7 Wheezy.

Prochaines idées d’optimisations sur lesquelles travailler :

  • soumettre les tablatures dans un fichier sitemap
  • héberger les images et le javascript sur un sous-domaine
  • activer le multisite pour héberger d’autres personnes sur le serveur ?

Ah, ce moment magique durant lequel tu constates que ta note PageSpeed monte à 99%, via GTmetrix :

pagespeed-99-201301

C’est beau, sachant qu’au niveau CSS, c’est la barre WordPress du haut qui génère l’overhead.

Prochaine étape : mettre les fichiers statiques sur un sous-domaine cookieless.

Rapport de faute d’orthographe

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