Blog

Internet, Navegadores, Trucos

Cómo evitar que se abra Edge en vez de Internet Explorer. Usar IE para sitios que lo necesitan.

/

Hace unos días un cliente, del ramo legal, nos llamó porque cuando intentaba abrir Internet Explorer se le abría automáticamente Edge. ¿ Y por qué quería abrir Internet Explorer? Porque desgraciadamente la administración española (y cualquiera que tiene que hacer trámites en ella lo sabe), y las webs legales de la administración, todavía tienen páginas que sólo funcionan en Internet Explorer. Y no es que no hayan tenido tiempo para migrarlo. Así que hoy os enseñamos cómo conseguir volver a abrir Internet Explorer en vez de Edge. Nota: ni se os ocurra usar IE para navegar. Es MUY inseguro. Cómo evitar que se abra Edge cuando queremos abrir Internet Explorer. Los pasos son los siguientes: Abre Edge Ve a los puntos en la parte superior derecha o pulsa Alf+F. Pincha en Configuración. Ve a la opción de Navegador predeterminado. Donde pone Permitir que Internet Explorer abra sitios en Microsoft Edge selecciona las opciones Nunca o Sólo sitios no compatibles (recomendado). Cierra Edge. Ahora verás que puedes abrir IE sin problemas. Como siempre, os lo mostramos en este vídeo.

Diseño Web, Gestores de contenidos, Trucos

Cómo cambiar el orden de los medios de pago en Prestashop.

/

Hace unos días, un cliente nos pidió que cambiáramos el orden de los medios de pago. Es decir, que cuando un cliente fuera a pagar, los medios de pago que le aparecieran fuera en el orden que quería. Y cuando fuimos a hacerlo, no es tan directo como parece. Así que os dejamos aquí cómo hacerlo. Cómo cambiar el orden de los medios de pago en Prestashop. Os lo vamos a mostrar en la versión 1..7, la actual. Obviamente, con el tiempo, esto puede cambiar, y en versiones anteriores puede ser ligeramente distinto. Para poder cambiar los medios de pago tenéis que: ir a Diseño -> Posiciones. Pero si buscáis ahí no van a aparecer. Tenéis que marcar la casilla Mostrar los hooks invisibles. Buscad la posición paymentOptions. Ahí podréis, con las flechas, cambiar los medios de pago. Subís y bajáis para poner el orden que queréis. Os lo mostramos en el vídeo. Esperemos que os sirva.

Trabajos, Webs

Nueva web tutors.smythacademy.com

/

La pandemia del COVID-19 ha servido para promover de una manera impresionante la educación online. Si, tienes sus pros y sus contras, pero está claro que está aquí para quedarse. Entre las ventajas de la educación online está que las empresas puede abrir sus zonas de acción, pueden impartir clases al público internacional. Pasan de escala local a escala global. Como respuesta a este cambio nace Tutors de Smyth Academy. https://tutors.smythacademy.com/ Una web para que los clientes puedan solicitar a los profesores con amplia experiencia en la enseñanza tanto del Sistema Británico (IGCSE, AS y A Level), como del Bachillerato Internacional (IB). La web es una web con poco contenido: básicamente una explicación de los servicios, del método que se sigue y una muestr de los vídeos del canal de Youtube. Así que, en esta web, hemos decidido realizar un aspecto gráfico diferente. Con fondos preparados, anchors que llevan de una sección a otra y ligeros efectos de movimiento. ¡Esperamos que os guste´!

Internet, Noticias Informáticas, Sistemas

Internet, la nube, la redundancia y los planes B. Caída de Fastly.

/

Hace poco el incendio en un CPD de OVH causó la caída de muchas páginas en Europa, y la posible pérdida de datos para los clientes. Pero buen, al fin y al cabo estamos hablando de clientes que deberían también tener sus copias de seguridad. Recientemente le explicaba a un cliente, que depende mucho de Sharepoint, que la nube tiene mecanismos redundantes para intentar asegurar las continuidad del servicio. Y dos días más tarde “se cayó” Sharepoint durante unas horas cruciales para ellos. Hoy, alrededor de las 12:00, se han caído webs tan importante como la CNN, The New York Times, HBO Max, Shopify, Twitter, Twitch, Vimeo.… En un principio se pensó en caída física ( de AWS principalmente) pero luego se ha confirmado que es un problema en el servicio de Fastly, un CDN que usan muchas empresas para acelerar las páginas y protegerlas de ataques de DDoS. Fastly ha confirmado el hecho. ¿Qué debería aprender Internet (clientes y proveedores) de todo esto? En informática los fallos deberían usarse para aprender y mejorar. Igual que el incendio de OVH lo deberían haber usado los clientes para revisar sus políticas de copia de seguridad, esto se debería usar como aviso. Tanto clientes como proveedores deberían darse cuenta de la importancia de medidas reduntantes y planes de disaster recovery. Y exigirlo a los proveedores. Todo es susceptible de fallar. Pero si dependes tanto de la nube, y hoy lo hacemos, debería haber un Plan B para cada componente vital. si cae la línea deberíamos tener una de respaldo. si cae el servidor deberíamos tener una copia redundante, preparada para estar arriba en minutos. si mi alojamiento no funciona, tener otro de AWS o de Google Cloud para poder restaurar la página en minutos. si cae el CDN, como hoy, deberíamos estar preparados para desactivarlo. Y el CDN debería tener unos de respaldo. ¿Por qué estas empresas no parecen haber pensado nada de esto o tenerlo en cuenta? Y si, todo eso lleva dinero. Pero ¿ cuánto dinero están perdiendo estas empresas por tener 1,2-5 horas caías las webs? No podemos estar teniendo estas caídas globales en sistemas críticos para nuestros negocios. Revisad vuestros sistemas, ved dónde pueden fallar, y aseguraros que tenéis preparada una respuesta para activarla en menos de 2 horas.

Limpieza de PC, Sistemas, Trucos

Quitar aplicaciones de inicio en Windows. Optimizar Windows.

/

Cuando se habla sobre cómo optimizar Windows, hacer que vaya más rápido, que arranque antes, etc, uno de los puntos que siempre salen es este: quitar las aplicaciones de inicio de Windows 10. Es sencillo, estas aplicaciones se arrancan al iniciar Windows. Este no se vuelve funcional hasta que todas se cargan, por lo que ralentiza el tiempo que tardamos en poder usarlo. Además. al estar ejecutándose todo el rato, las usemos o no, quitan RAM y procesador, es decir quitan recursos del sistema y lo hacen más lento.Quitar estas aplicaciones o, al menos, mantenerlas a raya, es una buena idea para que nuestro ordenador vaya fluido. Podéis mirar también la opción de quitar aplicaciones de segundo plano. Cómo quitar aplicaciones de inicio en Windows 10 en adelante. Quitar aplicaciones de inicio siempre ha sido una opción, en casi todos los Windows. Pero antes de Windows 10 había que hacer cosas como dar botón derecho en la barra de tareas, abrir el Administrador de tareas, Ahí se podía elegir qué programas queríamos que se iniciaran con Windows y cuales no. Teníamos también una indicación del grado de impacto que tenía en el arranque de Windows. Ahora, en Windows 10, es más sencillo. Sólo tenemos que pinchar en el cuadro de búsqueda y poner Inicio, para luego pinchar en la opción de Aplicaciones de Inicio. También podéis pinchar en Configuración->Aplicaciones->Inicio. Desde esa ventana podéis ver, de una manera más intuitiva, qué programas se arrancan al inicio. Con el deslizador podemos desactivar las aplicaciones que no queremos que se arranquen. También podemos ver el impacto de cada programa en el rendimiento del ordenador.

Diseño Web, Gestores de contenidos, Seguridad

Si hackean tu web de WordPress, cambia las claves de seguridad y las salts además de las contraseñas.

/

WordPress es el gestor de contenidos más usado y, como todo en informática, lo más usado es lo más atacado. En algún momento, sobre todo si no mantienes tu web actualizada, pueden hackearte la web. Cuando esto pasa, lo más común es cambiar contraseñas de los usuarios con permisos de modificación en la web. Pero no es suficiente. Tienes que cambiar también tus claves de seguridad y los salt que van asociadas a ellas. Hoy os explicamos por qué y cómo hacerlo. ¿Qué son las claves de seguridad y los salts de WordPress? Seguramente te habrás dado cuenta que no necesitas introducir tu usuario y contraseña en WordPress cada vez que vas a usarlo. Tus usuarios registrados tampoco. Esto es porque estos datos se guardan en el ordenador de cada uno en unas cookies. Está claro que guardar esto en texto que se pueda leer ( texto plano ) es un fallo de seguridad enorme. Así que WordPress, desde la versión 2.6 añade una pareja de caracteres largos para cifrar estos datos: la clave de seguridad y el salt. En WordPress hay 4 pares ( 4 claves, 4 salts). Cada clave tiene su salt asociada. AUTH_KEY. Permite hacer cambios en la web. Firma la cookie para la identificación sin ssl. SECURE_AUTH_KEY. Permite hacer cambios en la web. Firma la cookie para la identificación por ssl. LOGGED_IN_KEY. No permite hacer cambios. Firma la cookie para usuarios con sesión iniciada. NONCE_KEY. Para firmar la clave nonce. Estos son los de un WordPress sin instalar: El proceso de instalación rellena los campos donde poner “put your unique phrase here” con valores únicos para cada instalación. Y en principio no hay que cambiarlos ni tocarlos. Estos son un ejemplo de valores posibles: ¿Cuándo necesitas cambiar las claves de seguridad y los salt y cómo hacerlo? Muy sencillo, cuando tu web haya sido hackeada. Porque entonces, no es suficiente con cambiar las contraseñas, ya que si los atacantes han conseguido las claves de seguridad y salt que tenías, y las sigues usando, pueden usarlas para volver a conseguir acceso a tu web. Pueden realizar ataques XSS (Cross Site Scripting) o de secuestro de sesión para conseguir las cookies, Con las cookies, y las claves que tenían del ataque, pueden descubrir los datos de acceso y volver a entrar en tu web. Así que cuando una web ha sido atacada, debes cambiar las claves y los salt además de las contraseñas de administración. Para ello (aunque hay plugins de seguridad que lo hacen) puedes hacer lo siguiente. Entra por FTP o ssh a tu servidor y a la carpeta de tu web. Edita el fichero wp-config.php. Encuentra las líneas de las claves y salt y borra el contenido de las mismas. Entra en https://api.wordpress.org/secret-key/1.1/salt/ Esta web genera los 4 pares diferentes cada vez que accedes. Sustituye las de tu fichero wp-config.php por las que te ha dado la web. Guarda el fichero. Con esto ya lo tendrías cambiado, pero recuerda que, al hacer el cambio , “echará” a todos los usuario y tendrán que iniciar sesión de nuevo. Otra razón por la que puedas querer añadir estas líneas es que tengas un WordPress que se hubiera creado antes de la versión 2.6 y hayas estado actualizando. SI es así, puede que no se te hayan añadido estos campos. Si entras en tu wp-config.php y ves que es así, puedes (debes) añadirlo.

Diseño Web, Gestores de contenidos, Trucos

Solución a “Publica recursos estáticos con una política de caché eficaz” en PageSpeed.

/

Hoy dedicamos otro artículo a la optimización de las páginas mediante el arreglo de los errores detectados por un análisis en PageSpeed. El aviso que queremos arreglar hoy es el siguiente: Publica recursos estáticos con una política de caché eficaz. ¿Qué es la caché? La caché es un almacenamiento que se usa para guardar contenidos que se van a usar más veces, para poder acceder a ellos de manera más rápida. Si mi navegador no tiene que ir a Internet a buscar ciertos contenidos, la navegación por la página será más rápida. Existe caché del servidor, y caché del navegador. Esta última es la que nos interesa hoy, y se guarda en los ordenadores de cada usuario. Dentro de lo que se guarda, en este caso nos vamos a centrar en los contenidos estáticos, es decir principalmente imágenes, ficheros de estilo (css) y ficheros con scripts (javascript). Google se está quejando que esta caché, para estos ficheros, no está configurada de manera óptima. Especificar correctamente los tiempos que se guardan estos ficheros es importante. Porque si no se definen estás obligando al usuario a ir a buscarlos a la web cada vez que se necesitan (lento e innecesario). Si los defines con un tiempo demasiado grande no se renovarán y los usuarios no verán cambios en tu web. ¿Cómo se puede definir la política de caché? Como siempre en WordPress podemos usar un plugin para hacer esto. Pero los plugins también añaden scripts y usan recursos. Así que hoy vamos a explicar cómo hacerlo sin plugin. Para ello vamos a usar el fichero .htacess del servidor, que podemos editar mediante un cliente como Filezilla (tendremos que mostrar los ficheros ocultos). Recordad hacer una copia de seguridad antes por si tenemos que volver todo a como estaba (en informática es vital tener un plan b,c,y d). Hay dos maneras de hacerlo, con cabeceras Control de Caché o Expiración. Ahora la tendencia es con Control de Caché, pero os dejamos las dos para la versión de Apache. Cabeceras de Expiración (método antiguo). Os vamos a dejar el código que usamos aquí, recopilado de varios sitios web. Podéis usarlo todo o en parte. Y podéis modificar los tiempos. Recordad que está puesto en segundos, así que, por ejemplo, 31536000 es un año (365 días) y 2592000 es un mes (30 días). El código que usamos es el siguiente: Cabeceras de Control de Caché. Método actual. Os dejamos un ejemplo. Activar la compresión. Esto es además de lo anterior. En el caso ideal debemos añadir las Cabeceras de Caché y luego esto después. Ya que estamos, podemos añadir la compresión de estos estáticos. Así reduciremos la cantidad de datos que tenemos que enviar y recibir. Para ello vamos a activar gzip o, en su defecto, deflate. Lo mejor es que añadamos esto antes del código anterior. Si añadimos esto en htaccess y hacemos la prueba de PageSpeed de nuevo, deberíamos ver que el mensaje mencionado ha desaparecido. Si no, apuntad los estáticos y ved si hay que ajustar algo más. Nota: no se puede definir estas políticas para estáticos externos (recursos de terceros).

Diseño Web, Gestores de contenidos, Internet, Noticias Informáticas

Nuevo algoritmo de Google “Page Experience” y las novedades que trae para el SEO de las páginas web.

/

En Noviembre del año pasado Google anunció nuevos cambios en su algoritmo: ese famoso conjunto de cientos de reglas que deciden las puntuaciones de nuestras páginas web en este buscador y, por lo tanto, su colocación en las posiciones de búsqueda. A dicha actualización se la conoce como Page Experience update, porque está enfocada en mejorar la experiencia de usuario en nuestras páginas. Esta actualización iba a salir en Mayo, pero se ha retrasado hasta Junio, y se irá implementando hasta Agosto de este año. ¿Y, en qué se basa Google para evaluar al “experiencia de usuario“? En los siguientes pilares. Es decir, la nueva actualización va a dar prioridad y mejores puntuaciones cuanto más óptimos sean los siguientes puntos: LCP: Largest Contentful Paint. Es decir lo que tarda en aparecer el elemento más grande del viewport con respecto a cuando se inició la carga de la web. Lo deseable sería tener unos tiempos de 2,5 segundos o menos. FID: First Inpt Delay. Que mide la interactividad porque es el tiempo desde que un usuario pincha en un elemento de la página hasta que el navegador puede procesar la respuesta. Lo deseable serían 100 milisegundos o menos. CLS: Cumulative Layout Shift. El CLS intenta medir la estabilidad visual de la página. Es la suma de todos los layout shifts (cada vez que un elemento cambia su posición desde un frame al siguiente) durante la carga de la página. Lo deseable es una puntuación de 0,1 o menos. Los tres anteriores son los denominados Core Web Vitals. Os dejamos unas herramientas que os pueden ayudar a medir estos 3 puntos CWV. Compatibilidad con los dispositivos móviles. Puedes comprobarlo en esta página. Navegación segura. El informe de Problemas de Seguridad de Search Console puede darte información sobre este punto. Https. Si tu página se muestra sobre https. Intersticiales no intrusivos. Espacios que pueden afectar a la navegación. Como dice Google, la experiencia de página no va a ser lo único ni lo más importante a la hora de posicionar. Sigue primando el contenido frente a cualquier otro factor, y una página con bueno contenido siempre será la mejor posicionada. Pero, cuando todos los factores estén igual, será cuando la experiencia de página sea decisiva. While page experience is important, Google still seeks to rank pages with the best information overall, even if the page experience is subpar. Great page experience doesn’t override having great page content. However, in cases where there are many pages that may be similar in relevance, page experience can be much more important for visibility in Search. Conclusión: los tiempos de carga en móvil van a contar mucho. ¿Cómo se consiguen esos tiempos de carga? Bueno, este es un tema que está en debate ahora mismo. Es difícil, por no decir imposible, tener tiempos de carga pequeños con desarrollos visuales elaborados y prestaciones avanzadas. Los tiempos que toma Google como referencia parecen ser de desarrollos como AMP, aunque Google diga que AMP ya no es requerido (y de hecho ya permiten páginas no AMP en el módulo Noticias Destacadas), lo cierto es que se necesitan formatos así, con sus restricciones de tamaño en recursos de JS y CSS para poder darlos. Y AMP si que consigue velocidades de carga muy interesantes. PERO, ¿a cambio de qué? Con esas restricciones es muy difícil tener contenidos visuales elaborados y novedosos. Si tenemos un blog, podemos prescindir del aspecto visual para poder proporcionar velocidad. Pero no todas las páginas son así. Así que parece que nos están haciendo elegir entre aspecto visual y puntuación en este apartado de Page Experience. Los diseñadores están “que trinan“, no todo es velocidad, y una página visualmente agradable puede hacer que merezca la pena unos segundos más de carga. Además, curiosamente los recursos de Google como Adsense o Analytics dañan nuestros CWV y nos puntúan negativamente. Aquí os dan algunos consejos al respecto. A Febrero del 2021, de 8 millones de páginas sólo el 21% cumplía con los tres parámetros de los CWV. ¿Qué herramientas nos proporciona Google para ayudarnos con esta actualización? Esta es una actualización extraña porque nos han avisado, nos han dado tiempo y nos dicen, más que otras veces, qué factores van a tener en cuenta. Y además, proporcionan nuevas herramientas en Google Search Console, para poder medir las variables que se van a tener en cuenta.Os dejamos un resumen de las mismas. Un nuevo informe de Experiencia de Página en Google Search Console. El informe de Rendimiento en la Búsqueda se ha actualizado para mostrar los nuevos parámetros de experiencia de página y las páginas que los cumplen o no. Se permiten los SXG (signed exchanges) en todo tipo de páginas (antes sólo en AMP). Conclusión. Nadie sabe bien cómo van a afectar estos cambios a las puntuaciones actuales de las páginas. Tampoco lo rápido que lo van a hacer. Parece claro que sigue primando el contenido y la relevancia, y que estos factores son algo añadido.Y no sabemos cómo seguirá la pelea entre diseño vs tiempos de carga. A lo mejor las páginas nuevas tendrán que primar la rapidez, y las mejor posicionadas podrán elegir más diseño. Lo que está claro es que vamos a tener que ir optimizando las páginas todavía más, midiendo los tiempos de carga, pensando cómo están diseñadas las páginas para optimizar las CWV y mejorando los servidores donde están alojadas.Porque esos puntos pueden ser decisivos para posicionarnos sobre nuestra competencia.

Diseño Web, Gestores de contenidos, Soporte

Errores en Contact Form 7. Cómo solucionarlos.

/

Como hemos dicho en muchas ocasiones, Contact Form 7 es uno de los plugins más usado para los formularios de contacto de WordPress. Aquí hemos hablado mucho sobre cómo reducir spam en los formularios hechos con este plugin, cómo tener una copia de los envíos en tu WordPress, integraciones con otros plugins etc. Hoy vamos a hablar de posibles errores en el envío de un formulario hecho con Contact Form 7. Errores en Contact Form 7 y cómo solucionarlos. Si has llegado aquí es porque has recibido el típico error de : “Hubo un error intentando enviar tu mensaje. Por favor inténtelo de nuevo más tarde” Vamos a ver qué puede estar pasando. Lo primero es darse cuenta que CF7 tiene unos códigos de colores para los errores, que puede que te indiquen algo. Son los siguientes. Es decir, de los tres que dan error podéis ver que el color da una indicación de qué puede estar pasando. Amarillo (parece naranja en la foto pero es amarillo): Error de validación. Uno de los campos esperaba un valor y, o está vacío, o no es del tipo esperado. Tienes que revisar tu formulario, los tipos de campo y cuales son obligatorios. Naranja: No ha pasado la validación de spam. Esto suele ser porque tienes integrado CF7 con algún plugin antispam tipo recaptcha y no ha pasado la validación. Prueba a desactivar la integración para asegurarte que es eso pero las causas típicas son: – Has puesto claves de reCaptcha V2 en la integración con reCaptcha. Recuerda que ahora CF7 es compatible con reCaptcha v3. Si quieres V2 tienes que instalar este plugin (el segundo de la lista lo seguimos usando). Y obtener unas claves de reCaptcha 2 en vez de la 3. – Tu plugin anti spam tiene algún problema (desactívalo y así te aseguras). – A veces los plugins de caché o de optimización interfieren en el anti spam. Desactiva la caché o límpiala. Si esa es la causa, intenta excluir CF7 o la página de contacto de la caché. Rojo: estamos hablando de problemas con la configuración del servidor. Tienes también varias opciones. – Comprueba si el resto de correos de WordPress están llegando. Por ejemplo los de recordatorio de contraseña. Si llegan el problema es de la configuración de CF7, si no, seguramente el servidor no pueda enviar mensajes por phpMailer (lo que usa WordPress por defecto). – Si no llega ningún correo de WordPress, considera usar un plugin de SMTP para mandar correos por SMTP. Necesitarás una cuenta de correo (sus datos de configuración). – Si sólo fallan los de CF7 mira la configuración de la segunda pestaña del formulario, la de “Mail“. Comprueba que todo está bien ahí. – Si lo anterior no funciona, habla con tu proveedor para ver qué puede ser la causa.

Diseño Web, Información Tecnica, Internet, Sistemas

Al redirigir un dominio a otro por DNS, no redirige el http a https y esta es la razón.

/

Los clientes nos piden muchas veces que redirijamos sus dominios o a otros dominios, o a otras páginas. Una manera de hacer esto es por una redirección por DNS, opción que permiten muchos alojamientos. Sin embargo no funciona en un caso: No permite redirigir el protocolo http a https. Y eso puede ser un problema, porque hay gente que todavía escribe http, o porque tengamos páginas indexadas con http. Hoy os explicamos por qué no funciona y cómo arreglarlo. Por qué la redirección por DNS no permite redirigir http a https. La razón puede explicarse de varias maneras. Una redirección por DNS realmente crea un registro A de un dominio a otro. Es independiente de protocolo (no lleva el protocolo consigo). Una redirección por https funciona cuando un servidor manda a otro la petición cifrada y espera que el otro le conteste, también del mismo método. Como os explicamos cuando explicamos la clave pública y privada. Es decir requiere un certificado válido en cada extremos.El problema es que, un dominio redireccionado por DNS carece (en origen) de certificado. Porque no se puede crear (ya que no se puede verificar), y además ya ni siquiera es válido porque el dominio apunta a otro sitio. Así que nunca hará la conexión cifrada y fallará.Es decir, una redirección de o a https debe partir o llegar a otro sitio con certificado. Por lo tanto necesitamos alojamientos en ambos lados, para poder instalar dichos certificados. ¿Las redirecciones por DNS son inútiles? No, cada día tiene menos sentido y uso el http sin cifrar y en muchas ocasiones no será necesario considerarlo. Pero si entra en juego, no podemos hacerlo. ¿Qué solución nos queda si queremos redireccionar un http a un https?. Como hemos dicho, entonces tenemos que tener alojamientos y certificados en ambos sitios. Eso nos obliga a realizar la redirección o en Apache o por htaccess. Aunque lo hemos puesto en algún otro artículo, por referencia rápida os dejamos un posible código para hacerlo.

Scroll al inicio