Gestores de contenidos

Diseño Web, Gestores de contenidos, Trucos

Snippet para añadir código justo detrás de la etiqueta en WordPress.

/

En ocasiones, por ejemplo para Google Tag Manager, tenemos que insertar código en todas, o en algunas páginas, justo detrás de la etiqueta <body> en WordPress. Como siempre, esto se puede hacer con algunos plugins, pero añadir plugins carga el sistema, lo complica y añade riesgos si no se actualizan. Siempre que se pueda, prefiero hacer estas cosas por código.Hoy os vamos a dejar un fragmento de código o snippet para añadir un código ahí de manera sencilla. Cómo añadir código justo detrás de la etiqueta <body> en WordPress. Para esto vamos a usar el hook de WordPress wp_body_open. El código que vamos a usar (puede haber variantes) es: Obviamente se trata de añadir el código que quieres (por ejemplo el de Google Tag Manager) donde ponemos aquí va el código a añadir. Si ponéis esto en el functions.php de tu tema hijo, o usando un plugin como Snippets, verás que se añade el código donde quieres. ¡Esperamos que os haya gustado el truco!

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.

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.

e-Learning, Gestores de contenidos, Sistemas, Trucos

Ejecutar tareas de Moodle manualmente por línea de comandos.

/

Moodle dispone de muchas tareas que realiza automáticamente: el cron (importante para la limpieza y funcionamiento ya que sincroniza el resto de tareas), las de backup, limpieza de la papelera, limpieza de backups, eliminación definitiva de cuentas eliminadas etc. La mayoría de estas están programadas (como decimos sincronizadas por el cron) y puedes verlas en Administración del Sitio -> Tareas ( y sus submenús). Pero en ocasiones nos puede interesar, ya sea para ver si funcionan correctamente, o para realizar una ejecución adicional, hacerlas manualmente. Algunas, como las de copia de seguridad, pueden incluso configurarse para sólo realizarse manualmente.Hoy os decimos cómo hacerlo. PD: recordad que podéis además, instalar Moosh para tener todavía más opciones por CLI.PD2: en el artículo, donde pongo php a veces tenéis que poner la versión de php. Dependiendo de la configuración de vuestro servidor y con qué variante de php está corriendo la web. Nosotros usaremos la configuración general que es con php ( como si sólo hubiera una versión).PD3: normalmente estos scripts deben ejecutarse con el usuario del servidor web. Cómo ejecutar tareas de Moodle manualmente por línea de comando. Os dejamos un listado e iremos rellenando si vamos . Cron: el proceso más importante del que cuelga el resto de tareas. Tenéis que ir a la carpeta principal de Moodle y ejecutar: Ejecutar las copias de seguridad automáticas: Actualizar Moodle : sudo -u apache /usr/bin/php admin/cli/upgrade.php Poner Moodle en mantenimiento: sudo -u apache /usr/bin/php admin/cli/maintenance.php –enable sudo -u apache /usr/bin/php admin/cli/maintenance.php –disable Cambiar la contraseña de un usuario, incluyendo el administrador: sudo -u apache /usr/bin/php admin/cli/reset_password.php Listado de tareas que se pueden ejecutar por cli: php admin/tool/task/cli/schedule_task.php –help Purgar caché: php admin/cli/purge_caches.php Finalizar todas las sesiones de usuarios: php admin/cli/kill_all_sessions.php Los siguientes se ejecutan desde carpetademoodle/admin/tool/task/cli/ Limpiezas varias: php schedule_task.php –execute=”\logstore_standard\task\cleanup_task”;php schedule_task.php –execute=”\core\task\backup_cleanup_task”;php schedule_task.php –execute=”\core\task\cache_cleanup_task”;php schedule_task.php –execute=”\core\task\file_temp_cleanup_task”;php schedule_task.php –execute=”\core\task\file_trash_cleanup_task”;php schedule_task.php –execute=”\core\task\session_cleanup_task”;php schedule_task.php –execute=”\core_files\task\conversion_cleanup_task”;php schedule_task.php –execute=”\tool_recyclebin\task\cleanup_category_bin”;php schedule_task.php –execute=”\tool_recyclebin\task\cleanup_course_bin”;php schedule_task.php –execute=”\core\task\messaging_cleanup_task”;php schedule_task.php –execute=”\core\task\delete_incomplete_users_task”;php schedule_task.php –execute=”\core\task\delete_unconfirmed_users_task”; Esperamos que os sirvan.

Diseño Web, Gestores de contenidos, Trucos

Quitar los js y css de Woocommerce en páginas donde no sean necesarios para mejorar SEO y velocidad.

/

Algo que no mucha gente sabe es que los plugins de WordPress cargan todos sus scripts (ficheros js) y estilos (ficheros css) desde la primera carga de la página. Se vayan a usar o no se vayan a usar esos plugins en esa sección de la página. Algo que, obviamente, ralentiza la página porque tienen que leerse esos ficheros. Además, si haces pruebas de Pagespeed o Gmetrix, son estos ficheros los que verás que afectan más a la velocidad de carga de la página. Con avisos como “quitar el Javascript que bloquea la visualización del contenido“. Así que estos días iremos compartiendo trucos para eliminar estos ficheros js o css en páginas donde no sean necesarios para los plugins más usados en WordPress. Hoy toca Woocommerce, el plugin más usado para crear páginas en WordPress. Script para eliminar los ficheros js y css de Woocommerce donde no se necesitan. Aquí os dejamos un script que podéis poner en vuestra página que hará un “deque” (eliminará) de los recursos de Woocommerce en las páginas que no sean carrito, página de categoría, página de producto, etiquetas etc. Como siempre, el código se puede poner en el fichero functions.php del tema hijo, o en un Snippet. He dejado una línea en rojo que hemos incluido con ciertas condiciones, pero que podéis ampliar con más. Estas son las conditional tags y os dejo aquí una referencia al respecto y otra más amplia aquí. Si hacéis una prueba de velocidad antes y después de poner el código, veréis que ganáis en velocidad de caga de la página y, seguramente, en puntuación. Nota: comprobad que os funciona todo bien en la tienda. Podéis tener que modificar el fichero para vuestra web.

Gestores de contenidos, Trucos

Cómo limitar el número de revisiones de las páginas o entradas en WordPress.

/

Las revisiones de las páginas o entradas de WordPress son como copias de seguridad de cada cambio que haces. Estas revisiones te permiten poder volver a un estado anterior de manera rápida. Muy útil para corregir errores, sobre todo cuando la web la gestiona más de un editor. ¿Cuál es el problema de las revisiones en WordPress? Todo poder conlleva un precio. Esto de poder tener una copia de todos los cambios que se han realizado, es muy útil. Pero cada una de estas revisiones añade una fila en la base de datos de tu web. Y WordPress guarda, por defecto, todas las revisiones. Esto hace que , con el tiempo, la base de datos aumente de tamaño. Una base de datos grande hace que se tarde más tiempo en leerla, y por lo tanto que aumenten los tiempos de respuesta de la web. Por lo tanto nos hace que nuestra página se más lenta. Y, como sabéis, los webs lentas puntúan negativamente en el posicionamiento (SEO). Tenemos que mantener la base de datos lo más pequeña y limpia posible. Y de ahí que controlar el número de revisiones sea importante. ¿Cómo limitamos el número de revisiones que WordPress guarda? Podemos limitar el número de revisiones de cada entrada o página editando el fichero wp-config.php. Ahí tenemos que añadir la siguiente línea. Donde hemos puesto el número 10 como ejemplo pero puede ser el que queramos. SI prefieres hacerlo por plugin os dejo este como opción: https://wordpress.org/plugins/wp-revisions-control/ ¿Cómo desactivar las revisiones? Si, por alguna razón, quieres deshabilitar esta opción, que viene habilitada por defecto, tienes que editar el fichero wp-config.php y añadir esta línea. ¿Cómo eliminar las revisiones de WordPress? Tienes varias formas de eliminar las revisiones de la base de datos. Si vas a cada revisión, puedes borrarla a mano. Pero claro…si tienes muchas revisiones ir una a una no es muy método muy razonable. Puedes usar un gestor de mysql como phpMyAdmin o similar para ejecutar la siguiente consulta. Puedes usar WP-CLI para hacer lo mismo con el siguiente comando. Puedes usar un plugin como este: https://wordpress.org/plugins/wp-sweep/

Diseño Web, Gestores de contenidos, SEO, Trucos

Quitar dashicons de la portada de WordPress para mejorar el SEO.

/

Si haces una prueba de velocidad de tu página con Pagespeed o con Gmetrix, uno de los ficheros que verás que está ralentizando la portada de tu web en WordPress es dashicons.min.css ¿Qué es dashicons.min.css? Este fichero carga los dashicons de WordPress, unos iconos que usa WordPress en su escritorio del backend y en la barra de administración. Pero, como ocurre mucho en WordPress, se carga también en el frontend. Y no tiene sentido. Iremos dedicando varios artículos a cómo dejar de cargar estos elementos no necesarios de la portada de nuestra web, y así mejorar la velocidad y puntuación de la misma. Cómo evitar que se carguen los dashicons donde no son necesarios. Nota: prueba esto en tu web antes de publicarla porque hay temas que si que usan los dashicons para PC, tablet o móvil. Lo que vamos a hacer es desactivarlos en toda la parte de la web que no tiene barra de administración ni escritorio de WordPress. Es decir, para el frontend. Os dejamos dos scripts posibles que, como siempre, tenéis que poner en el fichero functions.php de vuestro tema hijo o en un plugin de Snippets. Opción que detecta si está la barra de administrador y, si no, quita los dashicons. Esta la hemos usado y funciona perfectamente. Opción que detecta si el usuario está registrado y, si no, quita los dashicons. Como siempre podéis hacer mezclas de estas funciones, con capacidades diferentes de los usuarios (si es administrador o no). Haced una prueba con y sin el código y veréis que el aviso se va y la puntuación mejora.

Scroll al inicio