Cómo prevenir errores comunes en los temas de WordPress

 

 

 

  • ¡Registro!
  • Accesibilidad para diseñadores, con Stéphanie Walter

  • Índice
    1. 1. No reinventes la rueda gradualmente
    2. 2. Deja de predecir el futuro
    3. 3. La optimización prematura es la raíz de todos los males
    4. 4. Evite variables en archivos de plantilla
    5. 5.Asegúrate de estar actualizado
    6. 6. Utilice funciones nativas de WordPress cuando pueda
    7. 7. No construyas tu propio marco
      1. Problemas de mantenibilidad
      2. Territorio del complemento
      3. Mayor complejidad
    8. Conclusión
      1. Otras lecturas

    Al crear temas de WordPress gratuitos o premium, seguramente cometerás errores. WordPress tiene sus propios estándares de codificación y temática. Si bien puedes escribir PHP de la forma que desees en tus archivos de plantilla, es mejor seguir “la forma de WordPress”, incluso si no es necesariamente “la mejor manera”. En este artículo, Nauris Pūķis le mostrará cómo puede evitarlos para ahorrar tiempo y concentrarse en crear temas que la gente disfrutará usando.

     

    Si has estado pensando en crear temas de WordPress gratuitos o premium, espero poder ayudarte a evitar algunos de los errores que he cometido a lo largo de los años. Aunque siempre me esfuerzo por lograr un código bueno y limpio, hay actividades que de alguna manera me llevan a cometer errores. Espero poder ayudarte a evitarlos con la ayuda de este artículo.

    1. No reinventes la rueda gradualmente

    Tenga cuidado al hacer que las cosas se vean bien, especialmente si crea una función que hace casi exactamente lo mismo que otra función solo para envolver bien las cosas. Cuanto más código bonito agregues, más difícil será mantenerlo. Las pulsaciones de teclas por minuto no son el cuello de botella de su desempeño como desarrollador cuando pasa la mayor parte de su tiempo pensando en el código, sin escribirlo.

    He cometido este error muchas veces pensando que estaba secando el código.

    Por ejemplo, hice una función llamada get_portfolio_part($name, $slug). ¿Puedes adivinar lo que hizo? Sí. Es un envoltorio para ahorrarme la “molestia” de escribir algo extremadamente repetitivo get_template_part(“portfolio/$name”, $slug);. Esto es lo que yo llamo “reinvención gradual de la rueda”. Hace casi exactamente lo mismo que el original y al mismo tiempo complica la base del código.

    ¡No lo hagas! No es necesario guardar esas pocas pulsaciones de teclas. Va a ser difícil determinar la ruta real después de que haya pasado un año o cuando alguien más mire su código. Incluso si se pudiera argumentar que es simple y obvio, implicará analizar otra función más en la cabeza o pura conjetura para adivinar de dónde está obteniendo archivos esa función.

    Además de guardar algunos caracteres, recuerdo el argumento perfectamente válido para crear una get_portfolio_part()función en mi cabeza: ¿qué pasa si decido mover el directorio de la cartera en el futuro? Tendré que realizar una “búsqueda y reemplazo desagradable”.

    ¿Puedes adivinar cuántas veces he cambiado el nombre de ese directorio a lo largo de los años? Cero. Esto nos lleva al error número 2.

    2. Deja de predecir el futuro

    Los humanos son terribles a la hora de predecir el futuro. Sin embargo, como desarrolladores, intentamos hacerlo todo el tiempo.

    Por ejemplo, imagina que has elegido la opción para mostrar íconos sociales en algún lugar de tu publicación. Dejemos de lado la discusión sobre si eso es territorio de complementos o no. Imagínate que esto es lo que has decidido hacer. Entonces nuestra función hipotética se vería así:

    function has_social_icon($icon) { $icons = get_post_meta(get_the_ID(), 'post_social_icons', true); // do what has to be done with $icons return true; }

    Una idea muy típica pasa por mi mente ahora: "*Pero ¿qué pasa si quiero usar esta función fuera del bucle en algún momento en el futuro*?" Bueno, esto me llevó a una refactorización que se parece a esto:

    function has_social_icon($icon, $post_id = 0) { if( ! $post_id ) { $post_id = get_the_ID(); } $icons = get_post_meta($post_id, 'post_social_icons', true); // do what has to be done with $icons return true; }

    Y voilá*! Ahora has creado una hinchazón absolutamente innecesaria en nombre de un futuro inexistente. Este es un ejemplo muy simple de cómo suceden estas cosas, pero cuanto más complicado se vuelve, más fácil te resultará atraerte a una madriguera de conejo futurista.

    ¡No lo hagas! Refactorice a partir de necesidades reales, no de escenarios hipotéticos que pueden ocurrir o no.

     

    3. La optimización prematura es la raíz de todos los males

    ¿Alguna vez has escuchado esa cita? No le di mucha importancia hasta hace poco. Es muy difícil reformar viejos hábitos, así que esto es algo que me hace tropezar hasta el día de hoy. Todavía me sorprendo optimizando código que no debería optimizar.

    ¿Alguna vez has hecho algo así?

    ?php$post_id = get_the_ID(); // look 'ma - I'm reusing ID, saving 1 function call!$thumb = get_the_post_thumbnail( $post_id, 'large'); // look 'ma - I'm saving another function call! Yay!?div?php if( $thumb ): ? div ?php echo $thumb ? /div?php endif; ?/div

    Asignar un valor a una variable, porque está usando ese valor dos veces, le ahorrará exactamente 0,000002 ms (una cifra completamente inventada e inútil), y 0 ms cuando esa solicitud se almacene en caché, que será la mayor parte del tiempo cuando el rendimiento es motivo de preocupación de todos modos.

    Aquí hay una forma mucho más sencilla de escribir lo mismo en WordPress :

    div?php if( has_post_thumbnail() ): ? div ?php the_post_thumbnail('large') ? /div?php endif; ?/div

    Sí, implica dos llamadas a funciones adicionales, pero el beneficio en el rendimiento del código es insignificante. Eso no significa que no debas optimizar tu código en absoluto. Sea inteligente al respecto. Si está guardando consultas de bases de datos o está ejecutando funciones costosas en un bucle, por supuesto debe mantener su código optimizado. Pero hazlo inteligentemente. No arrojes todo en una variable solo para guardar una llamada a función. Hablando de variables...

    4. Evite variables en archivos de plantilla

    Cuando dejes de intentar optimizar demasiado, deberías notar muchas menos variables en tus archivos de plantilla. Le recomiendo que lleve esa idea un paso más allá y trate de evitar variables en los archivos de plantilla en general. No porque debas evitar las variables en sí, sino por lo que son un síntoma de los archivos de plantilla: la lógica.

    Si bien siempre será necesaria algo de lógica, puedes mejorar significativamente la legibilidad de tus archivos de plantilla eliminando todo lo que puedas.

    He aquí un ejemplo sencillo.

    ?php$logo_url = false;$thumbnail_url = wp_get_attachment_image_src( get_theme_mod( 'hypthetical_theme_logo' ), 'full' );if( $thumbnail_url ) { $logo_url = $thumbnail_url[0]; }??php if( $logo_url ): ? a href="?php echo esc_url( home_url() ); ?" img src="?php echo $logo_url; ?" / /a?php endif; ?

    Por sí solo, esto puede no parecer terrible, pero cuando está en algún lugar dentro de su archivo `header.php`, se verá bastante desordenado, especialmente cuando está envuelto en múltiples divs con sangría.

    Además de que no se ve muy bien, ¿por qué la plantilla (o la persona que lee el código) debería preocuparse por cómo se recupera el logotipo? Los archivos de plantilla solo quieren mostrar contenido, no buscarlo ni analizarlo.

    En lugar de definir dos variables, ¿por qué no extraerlas y convertirlas en funciones? Entonces el código anterior puede convertirse fácilmente en esto:

    ?php if( hypotheme_has_logo() ): ? a href="?php echo esc_url( home_url() ); ?" img src="?php hypotheme_the_logo_url() ?" / /a?php endif; ?

    Esto es mucho, mucho más fácil de leer y evita cualquier desorden innecesario y, en caso de que alguien quiera saber de dónde viene el logotipo, puede inspeccionar la función. Ahora la lógica está separada de la presentación.

     

    Aquí hay otro ejemplo:

    ?php/** * page.php */??php get_header(); ??php$hypotheme_sidebar = hypotheme_get_option( 'hypotheme_sidebar' );$hypotheme_sidebar_size = hypotheme_get_option( 'hypotheme_sidebar_size' );??php while ( have_posts() ) : the_post(); ? div ?php if ( $hypotheme_sidebar == 1 ): ? div ?php else: ? div ?php endif; ? div ?php post_class( 'entry-page' ); ? h1?php the_title(); ?/h1 div?php the_content(); ?/div /div ?php if ( comments_open() ) : ? ?php comments_template(); ? ?php endif; ? /div ?php if ( $hypotheme_sidebar == 1 ) { get_sidebar(); } ? /div?php endwhile; ??php get_footer(); ?

    Mira esas variables. Por sí solos no están realmente fuera de lugar: están haciendo lo que deberían hacer. MX Motocross

    Sin embargo, esta plantilla probablemente no sea la única plantilla de este tema con una barra lateral. Eso significa que esas variables probablemente estén presentes en todos los archivos de plantilla donde hay una barra lateral.

    No sólo la lógica se mezcla con la presentación, sino que también se repite en todos los archivos de plantilla (page.php, single.php, index.php, etc.). Eso es mucha repetición, mucho código que se puede eliminar fácilmente:

    ?php/** * page.php */??php get_header(); ??php while ( have_posts() ) : the_post(); ? div div div ?php post_class( 'entry-page' ); ? h1?php the_title(); ?/h1 div?php the_content(); ?/div /div ?php if ( comments_open() ) : ? ?php comments_template(); ? ?php endif; ? /div ?php get_sidebar(); ? /div?php endwhile; ??php get_footer(); ?

    Esto es mucho más fácil de leer y comprender. El lector no tiene que preocuparse por cómo decide el ancho del contenedor, pero si está interesado, en la mayoría de los editores de código puede saltar rápidamente a esa función y leer todo sobre ella. Las funciones ayudan a que su código sea más legible y ampliable si se usan junto con los ganchos de WordPress o el patrón de funciones conectables .

    No tenga miedo de crear varios archivos donde pueda almacenar todas las funciones de plantilla necesarias, es decir, no descarte todo dentro functions.php. De forma predeterminada, el tema _s incluye /inc/template-tags.phpun archivo para ese propósito. Y si descubre que el archivo se vuelve demasiado grande con todas las nuevas etiquetas de plantilla que ha creado, puede crear más archivos según sea necesario. ¡Es tu tema después de todo!

    5.Asegúrate de estar actualizado

    WordPress está en constante evolución, como todo lo demás en Internet. Manténgase actualizado con las mejores prácticas, pregúntese de vez en cuando y asegúrese también de seguir utilizando las mejores prácticas.

    Por ejemplo, he visto temas lanzados en WordPress.org este año, que todavía se usan wp_print_stylesen lugar de wp_enqueue_scripts, aunque wp_print_styleshan quedado obsoletos desde la versión 3.3 de WordPress .

     

    Si está creando temas de WordPress para que otros los usen, manténgase actualizado con las mejores prácticas y revise el códice de vez en cuando para ver si la forma en que está haciendo algo sigue siendo la mejor manera de hacerlo.

    6. Utilice funciones nativas de WordPress cuando pueda

    Es importante utilizar funciones nativas de WordPress cuando sea posible para que otros puedan acceder a su tema, ya sea desde un complemento o un tema secundario.

    Cuando esté actualizado con lo último y lo mejor que WordPress tiene para ofrecer, puede descubrir que el ejemplo "Error n.° 4" se puede reemplazar completamente con funciones nativas de WordPress desde la versión 4.5 de WordPress porque WordPress ahora admite la funcionalidad de logotipo personalizado de forma nativa.

    ?php if( has_custom_logo() ): ? a href="?php echo esc_url( home_url() ); ?" img src="?php the_custom_logo() ?" / /a?php endif; ?

    Aquí hay otro ejemplo.

    Al diseñar una navegación agradable entre publicaciones sin pensar demasiado en ello, recurrí a la función get_next_post y copié y pegué algo como esto en mi tema:

    ?php$next_post = get_next_post();if (!get_next_post()): ? a href="?php echo esc_url( get_permalink( $next_post-ID ) ); ?"?php echo esc_attr( $next_post-post_title ); ?/a?php endif; ?

    ¡Dulce! ¡Internet acaba de escribir un código para mí! Esto es exactamente lo que necesitaba.

    ¿Qué hay de malo en esto? Bueno, varias cosas.

    En primer lugar, no acceda a las propiedades del objeto directamente cuando sea posible, a menos que esté seguro de que es necesario. En este caso, puede utilizar la función get_the_title() en su lugar. De esta manera recuperará correctamente el título, antepondrá "Privado/Protegido" y aplicará el the_titlefiltro.

    // do thisecho get_the_title( $next_post )// instead of this:echo $next_post-post_title

    Y en segundo lugar, hay una función de WordPress llamada enlace de siguiente publicación y puedes reemplazar todo lo anterior con solo una simple llamada de función:

    ?php next_post_link() ?

    Una vez más, investigar un poco y mantenerse actualizado puede ayudar a limpiar los temas de manera significativa.

    7. No construyas tu propio marco

    Cuando escribo código, quiero que sea SECO, con una interfaz limpia, reutilizable y eficaz. Creo que, en última instancia, todos queremos eso.

    Cuando todas esas ambiciones se combinan con una pizca de optimización prematura, una pizca de predicción futura, ignorando una o dos funciones nativas de WordPress y el deseo de ahorrar en unas pocas pulsaciones de teclas, es cuando nace " un marco para mí, por mí ".

    Como dice el refrán: "El camino al infierno está empedrado de buenas intenciones". En mis casi cinco años de desarrollo de temas, he construido un "marco sólido" para mí al menos dos veces y lo he refactorizado innumerables veces. Ahora, desearía poder eliminarlo todo de una sola vez. ¡No lo hagas! ¡Perdona tu yo futuro!

    Estoy en contra de construir "un marco para mí y por mí", no marcos en general. Existen frameworks bien soportados y mantenidos, como el tema Genesis o Sage by Roots. Pero no están en el formato "un marco hecho por mí para mí".

     

    A continuación se muestran algunos problemas y efectos secundarios de crear un marco usted mismo:

    Problemas de mantenibilidad

    El primer problema es que construir un "marco" es simplemente agregar una base de código adicional para mantener. Especialmente si el marco se encuentra en su /inc/me-frameworkdirectorio, tendrá que actualizar todos sus temas utilizando ese marco cuando publique una actualización.

    Si decide no actualizar su marco en cada tema cada vez que lo actualiza, todavía habrá problemas al acecho a la vuelta de la esquina.

    A medida que crezca como desarrollador, su marco crecerá y cambiará también. Con el tiempo, conduce a la incompatibilidad con sus temas antiguos. ¿Qué pasa si descubre un error crítico en versiones anteriores del marco? Tendrás que reescribir partes de todos los temas que hayas creado o crear una bifurcación muy especial con errores corregidos. Y nuevamente: más código para mantener.

    Territorio del complemento

    Si se encuentra agregando “funcionalidad personalizada” en el tema, es posible que desee crear un complemento de WordPress en su lugar . Los temas deben tener diseños bonitos y darles estilo. Los archivos de tema deben llenarse con configuración, adjuntarse a ganchos y usar etiquetas de plantilla que proporcionan los complementos o el núcleo de WordPress. Si siente la necesidad de utilizar clases de PHP, probablemente se esté aventurando en el territorio de los complementos.

    En su lugar, cree un complemento; hazlo fácilmente personalizable y dale estilo según tu tema. ¡No solo evitarás crear un marco, sino que también contribuirás al regreso de la comunidad de código abierto!

    Mayor complejidad

    Cuando construyes un marco para ti mismo, haces que tu tema sea más complejo y difícil de trabajar. Cuando alguien lea el código de su tema, tendrá que aprender su marco, que probablemente esté mal documentado o no esté documentado en absoluto.

    Conclusión

    Me he dado cuenta de que la mayoría de los errores que he cometido han sido causados ​​por el deseo de ahorrar tiempo en el futuro ( xkcd tiene un cómic maravilloso sobre eso ) o por mejorar el código en sí de alguna manera, ya sea siguiendo un mejores prácticas que he leído en alguna parte o hacer que el código se vea mejor.

    WordPress tiene sus propios estándares de codificación y temática . Si bien puedes escribir PHP de la forma que desees en tus archivos de plantilla, es mejor seguir “la forma de WordPress”, incluso si no es necesariamente “la mejor manera”. Recuerde que "mejor" es relativo a la audiencia. Cuando fueres haz lo que vieres.

    Así que, por favor, no repitas mis errores. ¡Realmente espero que este artículo te ayude a crear excelentes temas de WordPress!

    Otras lecturas

    • Edición del sitio completo de WordPress: una inmersión profunda en la nueva función
    • Zona de juegos de WordPress: desde la instalación en 5 minutos hasta la puesta en marcha instantánea
    • Cómo reducir la necesidad de codificar manualmente las partes del tema en su sitio web de WordPress
    • JavaScript básico, bibliotecas y la búsqueda de una representación DOM con estado

    (mc, ra, yk, il, mrn)Explora más en

    • WordPress
    • Temas
    • javascript





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Cómo prevenir errores comunes en los temas de WordPress

    Cómo prevenir errores comunes en los temas de WordPress

    ¡Registro! Accesibilidad para diseñadores, con Stéphanie Walter Índice 1. No reinventes la rueda gradu

    programar

    es

    https://aprendeprogramando.es/static/images/programar-como-prevenir-errores-comunes-en-los-temas-de-wordpress-917-0.jpg

    2024-05-20

     

    Cómo prevenir errores comunes en los temas de WordPress
    Cómo prevenir errores comunes en los temas de WordPress

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20