Pensamos que WordPress es para blogs y páginas corporativas sencillas, pero, ¿es realmente así? ¿Cómo una gran empresa debe afrontar el lanzamiento de su sitio con WordPress?
Patrocinador
Hosting WooCommerce en SiteGround: Crear tu tienda nunca ha sido tan sencillo, y es que te das de alta, pulsas en crear una tienda y ya tienes todo lo necesario para comenzar.
Enlaces comentados
- Joan ha presentado el Curso de Matomo y el Curso de Anchor.
- Javier ha explicado su proyecto empresarial, además de adelantar su nuevo proyecto de Seguridad WordPress
Actualidad
Cosas que vienen de la semanas pasadas
- Sobre el cambio de WordPress.com
- WebP
- Discusiones internas sobre si usar WebP o no
- Que es sólo un formato web (y la gente no los puede descargar en su ordenador) WTF!
- Que se generan muchas imágenes
- Que hay formatos mejores
- Qué pasa cuando se regeneren todos los thumbnails.
WordCamp y Eventos
Novedades
- WordPress 5.9.3
- GlotPress 3.0
- Performance Lab 1.0.0
- Version 1.0.0 of the Performance Lab plugin published – Make WordPress Core
- WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
- WebP Support: Adds a WebP support check in Site Health status. View related GitHub issues
- Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
- Audit Autoloaded Options (experimental): Adds a check for autoloaded options in Site Health status. View related GitHub issues
- Audit Enqueued Assets (experimental): Adds a CSS and JS resource check in Site Health status. View related GitHub issues
- WordPress 6.0
WordPress 6.0 Beta 1 – ¿Qué es lo que se va a destacar de esta versión?- Cambios de estilos: directamente desde los temas de bloques, sin cambiar el tema.
- Más plantillas: como las de autor, fecha, categorías, etiquetas y taxonomías en general.
- Multi-selección: pudiendo seleccionar texto de varios bloques.
- Mantener los estilos: Tus estilos personalizados se mantienen aunque cambies los globales.
- Más patrones en más sitios: gracias al Sistema de inserción rápida, se podrán añadir patrones de forma rápida y eficiente.
- Mejoras en la Lista de Vista: Nuevos atajos de teclado que permiten reorganizar, eliminar y acceder a distintas funcionalidades.
- Herramientas de estilos mejoradas: con los paneles de colores, opciones de transparencia, variaciones de bloques, organización en fila o apilada, control de tamaños o espaciados, tamaño del bloque destacado, de la imagen destacada, de las galerías, y más.
- Nuevos bloques: el de comentarios, leer más, no hay resultados, biografía del autor o avatar.
- Bloqueo de bloques: pudiendo bloquear que el contenido de un bloque cambie si no se desactivar la opción, pudiendo protegerlo de cambios inesperados.
- Exportación de temas: pudiendo crear un tema sin necesidad de programar y pudiendo crear un tema completamente nuevo y que puedes activar en cualquier otro WordPress.
- Y las Webfonts API: Que van a permitir la gestión de tipografía directamente desde el tema, sin necesidad de incluir un plugin o código extra.
- Y, una cosa, al menos por las pruebas que he hecho, y algo que suele preocuparte, Joan, es que no hay cambios en la estructura de la base de datos.
Tema del programa
¿Está WordPress preparado para las grandes empresas?
¿Por qué elegir WordPress y no otro gestor de contenidos? Para esto podría dar muchas respuestas posibles. Por ejemplo, que es código abierto y eso permite que cualquiera pueda colaborar, que se pueda revisar la seguridad del software en cada cambio y versión, que cualquier empresa pueda participar.
Pero es que esto mismo, precisamente, es lo que ha hecho que WordPress sea la plataforma más utilizada en Internet ahora mismo. Y como siempre, ser el más usado y conocido puede tener sus pros y sus contras. Y esto es lo que muchas grandes empresas se preguntan.
Y me gustaría comenzar con los clásicos que se pone de ejemplo como La Casa Blanca, o el blog de noticias de tecnología más importante, TechCrunch, la revista People, el Blog de Playstation de SONY, el Equipo Olímpico de Canadá, el grupo de música Rolling Stones, la cantante Katy Perry, el Newsroom de Meta (o sea, Facebook), la web de Sony Music, la web del servidor web NGINX
Y así, cosas que nos pueden pillar más de cerca, la constructora Ferrovial, las ensaladas Florette, los vinos de Marqués de Cáceres, la Mobile World Capital (que están en Barcelona).
Y como en todo proyecto grande, y yéndonos a cómo funciona el mundo WordPress, varias recomendaciones a muchos niveles.
Comenzando por el principio, y ya sabéis que como siempre cuando explico cosas así, de abajo a arriba, es decir, desde las tripas y el hosting, hasta lo que se ve, es decir, la parte del frontal.
Es verdad que las grandes empresas no suelen usar «los hostings habituales», o sí. En este caso sí que una recomendación que habitualmente planteo a los clientes es la de separar sus sistemas habituales, sobre todo los internos, de los públicos. Es decir, el hosting de la web va por un lado, y el del negocio, por otro. Si hace falta alguna relación, que sea mediante un sistema de APIs entre los dos sistemas.
Además, también hay que plantear la escalabilidad, los picos de tráfico, lo que significa que se pueden plantear sistemas de cloud muy a medida, porque, eso sí, la instalación general que viene por defecto en un hosting seguro que no nos sirve. Aquí hay que configurar todo de manera artesanal.
Ahora que ya tenemos la base, hemos de plantearnos cómo se va a trabajar. Y para esto hemos de plantear 3 plataformas, que se pueden resumir también en 3 hostings. Uno para DEVEL o desarrollo, uno para PRE, o preproducción, y otro para PRO o producción.
Aquí lo que prima es la seguridad y la estabilidad, y de cerca, el procedimiento que se va a utilizar para el mantenimiento y desarrollo y aplicación de los cambios que se van a hacer en la web, incluso se puede incluir la seguridad, copias de seguridad y oros factores.
Independientemente de quién trabaje en el proyecto, lo primero, todos los plugins, temas o complementos que no sean del Core de WordPress han de estar en un Git propiedad de la empresa y no propiedad de los desarrolladores o la agencia de turno. Esto es importante porque, por ejemplo, se puede montar un Gitlab (que es como un Github open-source) que se instala en un servidor que está en la misma red que las webs, y por tanto no quedaría nada público y todos los accesos están controlados. Que con Github también se puede hacer, que conste.
Lo segundo es conectar ese Git al entorno de desarrollo. Si alguien tiene que hacer un cambio en algún complemento, lo hará por el Git, o por el panel. En principio no hace falta acceso al FTP o similar, y si hace falta cambiar algo interno se pediría al equipo de sistemas.
Una vez se decida que hay una versión estable de algo, se creará la «release» correspondiente en el Git, para que quede todo el paquetito del plugin, tema o lo que sea, y sea descargable en ZIP compatible WordPress.
El paso siguiente será el de probar en PRE. Los entornos de PRE se crearán con una copia de seguridad de PROducción, y con esto conseguimos dos cosas. Por un lado que cada poco tiempo se pruebe al menos una copia de seguridad, y por otro, tener la web lo más parecida a una foto fija de un día.
En esta versión de PRE a la que sólo tendrán acceso los responsables del proyecto y la persona de mantenimiento, se subirán vía panel todos los plugins y elementos nuevos y se aplicarán las actualizaciones que correspondan, es decir, se harán todos los mantenimientos planificados. Todo ese «changelog» de cambios y los ficheros que se van a instalar quedarán agrupados en un sitio en modo «sólo lectura» para que cualquiera pueda revisar qué se va a hacer, ya sea la gente de producto, de seguridad o de contenidos.
Una vez todos los equipos den el OK correspondiente, se hará el pase a PRO siguiendo el changelog con pelos y señales.
Mi recomendación personal es que los lunes por la tarde se cierre ese changelog y se reciban todas las propuestas de todos los equipos, se monte ese entorno de PRE; el martes por la tarde se cierre el momento de validación, y el miércoles por la mañana se hagan los pases a producción. El jueves sería el día de revisar que todo está bien y de parcheados urgentes si se hiciera necesario, y el viernes no se toca nada.
En paralelo se harían una serie de procesos para todo lo que es infraestructura, por ejemplo aplicar parches de seguridad urgentes en los servicios, e incluso poder meter en ese protocolo las actualizaciones críticas de WordPress.
En paralelo también tenemos las nuevas versiones mayores de WordPress. Cuando tengamos las versiones BETA o RC, ahí ya cada uno con los tiempos que necesite para trabajar, pero hablamos de entre 8 y 4 semanas antes del lanzamiento de una nueva versión, se aplicarían esas versiones a DEVEL, de forma que se empiecen a probar todos los plugins temas y demás complementos en las nuevas versiones.
De esta forma, cuando llegue una nueva versión mayor de WordPress el 80% del y trabajo estará hecho y no hará falta esperar semanas o meses con el riesgo que puede conllevar de incompatiblilidades.
Esta parte es la estrategia de mantenimiento y el protocolo, que sirve para cualquier tamaño de proyecto en cuanto a equipos y personas que intervienen. Lo digo proque a diferencia de otros proyectos más a medida, WordPress suele funcionar muchísimo con varias empresas trabajando en paralelo. Una que hace más cosas del frontal y algún plugin, otra que hace plugins muy avanzados (no sé, algo que ntegra la API de la empresa con el propio WordPress) y la gente de sistemas y mantenimiento. Además, a esto, le sumamos las personas que llevan los contenidos y se encargan de mantener el WordPress a nivel editorial.
la base para que todo esto funcione está hecha con el protocolo anterior. Entre el sistema de Git, y que alguien se encargue de recibir y gestonar las peticiones de todos es lo ideal. Incluso, esto permite que el, propio WordPress solo necesite de 1 o 2 administradores, que serían la gente de sistemas y mantenimiento, y que el nivel más alto del resto sean los Editores, con la posibilidad de que a alguno de ellos le podamos dar algunos esteroides para poder gestionar algún plugin concreto que suele estar sólo disponibe para los Administradores. Un ejemplo, así de hace poco que me pasó, el plugin Redirection. Pues con una función que tienen en su documentación ,se puede crear un pequeño plugin que permite por ejemplo, que un editor haga cambios en la lista de redirecciones, pero no pueda reconfigurar, por ejemplo, los logs o la gestión de IP, que quedaría sólo a los administradores.
La escalabilidad, la revisión de los contenidos, las pruebas y todo queda en manos de unos pocos sobre los que recae la responsabilidad, los tiempos de mantenimiento se reducen a un par de minutos, y no es necesario montar moderneces de Dockers o Kubernettes ni cosas así que, para un proyecto con WordPress, no son nada necesarios (y en general suelen molestar más que ayudar).
A partir de aquí, todo es hasta donde se quiera llegar. La escalabilidad recae en el equipo correspondiente, el frontal y diseño, cae en la agencia de turno, y el plugin de control cae en el freelance experto en la gestión de APIs. Un equipo multidisciplinar, una agenda bien organizada, y un gestor de contenidos en el que puedes delegar gran parte de los elementos en la propia Comunidad WordPress.
Eso sí, si eres una gran empresa y tienes aparte de tu equipo en la parte de WordPress, podrías darte un homenaje y, ya que el núcleo de la plataforma te lo estás ahorrando, podrías dedicar media jornada de una o dos personas del equipo a contribuir en la Comunidad mediante el proyecto del Five for the Future.
Y para acabar, pues eso, que no es tanto el que tu empresa sea grande o pequeña, es más que los procedimientos de las grandes empresas estén bien descritos y hechos para que trabajar con WordPress sea algo que vaya como la seda.
Despedida
Recordad que nos podéis dejar ideas posibles temas de los que queréis que hablemos en el podcast.
Ya sabéis que podéis encontrar a Joan Boluda donde tenéis sus cursos de WordPress, y a Javier Casares con todos sus proyectos.
Ya sabéis que estáis más que invitados a participar a través de la sección de contacto de la web, a través de la que podéis enviar preguntas, dudas, y sugerencias para nuevos episodios.
Y recuerda que puedes suscribirte y escucharnos cada semana en Pocket Casts, Apple Podcasts, Spotify, Google Podcasts e iVoox.
¡Nos vemos el programa que viene con más WordPress!