WordPress est un outil particulièrement accessible : en terme d’ergonomie, de prise en main pour l’utilisateur/rice. Pour ce qui est des développeurs et développeuses, la documentation bien touffue qu’est le codex et l’utilisation de grands standards du Web (PHP, MySQL, CSS, jQuery…) en font en plus un cadre de travail très agréable et optimisé pour le co-développement.
Dans la plupart des cas, en 3 clics, un thème enfant est créé, et si il y a un besoin spécifique : une extension fera l’affaire. On a bien profité du système open-source communautaire pour s’économiser du temps de développement.
Et si la démarche pouvait être autre ?
Déjà, fallait il « vraiment » créer une extension ? La fonctionnalité recherchée n’existait elle pas déjà ? Peut être qu’un addon de plugin suffirait ? une grosse partie serait déjà en place et éprouvée par la communauté. Une fois répondu à ces questions, si l’idée initiale comble un vrai manque, il faut donc la développer, mais pourquoi la publier?
Les inconvénients
Au premier abord, cela semble contraignant, il faut prévoir les traductions, éviter les mauvaises habitudes à la « je fais ça vite fait, et on verra »… et donc cela prend plus de temps. En fait, publier apporte beaucoup plus d’avantages que de contraintes.
Les avantages
Le coté altruiste :
- Par éthique, cela pourra servir a d’autres et laisse bonne conscience.
- Pour apporter sa pierre a l’édifice WordPress.
le coté égoïste (encore que):
- Cela oblige a faire un code propre, en évitant les commentaires inutiles, les PHP warnings divers. le travail fournit pour publication est de meilleure qualité.
- L’équipe de validation évite les grosses erreurs.
- Cela permet de passer son développement sur un site en production par l’installateur intégré, sans besoin de FTP, surtout pratique pour appliquer des mise à jours sur plusieurs sites.
- D’autres regardent ! Ce la fait des remontées de bugs, ou peut être même des contributions ou améliorations
Alors comment procède t-on ?
Les bonnes pratiques
- Comme l’extension pourra se retrouver dans beaucoup d’environnements différents, il y a des cas de figure très précis ou une grande souplesse.
- Coder clairement et proprement : le code doit être utilisable par n’importe qui.
- Le code doit être compatible avec WordPress, la licence GPL
La boite à outils
- Utiliser au maximum l’existant : Class et APIWordPress, Extensions à forte communauté.
- Optionnel, la localisation avec textdomain et poedit
- Incontournable, Le fichier readme.txt,
- WordPress.org et la soumission de plugins.
- Les outils de SVN.