En WordPress las buenas prácticas son la base de que todo el mundo trabaje de forma similar y sea todo compatible. Hoy Javier hace un repaso de algunas cosas que hacemos mal, queriendo o sin querer.
Patrocinador
Copias de seguridad diarias en SiteGround: Cada día, durante 30 días, copias automatizadas disponibles desde el panel para restaurar y que se pueden alojar en otro centro de datos.
Enlaces comentados
- Joan ha presentado el Curso Intermedio de After Effects y Curso Avanzado de Google Tag Manager.
- Javier sigue trabajando con David en la mejora y lanzamiento de la versión 0.8 de WordPress Auto Translate para MultilingualPress.
Actualidad
WPDrama: plugin Zamir
WordPress 5.9.3, 31/03 o 05/04
Gutenberg 12.8:
- Webfont API
- Exportación de temas (importante). Crear temas, exportar index, styles y theme.json (además del resto de plantillas y cosas).
- Patrones del directorio en theme.json
- Mejoras en el bloque de navegación, con placeholders para facilitar su creación.
Two-Factor 0.8: incompatibilidad Chrome
Performance Lab: 1.0.0-beta 3 mejoras
Health Check and Troobleshooting 1.5.0: limpieza de código y simplificar.
Directorio de Patrones, envío desde el frontal. Es un editor de Gutenberg público que permite crear patrones allí mismo.
Eventos regionales.WooCommerce Store API is now considered stable
Tema del programa
Hoy es el día en el que he venido a buscarme enemigos, pero, la verdad es que me da un poco igual. Por cierto, sé que habrá gente que me conozca que se va a ofender porque se va a pensar que hablo de ellos, pero no, lo que voy a comentar es la suma de un montón de proyectos y de cosas que me han pasado en los últimos meses. Lo dicho, que nadie se lo tome como algo personal.
Una de las ventajas e inconvenientes de trabajar con mucha gente, ya sea por algo puntual, o sea por algo a largo plazo, es que ves muchos proyectos… cada uno de su padre y de su madre, y hoy me gustaría hacer un repaso de algunas cosas que se hacen mal.
Y cuando digo mal, no quiero decir que no se pueda hacer así, lo que quiero decir es que no se hace como se supone que se debería hacer y, aquí comienza la primera puya directamente contra la Comunidad: documentad bien.
Desde que salió WordPress 5.0 parece que cada versión nueva de WordPress solo lleva cambios en el editor, y nada más. Y aunque tanto aquí como en otros podcasts comento las novedades de cada versión, parece que la gente se queda únicamente con los nuevos bloques, si el editor va bien o va mal… y no.
Todo aquel que trabaja con WordPress, al menos los desarrolladores, los que hacen mantenimientos, los de sistemas y, en resumen, todo el que no es un simple usuario que usa WordPress, debería leerse al completo todos los artículos de los Dev-Notes que se publican en cada versión y rebuscar entre los cambios del Trac todo aquello que le pueda afectar. Supongo que esta es una de las razones por las que el equipo de documentación quiere lanzar el Blog en el Developer.
Y un ejemplo. Cuando instalamos un WordPress, ya sea subiendo los ficheros, o con alguna de esas herramientas de one-click o, con el sistema que queráis… ¿qué es lo primero que hay qué hacer?
Pues no. Bueno, no lo sé porque no estoy metido en vuestras cabezas aunque ahora mismo lo esté… pero seguramente el 99% de lo que habéis pensado es erróneo. Lo correcto es editar el WP-Config con tooodas las opciones habidas y por haber para que el WordPress no se desmadre. Limitar la cantidad de revisiones, el intervalo de autoguardado, las actualizaciones automáticas, las cachés, los debugs… en fin, será por opciones. Por cierto, un poco de autobombo, pero recordad que tenéis wpconfig punto pro para conseguir un fichero optimizado con vuestras configuraciones.
Y otra cosa a hacer, justo después de la primera instalación, es documentar. Sí, documentar qué has hecho, cómo lo has hecho, los accesos al sitio, los usuarios y contraseñas, si has tenido que instalar un «yoquesé» para que eso funcione… porque dentro de 3 meses no te acordarás, algo no funcionará y el que venga detrás a mirarlo se va a volver loco para encontrar porqué eso que no funciona, no funciona.
Por cierto, en algunos casos me he dado cuenta de que esos one-click de instalación te dejan activo el sistema de poder crear WordPress MultiSite… y la gente los usa mal. Así que, antes de seguir, y volviendo al principio, si un sitio no es WordPress Multisite, desactivad la opción que permite crearlos por cualquiera simplemente tocando un botón y que líe parda toda la instalación y la base de datos.
Como la mayoría de vosotros no sois Automattic para montar un WordPress.com en el que cada sitio está hecho a su manera, un WordPress MultiSite debería usarse sólo cuando la mayoría de plugins y temas son comunes entre sí. Por ejemplo, si vas a usar varios WooCommerce que venden casi lo mismo, o son multiidioma o multipaís, vale, eso cuela… pero en el momento en el que un WordPress que tenga 50 plugins, hay uno sitio que tiene 25 plugins activos, y el otro los 40, deberías plantearte si eso es lo que se debe montar. Y no me digáis que es que claro, es más fácil mantener un único WordPress que mantener muchos, porque tampcoo es 100% cierto. Mantener un WordPress MultiSite es ligeramente más complejo que varios sitios normales. Además, hay herramientas para mantener los sitios de forma externa muy fácilmente, y que ya hablaré en otro programa. Que las excusas no valen que yo gestiono y mantengo más de 100 WordPress cada día desde un único sitio funcionando todo a la perfección.
Volviendo al MultiSite, hay que tener en cuenta que consume mucho más un WordPress MultiSite de 5 sitios que 5 sitios separados. Por un lado porque no muchos plugins están optimizados para usarse en MultiSite, y por otro que, para empezar, necesitas como mínimo el doble de recursos del hosting.
Así que, piénsate si realmente has de usar un sitio único con 5 subsitios, o es mejor 5 sitios. Y no me digas que claro, es más difícil de mantener todo, porque WordPress incluye ya las auto-actualizaciones en el core, plugins y temas, si es que no quieres mantenerlo con alguna cosa externa.
Otra cosa importante: SIEMPRE, y lo digo en mayúsculas, hay que actualizar. Nada de «bueno, ya hacemos un mantenimiento cada 3 meses o cada versión nueva de WordPress». No, WordPress no es como Windows o Mac que le puedes dar a Recordar Más Tarde.
WordPress funciona con versiones mayores y parches, o si lo queréis llamar versiones menores, también me vale. Es decir, Tenemos las 2 primeras cifras de la versión, y una tercera. En el caso de WordPress tendríamos WordPress 5.9.3, por ejemplo. 5.9 es la versión, y .3 es la versión menor. En principio, si el programador no es tonto, cualquier versión menor se debería poder aplicar con los ojos cerrados a sabiendas de que es muy muy muy difícil de que falle. Otra cosa es cuando cambiamos de versión de la 5.8 a la 5.9, o de la 5.9 a la 6.0. Eso sí que hay que probarlo.
En resumen, nada de esperarme a que salga la 6.0.1 por si arreglan las cosas chungas… porque hoy en día WordPress se revisa mucho más de lo que puede parecer. Los procesos de lanzamiento desde WordPress 5.6 han cambiado mucho, y han llevado a que incluso, como pasó con la 5.9, se retrasase un mes y medio para estar seguros de lo que se lanzaba. Que sí, que como todo lo creado por seres humanos puede tener errores, pero la inteligencia colectiva ayuda mucho a encontrar problemas.
Y hablando de actualizaciones… ¿sabes que podrías tener un plugin que hace más de 10 años no se actualiza y no te enterarías? Porque WordPress te avisa de las versiones nuevas, pero no de si tienes un plugin o tema obsoleto o incompatible con tu versión actual… no puede ser que actualices plugins y no actualices WordPress, o que actualices WordPress y sigas usando un plugin compatible para WordPress 4.1…
Al menos, cada vez que haya una versión de WordPress nueva, aprovecha y revisa plugin a plugin que sea compatible con la versión actual, o alguna de las 2 versiones previas de WordPress… si vas con más de 3 versiones de retraso es probable que te acabe explotando en las manos esa instalación.
Y aprovechando que hablo de plugin sin actualizar… ¿has revisado ese plugin de un desconocido? Por ahora, aunque hay un proyecto para ello, no existe ningún tipo de revisión en el código de los plugins que se sube al repositorio… sí la primera versión, pero no el resto de actualizaciones… intenta investigar un poco quién anda detrás de un plugin, si se mantiene con cierta frecuencia, contacta con él a través del foro de soporte de cada plugin para informarte…
Venga, y la batalla final. Tú, programador. Sí, tú… ¿sabes qué es Git? Git es una herramienta para el control de versiones. No es tu FTP particular automático. Git es una herramienta en la que vas aplicando cambios de código en la que se van registrando los cambios, los puedes comparar, puedes ir para adelante y para atrás y, cuando tienes un código estable creas una etiqueta o, mejor aún, una «release». Esa release, que en general es un ZIP, suele ir relacionada a una versión. Y esa versión y ese ZIP es lo que se sube al WordPress.
Que conste que hablo de Git para WordPress, no de Git en general. Que sí, que puedes sincronizar tu Git con tu entorno de dxesarrollo, perfecto. Y que puedes sincronizar tu Git con un proyecto completo desarrollado a medida. En ese caso, allá tú. Pero con WordPress las cosas no funcionan así.
El Git no es un sistema que conectas a producción para que cuando hagas un commit se publique automáticamente. Para eso está desarrollo.
¿Verdad que cuando vas conduciendo tienes que parar a repostar? Y no equivocarte en poner gasolina a un diesel, o enchufar en la corriente equivocada? Y sí, es verdad que hay aviones a los que les enchufan una manguera en pleno vuelo, pero no me vayas de Maverick, ¡por favor! Que no sabes ni lanzar un avioncito de papel.
Pues con los plugins y los temas pasa lo mismo. Desde, creo recordar, WordPress 5.4 o así que ya se pueden sobrescribir los plugins directamente desde el panel. Te vas a la zona de plugins, te vas a Añadir nuevo plugin, y allí le metes el ZIP con la nueva versión del plugin. Si existe, te saldrá una pantalla preguntándote si quieres actualizar… y ¿sabes qué? Que si algo se fastidia por mitad del camino, desde WordPress 5.8, y más en WordPress 5.9 se hace un rollback automático que hace que el WordPress no explote.
Pero tú sigue subiendo los ficheros por FTP o sincronizados al Git para que en cualquier momento algún desarrollador cambie algo, tú no te enteres porque, obviamente, ni te avisan de que hay versiones nuevas ni de que han actualizado… y deje de funcionar tu sitio.
No hace falta que te quedes en los sistemas del siglo pasado haciendo cambios por FTP, ni que tampoco seas un «hashtag ModernitoDeMierda» haciendo inventos raros con Git.
WordPress tiene su propio sistema de actualización de plugins. Si en el panel tienes la opción de actualizar, le das a actualizar. Si quieres ir de guays, puedes hacer las actualizaciones mediante WP-CLI, que no deja de ser código de WordPress, y si no, subes el ZIP con la nueva versión.
¿Sabes qué otras cosas hacen estos 3 sistemas? Verificar y validar. Validan el código, validan la compatibilidad, y cuando se ha subido la actualización se refrescan las cachés que haga falta para que la gente vea el nuevo código desde el momento en el que se actualiza. Y todo sin salir de tu WordPress. Y digo más, si al subir el ZIP hay alguna cosa en el código que esté mal, petará antes de que deje de funcionar el WordPress, y te saldrá un mensaje diciendo que error tienes, para que puedas arreglarlo antes de romper todo.
Cuando tengáis dudas no hagáis eso de «es que mi primo lo hace así» o «es que mi cuñado me ha dicho» o «en una página de 2016 pone que se ha de hacer asá»…
Sabéis que mi lema principal es «si te vas a dedicar a Internet, has de saber cómo funciona Internet»… pues aplícate el cuento de «si vas a utilizar WordPress, has de saber cómo funciona WordPress»… que por algo, para conducir un coche hay que sacarse el carné de conducir.
Y hasta aquí la rajada del día… No os preocupéis, no estoy enfadado… aunque lo parezca. Un abrazo a todos los «hashtag ModernitosDeMierda» que nos escuchan. Yo también os quiero.
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!