Get_template_part tema hijo
Contents
Hoy en día, en la mayoría de los temas modernos de WordPress, la función get_template_part() es uno de sus elementos esenciales. Basta con repasar la estructura de, por ejemplo, los últimos temas oficiales (…, Fourteen, Fifteen, Sixteen), para darse cuenta de que los temas de WordPress han evolucionado, pasando de una estructura bastante monolítica a una estructura dirigida por contenidos y formatos. Y una de las claves de esta evolución es la función get_template_part ().
get_template_part() es en realidad un elemento inestimable de cualquier tema moderno de WordPress que a través de sus dos parámetros nos permite seleccionar dinámicamente qué archivo .php (qué parte) se va a cargar para mostrar la página actual (ver la documentación oficial para más información) sin embargo, una de sus características es que, como advierte la documentación oficial, get_template_part() falla silenciosamente, es decir, cuando la función no encuentra la parte, no dice nada, no devuelve ningún valor…
Pero esto no es del todo exacto porque, lo contrario también es cierto. Cuando get_template_part() encuentra la pieza, de hecho, no devuelve ningún valor aunque, por supuesto, la pieza está cargada para que, algo aparezca en la pantalla. En cualquier caso, la verdad es que get_template_part() nunca devuelve un valor. Entonces, partiendo de esta base, ¿cómo controlamos cuando la función falla? es decir, sin un valor devuelto, ¿cómo diferenciar cuando se ha cargado realmente una pieza o cuando en la pantalla no hay nada?
Localizar_plantilla
}Un buen caso de uso para esto sería si tienes una tienda en tu sitio y necesitas mostrar una imagen de cabecera diferente o un menú personalizado en la página de la tienda. Podrías añadir estas personalizaciones en header-shop.php y se mostraría en el lugar apropiado.Sin embargo, las etiquetas condicionales no se limitan a una página. Usted puede hacer varias declaraciones en una fila como así:if ( is_page(‘products’) ) {
Como puede ver, no hay nada demasiado sofisticado aquí: las llamadas habituales para la cabecera y el pie de página, y el bucle en el medio. La página en cuestión tiene este aspecto:La plantilla de página por defecto en el tema Twenty Twelve. (Ver versión grande)2. Copiar y renombrar el archivo de la plantillaDespués de identificar el archivo de la plantilla por defecto, es el momento de hacer una copia. Utilizaremos el archivo duplicado para realizar los cambios deseados en nuestra página. Para ello también tendremos que renombrarlo. No puedes tener dos archivos con el mismo nombre, eso sólo confunde a todo el mundo.Eres libre de darle al archivo el nombre que quieras siempre que no empiece con ninguno de los nombres de archivos de temas reservados. Así que no lo llames page-algo.php o cualquier otra cosa que haga pensar a WordPress que es un archivo de plantilla dedicado.Tiene sentido usar un nombre que identifique fácilmente para qué se usa este archivo de plantilla, como mi-plantilla-personalizada.php. En mi caso, usaré custom-full-width.php.3. Personalizar la cabecera del archivo de plantillaLuego tenemos que decirle a WordPress que este nuevo archivo es una plantilla de página personalizada. Para ello, tendremos que ajustar la cabecera del archivo de la siguiente manera:
WordPress get_template_part en la variable
Actualización: Este artículo ya está un poco anticuado. Desde hace unos meses, he dejado de usar Victoria Park y ahora uso un fork de Underscores de Automattic. Yo recomendaría empezar por ahí. Dicho esto, todo lo demás en el artículo sigue siendo válido.
Yo uso Victoria Park, un fork muy ligeramente modificado de Toolbox de Automattic, para todos mis proyectos. Pero de vez en cuando, cuando empiezo algo nuevo, voy a buscar un tema hecho a medida para la tarea en cuestión. Por ejemplo, si estoy creando un sitio para un portafolio o una base de conocimientos, a menudo busco una solución ya hecha, en lugar de empezar desde cero.
Utilizar un tema distinto al que has probado es como cocinar en la cocina de otro. Seguro que las cosas se cocinan, y lo más probable es que la comida salga bien, pero no será lo mismo. No encontrarás las mismas sartenes a las que estás acostumbrado, los fogones serán diferentes, la tabla de cortar será demasiado pequeña, los cuchillos no estarán afilados, etc. Cocinar en la cocina de otra persona no le resultará natural, como tampoco lo será utilizar el tema de WordPress de otra persona.
Get_template_part sin eco
get_footer();Como podéis ver, tenemos todas las partes que habíamos comentado anteriormente:Lo interesante aquí, obviamente, es la zona de «contenido» en index.php. En concreto, vemos que tenemos un pequeño control para saber si estamos viendo o no algún contenido válido (función have_posts del Loop de WordPress) y, dependiendo de si lo tenemos o no, cargamos una plantilla parcial (…/content) u otra (…/content-none).Si ahora echamos un vistazo a la plantilla parcial content.php, veremos a grandes rasgos lo siguiente:<article id=»post<?php the_ID(); ?>» <?php post_class(); ?>>
</articulo>Muy sencillo, ¿verdad? Todo lo que tenemos es una pequeña plantilla diseñada para renderizar contenido genérico de WordPress como, por ejemplo, una entrada de blog. Observe que el esqueleto HTML resultante no es más que una etiqueta de artículo con un título, su contenido y un pie de página, todo ello utilizando las etiquetas de plantilla de WordPress para extraer el contenido real.Por qué la API de WordPress es impresionanteIncluso si no supiera que todas estas funciones existen (get_header, get_footer, o la estrella de hoy: get_template_part), estoy bastante seguro de que habría organizado su código siguiendo un enfoque similar. Al fin y al cabo, parece bastante lógico crear una plantilla para la cabecera, otra para el pie de página, otra para el contenido… y luego tener un archivo especial o algo así que lo pegue todo, ¿no? Si hubieras seguido ese enfoque, apuesto a que tu archivo index.php habría tenido un aspecto parecido a este:require_once ‘header.php’;
