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

Crear temas mantenibles para WordPress: Convenciones de nomenclatura

by
Length:MediumLanguages:
This post is part of a series called Writing Maintainable WordPress Themes.
Writing Maintainable WordPress Themes: Directories
Writing Maintainable WordPress Themes: Tools

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

En la primera parte de esta serie, revisamos algunas estrategias disponibles en relación a la organización de los directorios de nuestros temas para hacerlos más mantenibles.

Concretamente, vimos cómo organizar:

  1. Archivos JavaScript y CSS
  2. Plantillas y partes de plantillas
  3. Traducciones
  4. Archivos auxiliares y funciones de utilidad
  5. Librerías de terceros

En último término, el objetivo era proporcionar una estructura de directorio en la que pudiésemos organizar nuestros archivos de una forma coherente, comprensible y mantenible en los proyectos en los que trabajemos.

Pero para crear temas WordPress mantenibles no basta con esto. También hay que seguir las convenciones establecidas por los Estándares de Código de WordPress; sin embargo, en este artículo no vamos a ver los estándares. El Codex hace lo hace bastante bien y nosotros ya lo revisamos en otra serie de tutoriales.

En lugar de eso, vamos a ver algunas estrategias y herramientas más específicas que podemos usar para asegurarnos de que estamos creando temas que sean tan mantenibles como sea posible. En este artículo en concreto, vamos a cubrir estrategias, y después cerraremos la serie echando un vistazo a algunas herramientas disponibles.

Aumentar la mantenibilidad

Tal y como hemos mencionado anteriormente, una cosa es tener una forma lógica de organizar todos los directorios, archivos y librerías que conforman el tema; sin embargo, esto es sólo la mitad de lo que implica la construcción de un tema.

Después de todo, existen plantillas predefinidas, funciones, convenciones de nomenclatura, y herramientas que contribuyen o bien a construir nuestro tema o a asegurarnos de que no está usando ningún método obsoleto de llamada a la API y de que es compatible con la última versión de WordPress.

Para ello, creo que es importante comprender cada uno de estos asuntos como alguien que se está iniciando en la construcción de temas para WordPress, o como alguien que ha estado haciéndolo durante algún tiempo.

Después de todo, nunca hay un momento mejor que otro para mejorar en aquello a lo que te estés dedicando. Además, los comentarios son también  un lugar excelente en el que continuar el debate y compartir alternativas o puntos de vista.

Pero antes de llegar ahí, hablemos sobre algunas cosas prácticas que podemos hacer relacionadas con la creación de temas para WordPress, y que aumentan la mantenibilidad de lo que estamos haciendo.

Plantillas

Primero, si no estás familiarizado con la jerarquía de las plantillas, te recomiendo que leas la correspondiente página del Codex antes de continuar con este artículo.

Dicho en pocas palabras, las plantillas pueden describirse como sigue:

Las plantillas de WordPress encajan unas con otras como piezas de un puzzle para generar las páginas web de tu sitio WordPress. Algunas plantillas (los archivos de plantilla del header y el footer por ejemplo) se usan en todas las páginas de un sitio web, mientras que otras se usan sólo en situaciones concretas.

Otra forma de enfocar esto es: En lo que a WordPress respecta, todo lo que se le muestra al usuario proviene de la base de datos. En esto se incluye el título del post, los datos del post, las categorías del post, el contenido del post, los comentarios, etc.

Las plantillas son vehículos a través de los cuales se presenta la información a los usuarios. Están compuestas con código HTML y PHP, los estilos se aplican mediante CSS, y también podrían tener aplicados algunos efectos vía JavaScript.

Pero, asumiendo que no estés haciendo nada avanzado como crear tipos de entradas personalizadas y/o taxonomías personalizadas (este es un tema para otro tutorial), solo existe una cosa sobre la jerarquía de las plantillas de WordPress que puede constituir tanto un lujo como un problema para el mantenimiento, dependiendo de cómo lo enfoques.

Observa que en el artículo del Codex que hemos enlazado antes se indica que, WordPress contiene las plantillas predeterminadas index.phpheader.php, y footer.php. Lo cierto es que, realmente puedes crear un tema WordPress completo usando únicamente index.php.

Suena interesante, ¿no? Me refiero a que, quién necesita crear tantos archivos distintos cuando podrías crear un tema ligero y pequeño que haga todo lo que necesitas.

Pero piénsalo después desde la perspectiva de que tuviese que trabajar ya sea con un equipo externo o con tus propios colegas, o con aquellos que contribuyen a un repositorio, o con aquellos que puedan continuar en un momento dado tu trabajo allí donde tu lo dejes.

Si todo el código que se necesita para presentar la información extraída de la base de datos está contenida en un solo archivo, las posibilidades de que la complejidad de ese archivo vaya aumentando desde su creación son muy altas.

En su forma más básica, será un archivo que contendrá cierto número de condicionales, probablemente algunas declaraciones, etc. Y todo esto se hace porque tienes que tener en cuenta las páginas de archivo, las páginas de las entradas o "single posts", el listado principal, y así sucesivamente.

¿Entiendes a lo que me refiero?

Pero después, crear archivos independientes solo para mitigar esta complejidad puede ser una bestia por sí mismo. Por ejemplo, imagina que tienes un archivo single.php para mostrar una entrada y otro page.php para mostrar una página, y que ambas plantillas tienen exactamente la misma información a excepción de que single.php tiene metadatos de entrada y page.php no.

Esto es solo un ejemplo sobre cuándo te podría interesar extraer los meta datos de las entrada a su propio archivo parcial, tal y como explicamos en el artículo anterior. O quizá podrías extraer el código responsable de renderizar el propio contenido a su parcial independiente.

Sea cual sea la situación, lo que quiero destacar es que debes buscar el equilibrio cuando trabajes con plantillas de WordPress y su jerarquía.

No creo que sea buena idea usar una cantidad mínima de plantillas, pero tampoco creo que sea necesario usar cualquier plantilla posible si esto genera una excesiva duplicidad de código. Debe haber un equilibrio entre las plantillas y los elementos parciales.

En último término, creo que la experiencia en cómo usar cada uno se va adquiriendo con el tiempo, aunque tener en cuenta este marco de referencia puede ayudarte a proporcionar un nivel de organización y mantenibilidad que salta y pone límites por anticipado que empieces a hacer cosas 

Funciones de nomenclatura

En lo que respecta al trabajo con funciones y convenciones de nomenclatura, habitualmente existen dos reglas a seguir:

  1. las funciones deben tener nombres únicos,
  2. nómbralas adecuadamente para indicar qué datos devolverán (return) y qué datos mostrarán (echo)

Pero si eres alguien que acaba de empezar en el desarrollo de temas, o alguien que quiere mejorar sus habilidades, ¿qué es esto en la práctica?

Cuando se trata de asignar nombres únicos a tus funciones, las razones para hacerlo es no crear accidentalmente conflictos con funciones preexistentes definidas en el propio WordPress o en un plugin que esté funcionando en el entorno de tu proyecto.

Por ejemplo, imagina que vas a escribir tu propia función para filtrar el contenido antes de renderizarlo en la página. La forma correcta de hacerlo es, obviamente, usando la función add_filter; sin embargo, ¿nombrarías a tu función como the_content?

No, por supuesto que no. Porque WordPress ya contiene una función denominada the_content. Si usas ese nombre en otra función, obtendrás errores. Por eso, es mejor añadir siempre un prefijo a tus funciones con una clave única, por ejemplo, el nombre de tu tema o algo similar.

Así que, imagina que queremos añadir una firma de autor al final de nuestro contenido, y que tenemos un tema al que llamamos Acme. Para lograr esto, te recomiendo crear una función llamada acme_the_content ya que así se identificará como una función del tema e indicará a su vez el nombre de la función a la que se enganchará.

Imagina que quieres que en cada entrada parezca tu nombre y tu usuario de Twitter. Para conseguirlo, podrías definir esto en tu archivo functions.php:

Es bastante sencillo, ¿no? Resumiendo, intento usar un formato estándar cuando creo las funciones propias que voy a enganchar: nombre_tema-nombre_del_hook.

Esto hace que sea bastante sencillo comprender y seguir no solo cuando navegas a través del código sino también cuando visualizas las funciones que conforman el tema o el archivo que está activo en la actualidad en tu IDE.

Recuperar y devolver datos

Como he mencionado antes, WordPress usa otra convención relacionada con la información que recupera una determinada función o que devuelve.

Por fortuna, esta regla general es muy fácil de recordar:

  • Las funciones que recuperan o extraen datos tienen el prefijo get_
  • Las funciones que devuelven datos no presentan el prefijo get_

Es posible que encuentres algunas excepciones a esta regla, pero esta es la forma estándar indicada por la API de WordPress para proporcionarte datos una vez hayas invocado la función.

Para mantener la consistencia con nuestro anterior ejemplo, imagina que quieres devolver los datos tras invocar la función, entonces simplemente invocarías the_content(); sin embargo, si quisieses recuperar el contenido de una entrada que, por ejemplo, pertenece a un loop personalizado, usarías get_the_content() y lo almacenarías en tu propia variable.

Quizá algo parecido a esto: $content_for_later = get_the_content(). Ahora has leído los datos para el contenido que está actualmente relacionado con la entrada activa en el loop y los has almacenado en una variable que podrás usar posteriormente.

Pero conocer cómo nombra WordPress sus funciones es solo la mitad del asunto. Después de todo, estás planeando construir un tema o un plugin y quieres asegurarte de mantener la consistencia empleando la misma "forma" de hacer las cosas que usa WordPress, ¿no?

En ese caso: en el ejemplo que pusimos antes, donde filtramos el contenido, usamos un prefijo para la función de tal manera que su nombre fuese acme_the_content, y que indica que el tema Acme va a devolver el contenido desde cualquier lugar del tema en el que se invoque la función.

¿Qué pasaría si nombrásemos la función acme_get_the_content()

Bueno, en términos técnicos, la función también mostraría los datos allí donde se invocase; sin embargo, sería incoherente con la API de WordPress ya que el desarrollador esperaría que los datos devueltos pueden ser almacenados en una variable o pasados a otra función.

Hay una inconsistencia entre lo que el usuario espera que suceda y lo que ocurre en realidad.

Si estuviésemos hablando de algo del mundo real, entonces esto sería como un interruptor de pared que el usuario espera que al ser pulsado encienda una luz o un ventilador en la habitación, pero que en realidad, o no hace nada, o enciende la luz o el ventilador de otra habitación.

Por eso necesitamos tener cuidado con la nomenclatura de nuestras funciones de modo que las funciones que creamos no ocasionen conflictos con otras, pero a su vez, deben tener nombres clarificadores, e indicar cómo gestionarán la información cuando las invoquemos.

¿Qué herramientas de ayuda existen?

Tal y como he mencionado al principio de este artículo, también existen varias herramientas y ajustes que podemos instalar y configurar en nuestro entorno de desarrollo para ayudarnos a detectar cualquier problema potencial antes de lanzar nuestro tema.

Esto significa que podremos identificar funciones que en última instancia serán eliminadas de WordPress para que no escribamos código obsoleto. Además, existen formas de saber si las variables a las que intentamos acceder no tienen, por ejemplo, índices definidos, u otras características similares.

En el próximo, y último artículo de esta serie, vamos a echar precisamente un vistazo a todo esto. Mientras tanto, repasa lo que hemos visto aquí, y envíanos a través de la siguiente sección, cualquier duda o comentario que desees, y la próxima semana intentaremos hacer un resumen de todo el contenido de esta serie.

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.