WordPress en 2024
Publicado el 5 de noviembre de 2024
Este no ha sido un buen año para WordPress. No voy a entrar en detalle de lo que ha pasado, una búsqueda rápida online da la información necesaria para leer sobre el tema. Pero esto ha llevado tanto a mucha gente a renunciar a Automattic, como a reconsiderar el uso de WordPress en sí.
Personalmente vengo pensando migrar de WordPress a otra cosa desde hace años. El blog empezó en Blogger en 2007. Después de poco tiempo, migré a un hosting en linuxuruguay y eventualmente hosting propio con WordPress. Al ver que pensaba seguir con el blog, necesitaba tener control sobre la plataforma. WordPress era lo más fácil, rápido y conveniente en su momento.
Tener el blog en WordPress me permitía escribir y publicar sin demasiados problemas. Y al ser software libre, podía extenderlo con mis conocimientos en programación web y PHP. Gracias a WordPress desarrollé varios plugins que tuvieron su relativo éxito y me ayudaron a crecer como programador.
Al usar un mismo software por tantos años, uno le va encontrando cantidad de contras y detalles. Estos detalles atentan contra poder usar el software de forma cómoda y feliz. Pero la lista de contras nunca fue tan grande como para superar el esfuerzo de tener que migrar todo a otro sistema. Y también hay un montón de cosas en la lista de pros.
A lo que empezaron a agregarle cosas que no necesitaba a WordPress, se fue volviendo más pesado. Supongo que va acompañado del crecimiento del sitio, la cantidad de plugins que le fui agregando, o que estaría haciendo mal trabajo con el mantenimiento. Pero en algún momento se volvió mucho más lento de lo que considero debería ser un blog sin mucho JavaScript ni traqueos o pop ups de cookies.
Uno de los problemas más grandes de WordPress, para mí, fue la incorporación del editor de bloques “Gutenberg”. Algo que agregó un montón de código para una característica que no quería ni necesitaba. Un cambio fundamental que me obligó a instalar un plugin extra para mantener la experiencia a la que estaba acostumbrado hace años.
Esa experiencia sí necesitaba mejoras, pero no ese cambio radical de paradigma, o por lo menos no para ese lado. No digo que sea un cambio inútil, pero sí que debería ser opcional. Sin dudas deben tener a montón de expertos trabajando en experiencias de usuario que dicen que la experiencia de Gutenberg es mejor que un editor de texto común. Pero no lo va a ser para todo el mundo.
Este blog lleva 17 años sobre WordPress, así que migrarlo a otro sistema me resulta bastante aterrador. Siempre que pienso en la migración, pienso en poder mantener no sólo los posts y su contenido, sino también los comentarios. Éstos días no recibo tantos comentarios en los posts como en otros tiempos, pero son parte muy valiosa de un blog. Y los comentarios “viejos” sirven de captura de pantalla de épocas en el tiempo e interacciones que agregan mucho valor.
Por más que he mirado sistemas a los que podría migrar, me imagino que cambiar de sistema va a llevar la inevitable tarea herculeana de revisar los (al momento de escribir esto 1.714) posts uno por uno para ver que quedaron “bien migrados”. Pero de repente hay una solución más sencilla…
Hace tiempo que venía siguiendo con interés ClassicPress:
Un sistema de gestión de contenido liviano, estable, instantáneamente reconocible libre y de código abierto. Basado en WordPress sin el editor de bloques (Gutenberg).
Hemos recortado código innecesario para mejorar el rendimiento general y la privacidad comparado con WordPress. El núcleo de ClassicPress tiene la mitad de tamaño de WordPress.
Sonaba exactamente a lo que estaba buscando. Además han sacado montones de código extra como soporte para versiones antiguas de PHP. Y no estoy seguro si lo han terminado del todo en la versión más reciente, pero han ido deprecando y eliminando el código de jQuery UI que trae WordPress, reemplazándolo por HTML5 y JavaScript nativos. Lo mejor es que cuentan con un plugin instalable en WordPress que se encarga de migrarlo a ClassicPress automáticamente. Y el proceso es reversible, de forma manual por ahora pero están trabajando en automatizarlo.
Algo interesante y relacionado a lo que mencionaba más arriba sobre Gutenberg es la información que proveen al respecto. El 25% de los usuarios todavía usan la versión 4.9 o menor de WordPress porque no quieren migrar al editor de bloque.
El plugin Classic Editor que mantiene la funcionalidad clásica, tiene más de 10 millones de instalaciones activas (aparentemente WordPress deja de contar después de tantos millones, así que no se sabe el número exacto). Personalmente ayudé con esa cifra, instalé el plugin en todos mis blogs cuando forzaron este editor de bloques.
Lo que viene pasando con WordPress me ha hecho volver a considerarlo, esta vez más seriamente. Por ahora he probado ClassicPress con otros dos blogs que tengo inactivos. El primero fue Aplicando Scrum, que al menos venía actualizando las versiones de WordPress. Instalé el plugin de migración y quedó todo funcionando perfecto de primera. No tuve que hacer ningún cambio ni arreglo. Tampoco es que tenga mucho contenido, o plugins, pero siempre está bueno probar y ver que es verdad lo que “te venden”.
El otro blog que reviví fue Navegadores Web. Éste estaba en la versión 4.algo de WordPress, ya no lo actualizaba hace años. Ni siquiera era compatible con las versiones de PHP actuales del servidor de hosting. Así que tuve que ir al viejo y querido FTP y actualizar los archivos a la última versión de WordPress a mano.
El tema tenía un montón de código PHP que no funcionaba más con versiones más nuevas. En vez de arreglarlo, opté por cambiar a uno de los temas por defecto y finalmente logré que funcionara todo. Todavía quedaban algunas imágenes de cuando el sitio estaba alojado en su propio dominio. Así que tuve que ejecutar un UPDATE en la base de datos MySQL para reemplazar el viejo domino por el subdominio navegadoresweb.picandocodigo.net y quedó.
Una vez reestablecida la funcionalidad de WordPress, volví a instalar el plugin de migración a ClassicPress, y quedó todo funcionando de primera también.
Ya con éstos dos blogs migrados de WordPress a ClassicPress, me dió un poco más de confianza. Pero todavía hay un paso más que quiero dar antes de proceder con la migración. Como buen webmaster responsable, hago respaldos regulares de todo el contenido del blog. Pero nunca levanté el blog de uno de estos respaldos. Me gustaría aprovechar esta migración como excusa para probar levantarlo en local. De esta forma seguro aprendo un poco y me puedo armar un plan organizado en el caso de que un día dependa de ese respaldo porque algo salió mal. Ya contaré al respecto.
Mientras tanto, he estado trabajando un poco en el backend del blog. Hice un poco de todo: desinstalar plugins viejos, reemplazar plugins por otros más nuevos, optimizaciones y limpiezas en la base de datos, limpieza de etiquetas y borradores que nunca van a ver la luz del día y más. La cantidad de CSS y JavaScript que te agregan tanto WordPress como distintos Plugins es intensa, también saqué algunos de éstos en mi archivo functions.php.
Al principio pensé que era efecto placebo que me resultara que carga un poco más rápido. Pero usé algunas de las herramientas online para testear y realmente disminuyó el tamaño y cantidad de pedidos HTTP. Con suerte si migro el blog a ClassicPress, la cosa mejore más todavía. De todas formas el próximo objetivo es investigar un poco el tema ver qué se puede sacar y mejorar tanto para rendimiento como usabilidad. Y ya que estamos seguramente haga algún retoque de diseño.
Laegnûr 5 noviembre. 2024 - 09:43
Buenas.
Ya que te planteas migrar, ¿por que no pruebas algo nuevo?
Hace un par de años encontré Processwire, es un framework content manager, que unicamente te da las herramientas necesarias para crear paginas, añadirles contenido y acceder al mismo, pero toda la libertad para definir que clase contenido quieres en cada pagina.
Al contrario de WordPress donde todo es un post, y todo se guarda en la misma tabla, Processwire funciona con un esquema de Pagina > Template > Field, donde cada pagina tiene un template asignado, y cada template tiene los campos que quieras, siendo cada campo una tabla separada en la BBDD. Los templates se corresponden con un archivo físico en PHP, donde tu programas la lógica y el output que quieras que haga con los campos que le asignes.
Al principio se hace raro entender la relación entre las diferentes tablas, y requiere tiempo para montar todo de inicio, pero una vez que entiendes como funciona, y te das cuenta de la libertad que te permite, es una herramienta muy potente.
Yo lo estoy usando como base para mi propio blog, que algún día sacare del modo mantenimiento… :\