Comment la création d’applications WordPress change les perspectives et les normes dans le développement de WordPress

Dans mon dernier article pour Torque On Thinking like a APP, je n’ai pas spécifiquement mentionné comment mobiliser wordpress pour changer la façon dont nous développons ce que nous décidons de construire. Dans cet article, je vais discuter de mes idées sur les changements technologiques qui se produisent dans le processus de développement réel. Gardez à l’esprit que, pour l’instant, lorsque nous parlons de développement d’applications WordPress, nous parlons en fait de créer une application spécifique pour un but spécifique, plutôt que de créer une application réutilisable, recommandée de nouveau par d’autres, comme la façon dont nous écrivons les plug – ins et les thèmes.
La partie réutilisable de l’api rest, comme beaucoup de plug – ins et de thèmes que nous avons aujourd’hui, est sur le point de créer l’économie des applications WordPress. Mais nous n’en sommes pas encore là et nous devons attendre de voir ce qui se passe. Quels critères sont toujours applicables? Au fur et à mesure que vous commencez à développer votre application, vous pouvez tirer parti de ce que vous avez appris en développant des sujets et des plug – ins, mais gardez à l’esprit que toutes les règles ne s’appliquent pas. C’est principalement parce que vous n’avez pas créé de code distribué à des milliers de sites, comme c’est souvent le cas lorsque vous créez des sites spécifiques.
Lorsque vous développez un site Web, assurez – vous que vos clients peuvent remplacer n’importe quel sujet, plug – in ou code personnalisé et que le site web fonctionne correctement. Cette modularité est une raison importante pour laquelle ils ont commencé à créer des sites Web en utilisant WordPress. Lorsque vous créez une application, je pense (bien que je puisse me tromper) qu’il est juste de supposer qu’il s’agit de « votre application », et cet état d’esprit change en fait la façon dont vous pensez à la façon de la maintenir en marche. Comme pour le développement de site, vous avez un contrôle total sur la pile, donc vous n’avez pas besoin de considérer la compatibilité en arrière avec les versions précédentes de WordPress ou PHP. Il n’y a aucune raison de charger autre que la dernière version de WordPress, PHP ou hhvm.
En parlant de développement
Il est essentiel que les plug – ins et les thèmes soient adaptés aux autres plug – ins et thèmes. Même si on me demande d’écrire du code personnalisé pour le site, je m’assure toujours de respecter pleinement les normes et les meilleures pratiques de WordPress, car je ne sais pas quels plugins et thèmes les clients pourraient ajouter à l’avenir. Il est toujours logique de suivre les normes de documentation en ligne de WordPress et les normes de nommage et de structure de fichiers PSR – 4 lors du développement d’applications Web. Certaines bonnes pratiques sont moins importantes pour moi. Par exemple, dans un projet d’application récent, je n’a i pas utilisé le script WP _ enqueue pour ajouter un fichier JavaScript ou CSS à mon application qui n’est pas un plug – in.
Le codage dur des liens de script ou de feuille de style dans les en – têtes HTML est considéré comme une mauvaise pratique dans un projet client ou un sujet; Mais les coder rend mon code plus facile à lire pour les développeurs non WordPress de l’équipe. Il réduit également le temps de chargement initial de la page. Dans ce cas, c’est une petite chose, mais quand vous commencez à penser à tout ce que vous faites habituellement, vous réalisez rapidement comment ces petites choses s’accumulent. De plus, l’endroit où vous placez votre code (c. – à – D. dans un sujet, un plug – in, un plug – in Mu ou ailleurs) est très différent. Vous n’avez pas besoin de toujours penser du point de vue d’un thème ou d’un plugin, ni même de penser entièrement en WordPress. Dans de nombreux cas, il est logique de créer un répertoire à partir d’un plug – in indispensable ou d’un plug – in Mu.
Dans le développement de plug – ins, il n’est pas raisonnable de supposer que l’utilisateur final s’intègre à un autre cadre Php comme laraver. Cependant, si vous voulez créer la moitié des applications dans laraver, vous pouvez, ou si, pour une raison quelconque, il est plus logique d’utiliser le routeur d’événements Symfony plutôt que le crochet WordPress, alors Continuez. Comment autoriser? Lors du développement d’un thème WordPress ou de la publication d’un plugin, si vous êtes
La bonne licence, ou vous pensez que vous pouvez réellement ajouter une licence restrictive, n’a aucun sens sur le plan pratique. N’importe qui peut redistribuer et réutiliser tout ou partie du Code à moins que vous ne décidiez d’utiliser agpl.
Lorsque vous créez une application, vous n’avez pas à distribuer le Code la plupart du temps. Votre permis est donc moins important. J’aime garder mon code public parce que je pense que cela aidera mon entreprise. De même, il aide à protéger la sécurité de mes utilisateurs, car la sécurité de mon code peut être vérifiée indépendamment. Pour ces raisons, je voudrais une protection GPL ou une licence similaire. Utilisez – vous un plug – in? Personnellement, j’utilise toujours des plug – ins, mais j’ai tendance à insister sur l’utilisation de plug – ins auxquels j’ai participé activement en tant que principal contributeur. Faire partie du Code de pile n’est pas propre au projet et, bien qu’il soit efficace, il présente un risque important. Si vous n’avez pas une connaissance approfondie du plug – in que vous avez choisi, vous risquez d’ignorer les problèmes potentiels. De même, si l’auteur original quitte le support, vous pouvez être empêché de les maintenir.
Il reste encore beaucoup à dire sur la façon dont l’api WordPress rest sera ouverte aux experts non WordPress. Cela est particulièrement vrai pour le travail frontal, qui peut être complètement découplé de WordPress. Cependant, pour le côté serveur, vous devriez avoir une connaissance approfondie du noyau WordPress, de l’api rest et des plugins que vous utilisez. Cela nécessite des développeurs PHP WordPress expérimentés, de préférence des développeurs qui contribuent à toutes les dépendances pertinentes. En fin de compte, le plug – in est comme toute autre dépendance dans le développement d’applications. Ils peuvent accélérer le développement en vous permettant de profiter du travail des autres plutôt que de le faire vous – même. Cependant, chaque dépendance diminue votre contrôle sur vous – même et augmente votre p
Question.
Comment faire le front end? Le Front – end de l’application est là où la vraie différence fonctionne. Lorsque vous utilisez une application, vous voulez qu’elle soit très dynamique, qu’elle ait un nombre limité de pages vues et qu’elle fonctionne hors ligne. C’est pourquoi l’intégration des cadres JavaScript MVC frontaux tels que REACT et Angular devient très importante, car c’est pourquoi ils sont conçus. Vous pouvez peut – être offrir cette expérience en utilisant jquery, mais c’est un combat difficile et un cadre frontal de haute qualité a résolu ce problème pour vous. La décision de séparer complètement le front end de WordPress signifie que vous utilisez un serveur autonome indépendant de WordPress, ou si vous devez intégrer des applications Web dans un thème, sont des options valables qui nécessitent une certaine réflexion. La première ouvre tous les types d’options, y compris la réécriture du JavaScript. Pour les développeurs expérimentés de WordPress, ce dernier pourrait être une adaptation plus simple.
Roy Sivan a écrit un excellent article pour Torque sur l’application client créée avec l’api rest de WordPress. Il dispose également de nombreuses ressources pour utiliser Angular et d’autres cadres JavaScript MVC sur son site. Il est temps de faire l’expérience de l’api WordPress rest, qui offre une nouvelle opportunité passionnante, car nous avons trouvé de nouvelles façons de l’utiliser pour améliorer notre expérience WordPress globale. La partie la plus excitante de cet article, comme je l’espère, et de ses frères moins techniques, est qu’il ouvre une nouvelle façon de penser et de faire face à notre travail.