Les résolutions WordPress pour 2015 : Dans vos développements

Les résolutions WordPress pour 2015 : Dans vos développements

Haaaaaa, 2015 est arrivée ! La voici la nouvelle année déjà remplie de d’idées et de projet à n’en plus finir (et vous ne les finirez pas, on le sait tous !).

Vous avez peut-être fait votre liste de bonne résolutions pour cette année ? Mais avez-vous fait celle des bonnes résolutions dans vos développements WordPress ?

Je vais vous aider, prenez votre crayon et une A4, on y va pour cette liste, une peu comme votre future TODO !

LA LISTE !

  1. Développer avec la constante WP_DEBUG sur TRUE,
    • L’avantage de cette constante est de pouvoir vous apercevoir rapidement d’une erreur de code, les warnings et notices seront alors affichées.
  2. Utiliser les fonctions/APIs WordPress au lieu des fonctions/APIs PHP ou mes fonctions/APIs maison,
    • L’avantage d’utiliser le code de WordPress est que vous passerez par des hooks, ce dont raffolent les dévs !
  3. Ajouter des actions et des filtres dans mon code,
    • Je viens de le dire, on en raffole, cela ne vous coûte rien d’ajouter de temps en temps une ligne de code, aucune perf de perdue, promis !
  4. Ne pas toucher arbitrairement à des paramètres que je ne devrait pas,
    • N’allez pas filtrer non stop un élément du code, ne modifiez pas une option de WordPress sans demander la permission sous prétexte que votre plugin en a besoin, merci d’avance.
  5. Commenter et aérer mon code un gros minimum,
    • Essayez au moins de laisser quelques espaces entre certains blocs, et commentez l’utilisation de la fonction et le code.
  6. Utiliser des isset(), empty(), in_array(), array_key_exists(), defined() etc,
    • Vous éviterez les warnings et notices !
  7. Tester mes développements, et retester,
    • Test encore une fois tiens …
  8. Utiliser les fonctions de désinfection (sanitize_*) et d’échappement (esc_*) ou de filtrage (wp_kses*),
    • Ces fonctions de sécurité permettrons à votre plugin de ne pas se retrouver parmi les plugins vulnérables en version 0.1b. Vous éviterez principalement la faille XSS avec ça.
  9. Utiliser les fonctions wp_create_nonce(), wp_nonce_url(), wp_nonce_field(), settings_fields(),
    • Même chose pour la faille CSRF.
  10. Éviter de charger des librairies kikoolol,
    • Parfois on a pas le choix, parfois on l’a, faites le bon !
  11. Éviter de nommer mes fonctions de façon trop classiques,
    • Ne commencez jamais par wp_ et ne soyez pas trop court ou trop classique comme search ou getlist.
  12. Faire commencer chacun de vos fichiers de plugins ou de thèmes par defined( 'ABSPATH' ) or die( 'Direct acces not allowed!' );
    • Cela évite une erreur fatale puisque votre fichier utilise des fonctions WordPress, encore non déclarées lors d’un accès direct !
  13. Arrêter de charger mes propres petites icônes, vive dashicons ou les sprites,
    • On est en 2015 quand même …
  14. Éviter de faire un appel direct à un fichier inclus dans un plugin,
    • Utilisez les hooks via des actions, voir admin-post.php.
  15. Rendre mes développements prêts à être traduits avec __(), _e(), _x(), _n() etc,
    • Les fonctions de traductions sont disponibles, utilisez les (mais bien !) (Mes slides de janvier 2015 au WordCamp Paris seront dispo fin du mois)
  16. Traduire les mots dans mes fichiers JavaScript au lieu de tout mettre en dur,
  17. N’ajouter les styles et scripts que sur mes pages et pas partout tout le temps,
  18. Coder d’abord en NOJS puis rendre le dev compatible JS et non l’inverse,
    • Pensez que tout le monde n’a pas le JS actif, codez d’abord sans JS si possible.
  19. Utiliser admin-post.php avant d’utiliser admin-ajax.php,
    • Même chose qu’au dessus, si vous devez faire de l’ajax, faites le d’abord via admin-post.php,
  20. Rendre mes développements compatibles avec la plus ancienne version de PHP, MySQL et WP possible,
    • WordPress 4.1 tourne sous PHP 5.2.4, MySQL 5.0, pourquoi pas vos développements ?
  21. Arrêter de recalculer à chaque itération de boucle un sélecteur jQuery,
    • Le fait de recalculer fait vraiment perdre des secondes au visiteurs, déclarez une variable au préalable !
  22. Factoriser mon code pour éviter la redondance et faciliter la maintenance,
    • Si vous vous apercevez que plusieurs blocs ou fonctions de votre code sont quasi identiques, alors factorisez les !
  23. Utiliser les tags HTML button au lieu des a pour faire des boutons,
    • Ceci est un point SEO et accessibilité, les liens a ne seront pas visités, et les boutons seront alors de vrais boutons.
  24. Utiliser les ARIA et autres possibilités de rendre vos développements accessibles,
    • Il y a plus de gens qui ont besoin d’accessibilité que vous ne le pensez, et il ne faut pas être 100% handicapé visuel pour en avoir besoin.
  25. Éviter la surqualification CSS pour améliorer les perfs clients,
    • un [type=text] suffit contre un input[type=text], idem un #foo au lieu d’un div#foo.
  26. Toujours utiliser les braces dans les IF, FOR, FOREACH, WHILE, etc même pour une seule ligne de code,
    • Cela permets d’éviter de mettre une seconde ligne hors contexte lors d’une prochaine modification du code.
  27. Indenter mon code avec des tabulations et non des espaces,
    • Cela rends le code lisible plus facilement, et les tabulations ont été choisies comme standard pour WordPress.
  28. Utiliser $wpdb->prepare() avec au moins 1 paramètre lors des requêtes maison,
  29. Rendre le code lisible et maintenable facilement pour les humains plutôt de gagner un nombre de lignes pour la machine,
    • Mieux vaut coder sur 5 lignes lisibles par un humains que réussir à le faire sur 1/2 ligne, illisible.
  30. Ne pas mettre de chemins en dur dans mon code,

D’autres points plus détaillés sont lisible dans les WordPress Coding Standards (en).

Quelles sont vos résolutions développements WordPress ?

Lire la suite

Vous aimez ? Partagez !

Abonnement gratuit à 0€


10 thoughts on “Les résolutions WordPress pour 2015 : Dans vos développements”

  • 1
    stephendltg on 5 janvier 2015 Répondre
    Ça c’est top ! Des règles pour mieux coder sur wordpress est primordiale.
    Tout mes vœux . J’aime ce début d’année quand il commence ainsi!
  • 2
    Greg@Screenfeed on 6 janvier 2015 Répondre
    Ben dis donc, pour avoir autant de résolutions, tu dois vraiment coder comme une me*de.

    :D

    • 3
      Julio Potier on 6 janvier 2015
      TICON !
    • 4
      madvic on 7 janvier 2015
      C’est exactement ce que je me suis dis quand j’ai commencé la lecture : Et ben si ce sont ces résolutions, …
      :-b
    • 5
      Julio Potier on 7 janvier 2015
      « Dans VOS développements » ^^ (bon, ok, je dois plus/mieux commenter …)
  • 6
    michael on 6 janvier 2015 Répondre
    Bonjour,
    Bon, je ne fais pas encore de gros codage sur WP, juste des retouches, mais la, cela fait beaucoup de résolutions à prendre.. Je dirais que pour une majorité, je les suit, et puis, il y en a d’autres, on est toujours pressé, on verra ca demain…. et puis, 6 mois après, c’est toujours en attente.

    Merci pour cette check-list.

  • 7
    Mathieu Acthernoene on 6 janvier 2015 Répondre
    Je vais reprendre certains points.

    – Éviter de nommer mes fonctions de façon trop classiques
    -> Sinon on est en 2015, vous vous débarrassez de cette saloperie de PHP 5.2, et du coup vous utilisez les espaces de noms et les fonctions anonymes. Votre plugin / thème ne sera pas accepté sur les repos WordPress, mais GitHub ne dira rien. Passez même direct à PHP 5.4, les traits sont utiles sur WordPress (avec son architecture figée, un trait « Singleton » ça aide…)

    – Rendre mes développements compatibles avec la plus ancienne version de PHP, MySQL et WP possible
    -> Non merci. PHP 5.2 n’est plus maintenu (obsolète, plus de MàJs, et TOUTES les versions de PHP 5.2.x présentent des failles: http://blog.ircmaxell.com/2014/12/php-install-statistics.html), je ne vois pas pourquoi adapter mon code pour quelque chose qui n’est plus supporté (rappel: PHP 5.3 est sorti en 2009 – http://php.net/releases/ )

    – Indenter mon code avec des tabulations et non des espaces
    -> http://www.php-fig.org/psr/psr-2/ (Standards toussa)

    Le problème, c’est qu’actuellement WordPress est dans un cul-de-sac d’un point de vue développement…Ça serait bien qu’en 2015, on pense enfin à faire marche arrière plutôt que de continuer à foncer dans cette direction, parce qu’on atteinds la fin de la route là: https://wordpress.org/about/stats/

    • 8
      Julio Potier on 8 janvier 2015
      Hello

      Comme tu peux le voir dans les stats, PHP 5.2 et 5.3 représentent plus de 70% des installations.
      Si on vends un produit, comme WP Rocket, je serais bête de me fermer la porte à – potentiellement – 70% de clients.
      Être sur github c’est bien, mais les installations WordPress sont par défaut reliée à son propre repo. Certes, git serait un bienfait, mais ce n’est pas fait.
      Quand on veut ajouter un plugin sur le repo, il est un minimum passé au crible (je dis bien un minimum) alors que github c’est la foire, pire que le repo actuel de ce fait, logique me diras-tu, je suis d’accord aussi.

      Rendre compatible oui, même point que précédemment, 70% des installations. Ce n’est pas parce que je vais dev en 5.4 que les gens pourront passer en 5.4 comme ça. Ce n’est pas une case à cocher « 5.2 ou 5.4 » tu le sais.

      Les stats sécures sont bidons, aucune version d’un soft à un instant T-1 n’est sécure, elles le sont toutes à un instant T0. Question de logique aussi. Après je suis d’accord qu’il faut éviter de rester avec du PHP x.x non sécure mais c’est rarement du ressort du blogueur de pouvoir faire ça, il subit son hébergement qu’il a depuis des lustres par exemple.

      Indentation WordPress : https://make.wordpress.org/core/handbook/coding-standards/php/#indentation
      Le choix des tabs a été fait. Point.

      Faire marche arrière n’est pas possible, autant aller au bout, quitte à mourir de ça. imo.

      Merci pour ton comm !

    • 9
      Mathieu Acthernoene on 8 janvier 2015
      Bien sûr, il serait stupide de ne pas développer un plugin ou un thème payant avec une compatibilité PHP 5.2. Par contre, je pense qu’il faudrait que les thèmes / plugins gratuits commencent à forcer l’utilisation de PHP 5.4, ainsi qu’une architecture plus cohérente qui utiliserait les nouvelles fonctionnalités de PHP 5.3+ (et Composer)
      Dans la mesure où ceux-co ne respecteraient pas ce qui est imposé par WordPress, celui-ci se devrait d’être posté ailleurs (Github n’est qu’un exemple, il y a Packagist aussi, il est également possible de faire une plateforme dédiée, semblable à http://packalyst.com/ , mais pour WP). Cela freinera des gens, mais si le mouvement prend de l’ampleur, les obligera à aller de l’avant (on parle en années)

      Effectivement il y a des failles dans tout programme, mais toutes ne sont pas découvertes immédiatement…Pour PHP 5.2, toutes les versions sont déjà grillés. De plus, un hébergement avec PHP 5.2 installé a sûrement une vieille version d’Apache et un vieil OS…

      Le point a été fait pour les tabs…Mais il y a très longtemps. Aujourd’hui, c’est problèmatique car ça s’intègre très mal aux workflow de dev PHP (Git et les tabs…). De plus, c’est peut-être la seule amélioration possible qui ne gênerait personne.

  • 10
    michel on 1 juin 2015 Répondre
    Bon, j’ai du boulot : je ne dois pas être bon sur les 2/3 des points mentionnés. On est toujours (trop) pressé. Ma resolution 2015 ? Valider 75 % de ces résolutions à la fin de l’année.

Laisser un commentaire

Avant de parler, merci de lire la charte des commentaires.

Utiliser le tag [php][/php] pour ajouter du code ou utilisez un service comme pastebin.com.
Cibler un commentateur avec un "@", merci à Mention Comments Authors !