Retour sur le WordCamp Paris 2011
26 mai 2011 4 commentairesLa liste des ateliers cette année était encore pléthorique ainsi que l’atteste cette photo de Johnatan [1]. N’étant pas encore doté du don d’ubiquité, je n’ai pour ma part pu assister qu’à 4 ateliers. Retour sur lesdits ateliers.
Optimisation WordPress
L’optimisation de votre site sous WordPress dépend de 2 facteurs : le code de votre thème et de vos plugins et la configuration de votre serveur web. L’un ne va pas sans l’autre : vous pourrez avoir un serveur survitaminé avec proxy varnish, CDN et tout le toutim, si le code de votre thème est mauvais lourd et pesant, ça ne servira à rien.
Optimisez votre thème
- limitez le nombre de requêtes à votre base et utilisez la fonction get_num_queries pour connaître le nombre de requêtes générées par votre thème
- passez la constante wp_debug à true dans votre fichier de wp-config
- limitez les appels externes types images ou flux rss ou mettez-les en cache avec la librairie Simple Pie par exemple (si votre serveur est une bête de course ce n’est peut-être pas le cas de celui sur lequel vous appelez un flux externe)
- limitez les appels aux images, css et js en utilisant les sprites [2] par exemple et diverses méthodes de compression
- passez les appels de scripts js en bas de page et les appeler avec la méthode wp_enqueue_script – n’oubliez pas de mettre le dernier argument in_footer à true
- éventuellement pour les puristes, activez un plugin de mise en cache de page statique type wp super cache
Boostez votre serveur
- passez sur un dédié (attention, gérer un dédié c’est se rajouter un fil à la patte, à savoir la maintenance de votre serveur)
- utilisez un CDN (content delivery network) type amazon S3 ou cacheFly
- mettez en place des solutions d’accélération http type proxy varnish
- changez ce bon vieil apache pour un serveur type nginx
Ceci dit, administrer un serveur, c’est un métier et si vous avez les mains dans WordPress, ce n’est pas le vôtre. Je ne saurais donc trop vous conseiller que de passer par un professionnel pour effectuer des optimisations côté serveur.
Thèmes enfants
Si vous travaillez souvent sur WordPress, vous avez nécessairement développé des astuces pour accélérer la création d’un thème, que ce soit un jeu de fichier vierge, un thème que vous avez développé et que vous dupliquez à chaque démarrage de projet ou n’importe quelle autre technique maligne que ces fainéants de développeurs savent mettre en oeuvre pour ne pas en ramer une. Oubliez toutes ces astuces à Deux euroballes. Il existe – depuis quelques années déjà – une méthode simple de mutualiser vos développements : les thème enfants ou child themes
.
Le principe : vous avez un thème parent avec moults fonctionnalités, des widgets, des sidebars, un fichiers function.php qui vous fait un référencement aux petits oignons, un framework css embarqué… Plutôt que de dupliquer systématiquement ce thème pour chaque projet, créez un thème enfant à partir de ce thème Le thème enfant hérite de l’ensemble des pages et fonctionnalités du thème parent. Vous pouvez en plus personnaliser la feuille de style, le single.php ou n’importe quel autre fichier de votre thème. Ainsi vous n’avez plus qu’à maintenir un thème unique auquel vous pouvez apporter des améliorations régulièrement, améliorations qui impactent tous les thèmes enfants qui utiliseront ce thème, à la manière d’un framework. D’ailleurs de nombreux thèmes spéciaux ont vu le jour dans la communauté WordPress depuis l’apparition des thèmes enfant : les thèmes framework.
Lors de l’utilisation d’un thème enfant, WordPress charge d’abord le fichier function.php du thème enfant avant celui du thème parent. Il en va de même pour la feuille de style et tous les fichiers du thème. Attention dès lors à ne pas surdéfinir vos fonctions dans le thème enfant. Normalement un thème WordPress bien réalisé doit comporter dans son fichier function.php avant chaque déclaration de fonction un if(!function_exists(‘…’)
if(!function_exists('bar')) {
function bar() {
...
}
}
Évidemment en terme de performance, l’utilisation d’un couple thème parent – thème enfant est moins optimisée que l’utilisation d’un thème unique. Ne paniquez pas pour autant, la perte de performance est minime et le gain en terme de temps de développement est vraiment important.
WordPress dans la presse
Atelier inégal. On y a parlé de l’utilisation de WordPress pour un site de news. Tom de Owni – l’un des généreux sponsors de l’événement – avait évidemment des choses à dire. Il nous a parlé de ce qui se passe dans la soucoupe, de la formation et de l’échange continue entre journalistes graphistes et développeurs, des projets en cours de owni dans le monde de la presse, de la façon dont l’outil influe sur les idées des rédacteurs… Plutôt intéressant.
Pourtant, je suis assez sceptique quant au fait qu’un CMS soit mieux foutu qu’un autre pour les sites de presse. Aujourd’hui Drupal a le vent en poupe notamment grâce à (ou à cause de 😉 Rue89 qui l’a adopté lors de son lancement et qui avait fait à l’époque pas mal de bruit sur ses choix technologiques, Mediapart leur a ensuite adopté le pas, puis le Figaro s’y est mis. Côté WordPress, le groupe Moniteur migre ses sites vers WordPress, les inRocks sont entrain de faire de même. Je ne crois donc pas qu’il y ait UN CMS idéal pour les sites de presse. comme n’importe quel projet, cela dépend des besoins, du périmètre fonctionnel, du budget (et oui ! ). Et sur la presse précisément, je suis très sceptique quant au fait de dire que l’outil fait le média. A mon sens c’est plus la façon de l’implémenter et de l’utiliser. La technologie est toujours secondaire. Ceci dit si on parle d’adoption, WordPress en mode out of the box est 100 fois plus séduisant pour les utilisateurs que Drupal qui lui, plaît plus aux développeurs psycho rigides purs et durs. WordPress c’est le fun, Drupal c’est la rigueur. Chacun son truc.
Migration WordPress
Un atelier… un peu désert. J’avoue, c’est moi qui ait proposé ce sujet qui n’a malheureusement pas passionné les foules. J’ai lancé ce sujet pour deux raisons :
- en 15 ans de carrière, j’en ai migré des sites mon pti’ gars
- et je peux te dire mon gars que je vais encore en migrer des sites et plus tôt que tu ne le crois
En effet, figure toi ami lecteur, et je boucle avec le sujet ci-dessus, même si je pense que ce n’est pas la techno qui fait le site, j’avoue quand même que celle-ci facilite (ou pas) l’évolution de celui-là. Chez Reporters sans frontières, je le vis tous les jours. Notre site tourne sous Spip – ça marche évidemment – mais la communauté Spip est assez restreinte comparée à celle de WordPress. Qui dit petite communauté dit peu de plugins et c’est là le problème principal. Lorsque je dois rajouter une fonctionnalité à rsf.org, je trouve rarement le plugin adapté. Résultat – je suis obligé de le développer moi même. Vu l’équipe pléthorique de dev web chez RSF, si je peux éviter, j’évite (on est 1). Pour cette raison et pour beaucoup d’autres, moi et mon équipe nous posons sérieusement la question du changement d’outil… et de la migration associée. Et ça tombe bien parce que la migration Spip vers WordPress est tout à fait réalisable.
Import basique
Sachez que WordPress est doté d’un outil d’import puissant qui vous permet de récupérer des articles à partir
- d’un blog Live Journal,
- d’un blog Movable Type
- d’un autre blog WordPress
- ou plus commun encore, à partir d’un flux RSS
Normalement, n’importe quel site codé un peu correctement est capable de sortir un flux rss. C’est le cas D’un site sous Spip par exemple. La technique consiste donc à réaliser un script / template qui sort un flux RSS de l’intégralité de vos articles. Vu que le XML est assez verbeux, il se peut que le fichier ainsi obtenu soit énorme. Donc pour l’import, scindez-le en plusieurs morceaux.
Importer des champs personnalisés
Ok me direz-vous mais comment faire pour importer mes articles et ventiler les données que je souhaite dans des champs personnalisés de WordPres ? Hein gros malin ? Comment tu vas faire ça ? Simple comme tout jeune punk, il te suffit de regarder la structure d’un fichier d’export WordPress et de reproduire la structure xml dans ton fichier d’export àl’aide d’un sciprt php ou de ton langage de templating préféré.
Importer un gros volume de données
Ok, c’est bien gentil, mais comment je fais moi pour importer 30 000 articles dans WordPress ? Je vais quand même pas faire 300 imports de fichiers xml ? Meuh non gros malin. Si le volume de données à importer est trop important (plus de 2000 articles), la méthode d’import par fichier xml n’est plus adapté. Il vaut mieux dès lors utiliser la fonction wp_insert_post. Et là où le monde est bien fait, c’est que cette fonction retourne en cas de succès l’id du post inséré, ce qui nous permet ensuite de manipuler ledit post avec la fonction add_post_meta pour lui ajouter des champs personnalisés par exemple. Là on est déjà moins dans la bidouille et plus dans le développement, il faut tester, retester, re re tester, enregister les erreurs dans un fichier log et prévoir des fonctions de fallback en cas d’échec d’insertion de post. Développer quoi.
Redirections d’urls
Enfin, dans le cadre d’une migration, si votre site est un peu référencé dans les moteurs de recherche (ce qui est le cas de TOUS les sites), il faut prévoir la création d’un fichier htaccess qui redirigera les anciennes urls vers les nouvelles, afin de ne pas perdre votre référencement Pensez lors de l’import dans WordPress à enregistrer l’url de chaque article dans un champs personnalisé. Ainsi il vous sera facile de sortir les règles de redirections à insérer dans vorter fichier acess sur le modèle :
Redirect permanent /ancienne_url.php?meme_que_je_mets_des_parametre_comme_en=1990 /nouvelle_url_toute_propre/
et oui, un htaccess, ce n’est jamais que du texte.
Le débat (ridicule) de fin
Les membres de WordPress francophones et organisateur du WordCamp Paris ont organisé un débat de fin de journée afin de clore ce WordCamp en beauté. Premier sujet abordé: la polémique lancée par 4h18 sur le côté politburo de WordPress Francophone, tellement ridicule que j’ai préféré partir. Vraiment pas grand chose à dire là-dessus sinon que les membres de l’asso wordpress-fr ont été assez sympa pour organiser un débat sur le sujet et donner la parole à ceux qui trouvaient que l’association et le site étaient trop fermés. A mon sens ils n’ont de compte à rendre à personne sauf aux membres de leur asso. Moi perso j’aurais envoyé baladé. Donc un grand bravo les gars pour votre réaction intelligente et pour ce beau WordCamp.
- Jonhatan que je remercie au passage car il m’a gentiment donné la permission de l’utiliser
- ou mieux : les CSS 3
suis déçu ! je suis passé à coté de cet évènement wordpress francophone (comme l’année dernière) ! J’aurais moi aussi bien échangé et écouté cette communauté francophone spécialisée pas si immense que ça : il n’y a qu’à voir les nombreuses questions sans réponses sur les forums officiels dés que l’on entre un peu dans le code ou sur des poblématiques un peu poussé ! c’était à la Canitne ?
Suis tellement désolé de ne pas avoir pu discuter avec toi… Et dire qu’en plus j’ai dû me sauver après le WordCamp… :-/ J’espère qu’on aura l’occasion de se reparler très prochainement. Merci pour cet article qui est bien plus qu’un simple « Retour sur… » mais une vrai mine d’infos intéressantes !
[…] jours après, nous avons toujours des retours sur cet événement. Cette fois, c’est Barbablog qui nous livre un retour très enrichissant et […]
Salut Grégoire,
Merci pour l’article!
Je vais bientôt devoir migrer un spip -> wordpress et je me demandais si tu avais expérimenté plus en profondeur ?
Merci de m’en dire plus si c’est le cas 😉
ps: +1 pour le design de ton blog.