Category: WordPress | Page 4

WordPress : changer le mot de passe d’un utilisateur depuis le serveur SQL

30 September 202128 septembre 2017 by Matt Biscay · Lecture: 2 minutes

Il peut être nécessaire de changer le mot de passe d’un utilisateur WordPress par exemple lorsque l’on migre un compte, lorsque l’on repart de zéro avec une base de données vierge ou lorsque le mot de passe du site de développement diffère de celui du site de production.

Ou tout simplement pour en mettre un plus facile à retenir.

Voici donc comment changer le mot de passe d’un utilisateur WordPress directement depuis un terminal connecté sur le serveur de la base de données.

Changer le mot de passe d’un utilisateur WordPress depuis MariaDB

1. Connectez-vous au serveur de base de données :

mysql -u root -p

puis entrez votre mot de passe :

Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.Code language: JavaScript (javascript)

2. Sélectionnez la base de données qui contient l’installation WordPress concernée :

USE wordpress_wpdb;Code language: PHP (php)

Résultat :

Database changed

3. Vérifiez que votre utilisateur (ici : matt) est bien présent dans la base :

SELECT ID, user_login, user_pass FROM wp_users WHERE user_login LIKE '%matt%';Code language: JavaScript (javascript)

Résultat:

+----+-------------+------------------------------------+
| ID | user_login  | user_pass                          |
+----+-------------+------------------------------------+
| 78 | matt                | $P$BUZ6Uvu8aie2tBEWqwTu07qfzlKXc80 |
+----+-------------+------------------------------------+
1 row in set (0.00 sec)Code language: PHP (php)

4. Choisissez un mot de passe (ici: q8U@jM5uNMa*R66R), qui sera automatiquement chiffré en MD5 :

UPDATE wp_users SET user_pass = MD5('q8U@jM5uNMa*R66R') WHERE ID=78 LIMIT 1;Code language: JavaScript (javascript)

Résultat:

Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0Code language: CSS (css)

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

12 March 202217 février 2017 by Matt Biscay · Lecture: 2 minutes

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?

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ésoudre l'erreur "ftp_nlist() expects parameter 1 to be resource" photo

WordPress : installer des plugins et thèmes sur un site de développement local

24 March 202231 octobre 2016 by Matt Biscay · Lecture: 2 minutes

Lorsque 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.phpCode language: CSS (css)

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');Code language: JavaScript (javascript)

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

Pour rappel, WordPress recommande un chmod 644 pour les fichiers et un chmod 755 pour les répertoires.

En local, par contre, ce sera un petit peu différent : l’utilisateur www-data (Apache ou NginX) 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 750 {} \;
sudo find . -type f -exec chmod -R 640 {} \;

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.

Subversion : ajouter et mettre à jour un plugin WordPress sur le dépôt officiel

29 March 202216 juin 2015 by Matt Biscay · Lecture: 4 minutes

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-dirCode language: JavaScript (javascript)

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.txtCode language: JavaScript (javascript)

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.txtCode language: PHP (php)

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.
Code language: JavaScript (javascript)

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.Code language: JavaScript (javascript)

Résoudre les lightbox vides dans l’administration WordPress

6 November 202426 avril 2015 by Matt Biscay · Lecture: 3 minutes

Le problème : des iframes entièrement vides dans l’interface d’administration WordPress

Depuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.

C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.

Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures.

J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.

Et puis cette semaine, eurêka !

La solution : la configuration Apache du serveur

J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :

Load denied by X-Frame-Options.... X-Frame-Options does not permit framing.

Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :

Header always set X-Frame-Options DENYCode language: JavaScript (javascript)

Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame).

Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.

WordPress : afficher les accents dans des blocs texte colorisés par Crayon Syntax Highlighter

29 March 202215 janvier 2015 by Matt Biscay · Lecture: 2 minutes

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.

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.

WordPress : valider le code des meta oEmbeds de YouTube, DailyMotion, Vimeo et SlideShare

29 March 202219 décembre 2014 by Matt Biscay · Lecture: 2 minutes

Allez, je continue ma petite série sur la gestion de l’intégration oEmbed sous WordPress.

WordPress gère nativement plusieurs services : copiez-collez l’adresse d’une vidéo YouTube dans un article et hop, vous obtenez une vidéo entièrement intégrée, avec un code plutôt propre mais pas entièrement valide.

Je vous propose donc de valider le code généré par WordPress lorsqu’il vient de sites tiers comme YouTube, DailyMotion, Vimeo ou SlideShare.

Valider le code oEmbed de YouTube

Il suffit de lancer les quatre requêtes SQL suivantes :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" allowfullscreen', 'style="border: none"');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" allowfullscreen', 'style="border: none"');
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, "wmode=transparent' frameborder='0'", "wmode=transparent' style='border: none'");
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, "wmode=transparent' frameborder='0'", "wmode=transparent' style='border: none'");Code language: JavaScript (javascript)

Valider le code oEmbed de Dailymotion

Pour le code de Dailymotion, ces deux requêtes suffisent :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0">', 'style="border: none">');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0">', 'style="border: none">');Code language: JavaScript (javascript)

Valider le code oEmbed de Vimeo

Quatre requêtes pour Vimeo :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" title=', 'title=');
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, ' webkitallowfullscreen mozallowfullscreen allowfullscreen', '');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" title=', 'title=');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, ' webkitallowfullscreen mozallowfullscreen allowfullscreen', '');Code language: JavaScript (javascript)

Valider le code oEmbed de SlideShare

Et deux requêtes pour SlideShare :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px" allowfullscreen webkitallowfullscreen mozallowfullscreen>', 'style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px;overflow:auto;border:none">');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px" allowfullscreen webkitallowfullscreen mozallowfullscreen>', 'style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px;overflow:auto;border:none">');Code language: JavaScript (javascript)

Et voilà, le code est plus propre, plus valide et utilise CSS plutôt que des balises propriétaires.

WordPress : remplacer le vieux code Dailymotion de vos articles par une URL oEmbed photo 1

WordPress : mettre à jour le code Dailymotion

7 March 202413 décembre 2014 by Matt Biscay · Lecture: 1 minute

Cet article est le pendant de l’article pour remplacer le vieux code YouTube de vos articles WordPress par une URL oEmbed mais pour Dailymotion.

Voici donc les manipulations à effectuer pour transformer les vieux codes d’intégration avec les URL oEmbed de WordPress.

Nous utilisons toujours le plugin Search Regex pour WordPress avec la case regex activée et le signe dièse (#) comme délimiteur pour les expressions régulières.

Remplacer les liens swf/video de Dailymotion

J’appelle ces liens “swf/video” parce qu’on retrouve cela dans l’URL de l’intégration Flash. Il vaut mieux lancer cette substitution en premier.

On recherche :

#<object data="http://www.dailymotion.com/swf/video/(.*)" width="300" height="150">(.*)</object>#Code language: HTML, XML (xml)

Et on remplace par :

https://www.dailymotion.com/video/$2Code language: JavaScript (javascript)

Remplacer les liens swf de Dailymotion

On s’occupe maintenant des liens qui contiennent juste le terme “swf”.

On recherche :

#<object data="http://www.dailymotion.com/swf/(.*)" width="300" height="150">(.*)</object>#Code language: HTML, XML (xml)

Et on remplace par :

https://www.dailymotion.com/video/$2Code language: JavaScript (javascript)

Voilà, vous venez de nettoyer les anciens codes d’intégration Flash pour les remplacer par des URI oEmbed natives. Propre.

WordPress : remplacer le vieux code YouTube de vos articles par une URL oEmbed photo

WordPress : mettre à jour le code Youtube

7 March 202411 décembre 2014 by Matt Biscay · Lecture: 2 minutes

Le code des plateformes – vidéos ou autre – évolue et il n’est pas rare de tomber sur de vieux articles qui embarquent un vieux code embed pour afficher des vidéos.

Si votre site a quelques années, il y a plusieurs méthodes d’intégration – plus ou moins optimisées – dont certaines ne s’afficheront pas (celles utilisant le plugin Flash par exemple) sur une tablette ou un smartphone.

Sur SkyMinds, je me suis dit que ce serait sympa d’avoir un système unifié : toutes les vidéos YouTube seront automatiquement insérées par WordPress en utilisant la méthode native, à savoir oEmbed.

Pour ce faire, j’utilise le plugin Search Regex qui permet d’intervenir facilement sur la base de données pour effectuer des changements en masse, tout en proposant la visualisation des changements avant que ces derniers ne soient appliqués.

Toutes les manipulations sont à effectuer avec Search Regex, en activant la case regex. Je me sers du signe dièse (#) comme délimiteur pour les expressions régulières.

Remplacer le vieux code d’intégration flash de YouTube

Avec Search Regex, on cherche :

<object [^>]*><param name="movie" value="https:\/\/www\.youtube\.com\/v\/([^"&?]+)">.*?<\/object>Code language: HTML, XML (xml)

Et on remplace par :

https://www.youtube.com/watch?v=$1Code language: JavaScript (javascript)

Mise à jour du site du Centre de Kriya Yoga France : v4.0

2 March 202402 décembre 2014 by Matt Biscay · Lecture: 2 minutes

Il y a quelques mois de cela, le site du Centre de Kriya Yoga France a eu droit à un léger rafraichissement de son style : un peu plus de lisibilité, moins de fonds colorés, un peu plus de finesse dans les traits.

C’était juste un petit coup de plumeau mais comme j’ai oublié de vous en parler, voici une petite capture d’écran :

Mais cette semaine, j’ai retroussé mes manches et suis totalement passé à l’offensive :

redéfinition des couleurs
création du logo et des favicons
création de la boutique totalement intégrée à WordPress
mode responsive/adaptive pour smartphones et tablettes
conversion des pages de contenus en articles et classement des articles par catégories, en silos
modification des permaliens pour n’utiliser que le nom des articles
intégration des réseaux sociaux avec les comptes dédiés au CKYF
et de multiples essais en trial and error !

Note pour plus tard : si, lors de la prévisualisation d’un thème WordPress, rien ne s’affiche ou si la personnalisation (customizer) ne répond pas, c’est qu’un plugin met la zone au niveau du javascript. Dans mon cas, c’était pdf-js.

Without further ado, je suis assez content de vous présenter la version 4.0 :

Pas mal de changements mais je pense que cela en vaut vraiment le coup. Le site devenait vieillissant et n’était plus adapté aux smartphones et tablettes, et l’ancienne boutique (Cubecart) était une horreur à gérer.

Tout est beaucoup plus simple maintenant, avec de jolis graphiques pour les commandes, la gestion du stock… bref, c’est bien mieux pour moi à gérer et plus simple pour le CKYF.

Qu’en pensez-vous ?

WordPress : récupérer la liste emails des membres et commentateurs

29 March 202225 novembre 2014 by Matt Biscay · Lecture: 1 minute

Voici deux requêtes SQL pour récupérer la liste des adresses email de tous les utilisateurs d’un site tournant sous WordPress.

Emails des membres

En supposant que le préfixe WordPress est ‘wp_’, cette requête extrait l’adresse email de chaque membre du site :

/* Query name : get members' emails
/* Author : Matt
/* Author URI : https://www.skyminds.net/
*/
SELECT DISTINCT user_email FROM wp_users GROUP BY user_emailCode language: JavaScript (javascript)

Emails des commentateurs

Et cette requête extrait l’adresse email de chaque personne ayant commenté sur le site :

/* Query name : get commenter' emails
/* Author : Matt
/* Author URI : https://www.skyminds.net/
*/
SELECT DISTINCT comment_author_email FROM wp_comments WHERE comment_approved<>'spam' GROUP BY comment_author_emailCode language: JavaScript (javascript)

Astuce SQL : la clause DISTINCT permet d’éviter d’avoir des doublons dans la liste.

Serveur dédié : passer WordPress en HTTPS (TLS/SSL)

30 September 202407 octobre 2014 by Matt Biscay · Lecture: 9 minutes

Vous avez sauté le pas et avez validé votre nom de domaine avec un certificat TLS/SSL. Très bien ! Voyons comment passer WordPress sur la version sécurisée de votre site.

Il existe des plugins WordPress entièrement dédiés à SSL pour rediriger vers les pages sécurisées mais on peut très bien faire sans, avec un peu d’huile de coude.

Le tutoriel est pour Debian et WordPress tourne sous Apache chez moi. Cela prend moins d’une heure pour configurer l’essentiel mais il est probable que vous ayez des petites corrections (thèmes, plugins) pour que tout soit servi en https.

Le but est de tout (oui, absolument tout!) servir via la connexion sécurisée.

Étape 1 : configurer Apache

On édite notre fichier de configuration :

nano /etc/apache2/sites-available/www.skyminds.net

et voici ce que garde pour VirtualHost *:80 :

ServerName www.skyminds.net
ServerAlias skyminds.net
DocumentRoot /home/skyminds/public_html/
Redirect 301 / https://www.skyminds.net/Code language: JavaScript (javascript)

La directive ServerName est nécessaire. Ensuite, une simple redirection renvoie toutes les requêtes du port 80 vers le port 443, sécurisé. Même pas besoin de mod_rewrite!

← Précédent Suivant →