Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress
Code

Crear temas mantenibles para WordPress: Directorios

by
Length:LongLanguages:
This post is part of a series called Writing Maintainable WordPress Themes.
Writing Maintainable WordPress Themes: Naming Conventions

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

Cuando creamos temas para WordPress - como ocurre con otro tipo de cosas - existen formas correctas e incorrectas de hacerlo. Aquellos que queremos ser desarrolladores profesionales de WordPress, aquellos que nos preocupa verdaderamente el trabajo que realizamos, y aquellos que queremos que este perdure, debemos planificar con anticipación cómo vamos a organizar los archivos y el código de nuestro tema.

Sí, el Codex de WordPress ofrece un artículo fantástico sobre el Desarrollo de Temas, y creo que es una lectura obligatoria para cualquiera que quiera introducirse en la creación de temas - especialmente en los temas premium - pero hay algunas estrategias relacionadas con la creación, la publicación y el mantenimiento a largo plazo de los temas no cubiertas en dicho artículo que me parecen muy útiles.

En los dos próximos artículos vamos a ver algunas estrategias que profundizan un poco más en el desarrollo de temas y que nos ayudarán a estructurar nuestros temas de manera que sigan las pautas del Codex de WordPress, y también que logren que sean mucho más fáciles de mantener, actualizar, y mejorar conforme WordPress evoluciona, y conforme madura nuestro tema.

Unas palabras sobre prácticas durante el desarrollo de temas

La calidad de la organización de los archivos y el código que intervienen en la creación de un tema WordPress es, de alguna manera, un tema polémico.

Para ser claros, esta es una de esas cosas que los desarrolladores y diseñadores debaten hasta el punto de que se ha convertido en un tema controvertido. Es decir, algunos hablarán a menudo sobre la mala calidad de los temas disponibles para WordPress, y usarán este argumento para afirmar que WordPress es una plataforma pobre o mediocre tanto para la creación de blogs, como para otros fines.

Este no es el objetivo ni el argumento de lo que vamos a debatir aquí, ni pretende propiciar ese tipo de discusión en los comentarios. En lugar de eso, esta serie de dos partes asume lo siguiente:

  • Que eres un desarrollador WordPress que ha construido o pretende construir temas,
  • que eres un desarrollador WordPress que ya conoce los aspectos fundamentales de desarrollo cubiertos en el Codex,
  • que eres un desarrollador WordPress que busca formas de mejorar sus procesos y sus estructuras organizativas actuales para crear productos más sólidos.

Por supuesto, todos tenemos nuestras maneras de hacer las cosas, por tanto las recomendaciones que proponemos en esta serie podrían no funcionar en tu actual flujo de trabajo. Quizá no desees hacer cambios - ¡algo legítimo! - o quizá estés buscando precisamente eso.

Sea como sea, todo lo que comparto aquí está basado en mi experiencia en la creación y el mantenimiento de temas premium para WordPress y me ha facilitado bastante su actualización a lo largo del tiempo tanto desde el punto de vista del tema en sí, como desde la perspectiva de la compatibilidad con WordPress.

Todo sobre el mantenimiento

Una de las partes más duras en la creación de software no es el envío de la versión inicial (aunque sí es una tarea ardua en sí), sino el mantenimiento tras el lanzamiento.

No solo implica asegurarse de que el código base continúa siendo compatible con la estructura subyacente - algo de lo que hablaremos en la siguiente sección - sino también cerciorarse de que los archivos están organizados de manera que sean comprensibles para todo el equipo de desarrollo, que tienen cierto nivel de cohesión, y de que la forma en la que son nombrados y la organización de su ubicación tienen un sentido.

Ya sabemos gracias al Codex que existen varios archivos que componen el núcleo del tema. Esto incluye plantillas, un archivo de funciones, y una hoja de estilos como mínimo.

Pero, ¿qué pasa cuando tu tema se va complicando? Digamos que…

  • ¿Has introducido un tipo de preprocesador como LESS o Sass?
  • ¿Qué hay de la minimización de tu código JavaScript?
  • ¿Qué hay de los parciales - o partes reutilizables para las plantillas - que se usan en todo el tema?
  • ¿Tienen las traducciones algún lugar especial en el que deban ser ubicadas?
  • ¿Qué hay de las funciones auxiliares y de aquellas empleadas para mantener separada la lógica del negocio de la lógica de presentación?
  • ¿Qué pasa cuando introduces librerías de terceros?

Todo lo anterior puede organizarse claramente dentro del directorio de un tema WordPress. Echaremos un vistazo a cada una de estas cosas con más detalle y la lógica que hay detrás de sus ubicaciones dentro del directorio del tema con el objetivo de lograr un desarrollo de temas más limpio y que simplifique su mantenimiento posterior.

1. Hojas de estilo y JavaScript

Aunque en muchos contextos, las hojas de estilo y el JavaScript pueden discutirse de forma independiente puesto que se ocupan de cosas distintas, su estructura organizativa dentro de un tema es tan similar que resulta lógico hablar de ellos conjuntamente en este sentido.

Primero, asumiendo que estás usando algún tipo de preprocesador CSS, debería existir un directorio para cada unos de estos tipos de archivos. Es decir, deberías tener un directorio css y otro js (o quizá los hayas denominado styles y javascript).

Sea como sea, cada tipo de archivo debería residir en su propio directorio. A partir de aquí, puedes usar functions.php para registrar y encolar archivos conforme los necesites. Si se trata de un archivo utilizado a lo largo del tema, sin duda lo registrarás.

Pero si se trata de un estilo o un script que solo se usa en una plantilla concreta, en un tipo de entrada, o en una parte del escritorio, entonces podrías - o deberías - encolar el archivo de forma condicional.

Pero imagina que estás usando un preprocesador. En este punto, tendrás tu archivo preprocesado y tus archivos postprocesados. Dependiendo de la naturaleza de tu proyecto, podrías tener, o no, todo reducido a un archivo.

Yo haría una recomendación sobre cómo nombrar los archivos; sin embargo, hay que tener en consideración las diferencias en los temas, la forma en la que la gente construye su trabajo, y el problema que un tema concreto intenta resolver, y esto va más allá del ámbito de esta estrategia concreta.

De cualquier forma, si vas a usar un preprocesador, te recomendaría crear un subdirectorio dentro de los directorios del css y js llamado dev (o development o como más te guste). En este directorio, escribirás todos tus archivos preprocesados, después dejarás que la herramienta de tu elección (ya sea CodeKit, Grunt, o similares) den salida a tu o tus archivos procesados en la raíz de los directorios css y js.

De esta forma, todavía conservarás código procesado, combinado y/o minimizado, y un directorio que contiene el origen de esos archivos. Cuando llegue el momento de enviar el tema, tendrás el archivo functions.php invocando a otros archivos desde sus respectivos directorios, y también podrás excluir el directorio dev del producto final de manera que el usuario obtenga un paquete más pequeño, que contendrá simplemente lo que necesita para ejecutar el tema.

2. Partes de plantillas

Normalmente nos referimos a las partes de plantillas como "partials" (más en otros lenguajes que en WordPress) y con frecuencia, estas partes son invocadas en WordPress usando get_template_part. En pocas palabras, contienen código que es empleado en repetidas ocasiones por nuestro tema y podemos incorporarlo en sus distintas plantillas.

Un ejemplo de esto podrían ser los meta datos de las entradas. Estos metadatos suelen incluir la siguiente información:

  • El nombre del autor.
  • La fecha de publicación de la entrada.
  • La categoría y las etiquetas asignadas la entrada.
  • Si la entrada contiene o no comentarios, y en caso afirmativo, su número.

Como esta información puede existir en distintas plantillas (por ej. en las entradas individuales, en las páginas, en las páginas de archivo, etc.) tendría sentido extraerla e incluirla en un único archivo al que posteriormente podamos acudir cuando lo necesitemos.

El asunto es que, los meta datos de entradas no son el único tipo de información que se reutiliza en un tema. Por tanto, tenemos que identificar los elementos principales que vamos a reutilizar, extraerlos en un archivo, y crear un directorio partials.

A partir de aquí, nombra cada plantilla de alguna manera que identifique lo que representa (por ej. post-meta.php, gravatar.php, navigation.php, pagination.php, etc.) y después invoca cada partial en la plantilla en la que sea necesario.

Por ejemplo, en plantillas de entradas, páginas, y archivos, puedes usar get_template_part( 'partials/post-meta' );. Facilita la comprensión y crea un único sitio en el que realizar los cambios en lugar de tener que modificar todas las plantillas.

3. Traducciones

Si estás escribiendo un tema internacionalizado que, si lo vas a lanzar públicamente (algo que deberías hacer), hay una forma clara y limpia de hacerlo.

Primero, si este tema es nuevo para ti, te recomiendo leer el artículo del Códex. Este te mostrará todo lo que debes saber sobre cómo preparar las cadenas para la traducción, las herramientas disponibles, etc.

Después, te recomiendo que te asegures de contar con un lugar en tu tema dedicado a los idiomas. En términos generales, te recomiendo crear un directorio en tu tema denominado lang o languages, después incluye en él los archivos .po y .mo para las traducciones. Es una práctica ampliamente aceptada y esperada dentro de la comunidad WordPress.

Esto no solo relega las traducciones a un lugar propio dentro de la estructura del tema, sino que también indica a otros dónde pueden localizar las traducciones y dónde buscar los archivos que contienen las cadenas a traducir.

De nuevo, se trata de coherencia y de asegurarnos que las cosas que tienen una utilidad similar están agrupadas juntas y de una forma lógica.

4. Archivos auxiliares y funciones de utilidad

Dependiendo de tu experiencia en desarrollo, las funciones que uses para ayudarte a realizar tu trabajo y a separar la lógica del negocio de la de la presentación (en la mayoría de los casos, el PHP del HTML), son denominadas funciones de utilidad.

Para esta serie, nos referiremos a ellas como funciones auxiliares.

Pero esto plantea dos preguntas:

  1. ¿No deberían residir en functions.php?
  2. Si no residen en functions.php, ¿dónde lo hacen?

En mi opinión las funciones auxiliares y de utilidad no deberían residir en functions.php. Mi norma general es esta: si el código que estoy escribiendo se comunica directamente con WordPress, como add_theme_support, entonces pertenece a functions.php. Pero si el código que escribo va a ser ejecutado en una cadena personalizada que extrae información y devuelve el resultado procesado a la plantilla (o a parte de una plantilla), entonces pertenece a una función auxiliar.

De la misma manera que WordPress tiene etiquetas o funciones de plantilla que se pueden invocar a través de una plantilla, como the_content(), trata a las funciones auxiliares de una forma similar - puedes invocarlas en tus plantillas y en tus partials, pero estarán ubicadas en sus propios archivos.

Como estas funciones auxiliares no viven en functions.php, deberían residir en sus propios archivos y estos archivos deberían ser referenciados en algún lugar del código base de tu tema, ¿no? Además de esto, también es completamente posible dividir más allá tus auxiliares en múltiples archivos según la complejidad de tu tema.

Para este propósito, te recomiendo introducir un directorio inc o includes dentro del núcleo de tu tema. A partir de aquí, coloca tus archivos auxiliares en este directorio y sencillamente include_once (incluye una vez) el auxiliar en la parte superior de tu archivo de funciones, la funciones serán fácilmente accesibles para el resto de tu tema.

5. Librerías de terceros

Por último, hay ocasiones en las que incluiremos librerías de terceros en nuestros temas. Es decir, se trata de herramientas desarrolladas por otras personas, disponibles de forma gratuita para su uso y distribución y que además nos permiten aprovechar el trabajo realizado por otros.

Entonces, ¿dónde deberían residir? Honestamente, depende del tipo de librería con el que estés trabajando. Las librerías pueden venir en forma de CSS, JavaScript, o PHP. Por tanto, debería existir un lugar para esto:

  • Si estás trabajando con una librería JavaScript, entonces crea un directorio lib dentro de tu directorio js. Esto indica que la carpeta contiene librerías JavaScript.
  • De igual manera, si estás haciendo algo similar con CSS - como incorporar fuentes de iconos - entonces crea un directorio lib dentro de tu directorio css. De nuevo, esto indicará que tienes una librería CSS.
  • Si estás incorporando una librería PHP, entonces te recomiendo crear un directorio lib dentro del directorio raíz de tu tema. Esto indicará que no existe JavaScript ni CSS y que lo que incluye contribuye a la funcionalidad del núcleo del tema (principalmente compuesta por funciones PHP de llamada, etiquetas de plantilla, etc.).

Por supuesto, también he visto como algunos desarrolladores crean un directorio lib y después crean subdirectorios js, css, y php dentro de éste. Es una especie de inversión de los consejos que hemos indicado antes.

No es una mala estrategia; sin embargo, la razón por la que no me convence este enfoque es porque despliega los archivos JavaScript, CSS y PHP en distintos directorios del tema.

Compatibilidad con WordPress

Crear una estructura de directorios organizada es solo una parte del asunto. WordPress tiene una jerarquía de plantillas que requiere unas convenciones de nomenclatura concretas. ¿No deberían seguir también esta lógica nuestros archivos personalizados?

Más aún, ¿qué hay de las convenciones para los nombres de las funciones? ¿Muestran datos (echo) o devuelven (return) datos? Además, ¿cómo sabemos que estamos realizando llamadas de función de API adecuadas y que no estamos usando características obsoletas de WordPress?

En el próximo artículo hablaremos de todo esto y también sobre herramientas que podemos instalar para ayudarnos a evitar estos escollos. También veremos cómo funcionan y por qué es importante seguir las convenciones de nomenclatura en las funciones cuando creamos nuestros temas.

Sin embargo, de momento, hemos visto estrategias para organizar los archivos que deberían bastarnos para estar ocupados hasta la publicación del próximo artículo de esta serie.

Como ya es costumbre, si quieres añadir alguna observación ¡deja un comentario por favor!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.