Los que me sigáis, y los que me conocéis, sabéis que en el asunto de implementación de una Web soy, visto desde fuera, un poco radical. Siempre que puedo defiendo Genesis Framework como mejor plataforma para implementar una Web y, salvo excepciones, siempre que hago una nueva Web o migro una para un cliente, lo hago con este framework. Dónde otros ven radicalismo yo veo pragmatismo.
Hoy voy a hablar de los distintos tipos de themes o plantillas que existen en el ecosistema de WordPress: Themes, Parent Themes, Childs Themes, Framework Themes y Starter Themes.
Si eres un neófito, o únicamente te interesa WordPress para crear un blog, seguramente de lo que habrás oído hablar sea de las plantillas o Themes, y lo cierto es que bajo ese término se engloban los distintos tipos de Themes existentes, todos dentro del mismo saco.
A esa confusión ayuda que las diferencias entre unos y otros, al menos desde un punto de vista de aspecto, sean muy escasas y también que, en algunos casos, una plantilla puede estar en dos o más tipologías. Así que vamos a por ello
Themes
Podemos definir un Theme como el conjunto de archivos (php, js, css…) que dan apariencia a nuestro WordPress. Algo importante, un Theme, así a secas, no depende de ningún otro y está formado, como mínimo, por un archivo css llamado stile.css en el que, además de la configuración de los estilos (tamaños de fuentes, colores, cabeceras, enlaces….) está la información propia del Theme, o sea el nombre, el autor, la versión…
Dos cosas muy importantes:
- Un Theme no debería de traer consigo funcionalidades, de eso ya os hablé en otro artículo.
- Nunca, nunca, nunca deberíamos de modificar ninguno de los archivos de ese Theme, ni los css para cambiar su aspecto, ni los php ni javaScript para añadir o quitar funcionalidades. ¿Por qué? porque cada vez que el autor publique una nueva versión del Theme si este se actualiza machacará los cambios que hemos hecho, o tendremos que renunciar a actualizarlo, con el peligro que esto conlleva para la seguridad de nuestra instalación de WordPress.
En fin que si lo que queremos es realizar cambios en un Theme, lo que deberemos hacer es crear un tema hijo (Child Theme) copia del original, tema original que pasará a denominarse tema padre o Parent Theme. A partir de ese momento, y una vez activado el Child Theme, todos los cambios en estilos y funciones los haremos sobre los archivos del mismo y nunca sobre los del Parent.
Parent Themes
Acabamos de ver que un Theme, a secas, es algo muy limitado, porque no podemos, mejor dicho, no debemos, modificar su aspecto o funcionalidad mediante código. De forma que si queremos hacer este tipo de modificaciones deberíamos crear un Child Theme.
Por tanto, podemos definir un Parent Theme como aquel al que se le ha hecho un Child Theme, la verdad es que, salvo que estés en la nave Enterprise donde esto es posible, un Parent Theme debería llamarse realmente “Mother Theme”, pero mejor no entrar en ese tipo de discusiones de género… 🙂
No hay que modificar nada, y la razón de un Parent es esa, que no se modifique ni una línea de código en el Theme. Para que se convierta en Parent, tan sólo hay que crear un Child y este será el que modifiquemos. O sea, que para que un Theme pase a ser Parent Theme, alguien le tiene que “hacer un hijo”.
Child Themes
Digamos que, en su concepción un Child Theme es un “clon” del Parent Theme, pero que en su desarrollo adquiere nuevas propiedades y funcionalidades que no tiene su “padre/madre”. Es decir, por defecto, hereda todas las funcionalidades y estilos del Parent, pero luego, al modificarse su código, adquiere un nuevo aspecto y nuevas “habilidades”. Por ejemplo:
- Si tenemos un Parent Theme con una única área de Widgets y queremos añadir dos áreas de Widgets adicionales, crearemos un Child Theme copia del original y, en el archivo functions.php definiremos las dos nuevas áreas de Widget, a las que además, aplicaremos los estilos que deseemos en el archivo style.css del Child Theme.
- Si deseamos que el H1 de nuestra Web en vez de ser de color negro, sea de color Carmesí, pues entonces en el archivo style.css de nuestro Child Theme, definiremos esa propiedad para la clase .H1, o cualquier otro cambio de estilo que deseemos aplicar a nuestro Theme, como el color de fondo.
De esto podemos sacar una conclusión: el Child Theme dependerá del Parent Theme en todo aquello que no se modifique en el primero, es decir, que si se realiza algún cambio de función o de estilo en el Child Theme este cambio, cuál hijo contestón, prevalecerá sobre lo que diga el padre, aunque este último se actualice o modifique. Evidentemente, si añadimos algo al Child que no estuviera en el Parent, se mantendrá siempre hasta que lo modifiquemos.
Y una cosa muy importante, un Child Theme no puede tener Childs Themes, le ocurre como a las mulas. Así que no trateis de perpetuar la especie 🙂
Framework Themes
Y ahora vamos a hablar de una nueva especie, de los X-Men de los Themes, los Framework Themes (Genesis es uno de ellos).
Un Framework Theme es una especie de “Super Parent Theme”, se instala igual que un Theme normal y su misión en la vida es la de dotar de una capa adicional de funcionalidades adicionales que no están en el core de WordPress. Un Framework no se personaliza, para eso trabajaremos con Childs Themes que dependerán de él.
La idea de estos X-Themes es la de funcionar como Parent Themes que dotan a sus hijos de esas funcionalidades de las que WordPress no es capaz. Por ejemplo Genesis, ya os hablé de ello en otro artículo, añade a WordPress, en comparación con otros Themes y Frameworks del mercado: Ligereza, adaptabilidad, accesibilidad, seguridad…
Si trabajamos con un Framework, estaremos obteniendo lo mejor de dos mundos, tendremos un núcleo potente: el Framework, que funcionará como Parent Theme y sobre el que no trabajaremos, pero a cambio podrá actualizarse, y un Child Theme que aprovechará toda la potencia, actual y futura, del Framework y que será la capa que personalizamos para poner el sitio Web a nuestro gusto.
Eso sí, una vez que comencemos a personalizar nuestro Child Theme, este será eso, nuestro, es decir, no deberemos actualizarlo nunca jamás. Pero tranquilos, que los Child Themes creados ex profeso no suelen actualizarse, entre otras razones porque no tienen, o mejor dicho, no deberían tener ninguna funcionalidad, únicamente deben tener aspecto.
Llevado a la vida real, el Framework es como los estudios y el Child como la ropa que te pones. De base haces la primaria y cuando vas creciendo, pasas por el bachillerato, la universidad, aprendes a conducir… es decir vas actualizando tu Framework, a la vez, según creces, cambias de ropa y de estilo de la misma, te cortas el pelo o te lo dejas largo… eso es el Child.
El ecosistema Framework es como en Matrix, el Framework cargaba a Neo de nuevas habilidades y de armas y el Child era la gabardina negra y las gafas (un Child un poco limitado pero es lo que había).
Y vale, Genesis no es el único Framework que existe, algunos otros que, como mínimo, tienes que evaluar como StoreFront, de WooThemes, los creadores de WooCommerce, Thematic o Alien Ship.
Y esto nos lleva al último tipo de Themes que podemos encontrar en WordPress, los Starter Themes.
Starter Themes
Venga, vamos a liarlo un poco, así sin más, cualquiera de los Themes que hemos hablado antes en el momento que lo modificamos se convierte en un Starter Theme, es decir, a lo bruto, si modificamos un Theme, lo convertimos, al menos en teoría, en un Starter Theme.
Vale esto es muy radical, así que vamos a restringir un poco el ámbito. Un Starter Theme es aquel diseñado para ser modificado y nunca, nunca, nunca ser actualizado. Está pensado con dos premisas principales: Ser la base para el desarrollo de cualquier Theme y / o ser un Child Theme.
Si, por ejemplo, desarrollas Themes para WordPress y siempre usas unos elementos mínimos, seguro que tendrás ya creado un Starter Theme, o tiraras de uno creado por otro desarrollador, pero que es el que tiene lo mínimo de lo mínimo para comenzar. Posiblemente no tenga ni estilos, o tenga los mínimos pero te vale para eso, para comenzar.
Un ejemplo es _s, también conocido como Underscores, un proyecto creado por el equipo de Automattic, la empresa que creó y mantiene WordPress. Underscores proporciona los archivos necesarios para poder crear tu propio Theme. si entras en la Web, podrás definir y descargar tu propio Starter Theme con tu nombre.
Otros ejemplos de Starter Themes son los propios Childs de Genesis. Por lo general, están creados para ser personalizados y, hasta donde conozco, no se han actualizado nunca. Son simples, no contienen funcionalidades y su diseño cambia en función del desarrollador pero, eso si, son muy simples y modificables con facilidad, siempre que sepas de php y de css, claro.
Y otra ventaja: Son poco pesados, el más grande que conozco ocupa tan sólo 2.5 MB, Genesis 1.2MB, WordPress 4.7 28.6 MB y Divi, Divi ocupa 27.4 MB ¡¡¡Casi lo mismo que WordPress!!!.
Así que un Starter Theme, en cuanto lo creas y lo empiezas a modificar, se convierte en un Theme independiente del original y que nunca se actualizará. Es como he comentado antes una base para empezar a crear un Theme. A partir de un Starter Theme podemos, evidentemente crear un Parent, para ello deberíamos crear un Child Theme.
En resumen y siguiendo una evolución natural, la primera etapa podría ser un Starter Theme, a partir del cual crearemos un Theme, a secas, si le “hacemos un hijo» se convertirá en un Parent Theme que será el que se actualice. y si ese Parent Theme le dotamos de capacidades adicionales que no están en el core de WordPress, como por ejemplo nuevos Hooks o soporte para HTML5, CSS3 o Schema u optimización para funcionar con Woocomerce, estaremos ante un X-Theme, perdón ante un Framework Theme, que no deberá ser modificado si no usado en combinación con Child Themes, si modificamos cualquiera de ellos, nos volveremos a encontrar ante un Starter Theme, cuyas actualizaciones a partir de ese momento correrán de nuestra cuenta.
