Trabajo con WordPress desde 2008, conozco en profundidad la mayoría de sus secretos y técnicas de desarrollo y creo que nos está adelantando por la derecha. Voy a intentar reflexionar sobre cómo está la profesión del diseño y desarrollo web de manera objetiva.

Será difícil mantenerse objetivo, pero no por mi amor a WordPress (que algo queda), sino por intentar no posicionarse cuando tengo una opinión formada sobre el tema.
Sirva como advertencia que este texto no es más que una reflexión propia, basada en mi propia experiencia como desarrollador web. No quiero imponer mi punto de vista, más bien llevar a reflexionar a los lectores que entran aquí buscando inspiración o un camino a seguir en su autoformación.
Y ahí viene el primer punto a tratar, la autoformación. No hay una formación reglada para ser “diseñador web” o “desarrollador frontend” o alguna de esas etiquetas que tanto nos gusta debatir; quizá sea por esto por lo que cada uno aprendemos dónde y cómo podemos.
Los primeros pasos siempre son difíciles; recuerdo mis primeras búsquedas en el gran buscador sobre “cómo hacer páginas web”.
Después de muchos años de continuo aprendizaje, puedo decir que soy diseñador y desarrollador web especializado en WordPress. Actualmente trabajo con ActualidadBlog (una red de blogs donde gestionamos un montón de sitios WordPress) e incluso he empezado a montar mi propia plataforma, con cursos de WordPress y diseño web en general.
Me gusta mi trabajo, porque siempre hay algo que supone un reto; bien adaptar un plugin que nos está entorpeciendo, bien añadir una funcionalidad nueva o desarrollar algo orientado a facilitar el trabajo de los redactores y la navegación de los usuarios.
El caso es que recibo correos diarios solicitando presupuestos, muchos con un mismo patrón: reparar o terminar algo que se ha hecho mal o que no cumple con lo que el cliente requiere desde un principio. Creerás que es normal, pero… ¿si te digo que la mayoría de los problemas son por no tener la base de conocimientos necesarios?
Entiendo la necesidad de pagar facturas, pero jamás entenderé que se piense tan poco en el futuro del proyecto y, sobretodo, en el cliente.
A través de este texto me gustaría plantearte la incógnita de si estamos utilizando las herramientas adecuadas, o hacemos las cosas sin autocrítica, sin buscar lo mejor para el proyecto o por moda.
¿De verdad hace falta instalar un CMS para diseñar y desarrollar una página “sobre mi” y otra de “contacto”? ¿Hablamos ahora de instalar un plugin para poner los botones de compartir en Facebook y Twitter? O mejor aún, de cuando me contactan para cambiar el tamaño de un botón de Bootstrap.
Y aquí llega la gran pregunta: ¿Por qué WordPress? ¿Por qué Bootstrap? ¿Por qué [escoge la herramienta que más rabia te de]?
El caso del freelance, ¿optimizando el trabajo?
Muchas veces he hecho el ejercicio de intentar entender el por qué se usan herramientas tipo Visual Composer, Divi, Avada o algunas menos intrusivas como Bootstrap o Genesis, y no termino de entenderlo. Bueno sí, la curva de aprendizaje es más corta para estos casos, o no.
Mucha gente da el salto a ser freelance cuando descubre una herramienta que le hace fácil “desarrollar un sitio web” (así, entre comillas). Es fácil pensar que un sitio web, conociendo la herramienta, se hace en una tarde y se gana dinero fácil.
Y es cierto, al menos hasta cierto punto. ¿Quién no ha escuchado eso de “WordPress es fácil: un tema, dos plugins y lo tienes montado en una tarde”? Escoger un tema, configurarlo y hacerlo funcionar puede ser cuestión de horas si sabes lo que haces. Pero… ¿A qué precio?
Es por esto que muchos freelance deciden aprender la herramienta, obviando las bases. Aprender Bootstrap y su funcionamiento, antes que a desarrollar un layout con flexbox o grid. Aprender a utilizar Divi antes que a desarrollar un tema a medida para WordPress. Ir al repositorio de plugins a buscar algo que solucione la papeleta, en vez de estudiar el caso y desarrollar.
Si la herramienta lo hace por ti, para qué complicarte pudiendo dedicarse a generar ingresos. Afirmación que han utilizado para justificarse.
Esto lleva a muchos freelance a centrarse únicamente en desarrollar sitios con WordPress, amarrados a un tema o plugins en concreto. Incluso, en el peor de los casos, al uso de un page builder o editor visual.
Y después, cuando el cliente pide algo que se desmarca del funcionamiento de lo que tienen instalado, están perdidos.
El caso de la agencia, maximizando los beneficios
Con las agencias pasa algo parecido; tratan de maximizar los beneficios ahorrando en tiempo de desarrollo. Esto es lógico y normal, pero no siempre lo vas a conseguir utilizando herramientas de terceros.
Es lógico pensar que si una herramienta nos ahorra muchas horas de trabajo, ingresamos más con menos inversión de tiempo y recursos, ¿no?
Total, el resultado final va a ser el mismo. Otra afirmación de las tantas que me han dado como justificación.
La realidad aquí es que muchas agencias terminan trabajando exclusivamente con temas premium de WordPress. Cuando lo lógico -yo creo-, sería desarrollar tus propios frameworks o bases para así optimizar tu trabajo. Y esto es aplicable a ambos casos, tanto el del freelance como el de las agencias.
El problema más grave, proyectos que no se pueden heredar.
El uso de estas herramientas nos lleva a una situación que, por desgracia, me encuentro con más frecuencia de la que me gustaría. Proyectos imposibles de heredar, donde vale más la pena rehacer todo desde el principio que rediseñar.
Cuando me contactan para hacer un rediseño, siempre miro dos cosas: la posibilidad de reciclar el contenido y cómo está hecho el proyecto (si se ha utilizado WordPress, theme, plugins…).
Si el desarrollador anterior ha hecho un buen trabajo y la primera incógnita es afirmativa, la segunda incógnita es irrelevante; ya que el contenido es lo importante dentro de un sitio web.
Pero hay muchos casos en los que el proyecto puede ser un infierno, algunos ejemplos:
- Se ha utilizado un tema que utiliza códigos propios en los contenidos, generando un efecto lock-in sobre esa herramienta (en este caso el tema o su editor visual)
- Se han utilizado uno o varios plugins para gestionar la funcionalidad del tema; sistemas de reserva, catálogos, sistemas de votación...
- Modificar una o varias partes del diseño actual, construido con un framework mal utilizado, que al realizar cambios impiden su correcto funcionamiento. Por ejemplo, un mal uso de las clases de Bootstrap o Foundation hacen que modificar una parte del diseño sea costoso.
Se me ocurren varios más, pero los más típicos suelen ser de este tipo.
Y claro, ve tú donde ese cliente y explícale que para cambiar el diseño hay que rehacer toda la web o utilizar un tema concreto que sea compatible con el editor visual que tiene actualmente.
Personalmente, rehuso de realizar este tipo de proyectos; a veces es mayor la inversión de horas en saber qué hace el tema por dentro o un plugin que rehacer todo el proyecto desde cero.
Ese es el gran problema: pídele al cliente tanto o más como lo que costó hacer el sitio web nuevo por un rediseño cuando “el contenido y estructura ya están”.
El problema añadido, no se valora el trabajo
Y este es otro de los grandes problemas, no se valora el trabajo en general porque esa agencia o freelance “lo hacen por menos de la mitad”. Y aunque intentes explicar las diferencias entre un proyecto y otro, al cliente medio le cuesta entender tan sustancial diferencia económica.
Por no hablar de las modificaciones que, como está hecho de aquella manera, implican una inversión de tres horas y resulta que “me va a costar más cambiar cuatro cosas que la web entera”.
Lo malo no es la herramienta, sino el uso que se hace de ella
Como versa el encabezado, este problema viene del uso que se hace de la herramienta.
Imagina un sitio web que tiene un catálogo de servicios. Se ha hecho con una página de WordPress, en la que se ha utilizado Visual Composer (o el editor visual que más rabia te de) para mostrar los 23 servicios que ofrece la empresa.
Posteriormente viene el cliente y quiere que cada elemento de ese catálogo, tenga su propia página con la descripción y datos del servicio. Para esta tarea se crean subpáginas, una para cada servicio (lo que suma un total de 24 páginas con la principal).
Cuando el cliente quiera modificar un servicio, lo tendrás que modificar en dos sitios diferentes, ¿verdad? ¿Y por qué no crear un Custom Post Type y usado su plantilla archive para mostrar los servicios? Esto evitará tener que modificar dos páginas.
Esto es sólo un ejemplo, que demuestra uno de los usos en que todo se confía a la herramienta.
Y créeme, no es el peor ejemplo. Lo peor es cuando todo el contenido está envenenado con shortcodes del pagebuilder de turno… Pero eso da para otro artículo.
Principal solución, bases de conocimiento
Yo no digo que no debamos utilizar herramientas; todos lo hacemos, especialmente cuando nos ahorran tiempo o automatizan tareas repetitivas.
Hoy en día es impensable programar un gestor de noticias a mano para una pyme, por ejemplo. Se utiliza WordPress, Drupal o Joomla! y se termina mucho antes, lo que permite que el presupuesto de ese proyecto sea competitivo.
Pero antes de escoger una herramienta, deberías cuestionarte si es la adecuada para el proyecto que vas a afrontar o si de verdad es lo que necesitas. Y no hablo tanto de WordPress sino de todas las herramientas que pueden incluirse en él, como temas o plugins.
Antes de utilizar una herramienta deberías analizar y entender la tecnología que hay detrás. Ojo, hablo de conocer, no siempre hace falta ser un experto en ella.
Por ejemplo, si vas a utilizar Bootstrap porque te agiliza el trabajo y te ayuda en tus tareas, genial. Pero asegúrate de saber el CSS suficiente antes de ello, porque el día que utilices la herramienta lo harás con conocimiento suficiente para saber si es la adecuada a ti y hacer un uso óptimo y adecuado de ella.
Si vas a utilizar WordPress como gestor de contenidos, deberías de saber cómo funciona el motor de plantillas, los custom post types o WP_Query. Incluso si vas a utilizar un tema precocinado en un proyecto, porque te ayudará a saber si es el adecuado, si está bien desarrollado o será un lastre para el proyecto en el futuro.
Conclusiones
Te animo a que sigas tu aprendizaje, pero que lo hagas en base a tecnologías y no herramientas; que seas tú quien escoge la herramienta y no la herramienta quien te escoja a ti.
No te creas todo lo que lees en los blogs, cuestiónate las cosas y aprende la base. Cuanto más sólidos sean tus conocimientos sobre las tecnologías básicas (HTML, CSS, php, Javascript), mejor profesional serás. Tus proyectos tendrán más calidad y tus clientes estarán más satisfechos.
Para terminar y a modo de consejo, evita caer en la mecánica de probar herramientas por moda y céntrate en las que sean buenas para ti y tus proyectos; con el tiempo lo agradecerás.
Nos leemos en los comentarios, y recuerda: Quizá no necesitas ese plugin, theme, framework o herramienta.