7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. General

Desarrollo WordPress Profesional: Estrategias

Read Time: 9 mins

Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)

Trabajar para la comunidad de WordPress es tanto una bendición como una maldición. Debido a la naturaleza de código abierto de WordPress, disponemos de una fantástica plataforma con la que construir sitios web, temas, plugins e incluso aplicaciones. Está formada por una inteligente comunidad, una rica documentación y normas que tienen por objeto proporcionar un consenso respecto a la forma de escribir código y a la forma de construir herramientas para la plataforma.

Al mismo tiempo, la naturaleza de código abierto de WordPress así como los lenguajes con los que se construye, permiten que cualquier persona envíe su trabajo con independencia de si cumple algún tipo de estándar o si hace uso de alguna de las mejores prácticas. Para muchos usuarios, que desconocen lo que se cuece bajo el capó. Si el producto funciona, están felices.

Como personas serias en lo que afecta a su trabajo, no podemos conformarnos en absoluto simplemente con que "llegue a funcionar." Debemos preocuparnos por lo que sucede en la trastienda, en aquello que no se ve.

Si eres un desarrollador de WordPress serio, entonces usted probablemente ya tiene un método para cómo trabajar, pero si te acaba de empezar o está mirando para definirte como un desarrollador profesional de WordPress, hay estrategias, entornos y herramientas que puede utilizar que pueden ayudar.

En esta serie de tres artículos, vamos a ver exactamente lo que son y cómo se aplican en nuestro trabajo de proyecto. En primer lugar, comenzaremos con las estrategias.


Organización de los archivos

Una parte importante de la construcción de software realmente está manteniendo después del lanzamiento inicial. La verdad es que realmente se gasta más tiempo en el mantenimiento de proyectos de los construcción de. ¿Tiene sentido, correcto? Un producto existe para mucho más tiempo que se necesita para crearla, y, suponiendo que es de alta calidad, entonces los usuarios van a encontrar errores y solicitar nuevas características.

Lamentablemente, una cantidad significativa de tiempo de mantenimiento es gastada en conseguir un bug resuelto o rápidamente añadiendo una nueva característica y a menudo se hace de una manera que se centra más en conseguir sólo lo hecho que lo hace bien. Esto no es totalmente incorrecto-cuando un producto está ligado directamente a la línea de fondo de un negocio, entonces el tiempo es una prioridad.

Pero hay cosas que se pueden realizar durante el desarrollo inicial que puede recorrer un largo camino en lo que es más fácil de mantener un producto después de su lanzamiento.

Para Temas

Theme ConventionsTheme ConventionsTheme Conventions

El WordPress Codex ofrece a una guía completa de cómo crear temas. Cubiertas de guías de la hoja de estilos, archivos de plantilla, información de JavaScript, pautas pruebas, listas de comprobación y varias referencias. Incluso si usted está en el negocio de la construcción de temas, les recomiendo revisar esta lista de vez en cuando.

Además de seguir el base conjunto de directrices, hay cosas adicionales que pueden hacer para mejorar el mantenimiento. Suponiendo que usted está siguiendo las directrices del Codex para la construcción de temas, considere lo siguiente con respecto a algunos de sus activos y las dependencias.

Activos

Una de las cosas que hago para cada uno de mis proyectos es asegurarte de tener directorios específicos para los activos que están fuera de los archivos normales requeridos para el desarrollo del tema. Con esto, quiero decir que tengo directorios específicos para:

  • Imágenes
  • Hojas de Estilo
  • JavaScript
  • Archivos de Idioma
  • Las librerías, al igual que el código más modular como los plugins o las clases PHP
  • etcétera.

Por supuesto, cada tema requiere al menos una hoja de estilo, pero imaginemos que vas a proporcionar varias hojas de estilo para el panel de administración. Para facilitar el mantenimiento, es mejor mantenerlas separadas a reunirlas en una sola hoja de estilo, después puedes hacer uso de una herramienta que los combine en uno antes del lanzamiento.

Echaremos un vistazo a algunas herramientas para realizar esto en concreto en el último artículo de la serie.

Independientemente de donde caes en esto, planificar un poco con antelación podría ayudarte bastante a la hora de tener el conjunto de tus recursos bien organizados.

Convenciones de Nomenclatura

Cuando consideramos la mejor forma de organizar nuestros diferentes recursos, las convenciones de nomenclatura nos pueden aportar claridad y proporcionar un estándar que deban seguir todos los archivos relacionados. Por ejemplo, yo normalmente hago lo siguiente en cada uno de mis proyectos:

  • Las imágenes relacionadas con una plantilla específica llevan el prefijo del nombre de la plantilla, por ejemplo: full-width.background.png
  • JavaScript
    • Las imágenes del escritorio, llevarán el prefijo admin y se denominarán dependiendo de para qué página se carguen: admin.edit-post.js, admin.users.js.
    • Las imágenes para el tema, o para las áreas públicas, llevarán el prefijo theme y el nombre de la plantilla en la que se cargan: theme.about.js.
  • Las hojas de estilo siguen las mismas normas de nomenclatura que el JavaScript
    • Las hojas de estilo específicas del área administrativa son precedidas por admin y nombradas según la página en la que se carguen: admin.widgets.css
    • Las hojas de estilo específicas del tema se nombran de la misma manera, basandose en la plantilla en la que se cargan: theme.about.css.

Por supuesto, hay algunos universal JavaScript y hojas de estilos que se aplican en todo el tema. En este caso, simplemente mantener un conjunto de archivos admin.css y style.css.

Para Plugins

Plugin ConventionsPlugin ConventionsPlugin Conventions

La mayoría de los desarrolladores de WordPress sabe que los plugins deben ser independientes del tema. Es decir, no deberían depender de una característica de ningún tema, ni tampoco deberían imponer el empleo de ninguna de sus hojas de estilo o JavaScripts sobre el tema existente a excepción de aquellos que afectan a su propia característica en concreto.

Además de eso, hay dos maneras de desarrollar plugins:

Para ello, existen algunas estrategias que podrías emplear cuando escribas tus plugins para asegurarte de que las hojas de estilo, el JavaScript, las imágenes y otros recursos no entren en conflicto con el tema existente.

No Mezclar ni Combinar

Cuando se trata de escribir plugins, la API diferentes generalmente hace fácil de mezclar y combinar los idiomas que estás usando para construir tu plugin. Por eso, quiero decir que es totalmente posible incluir todos los estilos, JavaScript, HTML y PHP en un solo archivo y luego enviarlo.

Pero yo no soy un fan de este.

Por lo general, cada lenguaje tiene un propósito específico, y debido a eso, trato de mantener lo más posible cada idioma en su propio archivo. Considere esto:

  • HTML se usa para describir los datos que se muestran en el navegador
  • CSS se utiliza para aplicar estilo o presentar los datos que se muestran en el navegador
  • JavaScript se utiliza para manejar eventos y enviar o recuperar información desde o hacia el navegador y el servidor
  • PHP está destinado a ejecutar operaciones en el servidor

Por tanto, creo que tiene más lógica mantener los archivos separados de forma que sepas a dónde dirigirte cuando se presente un problema o llegue el momento de introducir una nueva característica.

Esto no quiere decir que ocasionalmente no tengas código PHP escrito en el el código de la estructura de la página o que no puedas crear elementos HTML de manera dinámica desde el servidor, pero su intención es proporcionar unos criterios básicos para que organices tu trabajo.

Separación las Consideraciones/Prioridades

Además de asegurarte de que cada conjunto de hojas de estilo y archivos JavaScript sean nombrados claramente, también suelo seguir la misma estructura para los temas que creo, nombrando el código especifícamente administrativo con el prefijo admin y el código del tema o el código que es concretamente público con el prefijo display (pantalla).

Es una sencilla estrategia pero ayuda bastante en la organización, para saber donde debes colocar los archivos. Ayuda también en las labores de mantenimiento, ya que los problemas suelen surgir cuando tu trabajo ya está publicado.

Una Última Palabra sobre Estrategia

El objetivo de estas recomendaciones no es imponer mi forma de organizar los archivos en tu sistema ni pretendo afirmar que esta sea la forma estándar de hacerlo. Mi intención es proporcionar un punto de partida que te permita mantener tus proyectos fácilmente.

En última instancia, el objetivo es reducir las necesidades e inversión en las labores de mantenimiento tanto como sea posible. Habiendo definido claramente convenciones de nomenclatura y con un nivel de organización que te permita saber exactamente cómo y dónde colocaste los archivos sin necesidad de hacer conjeturas, y permitir además que tus colaboradores o equipo puedan saber dónde enfocarse para localizar los problemas según sugen.


Documentos de Referencia

Uno de los retos que cara de desarrolladores es asegurarse de que estén familiarizados con las formas adecuadas para aprovechar la plataforma que está trabajando.

En su mayor parte, cada idioma, marco y biblioteca incluyen algún tipo de documentación y WordPress no es diferente. La cosa es, WordPress es compuesto por varias piezas diferentes - no sólo está la aplicación construida con PHP, pero hay aplicaciones específicas API, así como las bibliotecas como jQuery que son necesarias para tener como referencias.

Porque tarda mucho tiempo para familiarizarse íntimamente con los pormenores de cada idioma, la aplicación y la biblioteca, los desarrolladores de WordPress profesionales suelen tienen referencias fácilmente disponibles. Para los desarrolladores de WordPress, las siguientes referencias son extremadamente valiosas.

  • PHP. Obviamente, el lenguaje en el que WordPress es valioso. Tener el manual disponible para la revisión de las funciones y clases es importante especialmente si usted está operando fuera de la API estándar de WordPress.
  • Estándares de codificación. Uno de los mayores problemas en el desarrollo de WordPress es que los desarrolladores a menudo no aplican normas de codificación para su trabajo (yo solía ser culpable de esto, también!). Siguiendo un estándar, nos estamos asegurando que todo nuestro código tienen el mismo aspecto y así hacer más fácil contribuir a la comunidad que así lo desean. Si nada más, es para limpieza de código.
  • WordPress API. Esto debería ser una obviedad, pero asegurándose de que está trabajando correctamente con los diferentes objetos de WordPress es necesario para el desarrollo profesional. Sólo porque usted puede evitarlo no significa que usted debe. Las probabilidades son, si hay un método que necesita, ya está disponible como parte de la base API.
  • API de jQuery. jQuery es la librería de JavaScript que viene con WordPress y que utiliza para la funcionalidad dentro de la consola y dentro de muchos temas y plugins. Es mejor no intentar traer su propia variante de JavaScript a la mezcla, pero con lo que se proporciona.

En su mayor parte, eso es todo - marcarlos han fácilmente disponibles en su IDE (si lo soporta), pasan su tiempo en cada uno de ellos y usted estará bien en su manera a las prácticas de desarrollo más profesionales.

Como estrategias, esto cubre. En pocas palabras, tienen una forma definida para organizar y nombrar sus archivos, asegúrese de que usted siga las mejores prácticas de la base API de WordPress y estar seguro para referirse a los distintos documentos de lenguaje API al generar tu trabajo, y vas a estar en una posición mucho mejor que simplemente su obra de la banda.

En el siguiente artículo, a echar un vistazo en varios ambientes, control de versiones, cómo se relacionan, y cómo puede aprovechar mejor en el desarrollo, pruebas y en la versión final.

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Scroll to top
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.