WordPress

Tous les articles relatifs à WordPress et à son optimisation.

Créer un site staging pour WordPress sur un sous-domaine photo

Migrer WordPress d’un répertoire à la racine d’un domaine

by · Lecture: 4 minutes
Migrer WordPress

Si vous avez installé WordPress dans un répertoire, vous vous êtes peut-être un jour posé la question suivante : “et si je transférais tout à la racine du domaine ?”.

Si c’est le cas, sachez que cette migration ne prend que quelques minutes. 20 minutes environ sont nécessaires et les anciens liens seront redirigés automatiquement vers les nouveaux, sans risque d’erreur 404.

Le codex a bien une page qui explique comment migrer WordPress mais il y a beaucoup plus simple et moins risqué : je vous propose donc 5 étapes et non 12.

Lire la suite

WordPress hack : repair & optimize your database

by · Lecture: 2 minutes

Au vu des récentes tribulations de Claude, j’ai quelque peu amélioré le script PHP que j’ai écrit pour SkyMinds.Net et qui me permet de réparer et d’optimiser toutes les tables de ma base de données WordPress en un seul clic. Pour les intéressé(e)s, voici le code :


/*
Hack Name: Fix'n'Optimize
Hack URI: https://www.skyminds.net/wordpress-hack-repair-optimize-your-database/
Description: This hack repairs and optimizes your WP database.
Version: 1.0
Author: Matt
Author URI: https://www.skyminds.net/
*/ 

// Include DB config file.
include("wp-config.php");

// Remove useless data in some tables prior to optimizing.
$trunk = $wpdb->query("TRUNCATE TABLE `naatan_useronline`");
$trunk = $wpdb->query("TRUNCATE `wp_bad_behavior`");

// Grab table names.
$grab_all_tables = $wpdb->get_col("SHOW TABLES");

// Go through the list : repair/optimize all tables.
foreach($grab_all_tables as $table_name)
{
	$wpdb->query("REPAIR TABLE `".$table_name."`");
	$wpdb->query("OPTIMIZE TABLE `".$table_name."`");
}

Je lance ce script dans un navigateur de temps en temps – une fois par semaine environ -, histoire d’avoir une base de donnée ordonnée et réactive. Je ne transforme pas ce hack en plugin pour le moment, étant donné que c’est un script à lancer occasionnellement. On pourrait en faire un cron remarquez. Si j’ai le temps, pendant les vacances…

Le plugin WordPress ne s’affiche pas dans la liste des plugins

by · Lecture: 1 minute

Si votre blog ou CMS est géré par WordPress et que vous utilisez ou écrivez des plugins pour l’enrichir de quelques fonctionnalités, vous serez peut-être confronté au problème suivant.

Dans certains cas, WordPress n’affiche pas votre plugin dans la liste des plugins. Du coup, impossible de l’activer !

Après avoir passé un peu de temps à chercher le pourquoi du comment, je me suis rendu compte que WordPress était devenu très tâtillon sur la manière dont l’entête du plugin doit être disposé.

Voici l’entête d’un bon plugin :

/*
Plugin Name: Snowy
Plugin URI: https://www.skyminds.net/snowy/
Description: Adds self-generated snowflakes to WordPress.
Version: 1.2
Author: Matt
Author URI: https://www.skyminds.net/
*/

Observez bien la structure : Plugin Name, Plugin URI, Description, Version, Author et Author URI.

Si jamais il vous prenait l’idée d’inverser Description et Version, patatras ! Le plugin devient activable seulement s’il se trouve dans /wp-content/plugins/ mais pas s’il se trouve dans /wp-content/plugins/snowy/ par exemple.

En espérant que cela vous évite quelques heures de recherche !

Résoudre l’erreur HTTP 406 Not Acceptable

by · Lecture: 2 minutes

Depuis que mon hébergeur a mis ses serveurs en cluster et exécute PHP en CGI et non comme module Apache, certaines fonctions de WordPress ne se comportent pas correctement, notamment les éditeurs de fichiers.

En effet, ces derniers semblent être devenus incapables de modifier les fichiers sans provoquer une erreur HTTP 406 :

HTTP Error 406 – Not acceptable
An appropriate representation of the requested resource /XYZ.php could not be found on this server.

Après quelques recherches, il semblerait que ce soit les filtres du mod_security d’Apache qui, trop restrictifs, empêchent les éditeurs… d’éditer !

La solution consiste donc à désactiver mod_security dans le répertoire où se trouvent les éditeurs (/wp-admin/ dans le cas de WordPress) :

  1. Créez un fichier .htaccess
  2. Editez le fichier avec ces instructions : 
    
SecFilterEngine Off
SecFilterScanPOST Off
  3. Sauvegardez : vos éditeurs devraient maintenant fonctionner sans aucune erreur.

Notez que j’ai pris WordPress comme exemple mais cela résout les problèmes d’erreurs 406 quelle que soit l’application utilisée (blog, CMS…).

Mieux vaut créer le .htaccess dans le répertoire qui en a besoin : il est inutile voire déconseillé de désactiver mod_security sur l’ensemble d’un domaine pour des raisons évidentes de sécurité.

A utiliser là où il y a besoin donc.

Snowy : un plugin WordPress qui fait des flocons

by · Lecture: 1 minute
Snowy

Je viens d’écrire un nouveau petit plugin pour WordPress, baptisé Snowy, qui sera chargé d’afficher des flocons de neige sur le site à partir de décembre.

J’ai opté pour la solution sans images créée par Kurt Grigg : les flocons sont générés dynamiquement en DHTML.

L’essentiel du code est contenu dans un simple fichier javascript, le plugin injecte simplement ce code à la fin des pages HTML.

Simple et efficace, idéal pour donner un petit côté festif au blog sans pour autant gêner la lecture (ce qui est souvent le cas avec des images fixes).

Intéressés ? Tout se passe sur la page de Snowy.

Snowy, let it snow on your WordPress

by · Lecture: 1 minute

Snowy est un plugin pour WordPress qui permet de faire tomber quelques flocons de neige sur votre blog. Il ne requiert pas d’image, les flocons sont générés dynamiquement en DHTML.

Snowy is a WordPress plugin that makes some snowflakes fall all over you blog (ideal for the Christmas season !). It does not require any images, everything is dynamically generated via DHTML.

Dernière version / Latest version : 1.1

Install notes

  • Extract all files in /wp-content/plugins/snowy/
  • Activate the plugin

Changelog

  • v1.1 (15 Nov 2006) : fixed the script header.
  • v1.0 (12 Nov 2006) : initial release

Licence

The script is linkware. A link back here would be appreciated if you use the script.
And you can always show your appreciation by clicking the donate button ;-)

Sortie de WP-Date FR v1.2

by · Lecture: 1 minute
bug-fix pansement

Sortie de WP-Date FR v1.2 aujourd’hui : pas de grands changements, j’ai juste rajouté l’encodage UTF-8 pour que les noms de mois accentués (comme août par exemple) s’affichent correctement.

La mise à jour aurait dû être faite il y a quelques jours mais cela m’est complètement sorti de la tête.

Cela est peu ou prou la version finale. Je cherche toujours à franciser la date des commentaires mais apparemment rien n’y fait, cela ne semble pas possible pour le moment.

Rendez-vous sur la page dédiée à WP-Date FR ou téléchargez WP-Date FR v1.2 directement.

WordPress: migration d'une base de données iso-8859-15 au format UTF-8 photo

WordPress: migration d’une base de données iso-8859-15 au format UTF-8

by · Lecture: 6 minutes
Modifications

Après avoir joué avec WordPress 2.0.4 pour le compte du Centre de Kriya Yoga France et questionné à ce sujet par creatix, je me suis mis en tête de mettre le blog à jour.

Mais quitte à mettre à jour, autant le faire proprement, c’est à dire de manière pérenne.

J’ai donc étudié les nouvelles fonctions apportées par WP2+ et j’ai pu me défaire d’au moins 5 ou 6 plugins dont les fonctions sont maintenant inclues par défaut dans WordPress.

Mais ce n’est pas tout : ma base de données WP 1.5+ était encodée en iso-8859-15 (caractères de l’Europe de l’Ouest, avec le symbole Euro), ce qui était bien en 2004 mais qui ne l’est plus en 2006. Hé oui, les temps changent et les encodages de caractères avec eux !

Place donc à l’UTF-8, un codage qui se veut universel (il permet de représenter des milliers de caractères de toutes sortes de langues, dont l’ensemble des caractères spécifiques français), compatible (un texte en US-ASCII est codé identiquement en UTF-8) et visant l’interopérabilité (chaque caractère est codé sur une suite de un à quatre octets.

UTF-8 a été conçu pour être compatible avec certains logiciels originellement prévus pour traiter des caractères d’un seul octet).

Lire la suite

Récupérer l’ID d’un post ou d’une page sous WordPress

by · Lecture: 2 minutes

Vous utilisez peut-être WordPress pour publier votre blog.

Vous avez commencé à modifier un thème pour l’adapter à vos besoins/goûts/envies mais une variable vous résiste : la variable qui permet d’afficher un post grâce à un numéro unique l’identifiant (ID).

Par défaut, cet identifiant est disponible uniquement à l’intérieur de la boucle (The Loop) de WordPress :

/* on affiche le numéro de post/page dans la boucle WordPress */
the_ID();Code language: JavaScript (javascript)

Tant que vous vous trouvez dans la boucle, aucun souci.

Par contre, si vous souhaitez écrire votre propre plugin ou utiliser cette variable dans votre sidebar, vous êtes un peu coincé car the_ID() n’est alors plus une fonction valide.

Pour remédier à ce problème, vous pouvez utiliser la variable $post->ID afin de retourner le numéro du post ou de la page.

Jettez un oeil au code suivant :

/* on fait de $post une variable globale */
global $post;

/* on stocke la variable dans un nom de variable inutilisé */
$sky_post_ID = $post->ID;

/* on affiche cette variable */
echo $sky_post_ID;Code language: PHP (php)

Alternative, en effectuant une requête SQL simplifiée par $wp_query.

Cette méthode est utilisée principalement hors de la boucle, en travaillant directement sur la base de données :

/* on fait de $wp_query une variable globale */
global $wp_query;

/* on stocke la variable dans un nom de variable inutilisé */
$sky_post_ID = $wp_query->post->ID;

/* on echo cette variable */
echo $sky_post_ID;Code language: PHP (php)

Voilà, vous devriez maintenant pouvoir accéder à ces fameux post id et page id.

Happy coding :)

Sélection de plugins anti-spam pour WordPress

by · Lecture: 2 minutes

Tiens, c’est bizarre, je commence à avoir du spam sur mon compte Gmail : je n’en avais jamais eu jusqu’à présent et j’ai bien dû en recevoir une dizaine aujourd’hui. Même s’il est immédiatement capté par les filtres et redirigé dans le dossier spam, on perd toujours du temps à vérifier que des messages légitimes ne sont pas passés à la trappe. Une vraie perte de temps.

Heureusement, je n’ai (quasiment) plus ce problème sur le blog : après des dizaines d’essais, je pense à être arrivé à la solution la plus intéressante en terme de défenses antispam.

J’ai abandonné la solution en .htaccess qui bloquait certains utilisateurs pour utiliser les plugins suivants :

  • Better Comments ventile à vue les commentaires postés avec des noms d’utilisateurs composés uniquement de chiffres et permet d’éviter qu’un inconnu ne se fasse passer pour un utilisateur enregistré sur le site.
  • SpamJam est le must du must: il trompe littéralement tous les bots avec sa panoplie de mesures antispam, qui ont le mérite de fonctionner mais surtout d’être complètement invisibles pour les gens normaux.

Analysons un peu la situation : en activant seulement Akismet, le blog captait entre 100 et 200 spams par jour. En activant SpamJam, c’est environ un spam tous les trois mois !

Ce sont pour moi les 2 plugins les plus efficaces. J’ai essayé Bad Behavior pendant quelques temps mais cela ne m’a pas convaincu, doublant la taille de la base de donnée en quelques jours !

Akismet devient payant dès que vous tentez de monétiser votre site donc ce n’est pas une solution viable non plus (mais je peux comprendre, ce ne peut être un service gratuit vu le nombre dantesque de spams traités tous les jours).

Je considère donc ma quête comme momentanément aboutie – être virtuellement spam-free, c’est très agréable !

Song Displayer Live : a webradio feed checker

by · Lecture: 2 minutes
Webradio feed checker WP plugin

Qui dit nouvelle radio dit nouvelles fonctionnalités, nouveautés et tutti quanti.

Maintenant que Thunderstruck Radio tourne avec SAM Broadcaster un peu plus souvent qu’avec la mouture précédente (qui utilisait Winamp), j’ai dû quelque peu adapter Song Displayer afin que l’affichage des informations du flux soit actualisé en permanence, présentant ainsi le nom de la chanson et de l’artiste au moment même où ils jouent sur la radio.

Song Displayer, à l’origine, fonctionnait de la manière suivante : formatage des données dans un fichier texte, upload de ce fichier sur le serveur, extraction et présentation des données sur le site.

Les infos étaient affichées si la dernière modification du fichier texte était inférieure à 7 minutes. Passé ce délai, la radio était considérée comme offline.

Or, si la webradio tourne quasiment en permanence, on arrive vite à quelques problèmes de bande passante : ce système n’est plus adapté et mieux vaut détecter si le flux est actif au lieu de recourir à la lecture d’un fichier.

J’ai donc retouché Song Displayer pour qu’il regarde dans le répertoire pages jaunes Icecast si le flux s’y trouve. Le script recherche donc le flux et en extrait les infos. Simple et efficace. ^_^

Je n’ai pas sorti publiquement cette version du plugin parce qu’il me semble que peu de gens possèdent une webradio tout en utilisant Song Displayer. Mais peut-être me trompe-je ! Si c’est le cas, dîtes-le moi.

← PrécédentSuivant →