el arreglo – WP Smush.it y el error «No se pudo encontrar» en WordPress Media Manager

Esto me volvió loco por un tiempo. Todas mis imágenes recientes en WordPress podrían ser «aplastadas» por WP Smush it, pero todo lo anterior a 2009 tenía un mensaje de error masivo. Si estás aquí probablemente ya lo hayas visto, pero para asegurarte de que todos estamos en la misma página, esto es lo que podría parecer:

WP Smush No puede encontrar el archivo

 

Esencialmente, dice que no pudo encontrar /home/yaddayadda/public_html/etc. Y en este caso si miras la ubicación, en realidad fluye dos veces – verás la doble barra // después de la primera «uploads» y comienza de nuevo. Había hecho un poco de búsqueda de una solución rápida pero no estaba teniendo suerte, así que era hora de empezar a cavar!

 

La causa (para mí, de todos modos)

Normalmente, las ubicaciones de las imágenes se almacenan en la base de datos de WordPress con su ruta relativa. Esto significa algo como 2006/04/image.png. Cuando llega el momento de encontrar la imagen, WordPress mira su configuración para ver dónde están almacenadas sus imágenes (generalmente i ), y comienza a juntar todo para obtener la ruta completa final. Es genial porque hace que las cosas sean más portátiles.

Desafortunadamente, cuando creé el sitio de WordPress en 2006, por cualquier razón, las imágenes que subí se almacenaban en la base de datos con su ruta absoluta. Para aquellos que no conocen la jerga, absoluto en este caso significa algo como /home/server_account/public_html/i/2006/04/image.png. Como se puede adivinar, esto puede causar un problema si alguna vez mueves tu carpeta de subida (o la instalación de WordPress) a otra ubicación en el servidor (o a otro servidor con un nombre de cuenta diferente). Cuando me transferí a otro host en 2008, evidentemente debo haber hecho un cambio que arregló las cosas para usar una ruta relativa, por lo que todo lo que se subió desde 2009 estaba muy bien para mí.

En cualquier caso, mientras que el propio WordPress puede sobrevivir con una ruta absoluta (siempre y cuando sea correcta), la ruta absoluta causa un problema para WP Smush.it. Por lo que puedo ver, atascará la ubicación de tu carpeta de subidas delante de la ruta, pase lo que pase. Así que si tus imágenes se almacenan en la base de datos con una ruta absoluta, acabas en un pequeño aprieto.

 

Ok, basta de quejarse. ¡¿Como arreglarlo?!

Sólo para avisarte, parte de este proceso implica editar manualmente tu base de datos de WordPress. Así que si no te sientes cómodo haciendo eso, tal vez quieras seguir buscando y esperar que alguien encuentre una solución más elegante. E incluso si te sientes cómodo, ***** retrocede primero***** por si acaso!!!

Ahora voy a hacer una suposición aquí – recuerde que dije que mis imágenes recientes estaban funcionando bien (siendo aplastadas adecuadamente). Asumo que lo mismo vale para ti y que si subes una nueva imagen ahora mismo, se aplastaría bien. Si ese no es el caso, querrás resolver ese problema primero.

Paso 1 (después de hacer una copia de seguridad) – editar la base de datos

A) la manera más segura (pero más larga) – edición manual

Usé phpMyAdmin, pero probablemente hay algunos plugins de bases de datos de WordPress que puedes usar si no tienes acceso a phpMyAdmin.

1) Abre tu base de datos de WordPress y selecciona la tabla «wp_postmeta«.
2) Localiza las entradas de «_wp_attached_file» que tienes problemas para aplastar y haz clic en «Edit«. (no te molestes en editar las entradas «_wp_attachment_metadata» – hacer cambios allí no funciona y por lo tanto haremos que WordPress las regenere más tarde).

Haz clic en la imagen de abajo para verla más grande
wp-smushit-could-not-find-02-database

Obsérvese que el «meta_value» de los 2 primeros (etiquetados como «GOOD») es 2006/03/sitemaps1.gif que es un camino relativo. Por otro lado, los etiquetados como «BAD» tienen un camino que comienza con /home/ que es un camino absoluto que no queremos.

SUGERENCIA: Si miraron la imagen, probablemente notaron… que esto es un poco desordenado. Una cosa que puede ser útil es tener otro navegador (o pestaña) abierto con tu biblioteca multimedia de WordPress, y buscar el ID de la URL cuando pasas el ratón por encima de cada una de las imágenes problemáticas (siempre y cuando tu navegador muestre la barra de estado en la parte inferior, deberías verla allí). También puedes pasar el ratón por encima del botón «Re-smush» – mostrará el mismo número de identificación. Haga coincidir este número con el de la columna «post_id» en la tabla de la base de datos para hacer coincidir las imágenes con la entrada de la base de datos.

3) Una vez en la página de edición, recortar la ubicación/ruta del archivo. Haga clic en las imágenes siguientes para ver un antes y un después.

Editar la tabla - ANTES Editar la tabla - DESPUÉS

Si tienes WordPress configurado para organizar las subidas de imágenes por año y mes, lo más probable es que tu resultado final sea idéntico al de la 2ª imagen, borrando todo hasta e incluyendo i/ y dejando el resto.
Recuerda, no quieres una barra inclinada.

4) Una vez que le des a «Go», deberías mirar la tabla de nuevo. Y la entrada que acabas de editar debería verse correcta.

CONSEJO: Antes de editar la siguiente (y la siguiente, y la siguiente), probablemente deberías continuar con el siguiente paso para asegurarte de que nada se vuelva loco. Además, sería una lástima editar cien de estos sólo para descubrir que tu material no se aplasta al final por alguna razón. Preocúpate de esta imagen por ahora hasta que sepas que todo está bien.

B) la manera rápida y peligrosa

En lugar de editar manualmente todas esas filas, si tienes acceso a phpMyAdmin y no te apetece editar manualmente docenas (posiblemente cientos de líneas dependiendo de cuántas imágenes tengas), es posible hacer una consulta a MySQL para emitir una gran búsqueda y reemplazo.

Ten en cuenta que te recomiendo encarecidamente que edites al menos una fila manualmente primero – si no hay nada más, te dará una idea de lo que estás haciendo. Oh, y si por alguna razón no lo has hecho todavía, asegúrate de hacer una copia de seguridad. Una consulta SQL que salga mal puede destrozar tu sitio en un abrir y cerrar de ojos.

 

El preliminar: 

Si recuerdan nuestro método manual de arriba, esencialmente estamos cambiando cosas como:

/home/username/public_html/i/2006/08/image.jpg

 a:

2006/08/image.jpg

Ese /home/username/public_html/i/ está básicamente siendo borrado una y otra vez, una vez por cada imagen. En lugar de hacerlo manualmente, para ahorrar tiempo podemos decirle a MySQL que simplemente corra a través de toda la tabla wp_postmeta y borre cada instancia de /home/username/public_html/i/ que encuentre. Es un poco peligroso porque si por alguna razón WordPress u otro plugin realmente pone esa línea allí para algo más y la necesita allí…. bueno ya no estará. Le eché un vistazo rápido y no noté nada que debiera ser problemático, pero por lo que sé, tal vez en la próxima versión de WordPress tengan algo nuevo allí que esto destruirá. ¿Mencioné que deberías retroceder primero?

Empecemos.

1) Sigue las instrucciones del «manual» de arriba hasta este punto:

Copia esta línea al portapapeles

 

Verá que he modificado ligeramente las instrucciones. Vas a seleccionar esto y copiarlo al portapapeles con CTRL-C, o CMD-C en la Mac. O haz clic con el botón derecho del ratón en la copia. O…. bueno, digamos que si ni siquiera sabes cómo copiar, estoy muy sorprendido (aunque extremadamente impresionado) de que te sientas cómodo editando una base de datos.

Ahora pega esa línea en un documento de texto en algún lugar. Tenemos que empezar a armar la consulta SQL.

El formato que vamos a usar es el siguiente:

UPDATE `table_name` SET `field_name` = replace(same_field_name, 'texto_no_deseado', 'texto_deseado')

Puede ser mejor copiar toda esa línea a un archivo de texto en lugar de escribirla. Hay 2 tipos diferentes de citas usadas en la línea anterior « y es fácil usar accidentalmente la incorrecta. Tenemos que cambiar esos elementos de color a los valores adecuados, así que esto es lo que vamos a cambiar.

table_name va a ser wp_postmeta (si tienes un prefijo distinto a «wp_«, asegúrate de usar tu prefijo en su lugar)
field_name va a ser meta_value (puedes ver en la imagen de arriba que era el nombre del campo que estábamos editando)
same_field_name va a ser también meta_value
texto_no_deseado es la línea que copiamos con CTRL-C antes de
texto_deseado será borrado, dejando sólo las 2 citas simples.

 

Adelante, haz esos cambios ahora. Con los cambios en su lugar, ahora debería tener algo similar a esto:

UPDATE `wp_postmeta` SET `meta_value` = replace(meta_value, '/home/username/public_html/i/', '')

Lo más probable es que con una instalación estándar, la tuya se vea idéntica excepto por la línea verde (a menos que tu webhost te haya dado literalmente «username» como nombre de usuario y hayas conseguido tener exactamente el mismo problema de ruta que yo). Recuerda, estás usando la línea con la que hiciste una CTRL-C.

Así que ahora para ponerla:

1) Con tu base de datos seleccionada, elige la pestaña SQL de la parte superior.
2) Pega tu línea de UPDATE en (si hay texto por defecto, sólo tienes que copiar sobre ella)
3) Presiona «Go»

Consulta de la base de datos phpMyAdmin

 

Si tienes éxito, te llevará a la siguiente página que te dirá el número de filas que fueron cambiadas. Puede que quieras navegar hasta la tabla wp_postmeta y echar un vistazo rápido para asegurarte de que el cambio se ha realizado correctamente. Si en su lugar sucedió algo bastante horrible (o algo realmente difícil de arreglar… como si se te pasó una barra y borraste «upload» en lugar de «upload/» ), asegúrate de tener esa base de datos respaldada lista y restáurala.

Paso 2 – Salir del editor de la base de datos, y entrar en un plugin.

Desafortunadamente, editar la base de datos no es suficiente. Necesitamos WordPress para regenerar los metadatos de los archivos adjuntos (básicamente las filas de la tabla de la base de datos que no hemos editado).

La forma más fácil que he encontrado para hacer esto es a través de un plugin llamado «Regenerate Thumbnails«. Para ser honesto, hace más de lo que necesitamos, pero tenía problemas para encontrar un plugin cuyo único trabajo era regenerar los metadatos. Esta es la razón por la que funciona bien para nosotros:

1) Se instala fácilmente (puedes instalarlo desde WordPress), y no hay que hacer ninguna configuración.
2) Si sólo quieres regenerar miniaturas (y metadatos) para imágenes específicas, puedes, y es fácil.
3) Si quieres regenerar miniaturas (y metadatos) para todo, puedes hacerlo también, y es fácil.

Por supuesto, hay un par de posibles inconvenientes… el plugin va a recrear las miniaturas en base a los valores actuales en Ajustes/Medios (para miniaturas, pequeñas, medianas y grandes). Si has ajustado la configuración del tamaño de la imagen unas cuantas veces en el pasado, sólo usa tu imaginación y podrás ver el potencial de algunas consecuencias no deseadas. Además, si un gran número de tus imágenes no se pueden borrar y planeas usar este plugin para regenerar todas las imágenes a la vez, la carga de tu servidor podría dispararse hasta que se complete. Tal vez quieras hacerlo temprano en la mañana para minimizar el impacto en el tráfico de la web. Ten mucho cuidado al usar esto si estás en un servidor compartido, particularmente si tienes miles de imágenes.

Puede que quieras regenerar una imagen a la vez para estar seguro. Tenga en cuenta que probablemente hay un número de otros plugins que funcionarían si prefiere algo más – Regenerar miniaturas fue simplemente el primero que encontré que parecía que iba a satisfacer mis necesidades.

Le sugiero encarecidamente que haga una copia de seguridad de sus imágenes antes de continuar por si acaso… Puedes hacer una copia de seguridad completa del sitio web fácilmente a través de cPanel si tu host lo usa. De lo contrario, al menos, alquitrán o zip el contenido de su carpeta de subidas.

Ok, entonces asumiendo que lo instalaste y activaste el plugin, aquí están los siguientes pasos:

Regenerar la uña del pulgar y volver a pulir

1) Entra en la Biblioteca Multimedia, encuentra la imagen que has editado en la base de datos y haz clic en Regenerar miniaturas.

2) Asumiendo que se complete sin errores (debería funcionar si la edición de la base de datos fue bien), presiona Re-Smush.

El desagradable mensaje de «No se pudo encontrar» (Could not find) debería desaparecer, y……

 

Aaaand….. ¡VOILA!

wp-smushit-could-not-find-06-fixed

 

Si tu prueba de una sola imagen funcionó, vuelve a la parte 1 y comienza a revisar las imágenes (revisa tus mensajes periódicamente para asegurarte de que las imágenes siguen mostrándose sin efectos secundarios negativos).

Envolviendo las cosas

Ok, eso fue mucho trabajo. Pero con suerte, al final todas tus imágenes podrán ser fácilmente aplastadas. Echa un vistazo a algunos de tus mensajes para asegurarte de que todo sigue como debería, y ten las copias de seguridad a mano por si tienes algún problema unos días después.

Si has pasado por el proceso y tienes algún consejo o historia que compartir (esperemos que sean buenas historias de éxito, pero las historias de terror también lo serán), ¡no dudes en hacerlo en la sección de comentarios de abajo!

 

2 Comentarios | Diga un comentario

  1. Excelente artículo Matt. Gran lectura y un gran recorrido. Tuve exactamente el mismo problema ejecuté mi sitio a través de un proceso similar. Iba a escribir el paso a paso, pero no es necesario. Solo señalaré lo que hiciste aquí.

    ¡Tnx otra vez!

    -S
  2. Muy buena representación pictórica.
    :D

Diga un comentario

Puedes usar un alias y un correo electrónico falso. Sin embargo, si eliges usar un correo electrónico real, se admiten los "gravatars". Lee la política de privacidad para más detalles.