Gestores de contenidos

Prestashop: regenera tus miniaturas sin error de “conexión con el servidor se interrumpió antes de finalizar”. 1.6 en adelante.

por

Algo muy común en los gestores de contenidos es tener que regenerar las miniaturas. Esto significa volver a crear las miniaturas a partir de la única imagen que solemos subir. Ya sea porque alguna tiene error, o porque hemos cambiado los tamaños.

En Prestashop también existe esta opción, y se puede hacer “de golpe” (si tienes muy pocas), o por tipos (categoría, productos etc). Aún así, en cuanto tienes un buen número de productos, es muy común que te salga el error “Solamente una parte de las imágenes han sido regeneradas. La conexión con el servidor se interrumpió antes de finalizar.“

La razón es que los servidores tienen un tiempo que dejan que los procesos se ejecuten sin recibir respuesta. A partir de dicho tiempo ocurre lo que llamamos un “timeout” y el proceso se da por “colgado“. Esto ocurre para evitar tener procesos abiertos indefinidamente que bloqueen el servidor.

Puedes intentar subir los parámetros de php que regulan este timeout, los max_execution_time y max_input_time. Pero ya te digo que, en un alojamiento compartido, si tienes suficientes productos, es difícil que esto te resuelva el problema.

Es por ello que este plugin que recomendamos hoy es tan útil. Lo que hace es ir regenerando miniaturas por Ajax, donde el proceso es cada miniatura (o conjunto de ellas) y no todas. Consigue así evitar el error, y además otras cosas útiles como a) ver el estado de la regeneración b) pausarla y reanudarla cuando quieras.

Plugin gratuito para regenerar miniaturas: imageRegeneratorPrestashop.

Esta es una de las maravillas de tener una comunidad que aporte al gestor de contenidos. Este autor ha creado un módulo totalmente gratuito, válido para Prestashop 1.6 y 1.7 (1.6 en adelante). Y funciona muy bien.

Podéis descargarlo de su página de Github: https://github.com/ComonSoft/imageRegeneratorPrestashop (creo que ese es 1.6 y este 1.7 https://github.com/meetjey/imageRegeneratorPrestashop) o, más fácil, desde su página web: https://boutique.comonsoft.com/fr/modules-gratuits-prestashop/27-regeneration-des-images-prestashop.html

Es muy sencillo de usar: instálalo, actívalo y tienes un botón con las opciones de regeneración. Además, como os dije, podéis pausarlo y ver su proceso. Muy fácil, muy sencillo y muy eficaz.

Los plugins de backup, copia de seguridad, que más usamos en WordPress

por

Hace unos días un cliente nos ha contactado porque la empresa que les gestionaba la web no les había configurado una copia de seguridad. Y querían una solución. Les contamos lo que vamos a contaros hoy aquí.

Las copias de seguridad de una web en WordPress puedes tenerlas de dos maneras:

  1. Si tienes control de tu servidor (un servidor dedicado) puedes tener sistemas de copia de seguridad externos, con copias incrementales, con gestores de copias etc. Por ejemplo nosotros tenemos un servidor dedicado a las copias de seguridad, con un programa que gestiona las mismas, así como sus recuperaciones.
    Es más cómodo, más seguro y es independiente de WordPress. Funciona aunque éste no funcione o esté dañado, y permite recuperar las páginas de nuevo independientemente de tu CRM.
  2. Lo más normal es que no cumplas el punto 1, porque estés usando un alojamiento (hosting) compartido. En ese caso, puedes usar plugins de backup (copia de seguridad). De hecho, siempre recomendamos hacerlo aunque dispongas del punto 1. Porque nunca hace daño tener dos sistemas de respaldo. Y porque los propios usuarios pueden usar este sistema y, muchas veces, recuperar la web, o hacer copias antes de un cambio, sin tener que llamar a los técnicos.

    La copia de seguridad que se configure en el plugin puede ser externa (mejor) o interna (en los propios directorios del alojamiento). La segunda opción es peor…pero a veces no queda más remedio.

Hoy os hablamos de los plugins de copia de seguridad que más usamos en diferentes proyectos para que podáis tenerlos como referencia rápida.

Plugins de backup para WordPress.

  • BackWPup: Es el plugin que más usamos, y más tiempo llevamos usando, sin duda. Te permite crear diferentes tareas perfectamente configurables. Por ejemplo puedes crear una tarea mensual, una semanal, una completa, una sólo de base de datos… las opciones son enormes.
    Puedes elegir de qué hacer la copia (ficheros o base de datos), dónde (en el alojamiento o en sistemas externos), cada cuanto, excluir ficheros o directorios y mucho más.
    Además, puedes crear alertas que te avisen cuando haya errores.
    Restaurar: te permite descargar la copia de seguridad y subirla manualmente. Algo que para la mayoría de los usuarios puede ser peor…pero a los desarrolladores nos gusta.
  • Updraft Plus: nuestra segunda opción. Cuando el anterior no funciona porque la tarea se queda colgada, usamos este. Está pensado para usar servicios externos pero también permite hacer copias de seguridad locales. Si quieres uno sencillo de usar puede ser una buena opción porque permite crear respaldos, y restaurar, con un sólo clic. Y luego también te deja personalizarlos al máximo.
    Rápido, fácil y sencillo. Por eso tiene tanto éxito.
    Restaurar: puedes restaurara ficheros o base de datos de manera conjunta o independientemente y desde la interfaz del plugin.
  • BackupGuard: el plugin permite hacer copias de seguridad locales y en la nube, y restaurarlas de manera sencilla. Con muchas opciones de respaldo.
  • Vaultpress: sistema de copia de seguridad de Jetpack. Es de pago pero permite copias de seguridad a tiempo real o diarias y puede ser interesante para webs críticas.

Estos son de los que más nos fiamos y hemos probado. Si, en el futuro, probamos más, los incluiremos aquí.

Cómo desinstalar el plugin WP Rocket de manera manual en WordPress

por

Los plugins de caché son muy útiles para mejorar el rendimiento de nuestra página en WordPress. Pero, cuando dan problemas, se pueden poner muy pesados. Tanto, que no sea posible quitarlos desde el backend y sea necesario desinstalarlos de manera manual.

Ya escribimos cómo hacer esto con WC Total Caché, hoy os dejamos el proceso para otro muy conocido WP Rocket.

Cómo desinstalar WP Rocket de manera manual.

Tienes que:

  • Eliminar la carpeta del plugin de  /wp-content/plugins/
  • Borra la carpeta  /wp-content/cache/ 
  • Borrar la carpeta  /wp-content/wp-rocket-config/ 
  • Borra el fichero /wp-content/advanced-cache.php
  • Edita el fichero htaccess y borra cualquier cosa entre  #BEGIN WP ROCKET y #END WP ROCKET
  • Edita el fichero wp-config.php de la raíz de tu web y cambia el campo define(‘WP_CACHE’, true)  a define(‘WP_CACHE’, false) 
  • Borra la entrada wp_rocket_settings y la entrada transients and cronjob en la tabla Options de tu base de datos.

Con eso ya debería estar todo borrado. Más información aquí.

Comandos útiles para Magento 2

por

Llevamos un tiempo manejando Magento 2, y muchas de las acciones hay que hacerlas por línea de comandos. Así que, para referencia nuestra, y por si os viene bien a alguno, os dejamos un resumen de los comandos más útiles y usados.

Comandos más útiles en Magento 2.

Os dejamos los más usados (e iremos ampliando):

  • php bin/magento setup:upgrade : actualiza la configuración
    Si quieres conserva los ficheros estáticos puedes ejecutar: php bin/magento setup:upgrade –keep-generated
  • php bin/magento setup:di:compile : ejecuta el compilador
  • php bin/magento setup:static-content:deploy : deploy para el lenguaje por defecto (en_US).
    Si quieres forzarlo puedes poner: php bin/magento setup:static-content:deploy -f
    Puedes hacerlo para un tema concreto: php bin/magento setup:static-content:deploy –theme Magento/tema
  • php bin/magento setup:static-content:deploy es_ES : deploy para un idioma específico (puedes cambiar el idioma del final).
  • php bin/magento cache:clean : borra (purga) la cache por etiquetas.
    Puedes especificar el tipo de caché a vaciar poniendo php bin/magento cache:clean [type] …[type]
    Los tipos se separan con espacios y son los siguientes:

    Tipos: config, layout, block_html, collections, reflection, db_ddl, compiled_config, eav, customer_notification, config_integration, config_integration_api, full_page, config_webservice, translate
  • php bin/magento cache:flush : borra la caché completamente.
    Puedes especificar el tipo de caché a vaciar poniendo php bin/magento cache:flush [type] …[type]
    Los tipos se separan con espacios y son los mismos que en cache:clean (encima)
  • php bin/magento cache:enable : habilita la caché.
    También admite los type como en las dos opciones anteriores.
  • php bin/magento cache:disable : deshabilita la caché.
    También admite los type como en las opciones anteriores.

NOTA: Es muy normal que se ejecuten los siguientes comandos juntos tras un cambio en la configuración:

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
php bin/magento cache:clean
php bin/magento cache:flush

  • php bin/magento indexer:status : ver el estado de los índices de búsqueda.
  • php bin/magento indexer:show-mode : muestra el estado de los índices.
  • Reindexar los índices (para las búsquedas):

    php bin/magento indexer:reset
    php bin/magento indexer:reindex
    php bin/magento cache:clean
    php bin/magento cache:flush
  • php bin/magento module:status : ver el estado de los módulos (cuáles están activos y cuáles no).
  • php bin/magento module:enable Namespace_Module : Habilitar un módulo. Namespace_Module es el nombre del mismo como aparece en module:status (encima).
  • php bin/magento module:disable Namespace_Module : Deshabilitar un módulo.
  • php bin/magento module:uninstall Namespace_Module : Desinstalar un módulo.
  • php bin/magento deploy:mode:show : Consulta el modo de funcionamiento de Magento activo.
  • php bin/magento deploy:mode:set developer : Activa el modo desarrollo.
  • php bin/magento deploy:mode:set production : Activa el modo producción.
  • php bin/magento maintenance:enable : Activa el modo mantenimiento.
    Si quieres sólo habilitarlo excepto para ciertas IPs ponlas así:
    php bin/magento maintenance:enable –ip=x.x.x.x –ip=y.y.y.y.
  • php bin/magento maintenance:disable : Desactiva el modo mantenimiento.
  • php bin/magento maintenance:status : Estado del modo mantenimiento.
  • php bin/magento admin:user:unlock adminusername : Desbloquear un usuario administrador.

Más información aquí.

Moodle muestra las imágenes corruptas tras una migración: solución.

por

Hace unos días migramos un Moodle de un alojamiento a otro. Estas migraciones las hacemos constantemente, y no suele haber problemas.
Sin embargo está si que los dio: en el nuevo alojamiento las imágenes aparecían pixeladas, y verdes. En definitiva corruptas. Os mostramos un ejemplo.

Se podía también ver porque si entrabas en el backend y activabas el modo debug salían unos errores de visualicación de imagen donde indicaban que la imagen estaba dañada.
Además, si intentabas descargar la imagen desde el backend, no podías reproducirla.

Solución.

Las imágenes en Moodle están cifradas con un hash SH1. Puedes ver más información aquí: https://docs.moodle.org/dev/File_API_internals#File_API_internals

Esto lo hacen para que una imagen sólo tenga que guardarse una vez aunque se referencie muchas veces en el sitio, incluso con distinto nombre. Como se hace en el control de versiones de git, por ejemplo. Además, quiere decir que, entre otras cosas, se puede comprobar si un fichero está dañado o no con el comando sha1sum de Linux.

Pero, para el caso que nos ocupa, también quiere decir que no puede haber ninguna modificación en la transferencia de los archivos por FTP. Esto quiere decir, a modo práctico, que tienes que forzar en tu programa de FTP, por ejemplo en Filezilla, que la transferencia sea en modo Binario y no en Ascii o Auto. Los dos modos anteriores puede corromper las imágenes.

Para hacerlo en Filezilla sólo tienes que ir a Edición > Opciones > Transferencias > FTP: Tipos de archivo y en Tipo de transferencia predeterminada ponerlo en Binario.
Luego tienes que volver a descargar todas las imágenes de nuevo (el directorio data de Moodle) e importarlas otra vez. Verás que al hacerlo tendrás las imágenes sin corromper en el nuevo site.

Módulo gratuito Banner en el carrito para Prestashop 1.7.

por

Hoy os dejamos un recurso gratuito para Prestashop 1.7 que ha salido hace poco. Desarrollado por Prestashop.

Es un módulo llamado Banner en el carrito. Lo que hace es que te permite poner avisos cuando el cliente llega al carrito. El aviso sale como un banner en la parte superior del carrito y es adaptable para móviles. Además de ser multilingüe.

Con este banner podrás:

  • Poner recordatorios o alertas para tus clientes
  • Avisar de ofertas especiales.
  • Animar a tus clientes a tener conciencia ecológica reduciendo los paquetes agrupando los pedidos.
  • Y mucho más…

Así, podrás mantener a tus clientes informados, alertarles de cualquier promoción o problema con la tienda e incentivar más compras.

¡Y gratis!

Magento 2: RedSys. Pedidos se quedan pendientes y tras el pago,lleva a una página a una página con error.

por

Si tienes Magento con el módulo oficial de RedSys puede que te esté ocurriendo este error. Los pagos están entrando, se reciben, pero el pedido se queda pendiente y al cliente le devuelve a una página con error.

La causa de esto es que el módulo está mal, tiene definidas 3 páginas de “callback” (retorno):

DS_MERCHANT_MERCHANTURL, DS_MERCHANT_URLOK y DS_MERCHANT_URLKO

Estas páginas son las de la tienda, las de pedido correcto y las de pedido erróneo. Pero el plugin tiene definida la misa url (dirección) para todas estas páginas.

Os enseñamos a corregirlo.

Solución.

Tenemos que modificar el fichero /app/Code/Redsys/Redsys/Controller/RedSysController.php y añadir las direcciones. Una manera de hacerlo es:

  • Encontrad donde pone  $urlTiendaOK=$this->_baseURL.”redsys/index/notify”; y añadid justo después las siguientes dos líneas (dos variables):
        $urlTiendaOK=$this->_baseURL.”checkout/onepage/success”;
        $urlTiendaKO=$this->_baseURL.”checkout/onepage/failure”;
  • Id a donde pone:

    $miObj->setParameter(“DS_MERCHANT_URLOK”,$urlTienda);
    $miObj->setParameter(“DS_MERCHANT_URLKO”,$urlTienda);

    y cambiadlo por

    $miObj->setParameter(“DS_MERCHANT_URLOK”,$urlTiendaOK);
    $miObj->setParameter(“DS_MERCHANT_URLKO”,$urlTiendaKO);

De esta manera tiene las nuevas direcciones a las que ir cuando el pago sea exitoso o no.
Probad ahora un pago, veréis como llega bien a Magento, el pedido pasa a su estado pagado y el cliente recibe el mensaje de “pago correcto”.

WooCommerce: hacer que el estado del pago contrareembolso sea “En Espera” en vez de Procesando.

por

Hoy os vamos a dejar un pequeño código para cambiar el estado de los pedidos realizados en WooCommerce con el método de pago contrareembolso. No estamos arreglando un error, el sistema funciona correctamente. Es una modificación para ciertas tiendas que necesiten algo especial.
En la mayoría de los casos, cuando un pedido se hace contrareembolso, es normal que su estado sea Procesando porque el pedido debe enviarse. No tiene que esperar a nada. Se pagará al recibir el pedido.

Pero, en ciertos casos, se usa este método de pago como “pago en tienda” o “pago en mano”. En estos casos, especialmente si el pedido da acceso a descargas o productos virtuales, el pedido no debería ser Procesando (porque dicho estado da acceso al material online). Es mejor que se quede “En Espera” hasta que se procese el pago.

Estos días hemos tenido un caso parecido, y lo hemos arreglado generando un código (modificado de uno que encontramos en Internet) que afecta sólo a este tipo de pedidos. Os lo vamos a dejar por si os sirve (y porque no nos resultó fácil encontrar la solución).

Como siempre, el código debe insertarse en el functions.php del tema hijo, o en un plugin como Code Snippets.

Código para poner el pedidos pagados por contrareembolso como En Espera en WooCommerce.

El código es el siguiente:

function wooc_cod_status( $status ) {
return 'on-hold';
}
add_filter( 'woocommerce_cod_process_payment_order_status', 'wooc_cod_status', 15 );

Cuando lo apliquéis, haced una prueba con ese método de pago. Como veis usa un hook de WooCommerce woocommerce_cod_process_payment_order_status y, a fecha del artículo, está probado y funcionando.

Magento 2. MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled. Refused to apply style.

por

En ocasiones en Magento 2 vemos que nuestro sitio web no se ve bien, no se cargan los CSS o los JS y sale el error:
“MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled. Refused to apply style.”

Lo que ocurre en este caso es que el contenido estático no está correctamente generado y hay que regenerarlo. Pero no lo podemos hacer desde el backend (si la página está en modo producción, que debería). Lo tenemos que hacer por línea de comandos. Hoy os enseñamos cómo.

Solución.

Puede haber diferentes causas, os dejamos varias.

  1. Realizar un deploy.
    Sería una de las primeras cosas a probar: realizar un deploy que genera de nuevo todos los ficheros estáticos necesarios para producción. En teoría esto se hace desde el directorio raíz de Magento con:

    php bin/magento setup:static-content:deploy

    Lo que no viene en casi ningún manual es que esto hace deploy del contenido en_US, y no del español. Por eso a nosotros no nos funcionó. Tuvimos que forzar el deploy del contenido español con :

    php bin/magento setup:static-content:deploy -f es_ES
  2. Parece ser que si vas a modo Developer (desarrollo) y luego pasas a modo Producción te hace el paso anterior, te genera de nuevo el contenido estático. Otro día mostramos cómo hacer eso.
  3. Permisos.
    Puede que los ficheros no se estén cargando bien por tema de permisos. Para eso comprueba que los permisos están correctamente. Deberían ser:
    – Directorios: 711: find . -type d -exec chmod 0711 {} +
    – Ficheros php: 600: find . -type f -name “*.php” -exec chmod 600 {} +
    – Todos los demás ficheros 644. find . -type f -exec chmod 0644 {} +

    Comprueba que los ficheros y directorios pertenecen al usuario:grupo correcto (en modo recursivo). Y además que el directorio bin/magento tiene permisos de ejecución: chmod u+x bin/magento
    Más info aquí.
  4. FIchero .htaccess en pub/static/
    Entra en el directorio pub/static/ y asegúrate que tiene el fichero .htaccess. Cuidado, recuerda que es un fichero oculto.
    Si no está:
    – Descárgate la versión adecuada de Magento.
    – Coge el fichero de pub/static de esa descarga.
    -Súbelo a tu sitio.
    – Limpia caché de Magento y de tu navegador.

Cómo saber cuándo una web cambia a modo móvil. Media Queries en el inspector.

por

Cuando estás diseñando una página web, tienes que tener en cuenta los diferentes tamaños de los dispositivos. Ya no diseñamos una web, sino varias para diferentes tamaños. Lo que se llama hacer la página responsive y se hace mediante los media queries.

Una vez hecha la web, podemos querer saber en que tamaños están definidos esos cambios de comportamiento. Cuándo cambia una web de ser modo escritorio a ser modo tableta o modo móvil. E incluso dentro de cada una, si hay diferencias.
Esto se puede hacer con un truco en el inspector del navegador que no está activo por defecto. Hoy os enseñamos a activarlo (en Chrome, es similar en otros).

Activar los media queries en el inspector de Chrome.

Para activar los media queries en el inspector tenemos que:

  • Activar el inspector (botón derecho-> inspeccionar o Ctrl+Shit+I)
  • Ponerlo en modo responsive pinchando en el icono del móvil.
  • Arriba a la derecha hay 3 puntos en vertical en la barra de responsive.
  • Si pinchas en esos puntos se despliega un menú y tiene la opción de show media queries.

En el vídeo se ve cómo hacerlo y cómo usarlos.