Le premier, c’est qu’il ne se trouve pas dans le référentiel officiel des plugins, ce qui rend handicapantes les mises à jour et son installation. Son deuxième défaut, c’est les problèmes liés au déplacement d’un blog.

Dans de nombreux cas, on développe un blog WordPress avec une adresse de développement et lorsqu’on souhaite migrer, tout se passe bien sauf pour le plugin Cforms, pour 3 raisons :

1. Il enregistre le chemin complet vers le plugin dans un fichier PHP
2. Il enregistre l’adresse du blog dans un fichier JavaScript
3. Il enregistre l’adresse du blog et de destination des fichiers dans une option de WordPress.

L’inconvénient est que lorsqu’on change d’adresse du blog, Cforms conserve les réglages du blog où il a été installé, chose très gênante, car cela implique la modification des 2 fichiers et un bidouillage dans la base de données pour corriger le plugin.

Pour me simplifier la vie, j’ai développé un petit plugin qui permet l’édition depuis la console d’administration de ces différentes informations. Le plugin se présente de la façon suivant :

Le plugin est disponible sur le référentiel de WordPress.org et répond au doux nom de « Advanced Edit Cforms » (j’essaie d’être explicite !)

Articles relatifs

• WordPressMu : Copie à revoir… (9)
• Vous avez dit "Blog au ralenti ?" (4)
• Sortie de Simple Tagging 1.6.8 ! (5)
• Simple Tags : Gérez vos tags… différemment… (2)
• Simple Tagging 1.6.2 ! (4)

Cette nouvelle version est pleinement compatible avec WordPress 2.8 et 2.9. Elle n’est pas contre plus du tout compatible avec les versions antérieures, pour 2 raisons, alléger l’extension et ne pas faire semblant d’avoir des évolutions pour les anciennes versions de WordPress alors qu’en fait le code utilisé par les anciennes versions n’était plus mis à jour !

Cette version apporte quelques nouveautés dont :

• Compatibilité à 100% avec l’API taxonomie de WP2.8/2.9
• Utilisation de la nouvelle API des Widgets
• Amélioration du code en vue d’avoir 0 notice PHP (à 99%)
• Correction sur les méthodes de cache WordPress
• Correction avec le bug de la fausse activation. (rien ne se passer)
• Compatibilité à 100% avec PHP4
• Ajout d’un sélecteur de taxonomie pour l’édition de masse (permets de catégoriser massivement)
• Réaménagement de la page « Gestion des tags »
• Nouveau script pour l’auto-complétion, utilisation de l’AJAX pour de meilleures performances
• Correction d’un bug avec les articles très longs et la suggestion de tags de Yahoo/Tag The Net
• Ajout de 3 connecteurs pour la suggestion : OpenCalais, Alchemy et Zemanta
• Correction de l’importateur fourni avec l’extension
• Externalisation du tableau d’options de l’admin pour diminuer la consommation mémoire

Certains d’entre vous ont remarqué que j’avais fermé le projet Google Code, c’est assez simple. L’outil est, je trouve, très mal foutu pour le chef du projet. Les visiteurs peuvent commenter toutes les pages, et les demandes de supports et retours arrivent de partout à la fois.

De plus, la gestion de tickets est difficile à gérer pour une seule personne, un trac est beaucoup plus lisible à ce niveau.

De ce fait, j’ai déplacé le support sur une installation redmine que j’utilise désormais pour publier mes extensions et mini-extensions pour WordPress.

Enfin, beaucoup de personnes m’ont attesté que la version 1.6.x de Simple Tags fonctionnait bien avec WordPress 2.8, et bien il se trouve que non. Elle fonctionnait à peu près, sur certaines installations déjà en place, rien d’apparent. Mais sur une installation from scratch, il y avait de nombreux problèmes, l’ajout des tags sur les pages ne fonctionnait pas par exemple, etc.

Articles relatifs

• [Tuto] Migrer de Ultimate Tag Warrior vers Simple Tagging ! (30)
• [MAJ] 2ème rencontre WordPress Francophone ! (4)
• WordPressMu : Copie à revoir… (9)
• WordPress, Memcached et PECL Memcache : La solution pour les blogs a gros trafic ! (6)
• WordPress Mu : Astuce pour ne pas proposer la page inscription aux visiteurs (2)

Malheureusement, WordPress ne permet pas la désactivation des fonctionnalités non utilisées, c’est regrettable à plusieurs points. Le premier, c’est les performances, charger en mémoire des lignes de code non utilisé peut s’apparenter à un gâchis de ressources. Le deuxième point, c’est la présence de menus inutiles dans la console d’administration. Cet aspect peut être corrigé via des plugins permettant  la personnalisation la console d’administration, ces derniers proposent de choisir précisément les fonctionnalités que l’on souhaite afficher ou masquer.

Mais revenons à drupal…

Lorsque je discute avec des clients, des développeurs, on me dit, WordPress ce n’est pas vraiment un CMS, Drupal oui !

C’est vrai et faux, en fait techniquement parlant, ces 2 outils sont des CMS. WordPress est un CMS orienté gestion de contenu personnelle (plutôt blog), tandis que Drupal est un CMS « non orienté ». Autrement dit, Drupal est extrêmement générique et on le ressent bien à l’installation. (Comme l’on dit plusieurs blogueurs de la communauté WP, WordPress est beaucoup plus packagé que Drupal, plus « ready to use »).

Cette orientation, publication personnelle/blog, est donc à la fois la plus grande force et faiblesse de WordPress.

Force, car cela lui attire la sympathie d’un très grand nombre de webmestres, développeurs et surtout des utilisateurs. Faiblesse, car comme beaucoup d’outils de masse, on le considère à tort comme un outil d’entrée de gamme peu adapté au monde professionnel et à un usage CMS. Et pourtant…

J’ai installé un drupal en local, et j’ai comparé les modules par défaut de drupal avec ceux de WordPress. Vous trouverez dans un premier le tableau comparatif, puis mon analyse.

Comme vous pouvez le constater, mis à part 1-2 fonctionnalités mineures qui n’ont pas d’alternative complète sous WordPress, la totalité des fonctionnalités des modules intégrés dans Drupal possède une alternative ou plusieurs alternatives. Parfois nativement, parfois sous la forme de plugins de la communauté !

Lorsque la fonctionnalité est native, elle possède le même niveau de qualité que sa concurrente drupal. Lorsqu’il s’agit d’un plugin, c’est variable. Certains plugins de la communauté sont bien plus évolués que leurs concurrents par défaut de drupal (mais des plugins drupal peuvent équilibrer la balance), tandis que dans certains cas, c’est l’inverse.

Je conclurai en 3 points.

1. WordPress n’a rien à envier aux modules de base de Drupal. La communauté très active remplit parfaitement son rôle en réalisant des plugins de qualité similaire.

2. Le programme de plugins « officiel » de WordPress.org va permettre de constituer une base de plugins sûrs, vérifiés et mis à jour régulièrement. Ces plugins deviendront l’équivalent des modules de drupal.

3. Drupal possède une longueur d’avance concernant la possibilité de créer nativement des types de contenus à la volée. (je ne parle pas de CCK, mais des types de contenus), WordPress supporte depuis très longtemps ce genre d’ajout via des plugins, mais rien de  très propre. La version 3.0 ajoutera une API complète permettant d’ajouter autant de types de contenu que souhaité.

Dans un prochain article, je vous parlerai de Views/CCK et WordPress !

PS: J’ai sûrement oublié certaines fonctionnalités, je pense par exemple aux permissions, je me suis contenté des modules de base pour le moment, mais si vous voyez des fonctionnalités de bases qui n’existe pas dans WordPress, dites-le-moi, j’essaierai de trouver l’alternative si elle existe !

Articles relatifs

• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Utilisation originale de WordPress comme CMS : une documentation ! (8)

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 !

Articles relatifs

• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Un peu de moi dans WordPress Mu 1.3 ! (3)
• Sortie de Simple Tagging 1.6.8 ! (5)
• Simple Tags : Gérez vos tags… différemment… (2)

À force de le dire, on me reproche de vendre mon produit, mais avouer quand même que WordPress peut être utilisé dans un nombre incalculable de situations… En fait, je ne vois qu’une situation courante où WordPress ne convient pas… l’e-commerce… Et ça n’est pas les extensions existantes qui me feront mentir… rien ne vaut à mon goût un couplage avec un outil dédié… comme Magento par exemple !

Mais revenons au sujet principal de cet article, jQuery, dont une partie des sites est développée en drupal, vient de mettre à jour sa documentation pour la sortie future de la version 1.4 !

Et pour faire la mise à jour de la documentation, l’équipe de jQuery a migré de l’outil MediaWiki vers WordPress en utilisant l’aspect CMS…

Ainsi, elle profite :

• D’un référencement naturel de premier ordre
• La possibilité d’avoir des contributions pour chaque page via les commentaires et akismet pour contrer le spam
• Une rapidité d’affichage grâce à l’usage de WP-SuperCache
• Une classification libre via les catégories et les mots clefs.

Comme d’habitude avec l’équipe jQuery, le résultat est très soigné, en particulier le moteur de recherche avec l’effet AJAX qui actualise en temps réel les résultats de la recherche !

Peut-être les prémices d’une migration entière des sites jQuery vers WordPress… L’avenir nous le dira !

Source : Dougal Campbell’s geek ramblings & jQuery14.com

Articles relatifs

• WordPress va apprécier Firefox 3.1… (Safari 4 aussi !) (2)
• Drupal vs WordPress : Les modules de base (19)
• [WordPress Mu] Présentation (20)
• [Tuto] Migrer de Ultimate Tag Warrior vers Simple Tagging ! (30)
• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)

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 !

Articles relatifs

• [WordPress Mu] Présentation (20)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• WordPress Mu à haute fréquentation ? Problèmes de pages blanches ? (7)
• WordPress Mu : Astuce pour ne pas proposer la page inscription aux visiteurs (2)

Ici, je vais vous montrer avec 2 bouts de code, comment on peut générer automatiquement une barre de sidebar pour chaque page de votre blog/site sous WordPress, sans oublier une sidebar par défaut pour le reste du blog et les pages n'ayant aucun widget spécifique !

Étape 1 : Enregistrement automatique des nouvelles sidebars

Ici, on procède en 2 étapes,dans un premier temps on enregistre la sidebar par défaut, puis on récupère la liste complète des pages disponibles de votre blog via la fonction get_pages() et on fait une boucle dessus pour enregistrer chaque sidebar.

<?php
if ( function_exists('register_sidebar') ) {
 // Default sidebar
 register_sidebar(array(
 'id' => "sidebar-default",
 'name' => 'Sidebar par défaut',
 'before_widget' => '<li id="%1$s">',
 'after_widget' => '</div></li>',
 'before_title' => '<h2>',
 'after_title' => '</h2><div>',
 ));

 // One sidebar by page
 $_pages = get_pages();
 foreach( (array) $_pages as $_page ) {
 register_sidebar(array(
 'id' => "sidebar-$_page->ID",
 'name' => esc_html($_page->post_title),
 'before_widget' => '<li id="%1$s">',
 'after_widget' => '</div></li>',
 'before_title' => '<h2>',
 'after_title' => '</h2><div>',
 ));
 }
 unset($_pages, $_page);
 wp_reset_query();
}
?>

Étape 2 : Appel de la sidebar depuis votre thème

(Code généralement à placer dans le fichier sidebar.php de votre thème)

Ici il ne faut pas oublier d'ajouter la variable globale $wp_query, grâce à cette dernière nous récupérons l'ID de l'objet actuellement chargé, et je vérifie que je suis bien sur une page et que la sidebar est utilisée. (autrement dit qu'elle contient au moins un widget). Si ça n'est pas le cas, je charge la sidebar par défaut.

<?php
global $wp_query;
if ( function_exists('dynamic_sidebar') ) {
 if ( is_page() && is_active_sidebar( 'sidebar-' . $wp_query->queried_object_id ) ) {
 dynamic_sidebar( 'sidebar-' . $wp_query->queried_object_id );
 }  else {
 dynamic_sidebar( 'sidebar-default' );
 }
}
?>

Vous pouvez retrouver l'intégralité du code depuis cette page pastebin

Articles relatifs

• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Nouvelle API de Widgets pour WordPress 2.8, et un multi widget pour l’extension WP-Polls ! (2)
• Les 4 nouveautés "Développeur" de WordPress 2.3 (8)

J'ai donc cherché une solution sur le net, et sur le groupe de support de MailPress, je suis tombé sur un sujet traitant du problème, et la réponse d'André m'a fait sourire :)

ask viper and cform dev to stop spreading their code all over all admin pages ! ?

En fait, il a en partie raison... Les plugins en questions, Viper Video Quicktags, Cforms et bien d'autres, ajoutent sans trop se soucier leur bouton à l'éditeur visuel de WordPress, et ils ne font pas du tout attention sur quelle page est chargé l'éditeur et encore moins par quel plugin... Mais ils n'ont pas tort... Lorsque j'ajoute le plugin Viper Video Quicktags, je souhaite ajouter les boutons des services vidéos... Et si je déporte l'éditeur visuel sur une page du site, je souhaite également avoir ses boutons...

En fait, le fautif à mes yeux est WordPress, les filtres offrent des superbes possibilités d'extensibilité, mais le nombre d'incompatibilités entre les extensions est en croissance exponentielle... Ici, l'éditeur visuel devrait pouvoir être appelé avec ou sans les filtres. (WordPress le propose déjà pour la fonction get_posts/query_posts)

Mais trêve de bavardage, pour corriger l'incompatibilité, j'ai développé un petit plugin qui corrige la situation pour les 2 plugins (cforms, viper vidéo quicktags), et de la sorte pas besoin de modifier/désactiver l'un ou l'autre des plugins...

<?php
/*
Plugin Name: MailPress Fix TinyMCE
Plugin URI: http://www.herewithme.fr
Description: Fix TinyMCE for MailPress with Viper Video Quicktags and Cforms
Author: Amaury Balmer
Version: 0.1
Author URI: http://www.herewithme.fr
*/

add_action( 'init', 'fixTinyMCE_MailPress', 999 );
function fixTinyMCE_MailPress() {
 if ( !isset($_GET['page']) && $_GET['page'] != 'mailpress_write' ) {
 return false;
 }

 // Viper video quicktags
 global $VipersVideoQuicktags; 

 remove_filter( 'tiny_mce_version', array(&$VipersVideoQuicktags, 'tiny_mce_version') );
 remove_filter( 'mce_external_plugins', array(&$VipersVideoQuicktags, 'mce_external_plugins') );
 remove_action( 'edit_form_advanced', array(&$VipersVideoQuicktags, 'AddQuicktagsAndFunctions') );
 remove_action( 'edit_page_form', array(&$VipersVideoQuicktags, 'AddQuicktagsAndFunctions') );
 if ( 1 == $VipersVideoQuicktags->settings['tinymceline'] )
 remove_filter( 'mce_buttons', array(&$VipersVideoQuicktags, 'mce_buttons') );
 else
 remove_filter( 'mce_buttons_' . $VipersVideoQuicktags->settings['tinymceline'], array(&$VipersVideoQuicktags, 'mce_buttons') );

 // Cforms
 remove_filter( 'mce_external_plugins', 'cforms_plugin');
 remove_filter( 'mce_buttons', 'cforms_button');

 return true;
}
?>

Le fichier est également disponible au téléchargement ici.

Articles relatifs

• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Une barre de sidebar automatique par page et une sidebar par défaut ! (7)

Ces stages rémunérés par Google, permettent à des projets comme WordPress de travailler sur des sujets bien précis, comme les performances, la documentation ou encore la recherche dans WordPress !

Ce projet est pour l’heure disponible sous forme de plugin « Search API » bien qu’il soit, à mon avis, très rapidement intégré dans le cœur de WordPress…

Le plugin est totalement modulable, il peut fonctionner avec différents algorithmes, par défaut il y a la recherche MySQL (via FullText), mais il est possible d’utiliser d’autres modules comme Google Custom Search, Sphynx Search.

Le plugin permet un tri des résultats par pertinence, date ou alphabétique. Il y a également possibilité d’afficher un formulaire de recherche avancé, avec un tri possible sur les auteurs, les catégories, les mots clefs, etc.

Articles relatifs

• [Tuto] Migrer de Ultimate Tag Warrior vers Simple Tagging ! (30)
• [MAJ] 2ème rencontre WordPress Francophone ! (4)
• WordPressMu : Copie à revoir… (9)
• WordPress, Memcached et PECL Memcache : La solution pour les blogs a gros trafic ! (6)
• WordPress Mu : Astuce pour ne pas proposer la page inscription aux visiteurs (2)

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 !

Articles relatifs

• WordPress Mu à haute fréquentation ? Problèmes de pages blanches ? (7)
• Optimiser les performances de PHP et WordPress chez OVH en 4 lignes ! (64)
• [WordPress Mu] Présentation (20)
• WP Super Cache et le bug de la compression Gzip, solution temporaire (4)
• WordPressMu : Copie à revoir… (9)

Pour cela, il suffit juste de changer 4 paramètres de PHP et pour y parvenir nous allons créé/édité le fichier .htaccess à la racine de votre FTP. (dans le dossier WWW)

Et on va y insérer les lignes:

SetEnv REGISTER_GLOBALS 0
SetEnv ZEND_OPTIMIZER 1
SetEnv MAGIC_QUOTES 0
SetEnv PHP_VER 5

Autrement dit, on désactive les directives PHP magic quotes, register globals qui n’apportent rien à WordPress.
On passe à PHP5 (qui offre une meilleure comptabilité avec les extensions) et on active le module PHP Zend Optimiser, ainsi le code PHP sera optimisé et les traitements récurrents seront mis en cache.

Tout cela de façon transparente pour WordPress, mais avec une meilleure réactivité à la clef pour l’utilisateur.

Pour plus d’infos sur PHP chez OVH, 2 petits guides à lire:

• http://guide.ovh.com/PhpChezOvh
• http://guide.ovh.com/ConfigPhp

Articles relatifs

• Et un nouveau plugin de cache ! W3 Total Cache (10)
• WP Super Cache et le bug de la compression Gzip, solution temporaire (4)
• WordPress Mu à haute fréquentation ? Problèmes de pages blanches ? (7)
• Bloguer ? oui ! mais comment et avec quels outils ? (0)
• [WordPress Mu] Présentation (20)

En réalité, la source du problème vient de WordPress 2.7, cette nouvelle version a apporté une nouvelle API pour les commentaires, dont la fonctionnalité de pagination. Cette dernière est très pratique lorsqu’on a plus de 1000 commentaires de moyenne sur chaque article… ( ex: Bords de Pistes )

Prenons l’exemple de l’article « Top Chrono » que Lionel a rédigé, le lien de l’article est le suivant:

• http://www.bordsdepistes.com/2009/03/21/top-chrono/

Vu qu’il y a 10 pages de commentaires, nous nous retrouvons avec 10 liens pour le même article:

• http://www.bordsdepistes.com/2009/03/21/top-chrono/comment-page-1/
• …
• http://www.bordsdepistes.com/2009/03/21/top-chrono/comment-page-10/

10 pages où le titre, la description et le contenu sont les mêmes !

Autrement dit, nativement WordPress, qui est pourtant très bien optimisé pour le référencement, créé du duplicate content avec cette fonctionnalité. Un débat a eu lieu sur le mailing de WordPress, et plusieurs hypothèses ont été envisagé, petit résumé de la situation.

Les balises HTML méta

Une première solution aurai été d’ajouter une balise méta « no index, follow » à la page. Bien que cette méthode règle le problème du duplicate content, l’inconvénient est que Google ne référence pas le contenu de tous les commentaires et de ce fait, c’est potentiellement un moins bon positionnement dans Google vu que moins de contenu est référencé !

Utilisation de jQuery

Une autre idée aurait été d’utiliser jQuery pour faire la pagination, avec le plugin Tabs par exemple. L’intérêt est que fonctionnellement on obtient bien une pagination. Cependant, cette technique est peu ou pas accessible, il oblige le chargement de jQuery dans les thèmes WordPress et surtout il force à écrire la totalité des commentaires dans le code HTML. Lorsqu’on a plus de 1800 commentaires, cela peut vite devenir contraignant !

En pratique

Pour résoudre ce problème de façon concrète, j’ai trouvé 2 solutions. Les deux sont d’ailleurs compatibles et fonctionnent mieux ensemble.

Le contenu de l’article

En remplaçant le contenu de l’article par l’extrait et un lien vers le lien de l’article, on retombe dans le schéma classique d’une page listant des articles comme peuvent l’être les catégories ou les tags.

De cette façon, Google ne considère plus le contenu comme du duplicate content et les commentaires sont bien référencés tout en étant liés à l’article avec le permalien et l’extrait !

Pour faire cette modification, vous pouvez utiliser l’extension de Austin Matzko soit en utilisant son extension, soit en faisant un copier/coller de sa fonction directement dans le fichier functions.php de votre thème.

Le titre de la page

Malheureusement, la première méthode ne règle pas complètement le problème, le titre de la page HTML reste toujours le même sur chaque page de commentaires et cela gene Google. C’est là où rentre en jeu l’idée de Christian Schenk d’ajouter un suffixe au titre des pages de commentaires. L’astuce qu’il donne permet d’ajouter un suffixe à ces pages si vous utilisez l’extension All In One SEO Pack.

Pour y parvenir, il suffit de copier les 2 fonctions qu’il propose dans le fichier functions.php de son thème et de modifier le code de All In One SEO Pack pour permettre aux filtres de fonctionner.

On remarquera que la méthode n’est pas trop propre vu qu’on est obligé de hacker le plugin et comme c’est le genre de plugin qui est mis à jour toutes les 2 semaines, cela deviendra très rapidement pénalisant.

Mon extension : Simple SEO for Paged Comments

Afin de faciliter la résolution de ce petit problème, j’ai créé une petite extension qui utilise les 2 techniques données précédemment. A la différence près que le titre des pages de commentaires se verra ajouter un suffixe, et ceux sans nécessairement utiliser All In One SEO Pack (et encore moins le hacker). Théoriquement ma technique doit fonctionner avec tous les plugins SEO de la communauté.

Vous pouvez trouver la fiche de l’extension sur mon blog et prochainement sur WordPress.org.

Sources

Un peu de lecture en anglais ;)

• Paginated comments with WordPress 2.7 and the Copyblogger theme
• Paged Comments and the SEO Problem: A Solution

Articles relatifs

• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Une barre de sidebar automatique par page et une sidebar par défaut ! (7)

Eh oui… Entre WordPress 2.3 et WordPress 2.7, l’API des widgets n’a pas bougé d’un pouce alors que l’ergonomie et l’apparence ont complètement changé… L’une des problématiques les plus courantes était dans le cadre de thèmes avec un grand nombre de sidebars… Et oui à part 2-3 Widgets (comme le texte) qui proposaient l’ajout multiple, on était vite coincé…

Par exemple, dans WordPress 2.7, il est impossible de placer un widget « catégories » sur 2 sidebars en même temps… Frustrant lorsqu’on souhaite gérer des sidebars différentes selon la vue (tags, archives, catégories…) où l’on se trouve !

Pour remédier à cela, il fallait créer des widgets multiples, autrement dit que l’on peut ajouter plusieurs fois, la problématique étant que peu d’extensions proposées ce fonctionnement, car plus compliqué à développer.

WP-Polls

C’est le cas par exemple de WP-Polls 2.40, une extension permettant de gérer des sondages, qui par défaut ne possède qu’un seul widget. Cela peut poser problème si vous souhaitez afficher 2 sondages sur 2 sidebars différentes.

Pour mes besoins pros, j’ai dû adapté cette extension afin de la rendre compatible multi widget, et ainsi pouvoir placer autant de sondages que le client souhaitait sur ces sidebars. Je mets par la même occasion à disposition le widget en téléchargement ci-dessous :

WP Polls Widget Multi v2.40 (à renommer en .php et placer dans le dossier « wp-content/plugins »)

Et voici un petit apercu de 4 widget « Poll » en place avec encore la possibilité d’en ajouter :

La version multi widget de l'extension WP-Polls

La difficulté de WordPress 2.7, c’est que l’API pour faire du multi widget est très rudimentaire et de ce fait pas évident à manipuler pour les développeurs d’extensions non confirmés…

Petite comparaison :

• Mon widget multi de WP-Polls (WP 2.7) fait 240 lignes. (dispo ci-dessus)
• Le même widget (quasiment) fait par l’auteur de WP-Polls avec l’API 2.8 ne fait plus que 75 lignes.

Évidemment lorsque l’API est optimisée, c’est tout de suite plus simple et plus rapide de créer du multi widget ;)

Contrairement à l’ancienne API qui n’était composée que de fonctions PHP classiques, la nouvelle API va faire plaisir au puriste PHP ! Et oui pour la première fois (ou presque), nous devrons étendre une classe existante de WordPress pour ajouter nos widgets, hop petit exemple :

class WP_Widget_Polls extends WP_Widget {

Sur ce rythme on ne pourra bientôt plus critiquer WordPress pour la qualité de son code ;) Bien entendu, tout cela reste compatible PHP4 ! (ce qui n’est pas un cadeau pour les développeurs de WP)

Je ne détaille pas plus ici l’utilisation de la nouvelle API des widgets, j’en reparlerai avec un cas pratique lors de la sortie de WP 2.8. Pour info, la discussion relative à la nouvelle API est disponible sur le trac de WP.

Articles relatifs

• WordPressMu : Copie à revoir… (9)
• Vous avez dit "Blog au ralenti ?" (4)
• Une barre de sidebar automatique par page et une sidebar par défaut ! (7)
• Sortie de Simple Tagging 1.6.8 ! (5)
• Simple Tags : Gérez vos tags… différemment… (2)

De ce fait, j’ai repris la traduction de la version 1.0 faite par l’équipe de l’Atelier Mammouth que j’ai mis à jour (5-6 nouvelles chaines). J’ai également changé certaines traductions (billets -> articles) et quelques fautes d’orthographe.

J’ai également viré le copyright de traduction, que je trouve assez inutile lorsqu’on utilise un fichier Po/Mo. Hop je mets à disposition les 2 fichiers PO et MO, ils sont à placer dans le dossier du thème « carrington-blog ».

• Fichier MO du thème Carrington 1.3 en français
• Fichier PO du thème Carrington 1.3 en français

Articles relatifs

• [Tuto] Migrer de Ultimate Tag Warrior vers Simple Tagging ! (30)
• [MAJ] 2ème rencontre WordPress Francophone ! (4)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• WordPress doit-il craindre Dotclear 2 ? (Partie 1 : Les templates) (18)

2 raisons à cela, la première est que la version 2.7 à l’air de grandement satisfaire la communauté, la deuxième l’équipe de dev souhaite refondre complètement l’ergonomie de la page de gestion des Widgets.

Il est vrai que l’ergonomie actuelle des Widgets laisse à désirer, c’est tout sauf intuitif !
Et comme on parle de Widgets, d’un truc à la base dynamique et ergonomique, on reste un peu sur sa faim :)

Articles relatifs

• [WordPress Mu] Présentation (20)
• [Tuto] Migrer de Ultimate Tag Warrior vers Simple Tagging ! (30)
• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• [MAJ] 2ème rencontre WordPress Francophone ! (4)
• Ziki.com : ca marche vraiment ? (2)

La ligne à ajouter est la suivante :

$wp_local_package = 'fr_FR';

Elle permet de préciser la langue utilisée pour les mises à jour. Une fois le fichier modifié, vous devrez voir la notification disparaitre lors de la prochaine vérification de version de WordPress !

Si vous ne souhaitez ou ne pouvez pas faire la modification, n'oubliez pas qu'il est possible de masquer les mises à jour, pour cela il faut se rendre sur la page "Outils - Mettre à jour".

Articles relatifs

• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Une barre de sidebar automatique par page et une sidebar par défaut ! (7)

Pour y parvenir, il y a 2 possibilités, installer une extension ou créer une fonction dans le thème.

• L'extension a l'avantage d'être configurable depuis la console d'administration, le défaut c'est qu'on charge un peu plus de choses dans WordPress... Et puis pourquoi mettre personnalisable quelque chose de statique dans la vie de tous les jours...
• La deuxième méthode consiste à placer une fonction directement dans le fichier functions.php de votre thème. Cette fonction sera associée au filtre "pre_get_posts" de WordPress.

Fonction d'exemple:

add_filter( 'pre_get_posts', 'quantity_per_view' );
function quantity_per_view( $wp_query = '' ) {
	if ( is_search() ) { // recherche
		$wp_query->query_vars['posts_per_page'] = 9;
	} elseif ( is_category() ) { // Category
		$wp_query->query_vars['posts_per_page'] = 8;
	} elseif ( is_tag() ) { // Tag
		$wp_query->query_vars['posts_per_page'] = 8;
	} elseif ( is_author() ) { // Auteur
		$wp_query->query_vars['posts_per_page'] = 8;
	} elseif ( is_date() ) { // Archive
		$wp_query->query_vars['posts_per_page'] = 8;
	}

	return $wp_query;
}

Ici, on permet de spécifier une quantité différente pour la vue, les catégories, les tags, les auteurs et les archives... La valeur que vous fixerez écrasera l'option présente dans la page de réglages "Lecture" de WordPress.

Je conclurai en disant que cette méthodologie est l'unique bonne méthode pour spécifier le nombre d'articles par page. Utilise la fonction query_posts() est une aberration digne de tout bon webdesigner en herbe pour la simple et bonne raison que vous effectuerez le double de requête SQL...

Cela aura comme conséquence d'augmenter la charge serveur et le temps de génération des pages ;) Si les créateurs de thèmes magazine US (Mimbo et ses petits cousins) me lisent (ce qui est compliqué), prenez de la graine !

Articles relatifs

• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Une barre de sidebar automatique par page et une sidebar par défaut ! (7)
• Les 4 nouveautés "Développeur" de WordPress 2.3 (8)

Un éditeur de code dans WordPress : CodePress

L’intégration de la librairie JavaScript « CodePress » permettant une amélioration notable l’éditeur en ligne des thèmes et des extensions de WordPress. Cette librairie permet de mieux visionner le contenu des thèmes et des extensions WordPress.

Elle apporte également des améliorations concernant les raccourcis claviers, ce que ne permet pas un champ textarea classique.

CodePress lors de l'édition d'un thème

Simple Pie

Simple Pie est une librairie PHP bien connu des développeurs PHP. Elle permet d’agréger des flux RSS, RSS 2.0, Atom très facilement. Depuis très longtemps WordPress utilise la classe Magpie pour faire ce travail, mais le problème est que cet outil n’est plus mis à jour et que ses performances et ses fonctionnalités montrent leurs limites.

Dans WordPress 2.8, toutes la partie agrégation RSS (tableau de bord et Widget RSS) devrait être pris en charge par Simple Pie, qui lui a l’avantage de gérer la mise en cache en base de données, chose très pratique et de suivre un développement très actif.

Un générateur de classe HTML pour l’élément « body » de votre thème.

Cette fonctionnalité, à destination des intégrateurs et créateurs de thèmes, ajoute une fonction body_class() permettant de générer une classe pour l’élément BODY de votre thème. Ainsi, vous pourrez facilement personnaliser l’aspect CSS de votre thème selon l’emplacement où vous êtes.

Il utilisera différents critères, la vue (catégorie, tags, archives), le type (article, page), le statut de connexion (logged-in), etc. Par exemple, sur la page d’accueil du blog, vous obtiendrez :

<body class="home blog logged-in">

Les créateurs de thèmes complexes apprécieront !

La taxinomie de WordPress évolue

Et une nouveauté dédiée aux développeurs de plugins ! Afin de rendre l’API de taxinomie de WordPress encore plus souple, les développeurs de WordPress lui ont apporté des modifications afin de générer des pages d’édition (ajout, édition, suppression) plus facilement. Aujourd’hui la manipulation consistait à s’inspirer de la structure des tags ou des catégories…

Il devrait encore être plus facile de créer de nouvelle taxinomie dans WordPress !

Amélioration des performances (DB + JavaScript)

Plus WordPress évolue, plus il a tendance à grossir… Assez logique ! Pour améliorer la situation, les développeurs ont ajouté dans WordPress 2.5, la fonctionnalité Turbo. Cette fonctionnalité bien qu’efficace n’a pas satisfait tous les utilisateurs, et les développeurs bien conscients de la situation travaille sur une amélioration des performances dans WordPress 2.8.

Les librairies JavaScript

La fonction wp_enqueue_script() va recevoir un nouveau paramètre permettant de spécifier si le script doit être chargé dans l’entête ou dans le pied de la page. WordPress gérera par la même occasion la concaténation des scripts et CSS, la compression Gzip des JavaScripts et des CSS. Cela permettra ainsi de réduire la taille des JavaScripts et diminuera le nombre de connexions HTTP.

Pour plus d’informations sur ces ajouts, il y a 2 articles (en anglais) qui traitent de cette modification:

• http://wpdevel.wordpress.com/2009/02/06/script-loader-updates/
• http://lesterchan.net/wordpress/2009/01/26/loading-javascript-in-footer-in-wordpress-28/

Cela amène l’ajout de différentes constantes de configuration: (je ne traduis pas, ça me parait assez explicite !)

define(‘SCRIPT_DEBUG’, true); loads the develppment (non-minified) versions of all scripts
define(‘CONCATENATE_SCRIPTS’, false); disables both compression and cancatenating,
define(‘COMPRESS_SCRIPTS’, false); disables compression of scripts,
define(‘COMPRESS_CSS’, false); disables compression of CSS,
define(‘ENFORCE_GZIP’, true); forces gzip for compression (default is deflate).

La base de données

Ryan parle sur son blog d’une amélioration de la base de données, d’après les développements présents dans le trac, il n’y a encore rien en place à ce sujet !

Amélioration de la sécurité SQL

Depuis les premières versions de WordPress, les développeurs ont toujours préféré la fonction addslashes() de PHP pour sécuriser les requêtes SQL. Ce choix peut parait surprenant pour tout développeur PHP, en effet il existe depuis quelques années la fonction mysql_real_escape_string() qui est destinée à cet effet…

En fait, la fonction addslashes() ne pose aucun problème de compatibilité avec les hébergeurs, ce qui n’est pas toujours le cas avec la fonction mysql_real_escape_string(). De nos jours, les hébergeurs étant majoritairement passer à PHP5 et le problème ne se pose plus vraiment, ainsi la classe de connexion à la base de données WPDB de WordPress 2.8 choisira ainsi la meilleure fonction disponible pour sécuriser les données !

Correction d’un bug gênant avec la classe WP-Cron

Je détaille la chose dans l’article :Des problèmes avec WP Cron et la programmation des articles ?

Amélioration de la classe HTTP

La classe HTTP ajoutée dans WordPress 2.7 se voit greffer quelques nouveautés:

• Le support des compressions Gzip et Deflate pour le transfert des données
• La possibilité de créer un cookie de connexion via la classe HTTP
• La possibilité de bloquer l’appel à certaines URL via une liste noire (pratique si vous êtes derrière un serveur proxy par exemple)
• Meilleur support du SSL

Diverses choses

• Nouvel importeur pour le service LiveJournal
• Minification (Minified) de tous les JavaScripts utilisés par WordPress. (en plus de la compression Gzip et la concaténation)
• Amélioration de l’API XML-RPC concernant les médias de WP

La version 2.8 est prévue pour le 9 mars 2009, mais personnellement je doute qu’il soit dans les temps !

Pour visionner les évolutions, visitez le site de démo de la version de développement de WordPress

Articles relatifs

• WP Super Cache et le bug de la compression Gzip, solution temporaire (4)
• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress va apprécier Firefox 3.1… (Safari 4 aussi !) (2)
• WordPress passe la seconde avec Gears sous safari ! (0)

http://phpdoc.wordpress.org/trunk/

Pour les autres versions, une page du codex décortique les différentes docs disponibles :

http://phpdoc.wordpress.org/trunk/WordPress

À noter que contrairement à un phpXref classique, la documentation de WordPress contient également la doc de toutes les librairies (JS, PHP) utilisées dans le projet.

Articles relatifs

• [WordPress Mu] Présentation (20)
• [Tuto] Migrer de Ultimate Tag Warrior vers Simple Tagging ! (30)
• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• [MAJ] 2ème rencontre WordPress Francophone ! (4)
• Ziki.com : ca marche vraiment ? (2)

• http://yoast.com/wp-cron-issues/
• http://www.bloghighlight.com/wordpress-post-missed-schedule/

Et après une petite investigation, essayez éventuellement d’appliquer les modifications de ce changeset, il corrige des bugs liés à WP-Cron. (cela provient de la version de développement de WordPress)

Articles relatifs

• [TechDays 2007] PHP sur Windows / Projet Phalanger (6)
• WordPressMu : Copie à revoir… (9)
• WordPress Mu dans le cadre d’un projet professionnel (8)
• Vous avez dit "Blog au ralenti ?" (4)
• Une barre de sidebar automatique par page et une sidebar par défaut ! (7)