… que a veces resolver algunas cosas de WordPress son más simples de lo que parece.

Un cliente me contactó porque su sitio web en WordPress se había “desarmado un poco”: en el home algunas cosas se desejustaron de la maquetación (apenas) y lo más importante, en una sección ya no le aparecían las imágenes.

La sección en cuestión usa un armado con solapas para separar los contenidos ligados a días específicos de la semana. Cada día tenía cargada una serie de imágenes, a modo de flyers, para cada actividad. Había dejado “funcionar”, o por lo menos eso parecía porque no aparecía cuando se visualizaba la página desde la parte pública.

Cuestión que me pongo a relevar qué plugins tenía instalados. Un montón, y algunos con funciones similares como los site builders.

Dado que no tenía forma de hacer un backup completo de la base de datos, quería tocar lo menos posible y no actualizar ningún plugin ni nada.

Mientras trataba de ofrecerle una maquetación alternativa con el builder que sí funcionaba (o al menos eso pensaba yo), que le permitiera cargar las imágenes y separarlas por día de la semana (y que no sea un choclazo, vamos, que quede amigable), me encuentro que al querer aplicarle la misma plantilla de página ¡el contenido dejó de aparecer!

El problema era que la página había estado usando una plantilla que no le correspondía: específicamente la de archives. Cuando hago el cambio en la página original que no funcionaba, ¡empezó a funcionar de nuevo!

Por cierto, también aprendí que los builders pueden ser atractivos al principio, pero tienen demasiados pasos para hacer cosas sencilla. Igualmente me resultó interesante la forma en que se manejaban:

… a preparar un WordPress para editar contenidos en HTML simplón ¡chau Dreamweaver!

La idea es tener un editor para formatear textos en HTML desde un editor visual, que los editores se puedan ingresar con clave y trabajar con una herramienta conocida, que se conserve el formato HTML, además que haga coloreado (highlight) de la sintaxis por si hay que tocar el código, y que puedan aplicar estilos CSS a los elementos desde un menú visual.

No interesa (por ahora) la opción de bloques que propone el Editor Gutenberg, pero no desecharlo, por lo que la instalación se hizo con WP 5.0.

Los plugins específicamente instalados:

Además están: WP Cerber Security de Gregory, el Resctric User Access de Joachim Jensen , Members de Justin Tadlock, WP2Static de Leon Stafford.

En el TinyMCE Advanced hay que habilitar en Configuración Avanzada la opción que mantenga los párrafos y saltos de línea, es decir, desactivar el autoformato que hace WordPress, y por otro lado, para agregar las class personalizadas como estilos de formatos hay que agregar en el archivo functions.php del theme activo el archivo editor-style.css que se debe crear a mano en el directorio, y luego tildar la opción en la configuración avanzada (mejorar esta explicación con un paso a paso)

Ideas a futuro:

Como el asunto es utilizar esta sola instalación para editar contenidos de muchos sitios una forma de separar es editar entradas y que cada sitio sea una categoría.

También se podría utilizar algún tipo de plugin que permita definir diferentes cabeceras y pie, o layout para las diferentes categorías y hojas de estilo personalizadas, ya que de esta manera se podría previsualizar “casi” cómo quedaría el contenido con el aspecto del sitio al que pertence.

… que los mapaches son en realidad como gremling ¡cuidadín!

Inteligentes + adaptables + tenaces + con manos prensibles: hacen lo que quieren.

Con la capacidad de desestabilizar ecosistemas si no se controlan (cosa muy difícl).

Me colgué leyendo estos artículos:

https://magnet.xataka.com/why-so-serious/aquella-ocasion-que-mapache-invadio-japon-culpa-anime-infantil?utm_source=genbeta&utm_medium=network&utm_campaign=editorial_recommendation_section

Y este hilo de twitterr

https://twitter.com/aderojas/status/1093133021623009280

… y dividir un archivo SQL grande para importarlo

Resulta que tenía que reestablecer la base de datos de un sitio en WordPress dado que una actualización en la base de productos del Woocommerce se había “llenado de basura” y limpiarla era más engorroso que volver a cargar la base (o eso pensaba).

El archivo comprimido del dump sql pesaba 1,5Mb pero un vez expandido eran 18Mb, lo cual generaba que el phpMyAdmin tardara muchísimo en procesarlo y no llegaba a completar la importación.

Entonces se me ocurrió importar el archivo en partes, así que busqué un poco y encontré que con el comando split se puede trocear un archivo de texto plano en varios partes consecutivas.

Gracias a https://unix.stackexchange.com/a/163415

split -l 8000 archivo-de-texto.txt

Esto me genera archivos de 8000 líneas nombrados xaa; xab; xac …

Y chau.

… a recuperar la clave de Piwigo e instalarlo manualmente

Hacía como 2 años que no me ocupaba de las instalaciones locales que tengo de Piwigo para administrar las imágenes y fotos, y en el medio había perdido las claves tanto de mi memoria como de la compu, así que tuve que decidí meterme directo en la base de datos.

Todo porque como había pasado tiempo entre aquella versión de Piwigo y la versión del MySQL en el sistema actual que arrojaba un error fulero (como ya habían reportado hace tiempo en los foros):

Warning:  [mysql error 3065] Expression #1 of ORDER BY clause is not in SELECT list, (...)

Antes de intentar modificar la base de datos logré colarme deshabilitando la autenticación de Piwigo alterando directamente el código PHP de la configuración gracias a esta documentación oficial:

https://piwigo.org/doc/doku.php?id=user_documentation:use:features:conf_locale

Mi parche consistía simplemente en devolver true sea cual sea la clave del usuario que estaba intentanto ingresar, pero a pesar de poder ingresar no pude hacer mucho así que me metí de nuevo con la base de datos.

Pasa eso tuve que modificar la tabla de usuarios y poner una nueva clave a mano codificada en MD5 (ver link).

Con esto ya pude ingresar “normalmente” y preparar el sitio para hacer el upgrade de versión de Piwigo manualmente.

Y chau.