Al importar pedidos de WooCommerce de una plataforma WordPress antigua nos podemos encontrar el caso de que las cantidades no suman bien, con situaciones tan absurdas como esta: pedidos que engrosan el total pero que no aparecen en el listado hagamos lo que hagamos. Miramos en la papelera, y tampoco están.

Pedidos invisibles

El motivo es que estos pedidos son borradores automáticos, que se almacenan en la base de datos con estado wc-auto-draft.

Estado de los pedidos en la base de datos

No hay que alarmarse si esto ocurre: no hemos hecho nada mal. Este comportamiento se debe a un bug de versiones antiguas de WooCommerce. Como sabemos, WordPress crea automáticamente borradores para las páginas, pero no debería hacerlo para los pedidos, pero esto es exactamente lo que ha ocurrido en la plataforma de origen. Al importar también nos hemos traído estos borradores de pedidos que, a pesar de encontrarnos en una plataforma WordPress con WooCommerce acualizada, seguirán teniendo este comportamiento «fantasma» mientras sigan en la base de datos.

Más

El comando sed de Linux es una poderosa y polivalente herramienta que nos saca de más de un apuro, aunque no la lleguemos a utilizar en todo su potencial. Resulta especialmente útil para realizar sustituciones masivas, del tipo cambiar «bar» por «foo» en un centenar de archivos.

La sintaxis básica del comando es sencilla:

sed ´s/bar/foo/g´ miarchivo.txt

Los problemas empiezan cuando la cadena a sustituir no es una simple palabra sino una línea de código HTML, por ejemplo:

Como cabe imaginar, hay caracteres en esta cadena (comillas, barra, etc) que interfieren con la sintaxis de sed y dificultan la identificación de la cadena, cuando no devuelven un error. Obviamente se puede intentar «escapar» los caracteres molestos precediéndolos de una barra invertida (\), pero en cadenas largas esto se puede complicar. El número de barras puede ser elevado y es fácil dejarse alguna por el camino, legibilidad aparte. Además, el «escapado» de las comillas simples puede acabar siendo una pesadilla que deriva en comportamientos no esperados (y hablamos por experiencia).

Para hacer el camino más suave, aquí van un par de consejos que no siempre se tienen en cuenta:

  • En sed, el delimitador por defecto es la barra (/), pero se puede utilizar cualquier otro carácter. El carácter inmediatamente siguiente a la s inicial se tomará como delimitador.
  • El argumento de sed irá entrecomillado a menos que la sustitución sea del tipo palabra por palabra. En la inmensa mayoría de los ejemplos veremos que se emplean comillas simples, puesto que si se usan comillas dobles se interpretarán los posibles caracteres especiales que contenga el argumento. Pero en casos como el que nos ocupa, nos puede salvar del apuro.

Por tanto, en nuestro caso, el comando de sustitución quedaría así:

sed -i "s||nuevo_texto|g" miarchivo.txt

Utilizamos el argumento -i para que los cambios se apliquen, puesto que si lo quitamos, estaríamos haciendo un «dry run» que simplemente volcaría el resultado por pantalla, dejando el archivo intacto.

Aunque todo se puede mejorar y los más avezados tirarán de complejas expresiones regulares, a veces un par de cambios sencillos como estos nos pueden ahorrar bastante tiempo.

Más

El My Book de Western Digital es uno de los dispositivos más utilizados para hacer backup con un Mac, gracias a su compatibilidad con Time Machine. Funciona tan bien, que cuando se dan situaciones como la que describimos a continuación, nos podemos volver locos.

No son pocos los usuarios que, de buenas a primeras, se han encontrado con que su My Book está inaccesible. Time Machine no puede acceder a él, pero el equipo está correctamente conectado y su disco duro sigue haciendo el ruido de siempre. Aun así, puede que esté defectuoso o que incluso haya que volver a formatearlo, aunque no se pueda salvar nada y se pierdan las copias. Abrimos por tanto Utilidad de discos e intentamos repararlo. La primera en la frente:

El sistema macOS no puede reparar el disco My Book

Obedientemente, intentamos salvar el contenido del disco, y ahí es cuando descubrimos que en Finder el disco no aparece montado. Pero en Utilidad de discos sí, pero ahora que nos fijamos aparece sombreado.

Disco sin montar

Probamos a borrar contenido, pues la opción sí está disponible:

Error al borrar My Book

Todo indica que el disco se ha montado o desmontado mal. Intentamos desmontarlo desde la propia aplicación para empezar de cero, sin éxito. Probamos con Onyx, que logra limpiar las copias de seguridad anteriores del disco, pero no permite realizar ninguna operación más. Desesperados, utilizamos el comodín del público, es decir, buscar en Google. Casi todos los hilos relacionados con este problema, no pocos por cierto, acaban recomendando desconectar y/o desenchufar el WD y reiniciar el Mac tantas veces como sea necesario, hasta que lo detecte de nuevo, dado que el dispositivo no parece dañado, sino haberse quedado en un curioso limbo.

Puede que para muchos usuarios, la pesadilla termine aquí, tras dos, tres o diecisiete reinicios. Pero antes de ponerse a mirar el horario del punto limpio, hay un camino más. De hecho, puede haber varios, pero este es el que nos ha funcionado a nosotros: la utilidad WD Discovery, ese icono azul que muchos usuarios tienen decorando el dock o el escritorio.

Icono de WD Discovery

WD Discovery se utiliza para descargar y actualizar las aplicaciones propias del fabricante, Western Digital, pero en este caso no tenemos que ponernos a investigar ninguna de ellas. Basta con abrir y/o actualizar WD Discovery et… violà! Nuestro disco aparece automágicamente en Finder y todas aquellas aplicaciones en las que no figuraba o su nombre se mostraba sombreado. OJO: puede que la actualización lleve un tiempo e incluso parezca que ha dejado colgado el equipo. Nuestro consejo: vayan a por un café y no miren la pantalla; es mejor así.

Pasados unos minutos de tensión, basta pasarse por Time Machine para comprobar que todo ha sido un mal sueño.

Guardando copia de seguridad con Time Machine

 

Más

Para los que trabajamos con WordPress, wp-cli es una herramienta salvavidas. Por su versatilidad, su potencia, y porque nos permite realizar cómodamente una gran cantidad de operaciones relacionadas con el despliegue y el mantenimiento de las plataformas. Su instalación es rápida y sencilla y su uso está bien documentado. Sin embargo, no son pocos los que desisten de utilizarla porque no logran instalarla, pese a que las instrucciones para su instalación se pueden encontrar con facilidad y los pasos vienen a ser siempre los mismos, los que describimos a continuación.

Se recomienda utilizar un usuario no root. No es requisito imprescindible, pero de no ser así se nos mostrará una advertencia.

1. Descarga del archivo .phar

Mediante

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

descargamos el archivo wp-cli.phar, que es el archivo PHP empaquetado que nos va a permitir ejecutar los comandos de wp-cli. Ojo, como vamos a ver a continuación, no tenemos que descomprimirlo ni desplegarlo. Es mucho más sencillo.

2. Ver si se ha descargado correctamente

En el mismo directorio en el que hemos realizado la descarga, ejecutamos

php wp-cli.phar --info

Deberíamos obtener un mensaje parecido al siguiente:

OS: Linux 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php7.3
PHP version: 7.3.15-3+ubuntu18.04.1+deb.sury.org+1
php.ini used: /etc/php/7.3/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /tmp
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.4.0

En caso de que obtengamos un mensaje del tipo «Not found» o similar, nos estará indicando que el archivo .phar no se ha descargado correctamente y tendremos que buscar otra fuente.

3. Permisos de ejecución

Para deshacernos de ese prefijo «php», asignamos permisos de ejecución al archivo:

chmod +x wp-cli.phar

Si ejecutamos ahora

./wp-cli.phar

obtendremos la misma salida de antes:

OS: Linux 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php7.3
PHP version: 7.3.15-3+ubuntu18.04.1+deb.sury.org+1
php.ini used: /etc/php/7.3/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /tmp
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.4.0

4. Mover y renombrar

Finalmente, movemos el archivo a /usr/bin para que se pueda ejecutar desde cualquier sitio y le damos un nombre más manejable: wp. En este paso sí tendremos que tirar de superusuario.

sudo mv wp-cli.phar /usr/bin/wp

Este paso, que como puede verse no tiene dificultad alguna, es en el que se quedan atascadas tontamente muchas instalaciones. El motivo es el siguiente: aquí, wp no es un directorio, sino el el nuevo nombre que le damos a wp-cli.phar para que sea más cómodo de usar. No son pocos los que creen, erróneamente, que lo que hay que hacer en este paso es mover el archivo .phar al directorio /usr/bin/wp/, un directorio que no existe por defecto y que muchos crean pensando que hacen lo correcto.

Si lo hiciéramos así, al intentar usar wp-cli (por ejemplo, con el comando wp –info), obtendríamos un mensaje de error:

wp: command not found

Si por el contrario hemos hecho lo correcto, es decir, mover el archivo .phar a /usr/bin/ y renombrarlo como wp, al volver hacer el test con el nuevo comando

wp --info

el resultado debería ser el mismo de antes, con independencia ya del directorio desde el que lo ejecutemos.

Más

Si administráis un sitio web que genera una gran cantidad de archivos temporales, como por ejemplo un sitio web de comercio electrónico, puede que en algún momento os encontréis con un error como este que os paraliza la web y, lo que es peor, os impide el acceso por phpMyAdmin:

Can't create/write to file '/tmp/#sql_bc9_0.MYI' 
(Errcode: 28): select * from ##### where (insale=1) and ...

El error 28 nos está indicando que no tenemos espacio suficiente, como podemos comprobar fácilmente con el siguiente comando:

$ perror 28
OS error code  28:  No space left on device

Pero una simple comprobación nos indica que aún tenemos más de un 40% del disco duro libre, luego el problema no es exactamente ese. Optamos entonces por intentar reparar la tabla en cuestión, sin éxito. La tabla sigue «marked as crashed» y al ejecutar el comando repair se nos muestra un error diferente:

Can't create new tempfile: './#####/#####.TMD'

No puede crear un archivo temporal pese a tener casi medio disco duro vacío. Al ser un sitio web con muchos archivos, puede que el problema esté en los inodes (inodos, en español). Los inodes son unas estructuras de datos de Linux (y otros SO) que contienen las características de cualquier objeto del sistema de ficheros, ya se trate de archivos, directorios o enlaces simbólicos. En una web de este tipo y sin la configuración adecuada, puede que el número de inodes crezca y crezca hasta bloquear el sistema.

Para comprobar si este es el caso, ejecutamos df -i, lo que nos devuelve el siguiente resultado:

Filesystem Inodes IUsed IFree IUse% Mounted on
udev 254877 1427 253450 1% /dev
tmpfs 255448 927 254521 1% /run
/dev/sda1 1509600 1509600 0 100% /
none 255448 2 255446 1% /sys/fs/cgroup
none 255448 1 255447 1% /run/lock
none 255448 1 255447 1% /run/shm
none 255448 2 255446 1% /run/user

Ese 100% en /dev/sda1 nos confirma que estamos sobre la pista correcta. Ahora hay que averiguar la ubicación exacta de esos inodes. Para ello vamos ejecutando este comando, empezando por el directorio raíz y profundizando poco a poco, para localizar cuál es el directorio que está saturado.

for i in /*; do echo $i; find $i -type f | wc -l; done

Esto nos devuelve una lista con el número de archivos de cada directorio. Nos adentramos a cada paso en aquél con mayor número de archivos, cambiando únicamente la ruta del for del comando por la ruta del directorio en cuestión. En nuestro ejemplo, esta búsqueda nos lleva finalmente hasta un directorio de sesiones de nuestra plataforma de e-commerce que contiene más de 76 millones de archivos.

La solución parece sencilla: borrar esos 76 millones de archivos, pero eso no es algo que Linux nos permita hacer con un simple rm * de los archivos anteriores a una determinada fecha.  Son demasiados archivos. En un caso como este, debemos echar mano del útil comando xargs, que divide la lista de archivos en sublistas a las que va aplicando sucesivamente el comando de borrado. Otro detalle a tener en cuenta en este caso es el tiempo de sesión, pues no debemos borrar los inodes de sesiones activas, de modo que el comando queda así:

find /directoriosesiones/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec | xargs rm {} \;

Y esto es todo. Para un caso como este con varios millones de archivos a borrar, debéis esperar un poco a que la plataforma vuelva a estar operativa.

Más

Es probable que alguna vez os hayáis encontrado con que en vuestro servidor Ubuntu se ha dejado de lanzar la cron de ISPConfig por algún motivo desconocido, y necesitáis lanzarla a mano. Pero antes de hacerlo, es pertinente que activéis el modo de depuración para verificar que no hay ningún error durante la ejecución de la cron.

Para ello, accedemos a nuestro ISPConfig y dentro de la pestaña Servidor, en el desplegable Loglevel seleccionamos el valor Errors.

ISPConfig

Hecho esto, pasamos a lanzar la cron desde la línea de comandos. La instrucción para eso es /usr/local/ispconfig/server/server/server.sh. Al haber activado el modo de depuración, se nos irá mostrando por pantalla cada una de las operaciones, para que aparezcan los avisos pertinentes en caso de que la ejecución de la cron conlleve algún error.

Línea de comandos

Más
Esta web utiliza cookies propias para su correcto funcionamiento. Puede consultar nuestra política de cookies, política de privacidad y aviso legal. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información    Configurar y más información
Privacidad