Logo MA14

Pods : la solution pour transformer WordPress en un CMS?

  • Marc Boivin
  • Mardi, 10 novembre 2009

Un argument que j’entends souvent est que WordPress n’est pas un CMS parce qu’il est centré autour de la publication d’articles de blogue. Cette approche peut créer de la confusion lorsqu’il faut gérer autre chose que des articles ou des pages. Une extension tente de faire évoluer WordPress vers un «véritable» CMS : Pods.

Pods a comme objectif premier de permettre aux utilisateurs avancés de WordPress de publier des types de contenu qui ne sont pas des articles ou des pages.

Un exemple

Jo Blo à un blogue où il parle de voiture. C’est intéressant, mais il voudrait offrir la possibilité aux usagers de parcourir toutes les voitures desquelles il a parlé. WordPress offre certains outils pour accomplir la tâche, mais il faut toujours composer avec les articles. Avec Pods, Jo peut publier des voitures sans publier d’articles ou de pages.

L’avantage de cette méthode est qu’il peut amasser des données sans polluer les articles. Il peut se faire une collection de 1000 voitures sans avoir à écrire 1000 articles avec un contenu peu attrayant du genre «Article bidon pour afficher telle voiture».

En plus de lui permettre d’emmagasiner les voitures séparément de ses articles, Pods permet à Jo de faire des listes pour que les visiteurs puissent voir les véhicules qu’il préfère. Un système de gabarits, semblable à celui de WordPress, est offert à l’utilisateur afin qu’il puisse personnaliser l’affichage des données produites par Pods.

Pods est disponible depuis un certain temps déjà. Maintenant qu’il est rendu à la version 1.7.6, je pense qu’il est assez stable pour l’incorporer dans un mandat. Voici mes conclusions après une semaine d’utilisation en tant que développeur.

Prêt pour les développeurs?

Pour les développeurs, Pods offre des outils facilitateurs. Ces outils viennent par contre avec quelques contraintes.

Pods offre une approche qui se voit dans plusieurs CMS : faites votre structure de données sans connaissance SQL et laissez Pods s’occuper du reste. Là où Pods déçoit, est au point de vue structurel. On ne peut pas, simplement, sauvegarder un pod avec du code PHP. La sauvegarde est effectuée à l’aide d’un fichier PHP complètement indépendant de tous les types de pods et il ne marche qu’avec la réception d’un formulaire HTML. L’importation et la création de donnée avec du code sont donc très fastidieuses, et plusieurs hacks doivent être employés pour produire une expérience utilisateur intéressante.

Une fois que les données sont insérées, Pods est par contre très facile à utiliser. Un objet pod est accessible afin de récupérer des enregistrements ou d’en modifier. Le processus est très simple et intuitif.

Les relations entre les tables n’existent plus. Du moins, pas sous la forme SQL pure. Il faut passer par une table du plugin pour trouver quelles relations existent entre les données. Cette technique rend les requêtes complexes.

Un premier effort à souligner

Pods est le premier outil qui permet la création de type de données complètement arbitraires. Ce n’est jamais une mince tâche à entreprendre. Pour cet effort, les développeurs de Pods méritent mon respect. Maintenant, on ne peut pas encore lui attribuer le titre de framework.

Traduire un thème sous WordPress, c’est facile

  • Laurent LaSalle
  • Lundi, 24 août 2009

Le mois dernier avait lieu le premier WordCamp Montréal, une fin de semaine de conférences sur un outil qui est cher aux yeux des développeurs chez MA14 : WordPress. Une question fût soulevée lors de la conférence de Matt Mullenweg, co-fondateur du populaire CMS et l’homme derrière Automattic : Est-il possible de rendre WordPress multilingue, et ainsi faciliter la vie à plusieurs Québécois devant gérer du contenu dans les deux langues?

Sa réponse, même s’il ignorait le nom au moment de répondre, est d’utiliser l’extension qTranslate. Une fois l’extension installée, il ne vous suffit que d’internationaliser le thème de votre choix, une étape cruciale et simple… lorsqu’on connaît la procédure!

Repérer le contenu à traduire

Passez les fichiers de votre thème un par un, et quand vous tombez sur du texte à traduire, englobez celui devant être affiché dans la fonction _e(); et celui correspondant à un paramètre dans la fonction __();. Par exemple, le texte suivant :

<p class="center">Sorry, but you are looking for something that isn’t here.</p>

…devient…

<p class="center"><?php _e("Sorry, but you are looking for something that isn’t here.", "kubrick"); ?></p>

J’entends des gens me poser la question «Bon, c’est quoi l’idée de vénérer Stanley Kubrick dans ton exemple?!»

Sachez que «kubrick», utilisé ci-dessus comme nom de domaine, est le surnom de référence du thème activé par défaut sur WordPress depuis 2005. Dans un contexte de traduction, le nom de domaine permet d’identifier une série de chaînes de caractères afin de les regrouper pour les associer à un même fichier de traduction. Il est la clé qui permet l’association entre la phrase originale anglophone et sa version française.

Produire un fichier de traduction

Les habitués de WordPress connaissent bien le fichier fr_FR.mo. Il s’agit d’une version compilée du fichier de traduction de base pour la version française de WordPress. Encore aujourd’hui, il n’existe pas de distinction entre la France et le Canada au niveau de la traduction de WordPress, voilà pourquoi nous utiliserons l’identifiant français. La source du fichier se nomme fr_FR.po et se présente sous la forme d’un fichier texte. Voici un extrait de l’entête et d’une phrase traduite :

"Project-Id-Version: 1.6\n"
"Report-Msgid-Bugs-To: http://wordpress.org/tag/theme\n"
"POT-Creation-Date: 2009-05-18 17:54+0300\n"
"PO-Revision-Date: 2009-06-11 09:38+0100\n"
"Last-Translator: Amaury BALMER \n"
"Language-Team: French (France) \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n>1\n"
"X-Poedit-Language: French\n"
"X-Poedit-Country: FRANCE\n"
"X-Poedit-SourceCharset: utf-8\n"

#: index.php:36
msgid "Sorry, but you are looking for something that isn’t here."
msgstr "Désolé, mais vous cherchez quelque chose qui n’est pas ici."

Le dernier paragraphe est à répéter autant de fois que vous avez de phrases à traduire. La première ligne identifie l’endroit dans le fichier où se trouve la chaîne originale (à la ligne 36 du fichier index.php). Cette ligne est facultative, mais c’est une bonne pratique qui risque d’épargner beaucoup de temps autrement investi sur de la recherche. Vous aurez compris que la ligne du milieu représente la cible et que la dernière ligne représente le contenu devant remplacer cette cible.

Une fois le fichier de traduction complété, vous devez le compiler à l’aide d’un logiciel tel Poedit (disponible sur Windows, Mac et UNIX). Pour se faire, simplement ouvrir votre fichier fr_FR.po et sauvegarder votre fichier. Le logiciel compile celui-ci automatiquement, vous vous retrouverez donc avec un fichier fr_FR.mo prêt à être utilisé avec votre thème WordPress.

Déclarer le domaine dans functions.php

Une fois les fichiers fr_FR.mo et fr_FR.po (ce dernier est facultatif) transféré dans le répertoire de votre thème, vous devez modifier (ou produire) le fichier functions.php en y ajoutant la ligne suivante :

load_theme_textdomain("kubrick");

N’oubliez pas de remplacer le nom de domaine «kubrick» par celui-ci de votre choix (normalement, le surnom de votre thème). Celui-ci doit être le même que celui utilisé dans les fonctions _e(); et __(); que vous avez intégré à votre thème lors de la première étape.

Une fois ces trois étapes complétées, et si les fichiers produits ne sont pas corrompus (ou ne présentent pas d’incohérence), votre thème est maintenant internationalisé! Pour traduire celui-ci dans une nouvelle langue, vous n’avez qu’à compléter la seconde étape. Pourquoi ne pas produire une copie du fichier fr_FR.po en changeant son extension pour .pot (un standard) et vider ce dernier de son contenu français pour vos futurs besoins linguistiques?

Pourquoi réinventer la roue à chaque fois?

  • Marc Boivin
  • Mercredi, 15 juillet 2009

Plus je navigue dans le web québécois, plus je me rends compte que les nouvelles technologies ont de la difficulté à pénétrer le village gaulois du Québec. Pourquoi des compagnies utilisent-elles des solutions propriétaires sur mesure dans leur sites web? Quel est l’intérêt? Certes, des géants du web comme Google, Yahoo! et Microsoft ont des solutions faites sur mesure. Cependant, très peu d’organismes ont réellement besoin d’une solution complètement sur mesure. Je pense que certaines compagnies perdent une somme d’argent considérable à utiliser des outils propriétaires, mal développés, sur leur site.

Aussi, je veux parler ici des choses que vous devriez exiger en tant que clients, lorsque vous demandez une soumission pour un site. En partant, si votre contractant / entreprise / beau-frère hésite, ou encore esquive l’étape de la soumission en prétextant la complexité de ce genre de demande, allez voir ailleurs! Vous allez sauver beaucoup d’argent, et probablement beaucoup de temps.

Voici une liste d’éléments simples pour vous guider lorsque vous demander un site web.

Des liens lisibles

Nous sommes en 2009, les liens devraient être lisibles par les utilisateurs. Pas de http://monsite.com/index.php?lang=fr&page=programmation
#progGrid=fr%3BGetByDate%3B2009-07-11
.

Cette pratique, en plus de nuire à votre classement, a un look affreux. De plus, un lien est un indicateur du sujet de la page. Si ce lien est partagé par courriel ou par médias sociaux, il sera difficile d’en cerner le sujet. Les liens sous la forme http://monsite.com/fr/programmation/11-juillet-2009 sont non seulement plus lisibles, mais surtout beaucoup plus significatif pour un lecteur. Sans parler des bienfaits pour le référencement.

Possibilité de traduire le site

La traduction dans une autre langue prend du temps. Elle prend du temps parce qu’il faut que les textes soient traduits et bien traduits. Elle prend aussi du temps parce qu’il faut que quelqu’un insère les textes des nouvelles langues et en adapte la longueur (par exemple, un même texte en français sera plus long que sa version anglaise).

Mais au niveau de la structure, la traduction d’un site ne devrait pas être longue à développer. Si chaque fois que vous demandez une langue supplémentaire votre site double de grosseur, autant en megabites qu’en dollars, sauvez-vous en courant! Aujourd’hui, un développeur de sites web doit assumer que tous les sites sont multilingues, ou pourront le devenir éventuellement, même si le client ne le demande pas. Soyez un consommateur futé et négociez un prix juste pour la traduction de votre site, pensez-y dès le départ.

Publier du contenu

Si vous ne pouvez pas facilement publier du contenu sur votre site, comme des nouvelles ou un billet de blogue, changez de contractant / entreprise / beau-frère. Certes, il y a plusieurs cas ou avoir le contrôle total sur le contenu de son site est impossible. Mais vous devriez par contre toujours pouvoir publier du contenu dans une zone accessible de votre site, la section «Nouvelles» par exemple. L’ajout, la modification et la suppression des articles ne devraient pas être des processus douloureux car un site efficace évolue avec l’entreprise qu’il représente.

Vous ne devriez pas non plus avoir à apprendre le HTML pour publier votre contenu. Il faut être conscient que la procédure de publication nécessitera une adaptation par rapport à l’utilisation d’un traitement de texte comme Word, mais elle ne devrait pas être trop lourde non plus. Il existe actuellement des outils de publication faciles à manier.

Comportement sur les divers navigateurs

Il y a aujourd’hui une vaste sélection de fureteurs web : Internet Explorer, Safari, Firefox, Opera, en version mobile, sur des écrans restreints (netbooks et autres), etc. Bien qu’il soit souhaitable que le site ait un comportement parfait sur tous les navigateurs, il est fort possible que ça ne soit pas atteint si votre fournisseur ne procède pas à une série de tests.

Couvrir tous les cas de figure prend un temps considérable, qui vaut cependant l’investissement car cela garantie que votre site sera vu de la même manière sur tous les fureteurs. Si les efforts ne sont pas mis pour s’assurer d’avoir une expérience comparable sur les navigateurs de dernière génération, fuyez! La tenue de route de votre site sur Internet Explorer 7 et 8, Firefox 2 et 3, Safari 3 et 4 est un MUST aujourd’hui pour une entreprise sérieuse. Vous ne devriez pas payer un surplus pour corriger des bugs d’affichage ou de fonctionnalités dans ces navigateurs, car cette ronde de tests devrait être incluse dans le temps de développement. Informez-vous quant à la compatibilité du produit proposé avant de commencer le développement.

Des pistes de solutions pour mes amis développeurs

Si vous pensez que j’en demande trop, vous vous trompez. Il faut se mettre à jour et réaliser qu’il existe des plateformes qui sont là pour nous épauler dans le développement de site de plus en plus complexes et riches. Voici une liste, qui ne comporte rien de nouveau, mais qui peut faire sauver un temps considérable. Tous les outils de cette liste sont 100% libres et ont fait leurs preuves dans le milieu.

Les engins de blogue : Engin de blogue parmi les plus populaires, WordPress offre des outils faciles à utiliser. C’est une très bonne façon de s’introduire aux nouveaux concepts du web comme la gestion de plusieurs langues, la publication de contenu, la gestion des fil RSS, etc. Tout est facile, tout est modifiable.

J’ai utilisé WordPress comme CMS (Content Management System / Gestionnaire de contenu) souvent dans des contrats. WordPress est tout désigné pour les projets qui comportent quelques utilisateurs et des droits d’accès simples.

Les frameworks : Les frameworks (Zend Framework, Ruby on Rails, Django, Typo3) sont des outils pour les développeurs. Comme WordPress, ils offrent des manières de faire la gestion des cas courants comme la gestion des liens, des langues et des accès utilisateurs. Ils sont plus génériques et possèdent moins d’outils ciblés. Ils permettent surtout de développer des applications web biens précises, par exemple pour la gestion des stocks sur un site de vente. Évidemment, développer avec un framework demande plus de travail, mais beaucoup moins que de le faire entièrement à la main.

À la main : Pour les fois où, dans l’humanité, certaines personnes ont développé des bouts de code en C++ tellement géniaux qu’il fallait publier leurs fonctionnalités sur le web, certains geeks ont inventé des protocoles de messaging. XML-RPC et REST en sont 2 exemples très populaires. Un conseil : branchez votre bout de code révolutionnaire sur un buffer qui se sert des communications XML-RPC et communiquez avec votre application. Ne construisez pas une application autour.

Conclusion

Il existe plusieurs outils de gestion pour le web. Il est extrêmement difficile de déterminer lequel est bon, encore plus lequel est le meilleur. Il faut considérer le support, le contexte et la formation dans ce genre de décision. Vous est-il possible de trouver des gens pour vous former et vous supporter dans votre communauté? Est-ce que l’outil en question a une bonne communauté? (et ce, qu’il soit payant ou libre…)

Et voilà! C’étaient quelques pistes, qui je l’espère, aideront les personnes qui demandent des sites web à y voir plus clair, et qui seront vues par mes amis développeurs comme des arguments justifiant que c’est souvent inutile de réinventer la roue.

Thème par MA14. Fièrement propulsé par Wordpress