Contrairement à WordPress 3.0, la version 3.1 se doit d’avoir un temps de développement court, les évolutions envisagées seront donc rapides, et il n’y aura pas de gros projets intégrés.

L’objectif de date pour la sortie finale de WordPress 3.1 est prévu pour mi-décembre 2010.

Cette version va avant tout privilégier les évolutions sur l’interface, la qualité et les performances du code et il n’y aura pas de modification sur le schéma. L’avis de l’équipe est de réserver les évolutions majeures pour WordPress 3.2, et ainsi produire un code de qualité en PHP5.

Donc première chose à retenir : pas de modification de schéma et pas de nouvelles API importantes.

Ce que ne contiendra pas WordPress 3.1

La refonte des médias. Une mise à jour importante du gestionnaire des médias a été envisagée par l’équipe de dev, c’est aussi l’une des demandes les plus récurrentes de la communauté. Il ne changera pas pour la simple et bonne raison que le code en question est assez tordu et qu’il serait regrettable de développer quelque chose en PHP4 alors que WordPress 3.2 sera compatible PHP5 uniquement.

De plus, c’est un chantier qui demandera du temps, qui imposera des modifications sur le schéma de la base de données et sur l’interface utilisateur. De fait, c’est un chantier couteux en temps.

Pour WordPress 3.1, la seule évolution possible sur le gestionnaire de médias sera l’envoi de fichiers HTML.

L’autre point important qui ne sera pas modifié dans WordPress 3.1 concernant la gestion de widgets. En effet, le filtrage des widgets par vue article/page/catégorie ne pourra être travaillé que dans WordPress 3.2.

En attendant, les plugins proposent des solutions appréciables.

Les fonctionnalités probables de WordPress 3.1

1. Des évolutions prévues sur l’API de taxonomie afin d’effectuer des requêtes avancées. WordPress 3.0 avec les custom types et les custom taxonomies a radicalement changé la façon de penser un site WordPress. L’API des taxonomies évolue logiquement pour répondre à toutes les attentes.

2. Une refonte importante des rôles/permissions est demandée par certains membres de l’équipe WordPress, pour la version 3.1, une première version de l’API sera proposée avec des fonctions permettant de travailler plus facilement sur les utilisateurs. À l’heure actuelle, les requêtes SQL « maison » priment encore dans ce domaine.

3. Une nouvelle fonctionnalité est également envisagée, il s’agit des liens internes. Autrement dit, la possibilité de créer des relations entre les contenus de WordPress. Il s’agit de la principale évolution à mes yeux de WP 3.1 !

Il fut un temps où seuls les articles relatifs permettaient de créer des liens entre les contenus, désormais il existe plusieurs plugins permettant de créer manuellement des liens entre le contenu (comme mon plugin Relation Post Types). Cette fonctionnalité est en vive discussion sur le trac.

4. Les pages de l’administration vont être largement AJAXifié avec quelques modifications mineures d’interface. La modération des commentaires sera également revue.

5. La barre d’administration avec menu déroulant. Très utile pour les plateformes de sites, buddypress, la barre d’administration semblable à WordPress.com fera probablement son apparition. Mais comme tout le monde n’est pas d’accord, la fonctionnalité restera peut-être sur la forme d’un plugin. (le plugin de Viper007Bond gère cela très bien pour le moment.)

6. Quelques simplifications et nettoyages de l’interface à travers toute l’application, et principalement le multi-site. Des pistes de recherche pour l’élaboration d’un tableau de bord personnel à la place du tableau de bord générale sont menées par Ryan. Ces modifications pourront être publiées dans WordPress 3.2 selon le planning.

7. Quelques corrections à prévoir sur l’API des custom post types.

8. Modification de l’interface de la gestion de thèmes par la version de WordPress.com. Cette dernière est plus efficace, plus légère, supporte la recherche, etc. C’est une étape indispensable pour les personnes ayant un WordPress MS avec beaucoup de thèmes.

9. Les templates de pages pour les articles. Afin de pouvoir supporter des modèles comme les pages)

10. La fonctionnalité QuickPress sera disponible à travers une fonction afin de pouvoir afficher facilement un formulaire sur le thème utilisateur.

Le planning

La date de publication ne devrait pas dépasser le 15 décembre pour ne pas interférer avec les vacances.

• 9 septembre : Confirmation du planning
• 15 octobre : feature freeze, pas de nouvelles fonctionnalités ajoutés dans le code
• 1er novembre : primary code freeze, fin de grands changements dans le code PHP
• 15 novembre :période de béta, plus d’amélioration, uniquement de la correction de bugs.
• 1 décembre : string freeze, traduction !
• 15 décembre : publication de WordPress 3.1

En fait, le bug se caractérise par la perte des catégories/mots clefs ou bien une "confusion" dans la taxonomie de WordPress. Vous éditez un mot clef avec l'ID 199 et ce dernier disparait au profit de la catégorie avec l'ID 8.

Étrange n'est ce pas !

Pourtant en base de données rien n'est perdu, c'est juste que la fonctionnalité globale catégories de WordPress Mu fout le bordel dans la table term_taxonomy.

Pour éviter d'avoir ce problème à l'édition, je vous donne un correctif très rapide : créer un fichier fix-bug-cat.php dans le dossier mu-plugins de votre installation WordPress Mu.

Et insérez-y le code suivant :

<?php
remove_filter ( 'term_id_filter', 'global_terms' );
?>

En désactivant le filtre fautif, vous vous évitez ce bug ennuyant... Pour ceux que ça intéresse, j'ai créé un ticket sur le trac à ce sujet pour probablement une correction définitive d'ici WordPress 3.0 !

Dernière traduction française de WordPress Mu, car sauf mise à jour de sécurité rapide, il n’y aura plus de nouvelles versions de Mu ! WordPress et WordPress vont en effet fusionner dans la prochaine version 3.0 de WordPress.

C’est pour moi un soulagement que les 2 versions fusionnent… WordPress Mu, bien que très pratique, générait quand même pas mal de travail à chaque mise à jour… Un installateur codé « en dur », pas de mécanisme pour générer les archives automatiquement, une traduction plus conséquente que WordPress…

Bref !

Je suis donc très content de vous annoncer la disponibilité immédiate de la version française de WordPress Mu 2.9.1.1. Cette dernière est complètement synchronisée sur la version 2.9 de WP.

Vous pouvez télécharger la traduction et/ou le pack complet depuis la page de téléchargement de WordPress Francophone.

La version 2.9.1 de WPmu apporte :

• Synchronisation avec WordPress 2.9.1

La version 2.9.1.1 de WPmu apporte :

• Correction de 2 bugs apparus dans WPmu 2.9.1 (enregistrement des options et l’API XML-RPC)
• Amélioration de la sécurité dans l’installateur.

Enfin, n’hésitez pas à effacer le fichier index-install.php de l’installation WordPress Mu, une fois la plateforme installée !

Le thème du plugin en question n’a rien d’innovant, le cache, et les concurrents sont multiples dont :

• WP Super Cache : cache HTML en fichiers
• BatCache : cache HTML via Memcached
• HyperCache : cache HTML en fichiers

Sans oublier le mécanisme de cache objet interne à WordPress qui peut se coupler aux différents optimiseurs PHP et logiciels de cache du marché… ( Xcache, APC, Memcached, eAccelerator )

W3 Total Cache se veut résolument comme une solution transversale, il travaille sur les aspects suivants :

• Le cache HTML
• Le cache DB, donc orienté objet
• La compression des fichiers CSS et JS via la compression : Minify.
• L’utilisation de serveurs CDN (via FTP)

Pour le moment, le plugin est compatible avec les logiciels Memcached et APC, mais d’autres interfaces devraient voir le jour (on parle de Xcache assez rapidement).

Autrement dit, tout cela est très prometteur… Malheureusement, ce plugin n’est pas destiné au commun des mortels… En effet, avec des prérequis comme APC ou Xcache, très peu d’hébergeurs mutualisés sont compatibles… ( par exemple OVH et 1and1 ne le sont pas )

Ce plugin est donc destiné aux personnes ayant un serveur dédié ou virtualisé…

Autre inconvénient, et de taille, malgré que le plugin se dise compatible WordPress Mu, il ne l’est pas pour le moment. Mais cela devrait vite être résolu !

Bon caching !

Un paquet, c’est pratique pour les raisons suivantes :

• Gestion des dépendances
• Simplicité d’installation
• Mise à jour du paquet en 1 ligne de commande

Cela permet de démocratiser un peu plus l’installation de WordPress Mu. Cependant, je ne suis pas persuadé que ça soit une bonne solution.

Cette simplicité, elle n’est pas recherchée par les utilisateurs avertis et les développeurs, elle est recherchée par les utilisateurs sans trop de connaissances et souhaitant installer WordPress Mu.

Ce qui me pose problème, ça n’est pas l’installation, c’est la procédure de mise à jour… Dans le cadre d’une plateforme de blogs, la stabilité, la sécurité, l’intégrité et la fiabilité sont des critères très importants. (plus que WordPress en tout cas)

Raisons pour lesquelles, on clone généralement son installation de production pour faire un site de test.

En voulant trop simplifier, on risque de se retrouver avec des plateformes de blogs administrés par des *newbies*, mettant à jour à coup de « apt-get update » et « yum upgrade« …

Où sont les tests de mise à jour ? Les sauvegardes ?

Ce mec, c’est moi… Pour l’anecdote momo360modena, c’est le pseudonyme de mes jeunes années…

J’ai donc proposé il y a très peu de temps un énorme ticket pour passer les fonctions Mu sous les nouvelles fonctions de la classe WPDB, pour des raisons de lisibilités et de performances. Le patch contient également la proposition de déplacer tous les hooks par défaut de WordPress Mu dans un fichier, comme le fait WordPress.

J’espère que tout le patch sera retenu… ça m’a pris deux bonnes heures cette histoire…

Passons maintenant à la suite de ma todo:

• Manage Sites : La possibilité de gérer les sites sous WordPress Mu
• Clean DB : Effacer la table inutile, et rétaper wp_sitecategories
• Manage Global Terms : Permettre l’édition, même basique de la table des globals terms.
• Hardcoded $table_prefix : Permettre l’utilisation d’autre chose que wp_ comme préfixe de table (inutile mais c’est pour la beauté du geste)
• Localize Installer : Avoir un installeur localisé :) pour me faciliter la vie lors des mises à jour !
• Split mu-functions : Séparer les fonctions mu-functions par thématiques…
• Localize Users : Offrir la possibilité à chaque utilisateur de lancer la traduction de son choix. Actuellement ce choix est fait au niveau de l’admin.
• Mu Plugins : Reproduire la page des plugins pour les mu-plugins…

Conclusion derrière ces noms de codes, rien d’extraordinaire… juste les fonctionnalités qui manquent à mon gout à WordPress Mu.

Avant de me lancer dans le développement de ces patchs, je vais probablement discuter avec Donncha, pour voir de son côté si tout ça peut être intégré… En fait la grande difficulté d’un projet comme WordPress Mu, c’est de délimiter les fonctionnalités qui doivent être inclus dans le core et celles qui doivent rester en tant que mu-plugins…

Si de votre coté, vous avez des idées de fonctionnalités manquantes, je suis preneur ;) (le premier qui me répond le domaine mapping, je l’envoi chiez, ca existe déjà en mu-plugins…)

• Page blanche sur le tableau de bord et la page apparence
• Page blanche lors de la publication d'un article et/ou d'un commentaire

Le problème intervient sur les installations WordPress Mu à haute fréquentation uniquement.

Cause possible ?

Créer un fichier info.php à la racine de votre blog, placez-y :

<?php phpinfo(); ?>

Enregistrez le fichier, consultez la page générée et partez à la recherche de l'extension eAccelerator pour PHP.

Si le module est présent; vous êtes simplement victime d'un bug avec les caches OPcode PHP et les fonctions de filtrage HTML Kses de WordPress. Cela provoque une erreur de segmentation PHP, et hop page blanche.

La solution ?

Désinstallez eAccelerator de votre serveur dédié. Installez à la place l'extension pour PHP, j'ai nommé Alternative PHP Cache (APC).

Et n'oubliez pas de filtrer le fichier kses.php de l'optimisation. Pour cela, ajoutez dans votre fichier de configuration de PHP la ligne suivante:

apc.filters = "(kses.php)"

Redémarrez votre serveur Web et hop problème résolu !

1. Comme plateforme de blog public (ex: Unblog.fr)
2. Comme plateforme pour les réseaux de blogs de gros bloggeurs ou collectifs.

Dans le cas numéro 2, bien qu’il soit possible de désactiver les inscriptions publiques, vos visiteurs pourront toujours tomber sur la page d’inscription. Typiquement lors d’une erreur dans l’URL !

Le visiteur aura alors droit à une superbe page d’inscription aussi inutile que moche.

Pour éviter cette page, il y a 2 alternatives:

1. Hacker le code de WordPress MU
2. Créer une petite extension pour WPmu afin de rediriger automatiquement l’utilisateur.

Je vais bien évidemment utiliser la méthode 2 qui a l’avantage de simplifier les mises à jour.

Pour cela, nous allons créer un petit fichier mu-redirect.php dans le dossier wp-content/mu-plugins/

Et nous allons y placer le code suivant:

<?php
add_action('signup_header', 'redirect_home');
function redirect_home() {
	global $current_site;
	wp_redirect( "http://{$current_site->domain}{$current_site->path}" );
	exit();
}
?>

Très simplement cette fonction va rediriger le visiteur vers la page d’accueil de votre plateforme. Vous pouvez également diriger vos visiteurs sur une adresse ou page spécifique… selon vos besoins !

Le code de cette extension est également disponible sous pastebin.

Bon blogging !

C’est quoi le WordCamp ?

Le WordCamp est un barcamp consacré à WordPress (logiciel libre de création et maintenance de blogs et sites dynamiques) ainsi que WordPress MU (version multi-blogs de WordPress), et est dédié à la communauté WordPress en France. C’est l’opportunité de se rencontrer, d’échanger, d’apprendre, dans le but de mieux maîtriser WordPress.

Ou et quand ?

Paris 2eme. La cantine

Le samedi 3 mai 2008 de 11h à 20h

Qui sera la ?

Plein de gens, la liste sur le wiki du barcamp. Il ne manque plus que vous :)

On y parle de quoi ?

De tout et de rien… J’animerai probablement 2 conférences.

1. Le couple WordPress/bbPress
2. Et probablement le tagging et WordPress avec Yann de WordPress-tuto 

Comment s’inscrire ?

Encore une fois, cela se passe sur la page du Wiki. (Xavier rappelle la méthode sur WP-FR)

Remerciements…

…aux différents sponsors:

• CREASENSO
• O2Sources
• Monetiweb

Nous sommes toujours à la recherche de sponsors, n’hésitez pas à nous contacter via la page de contact.

En effet, WordPress Mu comparé à WordPress c’est :

• 1 unique mainteneur
• 3-4 contributeurs réguliers
• Peu de propositions farfelues.

Au final, "tout le monde connait tout le monde", et le côté industriel présent dans le développement de WordPress est absent du trac de WPmu… et c’est tant mieux… Tout ça pour dire que je préfère contribuer à WordPress MU que WordPress…

Revenons à WordPress Mu 1.3…

Les nouveautés en plus du passage à WordPress 2.3 (et donc à ses fonctionnalités de Tags)

• L’interface d’administration des blogs et utilisateurs a été revue
  • Confirmation JavaScript (lors de la suppression d’un blog par exemple)
  • Code HTML valide
  • Mise en page améliorée
  • Alertes personnalisées, finit les "Options mises à jour " lors de la suppression d’un blog !
  • Page de confirmation habillée (fini la vieille page sans CSS)
  • Les titres ont été uniformisés
• Possibilité de désactiver l’inscription d’utilisateurs, de blogs ou les 2.
• Possibilité de désactiver l’API XML-RPC individuellement ou globalement
• Présence du quota du blog sur le tableau de bord
• Possibilité de désactiver la notification de création de blogs/utilisateurs pour l’administrateur (enfin !)
• Page d’inscription interdite aux robots, et non référencée
• Possibilité de choisir le blog principal depuis le profil utilisateur
• Les fonctions d’envoi de fichiers supportent correctement les quotas
• La base de données utilise désormais l’interclassement UTF8
• L’utilisation de nom de domaines dynamique ( monblog.blog.fr ) n’oblige plus le préfixe "blog/" pour le blog principal.
• Utilisation massive des boucles foreach a la place de while

Pour les développeurs, à noter que la variable "$wpmuBaseTablePrefix" a été dépréciée, il faut désormais utiliser "$wpdb->base_prefix". Ce qui est bien plus cohérent d’un point de vue développement.

Bref, WPmu 1.3 apporte de réels changements sur la console d’administration. WordPress Mu 1.3 est un logiciel mieux fini, il est désormais utilisable sans modifications chez vos clients…

Note: Pourquoi un peu de moi dans WPmu ? Car la refonte de la console d’administration est ma réalisation ;)

Note 1: WordPress Mu 1.3 est sortie il y a 3 semaines je sais… mais comme on dit chez moi, mieux vaut tard que jamais…

Note 2: La version 1.3.1 de WordPress Mu devra sortir, mi-décembre, elle corrigera, bon nombre de bugs…

Quelques liens en passant:

• Annonce de Donncha de la sortie de WPmu 1.3 (EN)
• Site officiel de WordPress Mu (EN)
• Version française de WordPress Mu (FR)
• Trac de développement (EN)

WordPress 2.3 est une véritable révolution pour la gestion de tags. Fini les 12 plugins différents, nous voilà tous au même point.

Sauf que WordPress 2.3 embarque très peu de fonctionnalités, chose voulue par les développeurs, pour faire travailler un peu la communauté.

Chose qui a marché, vu que j’ai la satisfaction de vous annoncer la sortie de Simple Tags. Le plugin est déjà en version 1.0.1.

Il supporte un grand nombre de fonctionnalités dont:

• Autocomplétion pour les champs de tags
• Suggestion automatique de tags
• Gestion de tags (renommer, effacer, fusionner, rechercher et ajouter des tags, édition de l’identifiant des tags)
• Liste des contenus non taggés
• Édition massive de tags
• Possibilité de tagger les pages et de les inclure dans les résultats des tags
• Articles relatifs générés à partir des tags qu’ils ont en communs
• Possibilité d’ajouter les articles relatifs dans le flux RSS
• Génération de nuages de tags colorés dynamiquement et de leurs Widgets (jusqu’à 10 !)
• Génération de mots clés dans l’entête de votre blog
• Tags embarqués ([tags]tag1, tag2[/tags] pour une rétro compatibilité)

Vous trouverez plus d’informations et des captures d’écran sur la page du plugin Simple Tags en Français. Le téléchargement y a également lieu en attendant d’être accepté sur wordpress.org/extend/plugins !

Merci de me signaler tous problèmes rencontrés, ainsi que vos suggestions ! (sur la page de plugin de préférence)

• Ajout du plugin Bunny’s Technorati Tags au processus de nettoyage
• Possibilité de sélectionner les plugins à nettoyer, de manière sélective.

Cette dernière fonctionnalité inclut désormais la possibilité d’utiliser ce plugin, après une migration de UTW à Simple Tagging par exemple.

On est plus forcément dans le cas de la version 2.3 de WordPress.

L’intérêt de ce plugin ?

• Optimiser les performances de WP
• Gagner de l’espace disque en base de données

Plus d’informations et téléchargements sur la page du plugin Clean Old Tags.

Et pour l’occasion, on a décidé d’empêcher le peuple de hot-linker directement les images et autres médias de son site.

Objectif annoncé: réduire la charge processeur…

Extrait du Vhost en question:

$HTTP["host"] =~ "(^|\.)le-hiboo\.com$" {
	$HTTP["referer"] !~ "^($|http://www\.le-hiboo\.com)" {
		$HTTP["url"] =~ "^/wp-content/" {
			url.redirect = ( "^/(.*)" => "http://88.191.20.61/leech.jpg" )
		}
		url.access-deny = ( ".jpg", ".jpeg", ".png", ".mp3", ".flv" )
	}
}

• 1re ligne, on travaille uniquement pour le domaine le-hiboo.com
• 2e ligne, on teste le référant, si ça n’est pas le-hiboo.com on valide la condition et il se présente 2 choix:
  • 3e ligne, si l’adresse contient « /wp-content/ », on entre dans la 2ème condition
    • 4e ligne, si la 2e condition est validée, on redirige la requête vers une image précise. (créé pour l’occasion)
  • 6e ligne, l’adresse ne contient pas « /wp-content/ », il peut s’agir du flux RSS…
    • Donc on ne bloque que les fichiers JPG, PNG, MP3 et FLV

Pas si effrayant non ?

(en fait on fait un puzzle géant sur internet :D)

Pour faire différent, je me base sur la même source que lui, soit l’excellent article de Aaron Brazell sur les 10 nouveautés de WP 2.3 :).

Tout le monde suit ? Ou plutôt s’accroche ?

On est parti…

La fonction $wpdb->prepare()

En fait, c’est une fausse nouveauté… Les développeurs ont juste réalisé une première implémentation à la va-vite d’une méthode vous permettant de sécuriser vos requêtes contre les injections SQL.

Concrètement il s’agit d’une bonne habitude à prendre pour l’avenir dans le développement de plugins et d’extensions pour thèmes.

Donc à l’utilisation, ça donne ceci:

function getData() {
    global $wpdb;
    $query = "SELECT ID FROM $wpdb->posts";
    $query = $wpdb->prepare( $query );
    $results = $wpdb->get_results( $query );
}

Rien de bien compliqué :)

Et comme on dit chez moi (et chez vous surement), à utiliser et abuser :)

Atomlib

Un ajout tardif dans le développement dans WordPress 2.3.

Atomlib est une librairie en PHP facilitant l’utilisation et l’exploitation de fil Atom. (un format concurrent au RSS).

Concrètement il ajoute à WordPress, un ensemble de fonction, exploitable par les plugins et différents thèmes, pour la production de fil Atom ou tout simplement la syndication.

Pas d’exemple sous la main. Ça sera l’objet d’un article :)

Deprecated Functions

Au programme des fonctions dépréciées (donc à ne plus utiliser), nous avons:

• permalink_link() à remplacer par the_permalink()
• permalink_single_rss() à remplacer par the_permalink_rss()

Bien entendu ces fonctions restent utilisables, mais aucune garantie n’est prévue lors des prochaines mises à jour de WordPress.

Pluggable RSS Library

Enfin… Cela fait des mois que l’on demande à virer la « dépassée » librairie de syndication RSS « Magpie » et WordPress 2.3 apporte enfin des choses à ce niveau.

Non on ne quitte pas encore « Magpie », mais cette librairie devient « pluggable » ou enfichable :)

Cela veut dire que demain, on pourra très facilement la remplacer par SimplePie grâce à un petit plugin, et générer enfin des flux RSS sans se soucier de l’encodage de ces derniers :)

Sans oublier les features de cache, de multi URL, etc.

Pour finir…

Le dernier point technique que notre ami Aaron ne cite pas, s’agit du nouveau schéma de base de donnée pour la taxinomie.

Mais j’ai expliqué ce dernier point sur un article de WordPress Francophone.

Voilà, si vous n’avez rien compris à tout cela, lisez l’article de Fran6, sinon posez vos éventuelles questions ;)

De son aveu même, la méthodologie n’est pas parfaite, mais elle donne toute de même une bonne idée :)

J’ai pris le soin d’encadré en orange, les contributeurs francophones, j’ai peut être oublier quelqu’un, mais vu que je ne connais pas tous les pseudo ;)

Donc dans l’ordre: Denis de Bernady, Ozh, z720 et momo360modena (moi-même)

C’est peu n’est-ce pas ?

Lassé de mon ancien thème (original, mais peu lisible), j’ai décidé mercredi de créer un nouveau thème.

Je procède alors à quelques essais avec le framework CSS « blueprint » que mon collègue Nicolas Merouze m’a gentiment fait découvrir la semaine dernière.

Au début, j’ai été étonné par la rapidité à créer un squelette graphique.

Malheureusement l’inconvénient d’un tel framework, est que vous ne construisez plus le code HTML de votre site, de façon sémantique, mais vous essayez de bidouiller avec les différentes classes que le framework propose pour obtenir le résultat visuel escompté.

Au final, cela vous enferme dans les templates à la hemingway & co et c’est un vrai frein à votre créativité.

Bref, je ne suis pas du tout convaincu. (peut être que je changerai d’avis selon l’évolution du projet)

Il y’a tout de même de bonnes choses dans ce framework, telles que la notion de rythme vertical (même si utopique en pratique), le reset des CSS, et d’autres petites astuces.

Conclusion ! J’ai emprunté quelques lignes à blueprint et j’ai créé ma propre CSS :)

Pour ce nouveau thème, j’ai choisi la simplicité.

Une seule sidebar, utilisation exclusive des tags (pas de redondance avec les catégories), pas de pub, pas de bouton à la sauce Web 2.0, pas d’archives mensuelles…

Uniquement l’essentiel !

Merci à Rod pour le (gros) coup de main. (choisir les couleurs c’est plus compliqué qu’on pourrait l’imaginer)

Un zeste de folie !

Lorsque j’ai commencé à intégrer mon nouveau thème, j’ai commencé à le faire en version 2.2 de WordPress.

Et puis au bout de 2 minutes, je me suis dit que c’était débile de créer un thème pour WP 2.2 alors que la version 2.3, bien qu’en version béta (danger! danger! ne pas installer sans connaissance technique), sort dans moins d’un mois…

Conclusion, me voilà migré sur la dernière version de développement de WordPress 2.3, et c’est que du bonheur :)

Rien de nouveau ou presque pour vous humains ! (vous c’est la version 2.4 qui vous donnera envie) mais pour les développeurs c’est que du bonheur :)

La gestion de la taxinomie est… parfaite ! On peut imaginer tout plein de choses avec !! (hein Rod ?)

Bref du bonheur en boite :D

Pour cela, nous allons comparer le plugin "Seo Http error manager" au plugin "Http Error Codes Manager" que j'ai codéveloppé avec Thomas pour l'occasion.

Cela nous permettra de bien voir les choses, qu'il faut faire, qu'il ne faut pas faire, et nous donnera un bon contraste.

Précision: Lorsque je parle de l'API, il s'agit de la section développeur du Codex, et du PHPxRef.

Quand je parle du bon plugin, il s'agit de "Http Error Codes Manager", tandis que le mauvais plugin est "Seo Http error manager".

1. Évitez les variables globales, préférez-les constantes

Nous ne sommes pas ici pour débattre sur l'utilisation et la présence des variables globales dans le langage PHP, mais autant que possible, s'il est possible de s'en passer, faites-le !

Par exemple:

// ---------------------------------------------
// Constantes
// ---------------------------------------------
$TAGERROR        = "code_errorcode_worpress_seo"; // ne pas editer
$TAGURL            = "url_errorcode_worpress_seo"; // ne pas editer
$DEFAULTURL    = "http://www.wordpress-seo.com/redirection-par-defaut.php"; // editable a vos risques et peril

C'est typiquement une mauvaise utilisation des variables globales. Si vous souhaitez définir une constante, utilisez la fonction "define()" tout simplement...

Il n'y a pas de comparaison avec le bon plugin pour ce point, car l'utilisation de variables globales ou constantes est simplement inutile.

2. Consultez l'API avant d'écrire des requêtes SQL

L'API de WordPress est plus vaste qu'on peut l'imaginer. Consultez-la toujours avant d'écrire une requête SQL.

2.1 Dans le premier cas, nous souhaitons récupérer une valeur méta d'un article:

Voilà la mauvaise méthode:

function wordpress_seo_http_error_code_manager_GetPostMeta_FromKeyAndPostId($TagKey,$Id,$Max=1)
{
    // Les global issues de wordpress
    global $wpdb,$table_prefix;
    //
    // On force le debug
    $Print_debug=0;
    $ArrMsgAll=array();
    $ArrMsgCount=0;
    // ———————————-
    // On isole la liste
    $SQL="SELECT meta_id,meta_value FROM `".$table_prefix."postmeta` where meta_key='".$TagKey."' AND post_id='".$Id."' limit ".$Max." " ;
    $search_counter = 0;
    $A_meta = $wpdb->get_results($SQL);
    if($A_meta){return $A_meta[0]->meta_value;}
    else{if($Print_debug==1){echo "
DEBUG : 
No results.

";}}
    return ""; // vide !
}

Cette fonction est inutile. Il existe déjà une fonction dans l'API de WordPress:

get_post_meta( $post_id, $meta_name, $single );

Nous venons d'économiser 18 lignes et 10 minutes. Et nous profitons par la même occasion de toute la sécurité et l'expérience des développeurs de WordPress avec une pérennité garantie bien entendu.

2.2 Deuxième cas, nous décidons d'insérer ou de mettre à jour la valeur méta d'un article

Voilà la mauvaise méthode:

function wordpress_seo_http_error_code_manager_SetUserMeta($TagKey="error",$NewVal,$Id=0)
{
    // Les global issues de wordpress
    global $wpdb,$table_prefix;
    //
    // On force le debug
    $Print_debug=0;
    $SQL="DELETE FROM `".$table_prefix."postmeta` where meta_key='".$TagKey."' AND post_id='".$Id."' " ;
    $wpdb->get_results($SQL);
    $SQL="INSERT INTO `".$table_prefix."postmeta` set meta_key='".$TagKey."', meta_value='".addslashes($NewVal)."' , post_id='".$Id."' " ;
    if($Print_debug==1){echo "DEBUG : 
$SQL
";}
    $wpdb->get_results($SQL);
}

Encore une fois, cette fonction est inutile. Il suffit d'utiliser 2 fonctions de l'API WordPress:

delete_post_meta( $post_id, $key); // Supprimer une méta de la base de données
add_post_meta( $post_id, $key, $value); // Ajouter une méta à la base de données

Ces 2 exemples sont très parlants...

Les intérêts sautent aux yeux: Gain de temps, pérénnité, sécurité et lisibilité du code

3. N'utilisez plus la variable dépréciée "$table_prefix"

Depuis WordPress 2.1, la variable globale "$table_prefix" est dépréciée.

Cela ne veut pas dire qu'elle ne fonctionne plus, mais pour garantir la compatibilité WordPress Mu et des prochaines versions de WordPress, vous ne devez plus l'utiliser.

A la place, il faut utiliser "$wpdb->prefix".

PS: N'oubliez de rappeler la variable globale "$wpdb" au début de la fonction.

Exemple:

function test() {
    global $wpdb;
    $prefixdeWP = $wpdb->prefix;
}

4. Evitez les noms de variables et de fonctions à rallonges et utiliser les classes (même pour PHP4)

S'il vous plait... évitez les noms de fonctions et de variables à rallonges...

1. c'est illisible
2. ça augmente sensiblement la consommation mémoire de PHP

Exemple de nom de fonction trop long:

wordpress_seo_http_error_code_manager_GetPostMeta_FromKeyAndPostId()
wordpress_seo_http_error_code_manager_SetUserMeta()

Priviligiez l'utilisation des classes !

Même si l'implémentation des classes dans PHP4 est limitée, elles sont tout à fait utilisables et possèdent un grand avantage:

Seul le nom de la classe doit être unique !

Les fonctions contenues dans la classe peuvent avoir le nom que l'on souhaite sans problème de doublons. De quoi mettre des noms courts et concis.

Exemple:

Class HttpErrorCodesManager {
    // Displays two fields for 1. the error code and 2. the url to redirect the visitor to
    function printFields() {
    ...
    }
    function redirect() {
    ...
    }
}

Je n'ai plus besoin de savoir si une fonction "redirect()" existe déjà dans WordPress ou un autre plugin vu qu'elle est située dans ma classe.

Simple, mais efficace.

5. Développez vos plugins en anglais et internationalisés !

Oui, je sais la France est un beau pays, mais la France c'est petit... tout-petit... ne vous limitez pas aux utilisateurs francophones de WordPress !

Développez vos plugins en anglais...

Plusieurs raisons à cela, il existe plus de personnes lisant l'anglais que le français... très pratique pour la traduction de votre plugin dans plusieurs langues et aussi pour la lisibilité de votre code. Un développeur étranger sera plus à même de vous aider dans un code anglais, qu'un code français...

Conclusion, évitez d'entrer du texte en dur :

 
Plugin Seo, WordPress-seo.com : Imposer un code d'erreur.
Nous vous remercions de ne pas cree d'erreur 302 vers http://www.wordpress-seo.com
 
Action :  >Ne rien faire >301 ( redirection permanante ) >302 ( redirection temporaire ) >404 ( n'existe plus ) 
URL (301 ou 302 ):  
 

Mais écrivez en anglais et internationalisez vos textes:

echo '
',"\n",
'
' .__("Force a code error for this post", 'hecm'). '
',"\n", ' 
' .__('Actions', 'hecm'). ' ',"\n", ' ',"\n", ' ' .__('Do nothing', 'hecm'). '',"\n", ' ' .__('301 (permanent redirection)', 'hecm'). '',"\n", ' ' .__('302 (temporary redirection)', 'hecm'). '',"\n", ' ' .__('404 (not found)', 'hecm'). '',"\n", '',"\n", ' 
',"\n", ' 
' .__('URL (301 or 302 ):', 'hecm'). ' 
',"\n", '
',"\n";

Je ne fais pas de rappel sur les fonctions d'internationalisation, vu que j'ai écrit un article dessus, il y a peu de temps.

6. Utilisez correctement les Hooks de WordPress

Il existe 2 types de Hook dans WordPress, les actions et les filtres. (voir codex)

Ils sont listés sur le codex, on peut également les retrouver à l'adresse suivante: http://wphooks.flatearth.org/

Dans le cas présent, nous allons utiliser l'action présente lors de la publication d'un article. Il s'agit de "publish_post" et comme on peut le voir dans le codex, cette action prend en paramètre l'ID de l'article.

Point que le mauvais plugin n'a pas pris en compte:

function wordpress_seo_http_error_code_manager_save()  {
     global $TAGERROR,$TAGURL,$DEFAULTURL;
     wordpress_seo_http_error_code_manager_SetUserMeta($TAGERROR,$_POST['wordpressseoerrorcode_err'],$_POST['ID']);
     wordpress_seo_http_error_code_manager_SetUserMeta($TAGURL,$_POST['wordpressseoerrorcode_url'],$_POST['ID']);
}

Car il récupère l'ID de l'article depuis l'information $_POST['id'] sans aucun contrôle, ce qui peut poser des problèmes de sécurité.

La bonne méthode est la suivante:

function saveFields($post_id) {
    if( isset($_POST['redirect_code']) || isset($_POST['redirect_url']) ) {
        delete_post_meta($post_id, 'redirect_url');
        delete_post_meta($post_id, 'redirect_code');
        add_post_meta($post_id, 'redirect_code', (int) $_POST['redirect_code']);
        add_post_meta($post_id, 'redirect_url', clean_url($_POST['redirect_url']));
    }
    return;
}

Nous passons en paramètre l'ID de l'article, et comme nous savons que cette valeur provient de WordPress, elle est sécurisée et valide.

7. Faites le moins de requêtes

Un point bien souvent négligé dans les plugins WordPress est le nombre de requêtes effectuées...

Il faut bien comprendre que le nombre de requêtes influe directement sur les performances de votre blog, moins il y en a, plus l'affichage est rapide (sauf exception)

Exemple d'une mauvaise gestion des requêtes:

$Tag_url=$DEFAULTURL;
$Tag_error=wordpress_seo_http_error_code_manager_GetPostMeta_FromKeyAndPostId($TAGERROR,$wp_query->post->ID);
$Tag_urlt=wordpress_seo_http_error_code_manager_GetPostMeta_FromKeyAndPostId($TAGURL,$wp_query->post->ID);
if(strlen($Tag_urlt)>0) {$Tag_url=$Tag_urlt;}
switch($Tag_error)
{
    case 3:
    header("HTTP/1.1 404 Not Found");
    die("404 File not found!");
    exit();
    break;
    case 2:
    header("HTTP/1.1 302 Found", false, 302);
    header("Location: ".$Tag_url."");
    exit();
    break;
    case 1:
    header('HTTP/1.1 301 Moved Permanently', false, 301);
    header('Location: '.$Tag_url.'');
    exit();
    break;
    case 0: default:     break;
}

On voit que le plugin effectue toujours 2 requêtes. (ligne 2 et 3)

Or dans le cas numéro 3, on s'aperçoit que le résultat de la deuxième requête n'est pas utilisé. Voilà une requête de trop...

Voilà la même fonction revue et corrigée:

$code = (int) get_post_meta($wp_query->post->ID, 'redirect_code', true);
if ( $code === 3 ) {
    header('HTTP/1.1 404 Not Found');
    die(__('404 File not found!', 'hecm'));
} elseif ( $code === 2 || $code === 3 ) {
    $url = get_post_meta($wp_query->post->ID, 'redirect_url',  true);
    if ( $code === 2  && !empty(trim($url)) ) {
        wp_redirect($url, 302);
    }
    if ( $code === 3  && !empty(trim($url)) ) {
        wp_redirect($url, 301);
    }
}

La deuxième requête est effectuée uniquement au besoin et non systématiquement.

Voilà une utilisation intelligente et économique des requêtes.

8. Sécurisez votre plugin avec l'API WordPress

Le plugin ne se prête pas vraiment au jeu de la sécurisation des plugins mais sachez qu'il existe un excellent tutoriel en anglais sur la sécurisation des plugins WordPress.

On peut tout de même aborder 2 points.

1. Utiliser les fonctions de l'API vous évite de faire un effort sur la sécurité

2. "castez" vos données au maximum.

Par exemple, si le résultat attendu est un nombre entier, utiliser (int) comme dans l'exemple ci-dessous:

$code = (int) get_post_meta($wp_query->post->ID, 'redirect_code', true);

Si la donnée n'est pas un entier, mais une chaine de caractère ou autres, elle deviendra le chiffre 0.

9. Ne négligez pas la qualité du code HTML !

Oui je sais... c'est plus rapide d'écrire "<br>" que "<br />" mais peu importe... prenez le pari de respecter les normes du W3C et d'assurer à votre plugin une parfaite compatibilité avec tous les navigateurs existants.

Code HTML à bannir:

URL (301 ou 302 ): 

Version conforme au W3C:

URL (301 ou 302 ): 

Ca n'est pas si compliqué ;)

10. L'API de WordPress : Encore et toujours...

l'API de WordPress contient un grand nombre de fonctions très utiles, par exemple, la redirection en PHP.

Selon l'environnement serveur où l'on travaille, l'utilisation de la fonction headers() peut-être différente.

Ne vous compliquez pas la vie !!

La fonction "wp_redirect( $url, $code_http )" gère tout cela de façon transparente pour vous.

Exemple du mauvais plugin:

header("HTTP/1.1 302 Found", false, 302);
header("Location: ".$Tag_url."");

2 lignes et compatibilité plus que douteuse.

La même chose avec l'API WordPress:

wp_redirect($url, 302);

Autre exemple, nous souhaitons enregistrer une adresse internet dans la base de données.

Problématique : Comment savoir que le texte entré correspond bien à une adresse internet ?

On pourrait imaginer une fonction avec des pregs et diverses astuces...

Encore une fois, allez au plus simple...

WordPress possède une fonction "clean_url( $url )" qui s'assure que le texte entré correspond bien à une adresse internet.

11. Ne cherchez pas à profiter des erreurs de vos utilisateurs

Comme on peut le voir dans le mauvais plugin, si un utilisateur oublie de rentrer une adresse internet alors qu'il a sélectionné une redirection, ce dernier est automatiquement renvoyé à l'adresse suivante:

$DEFAULTURL = "http://www.wordpress-seo.com/redirection-par-defaut.php"; // editable a vos risques et peril

Honnêtement, dans une telle situation à part vouloir augmenter son nombre de visiteurs, quel est l'intérêt d'une telle redirection ?

Pourquoi ne pas simplement annuler la redirection si l'utilisateur oublie d'entrer une adresse internet ?

Il y a vraiment des développeurs peu scrupuleux...

Conclusion

Vous pouvez retrouver les 2 plugins au format PHPs içi:

• Seo Http error manager (le mauvais plugin)
• Http Error Codes Manager (le bon plugin, sécurisé, performant et bien développé)

À noter que développer un plugin correctement correspond à environ 50% de lignes de code en moins, ce qui n'est pas négligeable.

Vos réactions sont comme toujours, les bienvenues...

Je vais commencer par le début, présenter le logiciel WordPress MU…

C’est quoi WordPress Mu ?

WordPress Mu est la version multiblogs de WordPress.

On peut considérer WordPress Mu comme une enveloppe à WordPress, car les 2 logiciels sont très proches. Les différences portent sur quelques fichiers. (95% du code est le même)

WordPress Mu permet donc de créer des blogs WordPress à la volée.

Pourquoi « WordPress Mu » ?

Bonne question !

J’ai donc cherché sur internet une signification ou explication possible à ce choix.

Et bah j’ai pas trouver grand-chose jusqu’à un certain PDF (page 8 ou 9 de google)

Ou l’on peut lire:

μ : douzième lettre de l’alphabet grec utilisée pour noter le préfixe micro

Mue (en français) : mutation, changement de voix, de peau

Mü (en hongrois) : oeuvre, synthétique, artificielle

Mu (en japonais) : infini

Mu (en chinois) : arbre

Je ne vois pas trop le rapport entre le préfixe micro et WordPress. (Rod me corrigera)

Les versions françaises, hongroises et chinoises ne sont pas non plus très cohérentes, tandis que la version japonaise, « infini » parait plus cohérente avec la philosophie du logiciel :)

« Avec WordPress Mu on peut créer des blogs à l’infini ! »

Si vous avez d’autres d’idées, n’hésitez pas à les partager !

Historique de WordPress Mu

La version 1.0 de WPmu a été publiée en octobre 2006.

La série 1.1.x est apparue en janvier 2007. Ce fut la première version vraiment exploitable et stable.

Tandis que la série 1.2.x est apparue en mars, cette série est désormais calée sur les fonctionnalités de la série WordPress 2.2.

La version 1.3 devrait donc sortir peu après WordPress 2.3, soit début novembre !

Bien qu’en perte de vitesse comparée au flux RSS et autres accessoires Web 2.0, il m’a semblé utile de développer un plugin de newsletter simple et efficace pour WordPress.

Pour le moment, le plugin ne regorge pas de fonctionnalités, il permet juste l’inscription d’email (avec une gestion d’erreur complète et email de confirmation), le listing des inscrits et l’export CSV.

Autrement dit, le minimum.

Il est bien entendu développé à la Simple Tagging, c’est à dire léger, performant, internationalisé et sécurisé !

Il va évoluer progressivement, dont les fonctionnalités, pagination coté admin, différents types d’exportation, envoi d’un courrier depuis la console d’admin, filtrage des destinataires par rôle WP, envoi hebdomadaire des derniers articles, templates pour les emails, etc.

Faites vos suggestions !

Vous trouverez le trac de développement ici: http://trac.herewithme.fr/project/simple-newsletter/

Le plugin est compatible WordPress 2.1, 2.2 et WordPress MU 1.2.x

Il n’a pas été testé sous WordPress 2.0.x, mais il devrait fonctionner avec les dernières versions de cette branche.

Le téléchargement se passe là : http://trac.herewithme.fr/project/simple-newsletter/wiki/Download

N’hésitez pas à faire des retours ! (suggestions, critiques, etc.)

Malheureusement lorsque vous souhaitez ajouter votre blog à Windows Live Writer, ce dernier affiche une erreur 403 ?

Voici la solution !

La source du problème s’agit de Bad Behavior… Ce dernier travaille fortement en amont de WordPress, et considère malheureusement WLW comme un « bot malicieux » et par conséquent le bloque.

Pour résoudre ce problème, il va nous falloir éditer un fichier du plugin « Bad Behavior ».

Méthode:

Éditer le fichier « msie.php » du dossier « bad-behavior » présent dans le répertoire des plugin WordPress.

Et remplacer: (ligne 7)

if (!array_key_exists('Accept', $package['headers_mixed'])) {
    return "17566707";
}

Par

if (strpos($package['headers_mixed']['User-Agent'], "Windows Live Writer")
    === FALSE && !array_key_exists('Accept', $package['headers_mixed'])) {
    return "17566707";
}

Sauvergarder les modifications.

Vous pouvez dès à présent utiliser Windows Live Writer ! 

Source: http://www.jamesmckay.net/2007/06/bad-behavior-does-not-like-windows-live-writer