La communauté francophone autour de WordPress et WordPress Mu
Je reviens vers vous sur la question des frameworks CSS suite à la lecture de A Reflexion About Semantic Grids qui défend grosso modo le point de vue selon lequel les frameworks ne sont pas sémantiques et incitent à marcher sur la tête en bousculant le flux de production web.
A première vue, les classes ajoutées au code HTML par les déclarations présentes dans les bibliothèques CSS sont essentiellement destinées à la présentation. Un peu comme si l’on mettait une classe .rouge pour afficher en rouge ce qui est important dans le texte, alors que tout le monde sait que .red, étant plus court, est bien plus approprié ^_^v (je suppose ici que les professionnels du web seront sensibles à l’ironie ; je ne suis pas inquiet pour les autres !).
Ensuite, à cause des frameworks CSS, l’intégrateur serait obligé de commencer par la feuille de style au lieu de baliser correctement son contenu avec du HTML bon CHIC (Code Html Intrinsèquement Classe) bon genre.
Je ne suis pas vraiment convaincu par ces arguments car la sémantique ne se réduit pas à la place des opérations à accomplir dans le flux de production web : à partir du moment où l’on connait le pas de la grille, il n’y a aucune raison de ne pas générer le fichier grid.css qui va bien. D’autant plus que cette grille ne devrait avoir aucune influence sur la qualité du code HTML à venir, si justement, l’intégrateur ou le webdesigner a pris soin de séparer le fond de la forme en amont.
Mais surtout, à part quelques frameworks qui nécessitent jusqu’à trois classes — voire plus — pour placer un bloc (ce qui commence à manquer de factorisation), la suite des .span-x peut se comprendre comme l’importance accordées à chaque bloc : du moins important (.span-1) au plus important (.span-24), à l’image de la presse écrite où un article surmonté d’un titre en 8 colonnes à Une mérite plus d’attention qu’un entrefilet sur 2 colonnes.
C’est dans cet esprit que je préfère un .span-x à un .grid-x, d’autant plus qu’il existe déjà un élément span en HTML.
J’aime bien tester rapidement différentes déclinaisons d’une charte graphique avec les frameworks. En effet, dès que le fichier grid.css (ou layout.css, maquette.css, etc.) est en place, on peut déplacer les blocs de contenus très rapidement : l’Édito sur 6 ou 8 colonnes ? Le Sticky Post, avec une marge à gauche ou à droite ? etc.
Quand les choix sont validés, je refais la partie layout de mon fichier styles.css avec les éléments utilisés réellement tout en gardant grid.css sous le co(u)de prêt à servir avec une règle @import entre commentaires.
Par exemple, pour tester ma grille, j’ai tendance à utiliser :
<div id="sticky-post" class="clearfix span-8 last"></div>
Et en production :
<div id="sticky-post"></div>
Avec :
#sticky-post {
width: 310px;
float: left;
margin-right: 0;
overflow: hidden; /* avec #sticky-post { zoom: 1 } dans le fichier ie.css */
}
Et ainsi de suite avec tous les éléments de la page. C’est un peu fastidieux, mais au final — et pour peu que vous réunissiez toutes vos CSS dans un fichier unique bien commenté — votre code HTML et votre feuille de style CSS y gagneront en lisibilité et surtout en légèreté.
La nouvelle version de Wordpress intégre quelques nouveautés dans l'interface qui peuvent être énervante. En écrivant cela je pense à la mise en forme du code dans l'éditeur de thème ou de plugin qui reconnait automatiquement le type de langage utilisé et qui de ce fait applique un style de mise en forme.
Depuis la mise à jour vers la version 2.8 de wordpress j'ai à plusieurs moment du modifier du code sur les blogs et comme je ne suis pas codeur j'y vais par interpolation et à cause de cet éditeur j'ai perdu quelques bouts de pages (notamment celle de la sidebar). Alors plutôt que de ne plus utiliser l'éditeur de thème en ligne (ce qui pourrait être une solution) j'ai fait des petites recherches et pour virer cette mise en forme (qui ralenti l'affichage de la page par ailleurs), il suffit d'aller dans >Appearance>Editor puis de cliquer sur Screen Options en haut à droite et de cliquer sur "Disable syntax highlighting" et voila plus de mise en forme!
L'éditeur de texte avec la mise en forme de la syntaxe
Sans la mise en forme
Notez qu'une désactivation dans l'éditeur de thème, désactivera l'option dans l'éditeur de plugins aussi... Pour réactiver l'option il suffit de faire le process inverse.
Copyright © 2005-2009 2803 MEDIA
Enlever la mise en forme de la syntaxe dans l’éditeur de thème de Wordpress
Encore quelques ajustements dans l’interface d’adminisration, des améliorations des performances et de l’intégration à WordPress ; cette release candidate 3 sera la dernière avant la version finale 1.0.
L’équipe de BuddyPress, le moteur de réseau social pour WordPress Mu, vient de mettre en ligne la roadmap de ce projet. Celle-ci nous donne une bonne idée de ce qu’on pourra s’attendre à voir dans les prochaines versions.
Quelques jours après la version 2.8, la première mise à jour mineure pointe le bout de son nez… ou du moins sa première ébauche. Pour corriger des petits bugs découverts depuis la sortie de la mise à jour majeure, l’équipe de développeur nous met à disposition une version beta 1. Plus d’explications par Amaury et en français.
C’est la question que Mark Ghosh de WebLog Tools Collection nous pose. Dites nous où vous vous situez. C’est marrant.
Ce n’est pas la première fois que je vous en parle mais les champs personnalisés de WordPress sont vraiment puissant. En voilant encore une preuve toute en explication.
Le spam est la grande plaie des blogs, par exemple Blog Tool Box reçoit chaque jour une centaine de spams, Akismet, qui est l’un des meilleurs antispams de blog, bloque quotidiennement plus de 10 millions de spams.
Voici quelques techniques pour combattre efficacement le spam sur votre blog.
1. Réglages de WordPress
Il existe quelques petites options très simples dans WordPress qui permettent de limiter le spam.
Dans Réglages > Discussion, vous pouvez tout d’abord définir deux règles simples avant la publication d’un commentaire : “un administrateur doit toujours approuver le commentaire” et “l’auteur d’un commentaire doit avoir déjà publié un commentaire approuvé”. La première règle devient rapidement fastidieuse et ingérable au fur et à mesure que votre blog gagne en popularité ; la seconde, en revanche, se révèle relativement efficace.
Les spams sont généralement plus présents sur les anciens articles, si vous pensez que fermer les commentaires sur ceux-ci ne gênera pas vos lecteurs, vous pouvez les fermer pour les articles de plus de X jours depuis WordPress.
2. Antispam
L’installation d’un antispam est définitivement la solution la plus efficace et la plus simple pour protéger son blog. WordPress intègre par défaut Akismet, l’un des antispams les plus efficaces capable de stopper avec beaucoup de précision les spams de commentaires et de trackbacks. Les spams stoppés par Akismet se retrouvent dans une file d’attente dédiée ce qui rend leurs suppressions beaucoup plus facile.
Akismet nécessite une clé pour fonctionner, vous pouvez en obtenir une en enregistrant un compte gratuit sur WordPress.com.
Si vous ne souhaitez pas utiliser Akismet, il existe d’autres antispams tout aussi efficaces comme Defensio, WP-SpamFree ou TypePad Antispam (qui fonctionne sur les plateformes Movable Type et WordPress).
Il existe également des plugins dédiés uniquement au spam par trackback comme Simple Trackback Validation qui vérifie si l’IP de l’envoyeur est bien identique à l’IP du serveur dont le trackback se réfère.
Par ailleurs, certains antispams peuvent être combinés et sont capables de fonctionner en parallèle pour une meilleure efficacité.
3. Autres techniques
Vous pouvez empêcher l’accès à votre blog à certaines adresses IP via un fichier .htaccess mais cette technique se révèle relativement peu efficace car les spammeurs ont souvent des milliers d’adresses IP différentes. En revanche, cela peut être une bonne idée pour bannir un commentateur un peu trop pénible (en plus de la liste noire dans les options de discussion de WordPress).
Les systèmes de CAPTCHA ou de questions (”Combien font 1+3 ?”, etc) bien que efficaces sont très pénibles pour les lecteurs… A éviter pour les commentaires mais préconisés pour les formulaires de contact.
Pour WordPress, vous pouvez aussi renommer le fichier wp-comment-post.php en wp-comment-post-spam.php par exemple. Il faudra également mettre à jour le fichier comments.php de votre thème avec le nouveau nom pour que les commentaires fonctionnent à nouveau.
Il existe bien d’autres techniques pour se protéger du spam, mais, dans la grande majorité des cas, un simple antispam comme Akismet mettra votre blog à l’abri de ce fléau. Et vous ? Comment gérez vous les spams sur votre blog ?
Pas de vacances pour les développeurs de WordPress… à peine la version 2.8 sortie, que les voilà déjà à travailler sur la prochaine mise à jour mineure de notre outil préféré de publication !
Eh oui, comme dans tout projet informatique, on trouve toujours des bugs une fois l’application publiée, et WordPress n’échappent pas à la règle avec la préparation de la version 2.8.1.
Cette dernière est déjà disponible en bêta 1, elle corrige plusieurs bugs dont : (pour le moment, la liste grandit avec le temps)
Bref, on trouve ici des corrections mineures touchant un faible pourcentage des installations WordPress, donc pas besoin de se presser sur cette bêta si tout fonctionne bien chez vous 
Pour télécharger la version bêta depuis l’outil de mise à jour automatique, vous pouvez consulter la page suivante (en anglais).
Wordpress est certes une plateforme de blog mais aussi un très bon outil pour les CMS (Content Management Systems) et dans une utilisation de ce type l'architecture du site, donc des catégories peut être un peu complexe. J'ai eu le cas sur le site sur les hôtels design, je souhaitais utiliser les noms de pays comme nom de catégorie, à partir du moment où c'était moi qui gérait la mise en ligne des hôtels cela n'était pas problématique car chaque nouvelle intégration pouvait nécessiter au besoin la création d'une nouvelle catégorie.
Mais depuis quelques temps le site est ouvert aux contributions et propositions des visiteurs, l'écriture des articles sur les hôtels se fait par le biais d'un formulaire, j'ai donc besoin dans ce cas d'avoir tous les pays comme catégorie... Alors plutôt que de renseigner les 195 pays j'ai utilisé un plugin qui a fait le travail à ma place. Post Corrector est l'outil adapté pour cette opération car une fois installé vous allez pouvoir intégrer industriellement des noms de catégories simplement en copiant/collant leur nom dans la boite de dialogue.
Une catégorie par ligne...
Un petit outil qui vous fera peut être gagner du temps...
Copyright © 2005-2009 2803 MEDIA
Générer automatiquement des catégories Wordpress à partir d’un fichier texte
Depuis la version 2.6 de WordPress, la fonction Post Revisions permet de conserver les versions successives d’un billet. C’est pratique mais à la longue, c’est encombrant. Je n’ai fait appel à cette fonction qu’une ou deux fois et comme j’ai tendance à modifier mes billets assez souvent (j’utilise le bouton Save Draft en cours de rédaction ou Update Post lors des corrections ultérieures), en quelques mois, j’ai eu jusqu’à 113 Post Revisions pour un total de 320 billets… Il est temps de faire le ménage !
Mais avant de modifier la base de données, je vous conseille d’en faire un backup. Pour cela, plusieurs solutions s’offrent à vous :
wp_comments et d’exclure les Post Revisions de la table wp-posts. Dans le même genre, wp-dbmanager offre un menu étoffé pour effectuer des opérations de maintenance de votre base de données sans quitter WordPress !mysql -h host -u user -ppass base_de_donnees > fichier_dump — Plus d’information sur aidenet.Une fois la BDD à l’abrit, faites intervenir l’excellent Delete-Revision commis par gohsy. Ce plugin va simplement dégraisser la base de données et lui redonner une deuxième jeunesse en supprimant toutes les révisions redondantes. Comme ça, d’un seul clic. Je l’ai mis en place sur ce blog et tout à l’air de fonctionner correctement.
Il est possible de se prémunir une fois pour toutes de ces révisions intempestives en ajoutant une constante dans le fichier wp-config.php situé à la racine du blog :
define('WP_POST_REVISIONS', false);
Et en la plaçant juste avant le commentaire :
/* That's all, stop editing! Happy blogging. */
Dans le même esprit, il est possible de ne conserver qu’un nombre définit de révisions avec la ligne (ici 3) :
define('WP_POST_REVISIONS', 3);
Si vous n’avez pas ajouté WP_POST_REVISIONS dès l’installation de votre blog, il faudra supprimer les révisions existantes. Pour cela, cette requête SQL — à copier-coller dans le champs phpMyAdmin qui va bien — est votre amie :
DELETE FROM wp_posts WHERE post_type = 'revision';
Plus d’information sur Comment désactiver le suivi des versions sous Wordpress 2.6 chez Korben et Malaiac qui nous offre une page consacrée à l’optimisation pour WordPress.
Supprimer les Post Revisions, c’est bien, mais pourquoi s’arrêter en si bon chemin alors que le réseau regorge de liens plus intéressants les uns que les autres ?
Profitons-en pour profiler notre outil de blog comme une voiture de course :
Je suis encore tout esbaudis par la découverte de 45+ frameworks CSS que tout webdesigner devrait connaitre qui liste une palanquée de bibliothèques CSS et d’outils pour générer des grilles de mise en page sans douleur. Je ne reviendrais pas sur les avantages ou les inconvénients des frameworks CSS ni sur le choix du meilleur d’entre eux. Vous trouverez des éléments de réponse dans : Frameworks CSS + Reset CSS : design from scratch paru initialement en anglais sur Smashing Magazine ; dans Développement efficace avec les frameworks CSS et Blueprint ; ou encore dans Blueprint, un framework pour webdesigner. Oui, beaucoup de Blueprint car c’est le seul que j’ai vraiment utilisé jusqu’à présent.
Grosso modo, tout le monde reconnait que oui, les frameworks c’est de la balle mais que non, ça n’est pas toujours possible car les éléments du design, du .psd, de la charte graphique, etc. n’entrent pas forcément dans une grille horizontale.
Travailler avec une grille de mise en pages est très courant dans le print : j’ai pris l’habitude de travailler en fonction d’un format de papier, de marges, de colonnes et de gouttières ainsi qu’avec l’option Aligner sur la grille du logiciel QuarkXPress.
Pour beaucoup de webdesigners en revanche, les grilles semblent vécues comme une contrainte au lieu de servir de guide. Comme le dit si bien André Gide, l’art nait de contraintes, vit de luttes et meurt de liberté. Ce qu’on pourrait traduire librement par : sans contrainte, l’art n’est rien ou encore par trop de liberté, nuit.
Faut-il pour autant commencer la conception du design avec une grille devant les yeux ? Je ne le pense pas. Les premières recherches graphiques et les premiers placements de blocs devraient s’effectuer librement, à l’instint. C’est lorsque le résultat ressemble à quelque chose, qu’il est temps de déterminer le “pas” de la grille.
Pour des raisons de simplification et d’arrondi, la plupart des frameworks CSS proposent des grilles se limitant à des largeurs de 960 ou 950 pixels en 12, 16 ou 24 colonnes. Dans ces conditions, il est probable que le plus petit élément de ces grilles ne conviendront pas à vos besoins.
Pour définir une grille qui sorte des sentiers battus, il faut rassembler le maximum d’information sur votre contenu et le temps que vous êtes prêt à passer pour le préparer. Par exemple, si vous voulez afficher rapidement des vidéos Youtube dans votre sidebar, assurez-vous que sa largeur soit au moins égale à la largeur par défaut des vidéos, soit 425 pixels ! C’est pareil pour tout les éléments qui possèdent une taille fixée à l’avance, comme les Gravatars, les présentations Slideshare, les publicités, etc.
Et oui, il n’est pas nécessaire d’utiliser un framework CSS pour profiter des avantages qu’il procure. Dès que vous aurez déterminé le nombre de colonnes et la largeur de la gouttière en fonction de la largeur totale de votre design, vous aurez fait la moitié du chemin. L’autre moitié est composée du choix des balises HTML pour le contenu et le placement des blocs principaux (content, sidebars, header, footer, etc.).
Factoriser les déclarations CSS avec des classes plus ou moins sémantiques dans le code HTML ou multiplier les float:left et autres margin-right n’est pas le plus important et en ce qui concerne la partie purement layout. Il y a rarement des pixels à gagner avec l’une ou l’autre des solutions car les octets économisés par la factorisation sont souvent dépensés par les span-x et autres append-x ou prepend-x inutilisés : toutes les combinaisons d’une grille ne sont pas de la partie, et heureusement !
Les frameworks, c’est de la balle, mais il est important de s’éloigner des formats proposés pour suivre sa propre voie car si les solutions proposées par Blueprint ou 960.gs et consorts peuvent généralement prétendre au statut de standard, le risque est justement de standardiser sa production graphique pour la faire entrer dans le moule ! Gardez à l’esprit qu’une différence — même minime — dans les proportions d’un design peuvent changer radicalement la perception qu’on peut en avoir.
.dp50 {width:50%; float:left; display: inline; *margin-right:-1px; } Etonnant, non ?em qu’avec des % et s’accommode de largeur fixes ou fluides pour un poids de 4Kb pour la version compressée. Nombreuses démonstrations disponibles pour voir ce qu’il est possible de faire.
Semaine calme du coté de WordPress, deux petites news pour vous :
Un mois après la RC1, on se rapproche de la version finale 1.0 du système de forum bbPress avec la sortie de la Release Candidate 2. Annoncée comme suffisamment stable, cette version peut être utilisée en production.
Matt Mullenweg est interviewé par Veronica Belmont dans le show Tekzilla. Ça parle thèmes et templates, application iPhone et petites choses à venir chez WordPress.
J’ai profité du week-end pour mettre à jour ma version de Wordpress et passer à la dernière, à savoir la 2.8. Je n’ai pas trop respecté les consignes d’usage que je me fixe d’habitude et qui sont « regarde sur Google si ceux qui ont fait l’upgrade ont morflé ou pas» . J’y suis donc allé à l’instinct et j’ai tout d’abord pensé que tout fonctionnait à merveille.
Sauf qu’une fois que j’ai voulu rédiger un article je me suis rendu compte que mon éditeur visuel avait disparu. Pas insurmontable comme problème mais assez perturbant quand on est habitué à s’en servir (alors qu’au début du blog je ne l’utilisais quasi jamais, je ne me servait que de l’éditeur HTML).
Une demande via Twitter et Facebook m’a confirmé que je n’étais pas le seul dans le cas et selon ce que j’ai vu sur le forum Wordpress francophone ça n’a que confirmé l’idée (voir cette discussion, celle-ci et celle-là). Puisqu’aucune réponse n’a été apportée j’ai donc cherché un peu dans mon coin. Alors comme d’habitude n’étant pas un énorme pro en terme de bidouillage dev où de trifouillage de neurones techniques, j’ai fais ça au pif en fonction de ce qui me semblait logique et j’ai finis par retrouver mon éditeur visuel. Surement pas de manière académique mais ça marche :)
La première fois que j’ai tenté la mise à jour (qui s’est bien déroulée cela dit) je l’ai fais via le plugin Wordpress Automatic Update que j’utilise avec succès depuis plusieurs mois. Tout s’est bien passé mais pas d’éditeur visuel, pareil après un second essai.
Le second test est forcément celui via le FTP. Après avoir lu qu’il était possible que le soucis provienne d’une incompatibilité de langue (mettre une version FR sur une version anglaise ou l’inverse), je télécharge la dernière version francophone et je la balance sur mon client FTP.
Pareil, pas de changement.
En y regardant de plus près j’ai pu voir que certains fichiers ne remplaçaient pas ceux déjà présent sur mon hébergement. Ils se situent dans les dossiers /wp-admin et /wp-includes
Puisqu’il n’y avait toujours pas de changement dans mon interface je me suis dit que j’allais virer les fichiers « irremplaçables» à la main pour remettre les nouveaux à la place, donc pas juste les jeter sur l’hébergement tel quel mais les supprimer complètement et les ré-uplaoder. Au fur et à mesure rien n’a changé sauf lorsque j’ai remplacé de cette manière tous les fichiers avec un .dev. du dossier /wp-admin/js/
C’est la que j’ai vidé le cache et que mon éditeur visuel est réapparut comme par magie.
Alors honnêtement j’avoue que je ne sais pas si c’est ce qui a fonctionné mais ça a marché dans mon cas. Et vu qu’il ne semble pas y avoir de réponse qui traine je me permet de laisser la mienne en espérant qu’elle serve à quelques personnes :)
C’est sur le Dator Blog, que j’ai déniché jQuery Splitter tout droit sorti de chez Dave Methvin. Ce plugin requiert la dernière version de jQuery et permet d’afficher une séparation entre deux contenus sous la forme :
L’appel de la fonction étant réduite au strict minimum :
$().ready(function(){ $(”#MySplitter”).splitter(); });
La splitbar peut être déplacée très facilement de manière accessible en cliquant-déplaçant avec la souris, avec une accessKey ou encore via la touche tab.
Tout est dans le titre :
Pour la route :: Connaissez-vous Notorious Blog ? Mon dernier blog consacré au blogging et aux blogs d’entreprise
Pour les personnes ayant migré vers la version 2.8, vous avez pu remarquer que le bloc d’avertissement de mise à jour reste afficher une fois la mise à jour faite.
En fait, Nikolay (le responsable internationalisation de WordPress) vient d’annonce sur le mailing des traducteurs qu’il y avait un petit bug lors de la génération des packs localisés et que de ce fait il manque une variable dans le fichier versions.php.
De ce fait, pour corriger le problème vous avez 2 possibilités :
Si rien ne marche, n’oubliez pas qu’il y a un temps de latence entre chaque vérification sur le serveur de WordPress.org et que le bloc d’avertissement ne disparait pas instantanément et ensuite si rien ne fonctionne, télécharger l’archive ZIP, et envoyer le fichier via le FTP (plus long, mais efficace)
Voici une courte brève pour vous annoncer la sortie de WordPress 2.8 en version française !
La version anglaise a été publiée durant la nuit, et bien que Xavier ait réalisé un énorme travail sur la traduction au fur et à mesure du développement, il restait quelques corrections et ajustements de dernières minutes !
Vous pouvez télécharger la version française depuis le site fr.wordpress.org ou bien faire la mise à jour directement depuis WordPress, mais avant de faire quoi que ce soit sur votre installation, n’oubliez pas la chose suivante :
Une mise à jour est une étape critique sur votre base de données, pour éviter toute perte de données, veuillez faire une sauvegarde complète de votre blog (base de données + fichiers) avant de faire la mise à jour. Ce conseil vaut également pour le processus de mise à jour automatique !
Un article suivra pour vous détailler les nouveautés de cette version, et peut-être même qu’un membre de la communauté francophone prendra le soin de faire le sous-titrage de la vidéo de présentation ? (Avis aux volontaires !)
PS : Pour la mise à jour automatique, vous devez à priori utiliser la version française pour éviter tout message d’erreur, dans tous les cas, en cas de message d’erreur, télécharger le ZIP français, et envoyez le contenu sur votre FTP !
Pour plus d’infos, le forum possède déjà une bonne dizaine de sujets sur WP 2.8 !
PS2 : Si vous faites une mise à jour sur la version US, il vous sera probablement demandé de faire une mise à jour vers la VF peu après
PS3 : si le message vous demandant de mettre à jour vers la 2.8, c’est normal : un système de cache fait que la prise en compte n’est pas immédiate. Patientez, ça va venir.
MISE A JOUR : il peut aussi s’agir d’un bug, lisez cet article !
PS4 : Attention, pour ceux qui croient que la RC1 est identique à la version finale, ce n’est pas le cas. Voici les différences.
L'équipe de Wordpress tient le rythme des sorties de version avec une nouvelle version aujourd'hui la 2.8. Au programme des nouveautés, beaucoup de correction de bugs (un peu moins de 800), une nouvelle gestion des thèmes (plus besoin d'aller sur le site wordpress.org), une gestion des widgets simplifiée, un accès à la documentation sur le code de wordpress, et des options de modifications de l'interface.
La vidéo ci-dessous présente les principales nouveautés :
Une version qui personnellement ne m'apportera pas grand chose de nouveau (les thèmes sont gérés à la main chez moi et je n'utilise pas les widgets) mais pour beaucoup wordpress sera plus simple à manipuler. Sinon pour les curieux la liste des nouveautés de wordpress 2.8 est disponible ici, pour télécharger wordpress 2.8 c'est là, la version française ne devrait pas tarder à arriver ici .
Copyright © 2005-2009 2803 MEDIA
Avec "seulement" une dizaine d'heure de retards, la version finale de Wordpress 2.8 est enfin disponible au téléchargement ! Cette release nommée "Baker" apporte sont lot de nouveautés, d'ailleurs voici un aperçu en vidéo :
La version Release Candidate 1 est sortie hier. Il ne s’agit pas encore de la version finale et définitive mais c’est comme si. En effet si aucun bug important n’est signalé alors la date de sortie de la version finale restera comme annoncée le mercredi 10 juin 2009. Nous sommes dons à J-2. Notons que la traduction française est d’ores et déjà prête et n’attend que vos remarques pour éventuellement s’améliorer d’ici mercredi. Vous pouvez donc l’installer sur un espace dédié aux tests afin de donner vos avis et surtout pour essayer la nouvelle mouture de votre moteur de blog préféré.
C’est ce que nous propose Henri Labarre de 2803.fr avec un tutoriel des plus détaillés. C’est clair et très simple à exécuter. Fini les champs personnalisés pour que vos illustrations d’articles ornent dorénavant aussi votre page d’accueil.
Après la sortie récente de BuddyPress 1.0, première version stable du moteur de réseau social pour WordPress Mu, le premier correctif arrive. BuddyPress passe donc en version 1.0.1 pour le bonheur des amateurs. Notez qu’une version française existe.
Les flux sont mis à jour toutes les 2 heures
Toutes les sources au format OPML