Imagina este escenario, encuentras un fragmento de código realmente genial en uno de los muchos sitios de tutoriales de WordPress que existen y lo pegas en el archivo functions.php de tu tema.
El fragmento de código funciona tal y como se anuncia y pones tu tema a la venta en un mercado de temas muy conocido. Vamos a elegir uno al azar de un sombrero e ir con … ThemeForest.
De repente tu tema se vuelve muy popular, puede ser debido a la enorme lista de “características” aparentemente útiles que has enumerado en la página de ventas de tu tema. Con el éxito de su tema, también viene un número de consultas de soporte, en su mayoría relacionadas con plugins que se rompen al utilizar su tema.
¿Cómo ha ocurrido esto? Tal vez porque pegaste a ciegas trozos aleatorios de código de WordPress en tu archivo functions.php sin pensar o anticipar posibles problemas de compatibilidad.
Un ejemplo de la vida real
Así que, yo estaba tratando de encontrar un fragmento de código que se tire todas las imágenes adjuntas de un puesto y luego mostrarlos en ese puesto de forma automática. Finalmente encontré un trozo de código en Stack Overflow, lo pegué en mi archivo de funciones, y parecía resolver el problema.
La primera línea de código era la siguiente:
add_filter('the_content', 'strip_shortcodes');Bueno, funcionó, no le di importancia. Más tarde intenté incrustar un formulario de contacto con un shortcode. Sorpresa, no funcionó y me pasé una hora intentando 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 un tema liberado, así que por suerte no tuve que lidiar con un diluvio de consultas de soporte debido a mi estúpido error.
Lo que piensan los desarrolladores de plugins comerciales
He aquí una cita de Carl Hancock (desarrollador de Gravity Forms) sobre este mismo tema:
Apoyar 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 apoyo que nos encontramos son los temas que no se desarrollan utilizando las mejores prácticas, lo que resulta en problemas de estilo Gravity Forms y en algunos casos los conflictos que resultan en Gravity Forms no funcione correctamente.
El mayor culpable de 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 sólo porque el fragmento de código estaba en un sitio tutorial, debe ser bueno. Por desgracia, no siempre es así y estas malas decisiones provocan dolores de cabeza y problemas de soporte a los usuarios.
¿Quieres limitar la posibilidad de tener problemas con los plugins causados por un tema mal desarrollado? Cíñase a los desarrolladores de temas de buena reputación, como Press75, iThemes, Headway Themes, Organic Themes, WooThemes y StudioPress, por nombrar algunos. Desconfíe de los mercados de temas donde la experiencia y las habilidades del autor pueden ser escasas. En la mayoría de los casos, se obtiene lo que se paga.
Buenas prácticas de codificación
Muchos de estos problemas pueden evitarse siguiendo los estándares de codificación de WordPress. Por ejemplo, debería anteponer prefijos a los nombres de sus funciones para evitar posibles conflictos.
En el caso de los problemas de estilo con Gravity Forms, es posible que desee evitar ciertos estilos generales en el formulario y los elementos de entrada, y en su lugar utilizar los selectores de ID predeterminados de WordPress para la mayor parte de sus estilos de 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 muy versado 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 y tratar de entenderlo antes de usarlo.
Por ejemplo, si encuentras que tus shortcodes no están funcionando 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 al azar en su archivo functions.php, sólo para poder enumerar otra “característica” en las páginas de ventas de su tema.
Aunque no soy un gran fan de este tipo de idea, entra en otra discusión sobre el papel de los temas y plugins en los sitios de WordPress, que voy a guardar para un futuro post.
Interesting..I’m a theme developer myself thank you from bringing this to my attention…
I’ve even seen people copy and paste code with copyright notices (asking that the code not be shared!) still intact.
@mkjones – is the problem that the filter was removed, or that its removal wasn’t advertised? I almost always remove the wpautop filter because it automatically destroys perfectly good HTML (of course I tell everyone that it’s gone).
What really irritates me the most is when they paste Jquery (and 20+ other scripts/plugins) directly in the header of their theme or in some hard to find. IS wp_enqueue_script that difficult?
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums if anyone wants to check it out.
Just wanted to add one more thing that may be helpful to some of your readers.
Earlier this month I was helping out a client that purchased a support license for my plugin. The clients theme had around 20 different Jquery plugins loaded into the header.php. Not one of them were using wp_enque_script.
Most of these scripts were only being used for the home page slider and gallery page (that didn’t yet exist.) Since they were getting loaded across the entire site, the scripts were throwing Jquery errors on all of the rest of the pages in the site that had no need for these scripts.
Rather than rewriting the entire header.php and because I didin’t know if any of the scripts may be needed for future pages. I used a few conditional tags to solve the problem. By using conditional tags, I was able to turn off all of the arbitrary scripts, when the site loaded the registration form that was being generated by my plugin.
I actually posted a quick example of a Themeforest Jquery Fiasco in my forums, if anyone wants to check it out.
Sorry Leland, can you remove that first line in my last comment? I thought I removed it before posting.
Thanks!
Oh MAN I hate this. It causes NO end of headaches when customising themes.
I seem to recall the classic:
remove_filter(‘the_content’, ‘wpautop’);
Creeping into one a while ago. Without being properly advertised as a theme ‘feature’ 🙁
I completely agree with you here! I have been down this road and done this mistake myself, only to find myself in trouble later on.
The things you can do with your functions.php are great, but you need to be organized and careful with what you do if you don’t want to spend hours debugging later.
One of the recommandations I would give would be to carefully organize these snippets of code if you want to keep them.
Keep them in separated files, well commented, double test after implementing. In the end, documenting your work always pays off imo.
Couldn’t have said it any better myself. This isn’t just limited to random code snippets found in tutorials around the Web. Theme developers just randomly drop any and all code into functions.php without thinking about — you’d think they’d use a hook once in a while.