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.

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.

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.

Le problème : le code des vidéos n’est pas valide en HTML5

Voici ce que le code oEmbed de WordPress donne par défaut avec un lien Youtube :

<iframe src="https://www.youtube.com/embed/Gvh2Zo7UL6E?fs=1&feature=oembed" width="660" height="371" frameborder="0" allowfullscreen="allowfullscreen"></iframe>

Résultat:

Or le petit problème, c’est que tout cela n’est pas vraiment valide au niveau W3C et je commence à me lasser de voir ces erreurs de validation sur toutes les pages du site avec des vidéos :

Erreur 1 : Attribute allowfullscreen not allowed on element iframe at this point.
Erreur 2 : The frameborder attribute on the iframe element is obsolete. Use CSS instead.

La solution : filtrer le rendu oEmbed de WordPress pour purifier le code

Voici donc la solution que j’ai mise en place sur le site : je filtre le code oEmbed de WordPress de manière à retirer le tag allowfullscreen qui n’a rien à faire là et à supprimer l’attribut frameborder, que je remplace par un style="border: none".

Editez le fichier functions.php de votre thème et ajoutez-y cette fonction:

<?php
/*
|-----------------------------------------------------------------------
| Sky oEmbed Filter by Matt - www.skyminds.net
|-----------------------------------------------------------------------
|
| The sky_oembed_filter() function attempts to validate WordPress 
| video oEmbeds for HTML5.
| $return is the normal HTML that the oEmbed process would return. 
| $data is the data received from the oEmbed call, in an object format. 
| $url is the original URL being queried for oEmbed info. 
|
*/
add_filter('oembed_dataparse', 'sky_oembed_filter', 90, 3 );
function sky_oembed_filter( $return, $data, $url ) {
 	$return = str_replace('frameborder="0" allowfullscreen', 'style="border: none"', $return);
	return $return;
}

Notez que WordPress cache les résultats oEmbed dans la table postmeta donc après avoir installé ce code et si vous voulez vérifier que cela fonctionne, éditez un article pour que le postmeta se mette à jour.

Voilà, vos pages avec vidéos YouTube devraient maitenant être valides.

Avec le temps, les mises à jour successives et l’installation de différents plugins, la base de données de WordPress a tendance à prendre du poids, ce qui nuit aux performances. Voici donc comment lui faire bénéficier d’un petit régime.

N’oubliez pas de faire une sauvegarde de votre base de données avant de lancer ces requêtes. Backup now.

Nettoyage de wp_postmeta

Avant optimisation, ma table wp-postmeta faisait 12 403 enregistrements.

DELETE FROM wp_postmeta WHERE meta_key = '_edit_lock';
DELETE FROM wp_postmeta WHERE meta_key = '_edit_last';
DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug';

Maintenant : 12 240.

Nettoyage de wp_commentmeta

On supprime tout ce qu’Akismet nous a mis dans la table wp_commentmeta :

DELETE FROM wp_commentmeta WHERE meta_key LIKE '%akismet%';

et on supprime toutes les entrées qui n’ont aucune relation avec wp_comments :

DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);

Nettoyage de wp_options

Passage de 880 enregistrements à 476. WordPress crée ces entrées automatiquement et les purge occasionnellement, autant l’aider un peu.

DELETE FROM wp_options WHERE option_name LIKE '_site_transient_browser_%';
DELETE FROM wp_options WHERE option_name LIKE '_site_transient_timeout_browser_%';
DELETE FROM wp_options WHERE option_name LIKE '_transient_%';

Si, lors d’une journée de débuggage PHP, vous tombez sur l’erreur suivante :

Deprecated: Assigning the return value of new by reference is deprecated in  on line 12 

pas de panique, c’est extrêmement simple à résoudre. Vous avez probablement une ligne dans ce goût-là :

$data =& new Structured_Info();

Or, depuis PHP5, le passage par réference est systématique sur new, donc il suffit d’enlever le ‘&’ et d’écrire :

$data = new Structured_Info();

Tout simplement.

Je me suis rendu compte qu’un des fichiers javascript d’un plugin WordPress est appelé sur chaque article du site et qu’il n’est pas mis en cache par défaut…

C’est très moyen au niveau opimisation étant donné que c’est typiquement le genre de fichier statique qui n’est pas prêt d’être modifié.

Voici donc les en-têtes (headers) qui vont nous permettre de mettre un fichier en cache en PHP :

<?php
/*
|--------------------------------------------------------------------------
| Enable Caching with PHP headers by Matt - www.skyminds.net
|--------------------------------------------------------------------------
|
| Let's set it to 90 days caching.
| seconds, minutes, hours, days 
|
*/
$expires = 60*60*24*90;

header('Pragma: public');
header('Cache-Control: maxage='.$expires);
header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$expires) . ' GMT');

Et voilà, page mise en cache. Cela fait moins de requêtes sur le serveur puisque le navigateur n’a pas besoin de redemander la page à chaque visite.

Il y a quelques mois, je vous ai montré comment changer la structure des permaliens WordPress. Cela fonctionne très bien et tout le trafic des anciennes URL est bien redirigé vers les nouvelles.

Il est toutefois encore possible de faire mieux que cela : éditer toutes les URL de la base de données pour afficher les bons liens directement et éviter les redirections Apache à chaque fois qu’un visiteur clique sur un lien de vos anciens articles. Cela évite une redirection donc permet d’afficher la bonne page directement, sans le temps de latence dû à l’exécution de mod_rewrite.

Etape 1 : sauvegarder votre base de données

On n’insistera jamais assez sur l’importance de sauvegarder les données avant d’effectuer une quelconque manipulation des données. Commancez donc par faire une sauvegarde de votre base WordPress, vu que nous allons l’éditer en direct.