WordPress : nettoyer les tables wp_options et wp_postmeta photo

WordPress : nettoyer les tables wp_options et wp_postmeta

Nous allons aujourd’hui examiner deux tables importantes de votre base de données WordPress, wp_options et wp_postmeta.

C’est un domaine qui est souvent négligé en ce qui concerne les performances globales de WordPress et de la base de données.

Cela est très visible sur les sites les plus anciens et les plus gros et peut être la cause des temps de requête lents sur votre site en raison des données à chargement automatique laissées par les plugins et les thèmes tiers.

Voici quelques conseils pour vérifier, dépanner et nettoyer vos tables wp_options et wp_postmeta.

Que contient la table wp_options ?

La table wp_options contient toutes les données relatives aux options et paramètres de votre site WordPress telles que:

  • URL du site, URL de la page d’accueil, adresse électronique de l’administrateur, catégorie par défaut, publications par page, format d’heure, etc.
  • Paramètres pour les plugins, les thèmes, les widgets,
  • Données temporairement mises en cache.

La table wp_options contient plusieurs champs :

  • option_id
  • option_name
  • option_value
  • autoload

Le champ qui nous intéresse particulièrement est le champ autoload, qui contient un drapeau qui peut être soit “yes”, soit “no”. Cela contrôle essentiellement si la valeur est chargée ou non par la fonction wp_load_alloptions().

Les données à chargement automatique sont des données qui sont chargées sur chaque page de votre site WordPress. L’attribut autoload est défini sur «yes» par défaut pour les développeurs, mais tous les plugins ne doivent théoriquement pas charger leurs données sur chaque page.

Le problème que les sites WordPress peuvent rencontrer est celui où la table wp_options contient une grande quantité de données auto-chargées. Cependant, la table wp_options n’a pas non plus été conçue pour contenir des milliers de lignes.

Combien coûte trop de données autoloadées? Cela peut varier, bien sûr, mais idéalement, vous voulez que la taille de votre ordinateur soit comprise entre 300 Ko et 1 Mo.

Une fois que vous commencez à approcher la plage de 3 à 5 Mo ou plus, il existe très probablement des éléments pouvant être optimisés ou supprimés du chargement automatique.

Et tout ce qui dépasse 10 Mo doit être traité immédiatement. Cela ne signifie pas toujours que cela posera un problème, mais c’est un bon point de départ.

Vérifier la taille totale des données auto-chargées

On peut calculer la taille totale des données auto-chargées d’un site WordPress en effectuant la requête suivante sous MySQL:

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Code language: JavaScript (javascript)

La valeur d’autoload_size est exprimée en octets. Il y a 1024 octets dans un KB et 1024 KB dans un MB. Dans notre cas, 622 138 octets sont donc égaux à 0,62 MB. Donc pour ce site, c’est une bonne taille! Si vous restituez moins de 1 Mo, ne vous inquiétez pas. Cependant, si le résultat était beaucoup plus grand, passez à l’étape suivante.

Lire la suite

Ajouter un lien avec le nombre d'articles et le total du panier WooCommerce photo

Mettre à jour la base de données de WooCommerce avec wp-cli

Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.

Cet échec de la mise à jour de la base de données est généralement causé par le délai d’attente de PHP, en particulier sur l’environnement d’hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s’exécuter via une requête Web.

La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l’origine de problèmes.

Mise à jour de la base WooCommerce en ligne de commande

Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.

1. Connectez-vous au serveur en SSH.

2. Naviguez jusqu’à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:

wp wc update

Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :

wp wc update

Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0Code language: CSS (css)

3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.

Et voilà votre base de données WooCommerce à jour!

The SEO Framework : résoudre l'erreur 404 du fichier sitemap.xml sous NginX photo

The SEO Framework : résoudre l’erreur 404 du fichier sitemap.xml sous NginX

Cela fait belle lurette que j’ai troqué Yoast SEO pour The SEO Framework, qui est bien mieux codé et plus performant.

Récemment, lors d’un changement de serveur, je me suis aperçu que l’un des sites avait son fichier sitemap.xml qui renvoyait une erreur 404 sous NginX.

Si cela vous arrive, deux solutions s’offrent à vous.

Vérification du server block

Commencez d’abord par vérifier que votre serveur block contient les bonnes directives pour gérer les règles de WordPress:

location / {
        # This is cool because no php is touched for static content.
        # include the "?$args" part so non-default permalinks doesn't break when using query string
        try_files $uri $uri/ /index.php?$args;
}Code language: PHP (php)

Sauvez votre server block puis relancez NginX. Il est possible que cela ne soit pas suffisant, si c’est le cas, nous allons ajouter une directive supplémentaire.

Une directive dédiée pour sitemap.xml

Ajoutons une directive supplémentaire à notre server block, qui permettra de rediriger vers la sitemap générée par The SEO Framework :

# sitemap.xml directive
# Matt Biscay
# https://www.skyminds.net/?p=30771
location = /sitemap.xml {
	rewrite ^/sitemap.xml$ "/?the_seo_framework_sitemap=xml" permanent;
}Code language: PHP (php)

Sauvez les changements et rechargez NginX – boom, la sitemap est de retour!

WordPress : corriger l'erreur

WordPress : corriger l’erreur “Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given”

Je travaille actuellement sur un projet Codeable qui nécessite de passer de PHP5.6 à PHP7.2. Le site en question est une boutique WooCommerce avec un thème custom qui est hébergé chez WPEngine. Jusque là, tout va bien.

Lors de la migration sur un serveur PHP 7.4, le site de developpement (Staging) affiche alors un message d’avertissement sur toutes les pages :

Parameter 1 to wp_default_styles() expected to be a reference, value given
Parameter 1 to wp_default_scripts() expected to be a reference, value given

Après avoir passé un bon moment à éliminer les causes (plugins et thème), il se trouve que c’est un bug de WordPress 4.9.8 (la dernière version en date) dont il est question dans le ticket #44979.

Voici la solution temporaire à ce problème :

  1. éditez /wp-includes/script-loader.php
  2. retirez le caractère & de l’argument des fonctions wp_default_scripts() et wp_default_styles()
  3. sauvegardez le fichier
  4. rechargez le site, les deux messages d’avertissement ont disparu.

Voilà, ce n’est qu’un hotfix mais ce bug devrait être corrigé dans la prochaine version de WordPress – version 4.9.9 – qui sortira prochainement.

Installer Redis pour accélérer WordPress sous Debian photo

Installer Redis pour accélérer WordPress sous Debian

Aujourd’hui, nous installons le serveur Redis pour accélérer les temps de chargement de tous les sites présents sur le serveur.

Redis (de l’anglais REmote DIctionary Server qui peut être traduit par « serveur de dictionnaire distant » et jeu de mot avec Redistribute1) est un système de gestion de base de données clef-valeur scalable, très hautes performances, écrit en C ANSI.

Il fait partie de la mouvance NoSQL et vise à fournir les performances les plus élevées possibles.

Redis permet de manipuler des types de données simples : chaînes de caractères, tableaux associatifs, listes, ensembles et ensembles ordonnés.

Une des principales caractéristiques de Redis est de conserver l’intégralité des données en RAM. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux sur ce plan.

Lorsqu’une page WordPress est chargée par exemple, des requêtes sur la base de données sont lancées et cela prend un certain temps pour récupérer ces informations.

Lorsque Redis est activé, il garde ces requêtes SQL en mémoire, ce qui permet de gagner en temps de chargement des pages.

Voici donc le tutoriel pour mettre en place Redis sur votre serveur. Cela prend environ 15 minutes.

Installation du serveur Redis

Nous installons le serveur Redis et le paquet PHP associé:

apt install redis-server php-redis

Nous vérifions que Redis est bien actif, il nous suffit de lancer redis-cli:

redis-cli

On tape ping dans l’invite:

127.0.0.1:6379> pingCode language: CSS (css)

Réponse:

PONG

Parfait, le serveur Redis est bien installé et actif.

Configuration de Redis

Editons le fichier de configuration de Redis :

nano /etc/redis/redis.conf

Changez les valeurs suivantes :

maxmemory 256mb # max memory 
maxmemory-policy allkeys-lru # replace old keys with fresher ones
requirepass VOTRE-MOT-DE-PASSECode language: PHP (php)

Enregistrez et relancez le serveur pour prendre en charge la nouvelle configuration:

service redis-server restart

Lire la suite

CSS : supprimer subtilement le placeholder d'un champ input ou textarea photo

CSS : supprimer subtilement le placeholder d’un champ input ou textarea

Je viens de finir un projet sur Codeable qui utilisait WordPress et Gravity Forms et lors de la réalisation d’un formulaire de réservation complexe, je me suis heurté à Chrome qui ne supprime pas toujours (suivant les versions utilisées) le texte du placeholder d’un champ de type input ou textarea lorsque le curseur est placé à l’intérieur (action focus).

Normalement, la valeur du placeholder disparaît et permet à l’utilisateur de compléter sa saisie mais sous certaines versions de Chrome, cela ne passe pas bien.

J’ai considéré l’utilisation de JavaScript, évidemment, avant de me rendre compte que l’on pouvait résoudre le problème avec quelques règles CSS natives. Toutes les déclarations sont à ajouter – ne cherchez pas à les compiler, cela ne fonctionnera pas !

On joue donc avec l’opacité et un léger effet de transition pour le côté subtil et smooth :

/* Placeholders */
::-webkit-input-placeholder { opacity: 1; transition: opacity .5s; }  /* Chrome 56, Safari 9 */
:-moz-placeholder { opacity: 1; transition: opacity .5s; } /* FF 4-18 */
::-moz-placeholder { opacity: 1; transition: opacity .5s; } /* FF 19-51 */
:-ms-input-placeholder { opacity: 1; -ms-transition: opacity .5s; transition: opacity .5s; } /* IE 10+ */
::placeholder { opacity: 1; transition: opacity .5s; } /* Modern Browsers */

/* Focus */
*:focus::-webkit-input-placeholder { opacity: 0; } /* Chrome 56, Safari 9 */
*:focus:-moz-placeholder { opacity: 0; } /* FF 4-18 */
*:focus::-moz-placeholder { opacity: 0; } /* FF 19-50 */
*:focus:-ms-input-placeholder { opacity: 0; } /* IE 10+ */
*:focus::placeholder { opacity: 0; } /* Modern Browsers */Code language: CSS (css)

Ps : Chrome souffre également d’un bug qui concerne la fonction autofill qui aide les utilisateurs à pré-remplir les formulaires.

Pensez donc à supprimer les valeurs enregistrées pendant vos tests (Chrome > Paramètres > Paramètres avancés > Confidentialité et sécurité > Effacer les données de navigation > Paramètres avancés > cocher Données de saisie automatique).

Enjoy !

Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Nginx : créer un nouveau site WordPress dans un sous-répertoire, sans conflit avec le site principal

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}Code language: PHP (php)

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restartCode language: CSS (css)

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

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

WordPress: mettre un plugin à jour sur plusieurs sites sur le serveur en une seule opération

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.

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à !

Lire la suite

Nouveau logo pour SkyMinds (version 2018) photo

Nouveau logo pour SkyMinds (version 2018)

Aujourd’hui, le logo de SkyMinds fait peau neuve ! Plus discret, plus moderne aussi. J’en ai profité pour mettre en place toute une liste de modifications cosmétiques que j’ai trop longtemps repoussées.

Nouveau logo pour SkyMinds (version 2018) photo
Nouveau logo !

Mise à jour des templates du thème enfant

L’avantage d’un thème enfant sous WordPress, c’est que l’on ne perd pas ses modifications lorsque le thème parent se met à jour. Le thème enfant, c’est tout simplement la base, l’étape qui vient juste après l’installation d’un nouveau thème.

Or, au fil des mois ans, il se trouve que le thème parent évolue et que les fichiers du thème enfant (modifiés) ne sont plus exactement à jour. J’en ai donc profité pour reprendre les nouveaux fichiers et y apporter mes modifications.

Concaténation des appels des fichiers de police

En analysant les fichiers du thème, je me suis rendu compte qu’on pouvait gagner pas mal de temps de chargement grâce à une épuration du nombre de polices utilisées sur le site. Au lieu d’en avoir deux (Open Sans et Droid Sans), il n’y en aura plus qu’une : Open Sans. Elle est légère, classique et facile à lire.

Le problème, c’est que Divi charge pas mal de versions de cette police par défaut : 300, 400, 700… en normal, italic et gras et avec des subsets exotiques comme le cyrillique, le grec ou le vietnamien. Clairement, on doit pouvoir mieux faire !

Divi : suppression des subsets Google Fonts

On commence par virer les subsets exotiques. Rendez-vous dans Divi > Theme options > General > désactivez Google Fonts subsets. Vous venez d’économisez 400KB.

Divi : suppression de toutes les Google Fonts et chargement de l’unique nécessaire

C’est pénible d’avoir tous les grammages d’une police chargés pour rien. Voici ce que j’utilise pour tout virer dans un premier temps, puis ajouter uniquement ce dont j’ai réellement besoin:

/*
|-----------------------------------------------------------------------
| Plugin Name: Sky Remove DIVI Google Fonts and add what we need
| Plugin URI:  https://www.skyminds.net/?p=29578
| Author:  Matt Biscay
| Author URI:  https://www.skyminds.net/
|-----------------------------------------------------------------------
*/

// remove all Divi fonts, we'll just load what we need
// @return: array
function et_builder_get_google_fonts() { return array(); }
function et_get_google_fonts() { return array(); }

// add fonts : logo (Comfortaa:700) and site (Open+Sans:400,700). No subsets.
add_action( 'wp_enqueue_scripts', 'sky_logo_add_google_fonts' );
function sky_logo_add_google_fonts() {
	wp_enqueue_style( 'sky-logo-google-fonts', 'https://fonts.googleapis.com/css?family=Comfortaa:700|Open+Sans:400,700', false ); 
}
Code language: PHP (php)

Kaboom! On vient de se retirer une sacrée épine du pied. Il faudra juste relire la feuille de style pour être sûr que l’on utilise bien soit du font-weight 400 (regular), soit du 700 (bold). Pensez également à vérifier votre critical CSS.

Amélioration de la section Auteur

A la fin de chaque article se trouve la section de l’auteur, qui comprend une courte description ainsi que des liens vers ses profils sociaux. J’ai profité de la police du thème pour remplacer les noms des réseaux par des icônes. C’est purement cosmétique mais je trouve cela plus joli.

Cela m’a permis de me rendre compte que le site n’utilise absolument pas Font Awesome – ce que je trouve totalement fou. J’aime tellement cette police que j’ai acheté la version professionnelle pour mes développements… et ne l’utilise pas moi-même !

J’ai troqué le bleu clair pour un beige. A voir sur la durée.

Nouveau logo

Et enfin, last but not least, j’ai troqué mon logo image contre un logo font. Cela faisait pas mal de temps qu’il me trottait dans la tête l’idée de le changer. J’ai d’abord commencé, comme d’habitude, par tenter de créer des logos images avant de changer mon fusil d’épaule et considérer la possibilité d’utiliser une Google Font pour le générer à la volée.

Après quelques recherches, j’ai finalement opté pour la police Comfortaa en 700. C’est plutôt moderne par rapport au logo précédent qui avait la particularité d’être un dégradé de plusieurs couleurs (rose, violet, bleu, vert), avec des ligatures à certaines lettres.

Celui-ci sera donc beaucoup plus clean et professionnel. Je pense d’ailleurs le réutiliser sur d’autres supports de personal branding.

Lire la suite

WordPress : afficher des média oEmbed avec HTTPS photo

WordPress : forcer le chargement des média oEmbed en HTTPS

Lorsque le site est servi via HTTPS, toutes les ressources – même les ressources oEmbed automatiquement générée par WordPress – qui composent une page doivent également être servies via une connexion chiffrée aussi.

Il se trouve que je mets des vidéos Youtube et consorts de temps en temps : elles ne s’affichaient plus en https, étant servies par défaut en http.

Le changement vers HTTPS est en marche mais tous les services oEmbed n’ont pas encore adopté le chiffrement des connexions.

Servir les vidéos Youtube en HTTPS

Au lieu d’utiliser Youtube.com, nous allons utiliser la version cookie-less de Youtube, à savoir youtube-nocookie.com : cela permet d’éviter les cookies pisteurs de Google et donc offre plus de sécurité et de respect de la vie privée.

J’utilise ce système depuis des années sur SkyMinds donc je me suis dit qu’il était bien temps de le partager dans ces colonnes.

Le code permet donc de remplacer youtube.com par youtube-nocookie.com dans le code généré par l’oEmbed WordPress.

Ce code est à ajouter dans votre utility plugin (ou à défaut le fichier functions.php de votre thème WordPress).

Le premier code remplace toutes les occurences des médias HTTP pour HTTPS :

<?php
/* Force HTTPS rewrite for oEmbeds
* Source : https://wordpress.stackexchange.com/questions/40747/how-do-i-embed-youtube-videos-with-https-instead-of-http-in-the-url
*/
add_filter( 'embed_oembed_html', 'sky_embed_oembed_html' );
function sky_embed_oembed_html( $html ) { 
  return preg_replace( '@src="https?:@', 'src="', $html );
}Code language: HTML, XML (xml)

Le second code modifie tous les appels à youtube.com et les remplace par youtube-nocookie.com, ce qui empêche la création de cookies pisteurs :

<?php
//BEGIN Embed Video Fix - HTTPS and privacy mode
//https://wordpress.org/support/topic/forcing-ssl-return-for-youtube-oembed

add_filter('the_content', 'sky_add_secure_video_options', 10);
function sky_add_secure_video_options($html) {
   if (strpos($html, "<iframe" ) !== false) {
    	$search = array('src="http://www.youtube.com','src="http://youtube.com');
	$replace = array('src="https://www.youtube-nocookie.com','src="https://www.youtube-nocookie.com');
	$html = str_replace($search, $replace, $html);
   	return $html;
   } else {
        return $html;
   }
}Code language: HTML, XML (xml)

Cela a l’air tout bête mais cela permet de faire respecter un peu plus notre droit au refus de se faire pister à tout bout de champs sur le net.

Le petit plus : on charge également moins de cookies, qui ne sont pas des ressources cachables par essence donc on améliore un peu aussi le temps de chargement de la page.

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

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

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)

Lire la suite

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

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

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.