Au cours du WordCamp Paris #4, j’ai pu assister à un atelier de conseils et retours d’expérience pour le développement de plugins WordPress.

Voici donc mes notes, et pistes de réflexion, en vrac :

  • L’utilisation du répertoire mu-plugins/ peut être intéressant : les plugins fichiers ( aucun dossier n’est crawlé ) sont activés automatiquement, et n’apparaissent pas dans l’administration. Un reliquat de WordPress MU, qui peut rendre quelques services.
  • Les parties de vos plugins utilisées uniquement en admin doivent être isolées avec une condition is_admin(). Performances, toussa.
  • à la désactivation du plugin, il faut faire du ménage dans les fichiers créés par ce dernier, à l’aide du hook register_deactivation_hook.
  • Aucune solution n’est incluse dans WordPress pour permettre la mise à jour automatique de plugins non présents dans le repository WordPress.org. à coder ou rendre publique son extension.
  • Il a été rappelé que la publication de plugins sur le repository peut apporter une notoriété d’expert, mais que le prix à payer en temps pour faire le support client est important, p
  • L’idée d’un repository de plugins en licence WTFPL a été lancée.
  • Pour l’instant, aucun plugin n’est prévu pour accompagner par défaut Hello Dolly et Akismet avec l’installation de WordPress.
  • Il est nécessaire de fouiller le code de WordPress pour trouver les conventions de nommage.
  • Un plugin devrait idéalement avoir un code structuré, commenté, réutilisable, documenté, internationalisé, optimisé (cache, bonne gestion de la mémoire), sécurisé (utilisation des roles et de wp_nonce)
  • Les Plugins créés par Scribu sont de bons exemples.
  • La classe wpdb doit être maîtrisée pour bien gérer les échanges avec la base de données.

Tags : , , ,