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

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

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 !

Quelques personnes motivées ont repris les sources de la version 0.7.1 d’ activeCollab, qui était sous licence GPL.

Le nouveau projet, renommé ProjectPier, corrige divers bugs et failles de sécurité. Il apporte également de nouveaux thèmes, donc certains très réussi !

Pour finir en beauté, la traduction française existe aussi :)

(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 ;)

( Si le thème ou plugin en question n’est pas internationalisé, consultez la partie 3 de l’excellent article de Marc Charlet. )

Télécharger et installer Poedit

Direction le site internet de l’outil : http://www.poedit.net/

Vous trouverez sur la page de téléchargement une version pour chaque plateforme (Windows, Mac OS et Linux).

Prenez la bonne version et installez-la ! ( pour windows: Next – I’accept – Next – Next- Next – Next – Install – Finish )

Précision sur le fonctionnement de l’internationalisation dans WordPress

WordPress permet dans son implémentation de délimiter les traductions dans des « domaines ». On peut faire l’analogie avec le découpage de la France en départements / régions.

Pour cela, les fonctions d’internationalisations disposent de plusieurs paramètres :

function __($text, $domain = ‘default’)

function _e($text, $domain = ‘default’)

Le premier paramètre ($text) correspond à la chaine de texte à traduire. Tandis que le deuxième ($domain) correspond au domaine de traduction. On peut d’ailleurs remarquer que si on n’utilise pas de deuxième paramètre, le domaine prend la valeur « default ». (le cas des chaines originales de WordPress)

Le fichier PO/MO présent dans le pack français traduit l’ensemble du domaine « default » de WordPress.

Exemple: Une chaine de texte du domaine « default » traduit par le pack français.

<?php _e(‘Anonymous’); ?>

Attention: N’étendez pas la traduction par défaut à d’autres plugins ou thèmes, au risque d’avoir de nombreux problème lors des mises à jour du pack français…

Vous l’aurez compris, il faut que votre thème ou plugin, dispose de son propre domaine de traduction pour toutes les chaines à traduire. Si ça n’est pas le cas, uniformiser le nom du domaine.

Exemple: Une chaine du plugin SimpleTagging, utilisant le domaine « simpletagging ».

<?php _e(‘Simple Tagging: Options’, ‘simpletagging’); ?>

Le principe est le même pour les thèmes et les plugins.

Nommage des fichiers de traduction (PO/MO)

Selon le cas, plugin ou thème, le nommage des fichiers de traduction est différent, explications !

Les thèmes

C’est le cas le plus simple, votre fichier de traduction doit juste être nommé dans le code de langue utilisé.

Exemple pour un WordPress français, il faudra juste nommé vos fichiers en fr_FR.po et fr_FR.mo et les placer dans le même dossier que votre thème.

Plus généralement, il faudra que vos fichiers soient nommer de la même façon que la constante « WPLANG » fixée dans le fichier wp-config.php

define (‘WPLANG’, ‘fr_FR’);

Les plugins

Cette fois-çi c’est un tout petit peu plus compliqué, votre fichier doit être nommé de la façon suivante : domaine – code langue .mo

Exemple pour le plugin SimpleTagging (rappel, le domaine de traduction est « simpletagging ») :

simpletagging-fr_FR.po

simpletagging-fr_FR.mo

Attention: Tout cela ne vaut que si vos plugins et thèmes sont bien développés… si cela ne fonctionne pas le plus simple est de contacter l’auteur pour savoir quelle est la spécificité. (il n’est pas rare de voir des dossiers « languages » dans les plugins, le cas échant déplacer vos fichiers de traduction dedans)

Créer un fichier PO et POT depuis les sources dans Poedit

L’ancienne méthode en ligne de commande est révolue ! (sauf cas spécifique)

Poedit vous permet de créer directement un fichier PO depuis les sources de votre plugin ou thème.
Mon exemple traitera d’un plugin, mais c’est le même principe pour les thèmes !

1. Lancer Poedit
2. Cliquer « Fichier – Nouveau catologue »
3. Une fenêtre configuration apparait
1. Compléter l’onglet « Info projet »
   
2. Compléter l’onglet « Chemins »
   1. Ajouter un chemin grâce au bouton :
   2. Copier/coller le chemin de votre projet à l’aide de la barre d’adresse ou saisissez-la manuellement (cliquer pour agrandir)
      
      
3. Compléter l’onglet « Mots clé »
1. Ajouter un mot clé grâce au bouton:
2. Ajouter les mots clés : ‘__’, ‘_e’ et ‘_c’
3. Résultat à obtenir:
   
4. Appuyer sur Ok
4. Enregistrer le fichier avec comme nom, le domaine de votre plugin (exemple: exemple.po)
5. Si tout se déroule bien, Poedit vous affiche une fenêtre avec les chaines ajoutées et éventuellement supprimées.
6. Ne commencez pas tout de suite la traduction.
7. Enregistrer le fichier et fermer Poedit.
8. Dupliquer le fichier exemple.po en exemple.pot
9. Supprimer le fichier exemple.mo créé automatiquement lors de l’enregistrement
10. Renommer le fichier exemple.po en exemple-fr_FR.po
11. Vous pouvez alors éditer ce fichier avec Poedit et réaliser la traduction française
12. Le fichier POT permettra à d’autres personnes d’éventuellement traduire votre thème/plugin sans s’embêter à générer un fichier PO depuis les sources.

Mise à jour de votre traduction (POT)

Si vous effectuez des modifications dans les sources du plugins ou du thème:

1. Il vous suffit de renommer le fichier exemple.pot en fichier exemple.po
2. De le mettre à jour, pour cela:
1. Menu « Catalogue » – « Mise à jour depuis les sources »
2. Vous aurez un aperçu des ajouts et des suppressions
3. Valider
4. Enregistrer et fermer Poedit
3. Renommer le fichier exemple.po en exemple.pot
4. Supprimer le fichier exemple.mo créé automatiquement lors de l’enregistrement

Vous disposez alors d’un fichier POT à jour.

Mise à jour de votre traduction PO depuis un fichier POT

1. Ouvrer votre traduction exemple-fr_FR.po avec Poedit
2. Cliquer sur le sur menu « Catalogue – Mettre à jour depuis fichier POT »
3. Sélectionner le fichier POT
4. Valider les modifications
5. Traduiser les nouvelles chaines
6. Enregistrer !

Vous disposez d’un fichier de traduction à jour.

Bonne traduction ;)

Lorsqu’on travaille la première fois avec WordPress, le nombre de fichiers présents dans le thème par défaut, 18 pour être précis, peut paraître déroutant. Pourtant, la logique derrière est très simple et surtout très souple à l’usage…

Pour bien comprendre, rien ne vaut un petit schéma :)

(source: http://codex.wordpress.org/Template_Hierarchy)

 Comme on peut le voir sur ce schéma, WordPress dispose de 8 vues différentes :

• Page d’accueil
• Article unique (avec les commentaires en général)
• Page statique
• Catégorie
• Auteur
• Vues relatives aux dates (années, mois, jours)
• Recherche
• Erreur 404

Cas général

Selon l’adresse entrée par le visiteur, WordPress va sélectionner la vue correspondante. Si le fichier de la vue en question existe, WordPress lance le template, sinon il appelle le template par défaut, index.php

Voila le cas le plus simple… Cependant, WordPress est plus puissant et permet d’aller un peu plus loin dans la logique pour certaines vues. Les vues en question sont les pages statiques, les catégories et dans une moindre mesure les vues auteurs et relatives aux dates.

Cas spécifique 1 : Les pages statiques de WP

WordPress permet grâce aux pages statiques, d’afficher un contenu (contact, CV, présentation) hors de la chronologie du blog. Il est également possible de créer des templates spécifiques pour ces pages.

Pour cela, vous pouvez vous inspirer du tutoriel de fran6, mais revenons à nos moutons…

Dans le cas où votre page possède un template personnalisé, WordPress tentera de le lancer, sinon il chargera le fichier page.php. Enfin si ce dernier n’existe pas, il charger le fichier index.php (le cas général)

Soit : votretemplateperso.php –> page.php –> index.php

Cas spécifique 2 : Les catégories de WP

Ce deuxième cas est un peu moins souple que les templates des pages. En effet cette fois-ci, le nom de vos template sera obligatoirement formaté en « category-X.php », X étant l’ID de la catégorie. La logique est la même que pour les pages.

Soit: category-X.php –> category.php –> archive.php –> index.php

Cas spécifique 3 : Le fichier archive.php

Ce fichier est commun aux vues relatives aux articles du blog, c’est-à-dire catégorie, auteur et vues relatives aux dates.

Il s’intercale juste avant le fichier index.php

Soit: category-X.php –> category.php –> archive.php –> index.php

ou: author.php –> archive.php –> index.php

ou encore: date.php –> archive.php –> index.php

Conclusion

Tout ce que je viens d’expliquer ici textuellement est affiché sur le schéma ci-dessus… Un peu de logique de programmation vous permettra en un clin d’oeil de comprendre la logique de WP ;)

Vous trouverez d’autres ressources sur la page Template Hierarchy du codex WordPress.org

Ces derniers étant disponibles uniquement en anglais, j’ai pris le temps de les traduire et aussi les améliorer (suppression de dépendances à des plugins inutiles, remplacement de UTW par Simple Tagging, indentation du code, etc.).

Au programme aujourd’hui le thème « Hello 2007″ et « Minyx ».

Ils sont tous les 2 compatibles, WordPress 2.1 et supérieur, ainsi que Widgets.

Vous pouvez les trouver en téléchargement sur la page de mon blog dédiée aux thèmes WordPress ! (menu supérieur)

À noter, que je vais mettre à jour, durant l’été, les thèmes actuels afin de les rendre compatible WP 2.1 et supérieur et Widgets.

Les raisons ?

Diverses… manque d’envie, manque de temps…

Et puis il y a eu:

• La migration du blog de Sebeuh vers WordPress (et ça ne fut pas une mince affaire!)
• La traduction de 2 thèmes en français (publication début juillet)
• La réalisation du pack français de WPmu 1.2.2
• L’optimisation du blog et serveur de Rod.

Et il y a:

• Les examens SUPINFO
• Le développement de Simple Tagging
• Le développement de SDM
• Les démarches administratives pour ma déclaration en tant que professionnel indépendant…

Pourtant, ça n’est pas les sujets qui manquent !

Je pourrai parler de:

• La sortie de HyperDB pour WPmu (je publierai un tuto début juillet)
• La sortie de WPmu 1.2.2
• Des 2 « contests » WP
• La fin de ma 2ème année à SUPINFO
• Des nouveautés de Windows Live Writer Béta 2, ou encore de ses plugins
• De mon prochain ordinateur portable (qui a dit MacBook Pro ?)
• Etc.

Bref !

Encore 10 petits jours et ce blog reprendra son rythme de croisière !

Elle contient :

• Un antispam : Akismet
• Un plugin de colorisation de code: Code Snippet
• Le classique Feedburner Feed Replacement pour mes flux.
• Un aperçu en AJAX pour les commentaires: Filosofo Comments Preview
• La liste des derniers commentaires: Get Recent Comments mais modifié pour mes besoins (filtre par catégorie)
• Un générateur de sitemaps XML: Google (XML) Sitemaps
• Un générateur de mots clés, métas html : GWP – MetaAdmin
• ImageManager, bien que je ne l’utilise plus. (WLW Powa)
• La signalisation des différents types de liens grâce à Link Indication
• myGallery pour gérer les galeries de thèmes.
• Le formulaire de contact : PXS Mail Form
• Share This : pour le partage d’articles
• La gestion des tags grâce à Simple Tagging (étonnant non?)
• Subscribe To Comments pour s’abonner aux commentaires
• WP-PageNavi pour la navigation entre les pages

Je n’ai que ca.

Et c’est deja beaucoup trop à mon goût !

Des suggestions ? Es ce que je rate le plugin de la mort qui tue ?

La popularité de Firefox s’explique pour plusieurs raisons :

• C’est un logiciel libre multiplateforme
• Grâce à l’immobilisme de Microsoft envers Internet Explorer 6
• Il dispose d’un système de thèmes et d’extensions très performant et très simple
• Et d’une navigation par onglets très efficace
• Etc.

Et aussi, et surtout, pour la sécurité.

En effet, Firefox contrairement à IE, connait peu de failles de sécurités et ces dernières sont rapidement corrigées. (grâce à une communauté active et ouverte)

Un problème de sécurité… humain !

Malheureusement, Firefox propose une fonctionnalité que l’on pourrait assimiler à un problème de sécurité.

Attention, je ne parle pas d’un bug informatique corrigible avec un patch, loin de là.

En fait, Firefox autorise l’affichage des mots de passe enregistrés. ( Menu Outils – Onglet Sécurité – « Afficher les mots de passe  » – une nouvelle fois « Afficher les mots de passe  » )

Les informations stockées ne se contentent pas uniquement du site et de l’identifiant utilisé pour la connexion, mais aussi le mot de passe. C’est là que le problème se pose !

D’un point de vue technique, les développeurs ont pensé à tout ! Il est tout à fait possible de restreindre cette page avec un mot de passe dit « principal ».

En pratique, peu de personnes connaissent cette fonctionnalité et ces risques… De ce fait, peu de personnes définissent ce mot de passe.

Les risques sont majeurs… il vous suffit de laisser votre PC déverrouillé, de le déposer au SAV, de le prêter… pour qu’une personne malintentionnée récupère en 3 clics votre mot de passe… (Et sachant que la grande majorité des personnes utilisent le même mot de passe pour plusieurs services…)

Il a alors accès à tous vos mots de passe, accès email, fournisseur d’accès internet, boutique en ligne, et autres services web.

Remède et conclusion

Je vous invite vivement à définir un mot de passe principal.

Pour cela :

1. Menu Outils
2. Onglet Sécurité
3. Cocher la case « Utiliser un mot de passe principal »
4. Définissez votre mot de passe
5. Valider !

Enfin, je pense que la fondation Mozilla devrait communiquer nettement plus à ce sujet et pourquoi pas proposer un assistant à la fin de l’installation de Firefox, proposant l’activation du mot de passe principal et les risques liés !

C’est très simple.

• Simple Tagging dispose de toutes les fonctionnalités de Ultimate Tag Warrior (UTW)
• Simple Tagging est beaucoup plus performant que UTW (un blog avec UTW est 5 à 50 fois plus lent qu’un blog avec Simple Tagging.)
• Simple Tagging est plus ergonomique et plus simple à utiliser que UTW
• Simple Tagging est disponible en français
• L’intégration de Simple Tagging dans les thèmes est très simple (les options sont paramétrable depuis la console d’admin)
• Simple Tagging est compatible avec WordPressMu
• Simple Tagging est plus puissant que UTW pour les utilisateurs avancés

Si vous voyez autre chose, n’hésiter pas à en faire part dans les commentaires :) les critiques constructives sont également la bienvenue :)

C’est difficile à faire ?

Non.

Simple Tagging est beaucoup plus simple à mettre en place que UTW. Démonstration ci-dessous.

Instructions

Installation et importation de vos tags:

1. Sauvegarder votre base de données (on est jamais trop prudent)
2. Télécharger la dernière version de Simple Tagging
3. Envoyer les fichiers de Simple Tagging sur le FTP de votre installation de WordPress
4. Activer le plugin dans la page « Plugins » de la console d’administration
5. Cliquer sur le menu « Tags » puis sur le sous-menu « Importer des tags« 
6. Si votre installation de UTW est valide, vous avez la possibilité d’importer vos tags depuis les catégories, et depuis UTW. Dans notre cas, nous allons importer les tags UTW, pour cela on coche la case « J’ai sauvegardé ma base de données. » et on clique sur « Importation depuis UTW« 
7. Selon votre hébergeur, l’importation peut être plus ou moins longue. (très rapide sur ma dedibox)

La 2e étape est un peu plus technique, en effet, maintenant que vous importez les tags, vous devez modifier les fonctions de votre thème pour lui faire utiliser Simple Tagging à la place de UTW.

Contrairement à UTW, Simple Tagging propose toutes les options, tailles, ordres, couleurs, etc. dans la console d’administration. C’est un gain de temps, et cela permet à l’utilisateur final de ne pas avoir à modifier les templates lors une éventuelle modification.

Les principales équivalences :

Prenons le cas du nuage de tags.

Voici le code actuel dans le fichier sidebar.php:

[code lang="html"]

[/code]

Voici l’équivalent avec Simple Tagging

[code lang="html"]

[/code]

La personnalisation du nuage de tags a lieu dans la console d’admin avec Simple Tagging. (Les nuages de tags colorés automatiquement, sans modification du CSS, sera présent dans la version 1.6.5 qui devrait sortir début de semaine prochaine).

C’est le même principe pour toutes les fonctions.

Une fois votre thème migré vers Simple Tagging, vous pouvez alors désactiver UTW et vous disposez d’un blog plus rapide :)

Voilà quelques liens avec des ressources bien pratiques :

• WPMUDEV.org : Site regroupant un grand nombre de plug-ins/hacks/thèmes pour WordPress Mu. Dépôts plus ou moins officiels pour WPmu.
• mu.bloggles.info : blog listant un grand nombre de plug-ins et de thèmes pour WPmu.

Sans oublier le trac et le forum officiel.

Le support français est effectué sur 2 sous-forums de WordPress Francophone.

• Installation de WordPress Mu
• Utilisation de WPmu

Voilà pour la petite note !

Bon, allez, je le dis, je vais lancer très prochainement une gamme de plug-ins pour WordPress Mu de qualité (internationalisé comme il faut, bien finalisé) et surtout traduits en français !

Entre-temps, WordPress Mu est passé en version 1.2.1, et mieux, j’ai réalisé ma première « grande » plateforme de blog avec cet outil :)

Dans ce dernier article, j’avais été très sévère envers WordPressMu, mon avis n’a pas fondamentalement changé, mais il a logiquement évolué…

Par exemple, je suis toujours convaincu qu’utiliser WordPress Mu pour gérer 10 blogs ou moins n’est pas une bonne chose.

Vous gagnerez certes un peu de temps lors des mises à jour… mais vous perdrez un grand nombre de plug-ins, gagnerez un certain nombre de bugs, et perdrez beaucoup de souplesse.

Quels sont les manques de WPmu pour les professionnels ?

Nombreux.

En fait, WordPress Mu fait quelque chose très bien, il permet de créer des blogs à la volée. C’est tout.

Mais est-ce la finalité dans le cadre d’un projet professionnel ?

Je ne pense pas.

WPmu de base ne permet pas de trier les blogs par catégories, remonter les derniers commentaires, les derniers articles, les blogs les plus actifs, les tags pour la plateforme entière, les blogs à la une, les blogs les plus vus, différents flux RSS, des statistiques, la modération, etc.

WPmu ne se suffit pas à lui-même.

Utiliser WordPress Mu exige un grand nombre de développement autour, il faut en être conscient.

Je pense qu’on peut assimiler WPmu à un framework de développement de plateforme de blog.

Est-ce que WordPress Mu est stable ?

La version 1.2.1 apporte un très grand nombre de correction (plus de 500, voir le trac pour bien comprendre), WordPressMu commence à devenir un produit mature, d’ailleurs il suffit de suivre le « TimeLine » de WPmu pour se rendre compte, que la majorité des modifications actuelles concerne la partie WordPress de l’application et moins la partie « mu ».

Cependant, tout est loin d’être parfait.Il reste un certain nombre de chaines non internationalisé, et certains bugs liés à cette même internationalisation. (Ça n’est plus le cas maintenant, depuis l’application des différents patchs que j’ai proposés sur le trac.)

L’utilisation de WordPressMu en production est désormais une chose envisageable, mais un minimum de développement est tout de même à prévoir.

Les performances de WordPressMu

Mon avis n’a pas radicalement changé par rapport à mon premier article sur ce point. WordPressMu est sans aucun doute à l’image de WordPress. Loin d’être bien développé, mais terriblement efficace.

D’ailleurs quand, Automattic parle d’une enveloppe pour WordPressMu c’est effectivement le cas.

Il y a très très peu de modification sur WordPress mis à part les ajouts liés à « mu ».

On retrouve donc les avantages de WordPress, une architecture « plug-ins  » éprouvée, mais également ces défauts, avec une consommation SQL/PHP importante.

Or dans le cadre d’un blog WordPress, ça n’a pas ou peu d’importance, dans le cadre d’une grande plateforme de blog, c’est beaucoup plus gênant.

Pour y palier, les avis et méthodologie sont variés, certaines personnes privilégient l’utilisation du cache de WPmu, d’autres utilisent un cache à l’aide de serveurs proxy, sans oublier les load balancing et autres architectures exotiques…

Il n’y a pas vraiment de solutions miracles. Et le choix de la solution dépend d’un certain nombre de paramètres, architecture actuelle, budget, type de la charge, etc.

Personnellement, dans le cadre de mes projets WPmu, j’utilise une version de WPmu très légèrement modifié permettant de ne pas avoir de limite de blogs, autorisant l’utilisation massive du load balancing, et exploitant le cache de WordPress.

Les plug-ins et WordPress Mu

C’est un sujet sensible.

Le grand intérêt d’une plateforme de WordPressMu, c’est l’usage des plug-ins disponibles pour WordPress.

Malheureusement, ils ne sont pas tous compatibles, et pas tout envisageables pour WPmu.

Le 1er prérequis pour qu’un plug-in soit compatible WPmu est qu’il soit compatible WP 2.1.

En effet, WordPress Mu et WP 2.1 sont très proches à ce niveau. En général un plug-in compatible WP2.1 sera compatible WPmu.

Je dis bien en général, car en pratique, WordPress Mu utilise une version plus récente de TinyMCE que WordPress, et de ce fait un certain nombre de plug-ins provoquent des erreurs dans TinyMCE. (particulièrement les formulaires de contact)

Les thèmes et WordPress Mu

Que du bonheur.

Ils sont quasiment tous compatibles… il faudra juste prévoir l’ajout d’un lien vers l’accueil de la plateforme… et vérifier qu’ils sont compatible WordPress 2.1 comme d’habitude ^^

Conclusion

WordPress Mu est une excellente base pour monter une plateforme de blogs. Mais attention, WordPress Mu permet juste de créer des blogs à la volée. Le reste sera à développer, adapter.

Si vous souhaitez davantage d’informations sur WordPress Mu, le développement autour de ce dernier, les fonctionnalités possibles avec, n’hésitez pas à me contacter.

• Ce truc ?
• Oui ce truc !

Je sais ! C’est sombre. C’est bizarre. C’est déroutant.

C’est le but.

J’en avais marre d’utiliser des thèmes existants.

Et bien qu’un grand nombre d’entre eux soit réussi, ils ont tous un défaut de taille… Vous n’êtes pas le seul à l’utiliser…

Vos visiteurs, lorsqu’ils consultent votre blog, associent naturellement la chartre graphique à l’adresse internet, le nom du blog, la thématique de ce dernier. Avec un thème comme K2, il est impossible d’associer quoi que ce soit ! (vu que plus de 5000 personnes l’utilisent !)

D’où la réalisation de ce thème from scratch (de zéro) !

Toutefois, il n’est pas finalisé à 100%, des améliorations restent à venir. (surtout l’intégration de plug-ins tiers)

Alors convaincu par le thème ? oui ? non ? et pourquoi ?

Alors comme tout le monde, je vais donne mon avis sur WordPressMu.

C’est quoi WordPress Mu ?

Très longtemps en version alpha, Automattic, maison mère de WordPress and Co, a publié fin 2006, la version multi utilisateurs de l’outil de blog WordPress.

Jusque la rien de révolutionnaire dans le monde des CMS !

Sauf, que peu de temps après ce passage en version 1, la plateforme de blog de LeMonde.fr quitte la solution propriétaire et payante TypePad pour WPmu. (Sans aucune critique quant au logiciel même)

Et la c’est le buzz de fin d’année 2006, tout le monde parle de WordPressMu, tout le monde l’installe (en local), tout le monde installe 3 blogs et dit que c’est trop bien !

…

Si ca pouvait être vrai…

Et bah moi je ne pense pas que c’est trop bien, je pense même que c’est plutôt nul. Explications…

Politique de WordPress.org / Automattic

Vous l’aurez remarqué, très peu de communication officielle autour de WPmu, un site officiel très succinct, pas de communication particulière d’Automattic envers WPmu.

Bref un vide intergalactique autour de WPmu de la part d’Automattic.

Du style, « bon les gars, on release la version 1 de WPmu, mais faites y pas attention… »

Et bah ils ont tout faux. Pleins de blogs en parlent, à tort et à travers la plupart du temps, et finalement WordPressMu se présente comme une solution sympa, simple et performante pour gérer le multi blog.

Première erreur.

Les dangers et dérives

Cette philosophie (de considérer WP Mu comme un logiciel grand public, pour ce qui n’aurait pas suivi) va probablement augmenter le nombre de plateforme de blogging sur la toile.

Chouette !

Pleins d’alternatives, au méchant TypePad; Skyblog, Nrjblog et autres plateformes pour JeunZs !

Bonne nouvelle on pourrait se dire… bah pas vraiment…

Par expérience personnelle, et de part ce que je lis sur le forum de WordPress France, je vois débarquer plein de boyscouts, posant plein de questions sur WordPressMu. Courageux de leur part n’est ce pas ?

Mais ce qui me désole… c’est que pour la grande majorité d’entre eux… PHP, XHTML, MySQL sont des sciences obscures…

C’est un peu le même concept que la philosophie pour les terminales S…

Bref, des néophytes suivants la mode et souhaitant installés des WordPressMu à toutes les sauces, sur n’importe quel hébergeurs, et même chez Free.fr !!! (Mon cœur est fragile bordel !)

Tout ca pour dire, que le fait de ne pas communiquer intelligemment autour de WordPressMu va donner naissance à un certain nombre de nouvelle plateforme inutile et dont la seule originalité viendra du nom de domaine… et pour couronner le tout ces plateformes seront administrées par des boyscouts du WEB!

Hors j’estime qu’une nouvelle plateforme se justifie pour 2 raisons principalement :

• Idées novatrices, réel valeur ajoutée. (comme le podcasting l’a été pour Podemus)
• Besoin spécifiques, créer des blogs pour une communauté X tels que les abonnés d’un club, ou autres…

Et peu importe la raison finalement, des connaissances en WordPress, PHP, XHTML, MySQL sont INDISPENSABLES !

Je vais reprendre l’image que j’avais formulé sur le forum de WP: Fr.

Si on compare WordPress à WordPressMu

• WordPress c’est un vélo, la maintenance est facile, on peut le bidouiller sans trop de problème, et si on le plante, tant pis pour soit.
• WordPressMu c’est un Boeing 777, la maintenance est lourde, le bidouillage est proscrit, et si on le plante, on emmène 300 passagers avec soit.

Deuxième erreur.

Une architecture à revoir

D’un point de vue technique WordPressMu est un contre sens même.

Pourquoi ?

WordPressMu n’a pas été conçu et développé à l’origine pour gérer le multi blog.

WordPressMu n’est qu’une enveloppe de WordPress. (c’est le site officiel qui le dit!)

Et comme vous pouvez vous en douter, on ne développe pas une application grand public comme WordPress, comme une application professionnelle de grande envergure qu’est WordPressMu.

Hors…

WordPress est un logiciel qui se veut très très très grand public (et j’insiste), développé de façon à être compatible avec un maximum d’hébergeurs, au détriment des performances.

• Compatibilité avec MySQL3.23, ce qui veut dire absence des sous requêtes
• Développement PHP4 classique non orienté objet.
• Code peu flexible

Bref !

On utilise un script développé pour le très grand public, modifié pour l’occasion, sur des plateformes professionnelles visant à héberger 200, 1000 voir 10 000 blogs!

Très amateur la solution de plateforme… (En fait les grosses plateformes rencontrent des problèmes de montées en charge comparé aux solutions alternatives, le développement d’un système de cache est régulièrement cité par les équipes de dev… on l’attend… fermement…)

Troisième erreur.

Mais alors c’est quoi les avantages de WordPressMu ?

1. C’est libre. chacun peut modifier le code sources dans le but de l’optimiser, ajouter des fonctions et pourquoi pas les partager à la communauté.
2. WPmu fonctionne avec les thèmes de WordPress. Soit plus de 1100 thèmes.
3. WordPressMu fonctionne avec une partie des plugins de WordPress.
4. C’est un produit jeune, espérons que les prochaines versions apporteront des changements significatifs !

Et WordPress.com et leurs 600 000 blogs, ils font comment ?

1. Il dispose d’une très grosse architecture matérielle, on parle de cluster de serveurs.
2. Ils utilisent une version WPmu largement modifié
3. Ils ont dans leur équipe, les développeurs de WPmu, c’est plus simple de modifier une application lorsqu’on connait le code par cœur ;)

Conclusion

1. Arrêter de rêver, vous ne deviendrez pas riche en lançant votre plateforme de blog ! (sauf si elle possède des fonctions uniques et novatrices !!!)
2. Si vous ne disposez pas de compétences en développement, faites appel à des professionnels… (le formulaire de contact de WP Francophone, vous permettra d’être mis en relation avec des prestataires spécialisés WPmu et WP.)
3. Si vous souhaitez mettre en place 5-6 blogs pour vous et vos amis, installer des versions de WordPress indépendantes ! (le temps d’installation initial sera plus long mais au final vous y gagnerez en souplesse !)

Pour conclure, disons que WordPressMu ne dispose pas de concurrent libre, de ce fait l’utiliser n’est pas une aberration, mais alors dans ce cas, il faut y mettre les moyens, une équipe de développeurs n’étant pas de trop… (À l’image de lemonde.fr par exemple)

PS : Je n’ai rien contre les scouts…

PPS : Ceci est une réflexion strictement personnelle, et ne reflète nullement celui de mon agence web et de WordPress Francophone.

Pour la 2e fois depuis la création du site, WordPress France Francophone, organise une rencontre entre blogueurs, staff, passionnés et curieux, ce samedi 16 décembre.

Pour reprendre les mots de Matthieu, ça ne sera pas une rencontre, où l’on parlera technique, PHP, MySQL, thèmes, plugins, mais simplement une rencontre entre blogueur, et qui plus est blogueur WordPressien. (ou futur…)

Bref un moment sympathique… (les personnes venues à la 1re rencontre, ne pourront que confirmer mes propos…)

Pour plus d’informations (lieu, date, heure), je vous conseille de lire le billet de Matthieu, et pour la liste des personnes inscrites, rendez-vous sur le wiki dédié à cette occasion. (A noter la présence de Michel Valdrighi, créateur de b2/Cafelog, et finalement non! ;) ) 

@samedi ;) 

Rapide compte rendu de cette 2e rencontre :

• Une petite vingtaine de personnes présentes
• Pratiquement l’ensemble des rescapés de la 1re rencontre
• Un public très divers, blogueurs, photographes, développeurs, entrepreneurs et graphistes.
• Constitution du bureau de l »association WP:Fr faite
• Des stickers Netvibes un peu partout (sur les tables, pull, tête…) (à défaut d’avoir reçu à temps les stickers WordPress :D)
• Un restaurant sympathique a 4 h du matin avec les rescapés.

Pour résumer, une excellente soirée où pas mal d’idées et de carte de visite ont fusé… J’en redemande :)

Comment afficher l’heure en français dans un thème WordPress ?

Pour cela rien de bien compliqué !

Munissez vous de votre éditeur de texte préféré (pour ceux qui ont en pas, je conseille l’excellent NotePad++ )

Dans le dossier de votre thème, éditer les fichiers suivants :

• index.php (l’accueil)
• page.php (les pages)
• archive.php (les archives)
• single.php (la vue article unique)
• theloop.php (pour les thèmes ayant comme base K2)
• comments.php (les commentaires)

Repérer la fonction PHP suivante :

<?php the_time(‘F jS, Y’) ?>

Le contenu des parenthèses peur être légèrement différent selon les thèmes.

Produira :

October 1st, 2006

Et remplacez la par :

<?php the_time(‘j F Y’) ?>

Produira par exemple :

1 octobre 2006

De la même façon… si vous souhaitez ajouter la date au format 24H et non 12H

<?php the_time(‘G:i’) ?>

Produira par exemple :

22:26

Si les nom des mois restent en anglais, vérifier que la langue de votre blog est bien en français, le cas échéant, consultez l’article à ce sujet sur le blog de Xavier.

Si ca ne marche toujours pas rendez vous sur le forum de support de WordPress France !

Pour plus d’infos :

• Formatting_Date_and_Time sur le codex (en anglais)
• Un article français sur l’internalisation des thèmes
• php.net/date (pour connaitre tout les formats de date !)

Retrouvez cet article sur la FAQ de WordPress Francee !

Pour remédier à ce petit inconvénient, il existe quelques thèmes pour la console d’administration, il peut s’agir dans certains cas d’un plugin à activer mais aussi d’un hack à appliquer à l’interface d’administration.

Revenons donc au but de ce billet et voici une présentation des principaux thèmes Admin existants pour WordPress 2.0.x ;)
Dans le désordre…

• Aenonfiredesign
• SpotMilk
• WP Tiger
• Wordtunes
• WordPress Shuttle (Pas encore dispo)

Aenonfiredesign
Il est disponible sous la forme d’un hack à uploader dans le dossier wp-admin. Inconvénient il faut le remettre en place à chaque mise à jour de WordPress. Pas de grand changement, juste les couleurs revues. Très réussi… (c’est mon coup de coeur :P)

SpotMilk
Thème inspiré de l’interface Aqua de MacOS… Finition assez grossière à mon goûts… Possibilité de personnaliser la page de connexion et d’enregistrement. Installation sous la forme d’un plugin. Thème dans la continuité de l’interface par défaut de WordPress.

WP Tiger
La thème Tiger est en rupture totale avec ce qu’on a put voir auparavant…
Le système d’onglet horizontal laisse place à un menu vertical… La finition est de très haute qualité… L’installation est sous la forme d’un plugin… un sans faute ou presque… Thème inspiré du monde Apple.

Wordtunes
La encore la finition est excellente… Le thèmes est en continuité avec le thème par défaut. Installation sous la forme d’un plugin.

WordPress Shuttle
Le meilleur pour la fin ?
Oui et non… Seulement à l’état de projet… WordPress Shuttle est sans conteste une réussite tant visuellement qu’au niveau fonctionnalités (d’après les aperçus…)
Cependant on ne le trouvera (du moins pour le moment) sous la forme d’un plugin… Il sera directement intègrer à WordPress… la question maintenant est de savoir sur quelle version… 2.1 ? 2.5 ? 3 ?

Compatibilités avec les navigateurs Web
Pour cela… un petit tableau !

Thème\Navigateur	Internet Explorer 5.5	Internet Explorer 6	Firefox 1.x	Mozilla 1.x	Opera 8.x	Safari 1.x
Aenonfiredesign
SpotMilk
WP Tiger
Wordtunes
WordPress Shuttle

Maintenant à vous de choisir ;)

• CV mis à jour + version online
• Galerie photo en ligne
• Section WordPress réparé… 2 thèmes en plus
• Formulaire de contact fonctionnel
• TAGS mis en place sur le blog

C’est à peu prêt tout ;)