Imagina este escenario: encuentras un fragmento de código muy interesante en uno de los muchos sitios de tutoriales de WordPress y lo pegas en el archivo functions.php de tu tema.
El fragmento de código funciona como se anuncia, y luego lanzas tu tema a la venta en un conocido mercado de temas. Escojamos uno al azar y digamos... ThemeForest.
De repente, tu tema se vuelve muy popular, quizás debido a la enorme lista de "características" aparentemente útiles que has incluido en la página de ventas de tu tema. Con el éxito de tu tema, también llega un número de consultas de soporte, la mayoría relacionadas con plugins que fallan al usar tu tema.
¿Cómo sucedió esto, te preguntas? Tal vez sea porque pegaste ciegamente fragmentos de código de WordPress en tu archivo functions.php sin pensar realmente o anticipar posibles problemas de compatibilidad.
Un ejemplo de la vida real
Así que estaba tratando de encontrar un fragmento de código que extrajera todas las imágenes adjuntas de una publicación y luego las mostrara automáticamente en esa publicación. Finalmente encontré un trozo de código en Stack Overflow, lo pegué en mi archivo de funciones y pareció resolver el problema.
La primera línea de código fue la siguiente:
add_filter('the_content', 'strip_shortcodes');Bueno, funcionó, no le di mayor importancia. Más tarde intenté incrustar un formulario de contacto con un shortcode. Sorpresa, no funcionó y pasé aproximadamente una hora tratando de averiguar por qué. Si hubiera leído el código que estaba pegando, lo habría sabido.
Esto fue para el sitio de un cliente, no para un tema publicado, así que afortunadamente no tuve que lidiar con un aluvión de consultas de soporte debido a mi estúpido error.
Lo que piensan los desarrolladores de plugins comerciales
Aquí hay una cita de Carl Hancock (desarrollador de Gravity Forms) sobre este mismo tema:
El soporte para el popular plugin Gravity Forms significa que vemos más que nuestra parte justa de temas mal codificados. Uno de los principales problemas relacionados con el soporte que encontramos son temas que no se desarrollan utilizando las mejores prácticas, lo que resulta en problemas de estilo de Gravity Forms y, en algunos casos, conflictos que provocan que Gravity Forms no funcione correctamente.
El mayor culpable en estas situaciones son los temas que incluyen fragmentos de código copiados y pegados de sitios de tutoriales. Los desarrolladores de temas parecen pensar que solo porque el fragmento de código estaba en un sitio de tutoriales, debe ser bueno. Desafortunadamente, ese no es siempre el caso y estas malas decisiones resultan en dolores de cabeza y problemas de soporte para los usuarios.
¿Quiere limitar el potencial de encontrar problemas con plugins causados por un tema mal desarrollado? Apéguese a desarrolladores de temas de buena reputación como Press75, iThemes, Headway Themes, Organic Themes, WooThemes y StudioPress, por nombrar algunos. Tenga cuidado con los mercados de temas donde la experiencia y el conjunto de habilidades del autor pueden ser deficientes. En la mayoría de los casos, obtienes lo que pagas.
Mejores prácticas de codificación
Muchos de estos problemas probablemente se pueden evitar siguiendo los estándares de codificación de WordPress. Por ejemplo, deberías estar anteponiendo nombres a tus funciones para evitar posibles conflictos.
En el caso de problemas de estilo con Gravity Forms, es posible que desee evitar ciertos estilos generales en los elementos form y input, y en su lugar usar los selectores de ID predeterminados de WordPress para la mayor parte del estilo de su formulario.
Estos incluyen #searchform, #s, #searchsubmit en el cuadro de búsqueda. También #commentform #author, #url, #email, #comment, #submit para el formulario de comentarios.
Conclusión
Si eres un desarrollador de temas y no tienes mucha experiencia en PHP, ten cuidado al copiar y pegar estos fragmentos de código en tu tema. Incluso si no eres muy bueno en PHP, al menos puedes leer el código e intentar entenderlo antes de usarlo.
Por ejemplo, si descubres que tus shortcodes no funcionan correctamente, una línea de código que menciona "strip_shortcodes" podría tener algo que ver con eso.
A veces tengo la sensación de que los desarrolladores de temas de WordPress simplemente pegan fragmentos aleatorios en su archivo functions.php, solo para poder enumerar otra "característica" en las páginas de venta de su tema.
Aunque no soy un gran fanático de este tipo de idea, esto da pie a toda otra discusión sobre el papel de los temas y plugins en los sitios de WordPress, la cual guardaré para una futura publicación.
Interesante... soy desarrollador de temas, gracias por llamar mi atención sobre esto...
Incluso he visto a personas copiar y pegar código con avisos de derechos de autor (¡pidiendo que el código no se comparta!) todavía intactos.
@mkjones – ¿el problema es que se eliminó el filtro o que no se anunció su eliminación? Casi siempre elimino el filtro wpautop porque destruye automáticamente HTML perfectamente bueno (por supuesto, les digo a todos que ya no está).
Lo que realmente me irrita más es cuando pegan Jquery (y más de 20 scripts/plugins) directamente en el encabezado de su tema o en algún lugar difícil de encontrar. ¿Es wp_enqueue_script tan difícil?
De hecho, publiqué un ejemplo rápido de un Fiasco de Jquery de Themeforest en mis foros si alguien quiere echarle un vistazo.
Solo quería agregar una cosa más que puede ser útil para algunos de sus lectores.
A principios de este mes, estaba ayudando a un cliente que compró una licencia de soporte para mi plugin. El tema del cliente tenía alrededor de 20 plugins Jquery diferentes cargados en el header.php. Ninguno de ellos usaba wp_enque_script.
La mayoría de estos scripts solo se usaban para el slider de la página de inicio y la página de galería (que aún no existía). Dado que se cargaban en todo el sitio, los scripts generaban errores de Jquery en el resto de las páginas del sitio que no necesitaban estos scripts.
En lugar de reescribir todo el header.php y porque no sabía si alguno de los scripts podría ser necesario para páginas futuras. Usé algunas etiquetas condicionales para resolver el problema. Al usar etiquetas condicionales, pude desactivar todos los scripts arbitrarios, cuando el sitio cargaba el formulario de registro que estaba siendo generado por mi plugin.
De hecho, publiqué un ejemplo rápido de un Fiasco de Jquery de Themeforest en mis foros, si alguien quiere echarle un vistazo.
Lo siento Leland, ¿puedes eliminar esa primera línea de mi último comentario? Pensé que la había eliminado antes de publicarla.
¡Gracias!
Oh DIOS, odio esto. Causa MUCHOS dolores de cabeza al personalizar temas.
Recuerdo el clásico:
remove_filter(‘the_content’, ‘wpautop’);
Se coló hace un tiempo. Sin ser anunciado adecuadamente como una 'característica' del tema 🙁
¡Estoy completamente de acuerdo contigo aquí! He pasado por esto y he cometido este error yo mismo, solo para encontrarme en problemas más tarde.
Las cosas que puedes hacer con tu functions.php son geniales, pero necesitas estar organizado y ser cuidadoso con lo que haces si no quieres pasar horas depurando después.
Una de las recomendaciones que daría sería organizar cuidadosamente estos fragmentos de código si quieres conservarlos.
Consérvalos en archivos separados, bien comentados, prueba doble después de implementarlos. Al final, documentar tu trabajo siempre vale la pena, en mi opinión.
No podría haberlo dicho mejor. Esto no se limita solo a fragmentos de código aleatorios que se encuentran en tutoriales en la web. Los desarrolladores de temas simplemente introducen aleatoriamente cualquier código en functions.php sin pensar; pensarías que usarían un hook de vez en cuando.