get_template_part vs ganchos de acción en temas

Me parece que ambos ofrecen la oportunidad para que el usuario final modifique un tema sin editar realmente los archivos de temas (a través de temas secundarios).

Mi pregunta es, es un método preferido sobre el otro.

Por ejemplo, tome un tema en el que estoy trabajando ahora. Estoy tratando de decidir si ir con partes de plantilla de ganchos.

<?php get_template_part('before_sitecontainer' ); ?>
<div id="sitecontainer" class="sitecontainer" <?php //closed in footer ?>>

<?php get_template_part( 'before_topcontainer' ); ?>
<div id="topcontainer ">

    <?php get_template_part( 'before_topedge_navigation' ); ?>
    <?php get_template_part( 'topedge_navigation' ); ?>

    <?php get_template_part( 'before_site_header' ); ?>
    <?php get_template_part( 'site_header' ); ?>

    <?php get_template_part( 'before_second_navigation' ); ?>
    <?php get_template_part( 'second_navigation' ); ?>

    <?php get_template_part( 'after_second_navigation' ); ?>

</div><!-- end topcontainer div -->
<?php get_template_part( 'after_topcontainer' ); ?>

Lo anterior permite al usuario del tema reemplazar cualquier sección del código existente simplemente creando un archivo con el nombre apropiado en su carpeta de tema secundario, así como agregando un nuevo código antes / después de cada sección preexistente por el mismo método: la plantilla antes / después los archivos de pieza no existen en absoluto en el tema principal y están ahí simplemente para permitirles insertar código, y este método no requiere que entiendan los ganchos / filtros para lograr esto.

Por supuesto, podría lograr lo mismo con ganchos y filtros.

¿Hay alguna ventaja de usar ganchos / filtros en su lugar? Teniendo en cuenta el público objetivo que usará esto, decididamente no es experto en códigos. Puedo darles instrucciones relativamente básicas que pueden seguir para usar el método de plantilla, pero casi seguramente los confundiré con ganchos.

¿O hay situaciones en las que una sería mejor que la otra dentro del mismo tema?

Prefiero ganchos, ya que son más flexibles: puedes conectarlos desde el functions.phparchivo de tu tema , pero también desde complementos. Intento poner tanta lógica en los complementos, para que los temas contengan principalmente elementos de diseño.

Si usa un gancho de acción, aún es posible usarlo get_template_part() en ese controlador de gancho . Esto te da lo mejor de ambos mundos. Probablemente incluso podría crear un enlace predeterminado que llame get_template_part(), para que las personas que no tienen mucha experiencia con la codificación puedan agregar archivos adicionales, y otros pueden eliminar este enlace si no lo desean.

Respecto al rendimiento: get_template_part()utiliza ( enlocate_template() ) file_exists()una, dos o cuatro veces (dependiendo de cómo lo llame). Parece que file_exists()es muy rápido y utiliza el almacenamiento en caché en PHP y tal vez incluso en el sistema operativo. Entonces eso probablemente no sea un problema.

Yo diría que la principal diferencia es la legibilidad. Si ve varias partes de plantilla bien nombradas, puede comprender lo que está sucediendo fácilmente. Si solo ve un gancho, deberá buscar en el resto del tema para establecer qué se adjunta al gancho.

Es (relativamente) fácil eliminar la función del enlace en el tema secundario, pero es mucho más difícil hacer que ignore la plantilla principal no deseada.

Esencialmente, trabajar con ganchos está más cerca del lado de PHP y trabajar con plantillas está más cerca del lado de HTML. Uso el tema padre híbrido, que está muy orientado al gancho. Es una bendición justo hasta que necesite deshacerse de la plantilla de algunos padres.

Para los usuarios que no son expertos en tecnología, tampoco es una buena opción. ¿Por qué tendrían que meterse con tales temas internos de todos modos?

PS también nota problemas de rendimiento. Las cosas con ganchos ocurren en la memoria, las cosas con plantillas requieren muchas búsquedas de disco. Especialmente si estás escribiendo algo como en tu ejemplo.

PPS no es la preferencia de todos ... pero en lugar de escribir el tema principal desde cero, ¿por qué no tomar el tema principal existente y proporcionar un tema secundario simple al usuario?