Si tienes un VPS con Linux y panel de administración plesk con el disco duro lleno, ¿puedes eliminar el contenido de /var/lib/psa/dumps/? Esa es la pregunta que mucha gente se hace. Y si, puedes eliminar su contenido aunque te recomendamos no eliminar la carpeta.

Eso si. Hay que tener en cuenta que estamos haciendo. En esa carpeta PLESK guarda las copias de seguridad que tenemos programadas en el BACKUP MANAGER tanto de todas las suscripciones como de suscripciones individuales. Por tanto si eliminamos su contenido, estamos eliminando las copias de seguridad que PLESK ha hecho. O sea, es la carpeta local en la que Plesk guarda las copias de seguridad que hacemos en el propio servidor (algo que NUNCA deberíamos hacer) o las copias de seguridad cuando falla la copia de las mismas a un FTP externo (nuestro caso).

¿Cuándo nos puede interesar eliminar el contenido de /var/lib/psa/dumps/?

Nos puede interesar eliminar el contenido de /var/lib/psa/dumps/ cuando estamos haciendo las copias de seguridad en remoto por FTP y ha habido algún error en esas copias de seguridad y en BACKUP MANAGER / SETTINGS teníamos activado:

Save backups in the server storage if the upload to FTP fails: Manual and scheduled backups intended for FTP storage will be saved in the local server storage if uploading to FTP fails. Users must have the permission to store backups in the server storage.

Esto es algo que nos ha pasado esta semana porque el servidor de copias de seguridad tenía uno de los discos del RAID rotos y no permitía seguir haciendo copias hasta que no se hubiera aceptado el mensaje de error de que eramos conscientes del fallo :-(.

En este caso como no se podían hacer las copias en el FTP el disco se ha ido llenando. En el servidor de copias de seguridad hay espacio suficiente para cientos de copias mientras que en cada servidor hay espacio para 2 ó 3 como mucho. Con lo cual a los 3 días: lío. Espacio de disco lleno.

¿Cómo comprobar el espacio que ocupa /var/lib/psa/dumps/?

Hay que introducir en la línea de comando de Linux a la cual se puede acceder por ejemplo con PUTTY esto (si no tienes ni idea de qué es esto, mejor no lo intentes):

sudo du -h --max-depth=1 /var/lib/psa/dumps

¿Cómo eliminar el contenido de /var/lib/psa/dumps/?

Primero y antes de eliminar los datos de forma definitiva, deberíamos de hacernos una copia de seguridad en local de los mismos, porque al eliminarnos, estamos eliminando todas las copias de seguridad de PLESK del servidor.

Eliminar el contenido de /var/lib/psa/dumps/ es sencillo pero OJO que este comando elimina todo lo que hay en esa carpeta. OJO: Con este comando no se eliminan las carpetas y archivos ocultos pero esos no suelen ocupar mucho espacio y preferimos dejarlos en su sitio:

rm -r /var/lib/psa/dumps/*

Luego comprobamos con:

df -h

Y ya vemos que volvemos a tener espacio para que el servidor pueda funcionar.

Pero no hay que olvidar que nos acabamos de fundir todas las copias de seguridad. Por tanto enseguida a volver a hacer copias y siempre fuera del servidor.

Al hilo de un tweet de Ana Cirujano, os queremos recordar como configurar correctamente el formato de fecha en WordPress para España.

La configuración correcta de la fecha en WordPress para España no es la que nos propone por defecto:

j F, Y

Sino:

j \d\e F \d\e Y

¡Por tanto: Todos a configurar bien la fecha!

Hoy compartimos unas breves instrucciones para instalar y configurar un nuevo VPS en OVH.

Si ahora contratáis un VPS en OVH ya no nos da la opción de elegir UBUNTU como sistema operativo, sino solamente: “Plesk Onyx on Debian 8 64 bits”.

Si tenéis varios VPS con Ubuntu normalmente querréis tener los nuevos con el mismo sistema operativo. Esto se puede hacer contratando el VPS con el sistema operativo que nos sugieren: “Plesk Onyx on Debian 8 64 bits” y una vez lo han creado e instalado, en el panel de administración de OVH podemos reinstalar otro sistema operativo y aquí si que está disponible Ubuntu + Plesk.

Lo instalamos y nos esperamos 30 minutos que tardan aproximadamente en hacer la reinstalación. Aunque en el panel de OVH no se vea que pase nada, el VPS se está reinstalando y al terminar la reinstalación nos llega un email confirmándola.

OJO: Que la diferencia es que la imagen de DEBIAN lleva la última versión de Plesk y en las imágenes de Centos y Ubuntu hay que actualizar la versión de Plesk para llegar a la última.

Configuración rápida de un VPS nuevo

Primer login

Login a PLESK + Aceptar las condiciones de uso de plesk + Seleccionar “Corporate / Business Use y quitar” “Enable access to premium commercial apps” (Si sale un error de “Existe un problema con el certificado de seguridad de este sitio web” podéis tranquilamente seleccionar: “Vaya a este sitio web (no recomendado). “)

Crear algún usuario temporal.

Actualización de la versión de Plesk

Ir a Server / Updates and Upgrades + Install or upgrade product + Continue (actualizar a 12.8.xx)

Primer problema: Apache config file cannot be generated: “Wrong variable to subsitute”
Para solucionarlo en la consola:

mv -f /usr/local/psa/admin/conf/templates/custom /root/custom_templates/
/usr/local/psa/admin/sbin/httpdmng --reconfigure-all

Volvemos a Server / Updates and Upgrades + Install or upgrade product + Cuando ha acabado: OK.

Instalación de componentes adicionales

Luego añadimos componentes: Add/Remove Components

• Server Health Monitor
• Fail2Ban
• Mail hosting: SpamAssassin
• Webhosting: ModSecurity + PHP interpreter versions: PHP 7.2, PHP 7.1 y PHP 7.0.
• Plesk extensions: Plesk Firewall, Watchdog system monitoring y Let's Encrypt

Continue + OK.

Ahora hay que volver a loguearse en el PLESK del VPS y ver que podemos entrar. Si no podemos entrar al PLESK hay que mirar este artículo: 

Actualización Ubuntu desde la consola

Ahora actualizamos el Ubuntu desde la consola:

sudo apt-get update
sudo apt-get upgrade -y

Instalamos CLAMAV

Instalamos el CLAMAV (para configurar el escaneo diario, tenemos instrucciones aquí: Instalar ClamAV en Ubuntu 14 en un VPS Comandos SSH para Ubuntu 14 con Plesk (OVH y Gigas):

sudo apt-get install clamav clamav-daemon -y
sudo freshclam

Activamos MOD_EXPIRES.C

Activamos el módulo mod_expires.c necesario para muchos plugins de caché:

sudo a2enmod expires
service apache2 restart

Si lo quisiéramos desactivar en algún momento:

sudo a2dismod expires
service apache2 restart

Configuramos la compresión GZIP

Además del módulo mod_expires.c tenemos que comprobar que esté habilitada la compresión GZIP en el VPS. Aquí hay una entrada extensa sobre el tema: Cómo habilitar compresión GZIP en Plesk sobre Ubuntu (OVH y GIGAS).

vi /etc/nginx/nginx.conf

Dentro de http buscar las siguientes líneas:

#gzip on;
#gzip_disable "MSIE [1-6].(?!.*SV1)";

Quitar la almohadilla de comentario. Si no os la deja quitar pulsar la tecla insertar. Justo después hay que pegar lo siguiente:

gzip_comp_level 9;
gzip_http_version 1.1;
gzip_proxied any;
gzip_min_length 10;
gzip_buffers 16 8k;
# Add a vary header for downstream proxies to avoid sending cached gzipped files to IE6
gzip_vary on;
# GZIP Types - NEW
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/xhtml+xml application/javascript application/json application/vnd.ms-fontobject application/x-font-truetype font/eot font/opentype font/otf image/svg+xml image/vnd.microsoft.icon;

Guardar con ESC + :wq + Enter

Comprobar la sintaxis del archivo de configuración de NGINX con:

nginx -t

Si nos dice que la sintaxis es correcta volvemos a arrancar NGINX y APACHE con:

service nginx restart
sudo /etc/init.d/apache2 restart

Activamos HTTP2 y HSTS

Para activar el soporte accedemos por SSH al servidor y ejecutamos en la consola:

/usr/local/psa/bin/http2_pref enable

Optimizamos NGINX para HTTP2

Para optimizar NGINX:

sudo vi /etc/nginx/nginx.conf

La conexión inicial entre el servidor y el usuario tarda bastante y se puede cachear añadiendo estas líneas al final del bloque http del archivo nginx.conf (ojo: añadirlo dentro del bloque de http, antes del paréntesis que lo cierra):

ssl_session_cache shared:SSL:5m;
ssl_session_timeout 1h;

habilitamos HSTS en WordPress

sudo vi /etc/nginx/nginx.con

Añadir la línea antes del paréntesis que cierra HTML.

add_header Strict-Transport-Security "max-age=15768000" always;

Si queremos que también se aplique a subdominios, la sintaxis a añadir es esta:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

y así no tenemos que añadirlo en el archivo htaccess.

Ahora solo falta volver a arrancar NGINX (primero comprobamos que la sintáxis del archivo sea correcto con -t. Si no lo es, hay que corregir los errores):

sudo nginx -t
service nginx restart
service apache2 restart

OPCIONAL: Actualizamos MySQL de 5.5x a 5.7

Aquí están las instrucciones si os interesa actualizar MySQL de la versión 5.5.x a la versión 5.7.x: Actualizar MySQL a la versión 5.7.xx (VPS de Gigas y OVH con Ubuntu).

Si queréis hacer la actualización, seguir los pasos de ese post.

Y con esto por ejemplo evitamos los errores de Duplicator o Duplicator Pro acerca de utf8mb4_unicode_520_ci:

• STATUS: The collation test failed! The database server being connected to does not support a collation from where the database was created.
• DETAILS: This test checks to make sure this database can support the collations found in the database.sql script.
• Collations in database.sql: utf8mb4_unicode_520_ci: Fail – latin1_swedish_ci: Pass

Acabamos de configurar PLESK

Volvemos a PLESK:

• Tools & Settings / Branding: Personalizamos el nombre y el logo del VPS para poder distinguirlos.
• Tools & Settings / IP Addresses: Añadimos las IPs adicionales.
• Custom Buttons: Eliminamos el botón de “Order a new domain” de OVH.
• Activar ModSecurity (esto en Ubuntu de vez en cuando da un error interno, pero se activa de todas formas y funciona correctamente).
• Activar IP Address Banning con “Enable intrusion detection” y luego configuración de los jails (que por defecto están todos desactivados). OJO: En IP Address Banning / Trusted IP Addresses hay que verificar que estén todas las IPs asignadas al VPS porque sino puede ser que banee IPs propias por acceder demasiado por ejemplo a MySQL. Se supone que PLESK cada vez que le añadimos una IP la añade aquí pero en la práctica algunas veces las añade otras no; por eso mejor comprobarlo.
• Activar la limitación de envíos de email y la comprobación del SPF (en Tools & Settings / Mail Server Settings / Switch on limitations on outgoing email messages y  Tools & Settings / Mail Server Settings / Switch on SPF spam protection).

OPCIONAL: Configuramos el acceso al la línea de comando

Generar una clave de acceso SSH para poder acceder a un VPS de OVH. Esta combinación de clave pública y privada sustituye al acceso con contraseña. Aquí está la explicación: Cómo acceder con una clave SSH a un VPS de OVH o GIGAS

Configuramos los backups

Configuración de copias de seguridad: “Backup Settings”. OJO: Nosotros siempre usamos una contraseña de encriptación propia y no la de PLESK. Más que nada por si le pasa algo a la instalación de PLESK y ya no se pudiera recuperar la contraseña anterior.

Nosotros solemos siempre excluir los siguientes archivos y carpetas de las copias porque realmente no aportan mucho a las mismas:

/httpdocs/wp-content/cache/*,/httpdocs/wp-content/debug.log,/httpdocs/wp-content/uploads/backwpup*,/httpdocs/wp-content/temp/*,/httpdocs/wp-content/tmp/*,/httpdocs/wp-content/uploads/temp/*,/httpdocs/wp-content/uploads/tmp/*

Y ya lo tenemos todo listo y funcionando

Y con esto lo deberíamos de tener todo listo y funcionando. No obstante en el proceso pueden pasar mil cosas por lo que solo es para usuarios avanzados.

P.D. Aquí tenéis algunos comandos de Ubuntu de la consola útiles en el día a día: “Comandos SSH para Ubuntu 14 con Plesk (OVH y Gigas)“

A la hora de hacer copias de seguridad de nuestras webs en PLESK muchas veces no queremos hacer copias de archivos temporales, logs o carpetas con los archivos de caché.

Para excluir archivos o carpetas de las copias de seguridad de PLESK hay que marcar la casilla:

• Exclude specific files from the backup

Y se nos abrirá un recuadro en el que podemos introducir los archivos y carpetas que no queremos copiar.

You can only exclude files within webspaces. Specify the path or paths relative to the webspace root, separating individual files with commas. Using the mask symbol is allowed (e.g. /somedir/log*).

Eso significa que todos los archivos y carpetas que se incluyan en el recuadro tienen que ir separadas por comas y ser rutas relativas al directorio raíz del espacio web.

“/var/www/vhosts/TUDOMINIO.COM” es el directorio raiz del espacio web y por tanto hay que definir desde ahí todas las exclusiones (incluyendo en la exclusión /httpdocs/). Si queréis leer algo más de información sobre el tema echarle un vistazo a este hilo del foro de Plesk.

Para excluir por ejemplo la carpeta caché de WordPress, tendremos que incluir en el recuadro:

/httpdocs/wp-content/cache/*

Y si queremos excluir más archivos los pondremos detrás separados por una coma. Por ejemplo:

/httpdocs/wp-content/cache/*,/httpdocs/wp-content/debug.log

Siempre hay que tener en cuenta que hay que añadir el /httpdocs/ delante o incluir un asterisco:

/*/cache/*

Nosotros normalmente excluimos siempre:

/httpdocs/wp-content/cache/*,/httpdocs/wp-content/debug.log,/httpdocs/wp-content/uploads/backwpup*,/httpdocs/wp-content/temp/*,/httpdocs/wp-content/tmp/*,/httpdocs/wp-content/uploads/temp/*,/httpdocs/wp-content/uploads/tmp/*

¡Feliz fin de semana!

Uno de los problemas que tenemos los desarrolladores web es que al probar cambios en Google Chrome muchas veces estos no se reflejan porque tiene la versión antigua en caché. Nisiquiera con CTRL+F5 (PC con Windows) conseguimos que cargue la última versión.

Una opción es vaciar cada vez la caché de Chrome (la más coñazo):

O utilizar una extensión de Chrome que lo haga por nosotros cada vez que cargamos una página:

• Classic Cache Killer (aunque hay más de 20 extensiones que sirve para esto, esta parece ser la más ligera y se puede activar y desactivar).

Nos han comentado que esta extensión a muchos no les funciona correctamente. Seguiremos haciendo pruebas.

Y la tercera es desactivar la caché al tener abiertas las herramientas de desarrollo:

Entramos a las herramientas de desarrollador pulsando F12 (PC bajo Windows) y luego vamos a la pestaña “NETWORK” y ahí marcamos “DISABLE CACHE”. Ahora nuestros amigos de Chrome han añadido un aviso de “Disable cache (while DevTools is open)” porque la gente no tenía claro que ese ajuste solo es efectivo mientras tenemos abiertas las herramientas de desarrollo.

OJO: Para que realmente desactive la caché al recargar la página: CTRL+F5 (en PC con Windows); con F5 solo no la desactiva. Y no olvidéis que en el momento en el que cerréis las herramientas de desarrollador no está claro que versión vais a ver :-(.

Las últimas dos soluciones son las que usamos a diario y por eso las queríamos compartir con vosotros.

Cada vez que cambiamos la URL de un post publicado en WordPress se crea automáticamente una redirección de la URL antigua a la nueva. Pero, ¿qué pasa si no queremos esas redirecciones?

WordPress marca las redirecciones en la base de datos con `meta_key` = ‘_wp_old_slug'. Por tanto si queremos ver todas las redirecciones que WordPress ha creado podemos ejecutar el siguiente select en la base de datos (por ejemplo a través de PHPMyAdmin):

SELECT * FROM `wp_postmeta` WHERE `meta_key` = '_wp_old_slug'

OJO: Si tienes configurado un prefijo distinto al prefijo por defecto de WordPress (wp_) la tabla se llamará PREFIJO + POSTMETA.

Podremos obtener un resultado similar a este (normalmente mucho más extenso; esto es de una instalación reciente):

SELECT * FROM `wp_postmeta` WHERE `meta_key` = ‘_wp_old_slug'

Ahora podremos eliminarlas de forma selectiva (en este caso solo se eliminará la redirección con meta_id = ‘17398):

DELETE FROM `wp_postmeta` WHERE `meta_key` = '_wp_old_slug' AND meta_id = '17398'

_wp_old_slug: Un resultado específico eliminado

O eliminar todas las redirecciones de golpe:

DELETE FROM `wp_postmeta` WHERE `meta_key` = '_wp_old_slug'

¡Feliz domingo!

Si habéis movido alguna vez las imágenes desde una estructura de carpetas de /AÑO/MES/ a una sin el año y mes; sabréis lo tedioso que es copiar todas las imágenes a una única carpeta (además del proceso que describíamos aquí: “Cambiar estructura de archivos subidos en WordPress quitando mes y año“). 

Os compartimos un comando para la línea de comando de Windows que copia todo el contenido de las subcarpetas de la carpeta desde la que se ejecute a una única carpeta.

Primero nos vamos a la carpeta donde tenemos bajada la estructura de carpetas por FTP de /AÑO/MES/. Por ejemplo:

cd d:\uploads\

(Asumiendo que la carpeta está en la unidad D y es la carpeta “uploads”).

Y luego ejecutamos:

for /r %d in (*) do copy "%d" "d:\nuevacarpeta\" /Y

(Asumiendo que la nueva carpeta a la que queremos copiar todos los archivos está en la unidad D y se llama “nuevacarpeta”).

Si le añadimos el modificar /Y al final no pedirá confirmación si hay imágenes con el mismo nombre y las sobreescribirá automáticamente. Si os interesa que no se sobreescriban sin preguntar, quitar el /Y:

for /r %d in (*) do copy "%d" "d:\nuevacarpeta\"

Y listo. Ya tenemos todas las imágenes de WordPress en una única carpeta que podemos subir a uploads (y eliminar las carpetas de los años en cuanto hayamos realizado los pasos de:  “Cambiar estructura de archivos subidos en WordPress quitando mes y año“. 

Para todos los que uséis Elementor (nuestro editor de páginas de WordPress favorito) hoy os dejamos un fragmento de código que oculta los enlaces a ELEMENTOR del Dashboard de todos los usuarios que no son administradores.

Cualquier usuario que no sea administrador no debería de estar jugando con Elementor y por eso normalmente lo ocultamos. Os compartimos el fragmento de código que añadimos al archivo functions.php del child theme:

add_action( 'admin_init', 'hdi_elementor_remove_menu_pages' );

function hdi_elementor_remove_menu_pages() {
if ( !current_user_can('administrator') ) {
remove_menu_page( 'edit.php?post_type=elementor_library' );
remove_menu_page( 'elementor' );
}
}

Esperamos que os sea útil.

Hoy os compartimos un script que permite descomprimir un archivo ZIP en un servidor aunque solamente tengamos acceso por FTP.

Lo que hay que hacer es subir el archivo ZIP y el archivo PHP del script por FTP a una carpeta del servidor web (accesible por Internet).

El script es un archivo llamado unzipper.php.

Abrimos el script desde un navegador y nos dará un listado de todos los archivos ZIP de la carpeta. Hacemos click en UNZIP ARCHIVE y lo descomprime. Rápido y sencillo.

El script unzipper se puede descagar aquí desde GitHub.

Esta semana nos han pedido eliminar cientos de posts antiguos de una página web. Si se eliminan tal cual todas las imágenes que se subieron en los mismos permanecen en el servidor.

Hemos estado probando varias cosas para eliminar todas las imágenes al eliminar un post y al final lo que mejor ha funcionado es el plugin DX Delete Attached Media.

Este plugin elimina las imágenes adjuntadas en un post cuando eliminamos el post. Pero OJO, las imágenes se eliminan cuando eliminamos el post definitivamente. O sea cuando lo eliminamos también de la papelera de WordPress.

¡Buen fin de semana!

Esta semana ha sido la primera vez que Instagram me ha mostrado un error de qué estaba usando demasiados hashtags en una publicación.

Y la pregunta es: ¿Cuántos hashtags se pueden utilizar en Instagram?

En Instagram por cada publicación (publicación + comentarios) se pueden utilizar un máximo de 30 hashtags.

Por lo que si tenemos muchos hashtags relacionados con una publicación tenemos que mirar cuáles son los más interesantes y los que más publicaciones tienen. No tiene sentido malgastar uno de los 30 hashtags para un termino que no tiene más de 5 publicaciones con el mismo.

Por tanto hay que pensar muy bien que hashtags usamos en Instagram. Y sobre todo no pasarnos de 30.

Nuestros amigos de WPIntense han publicado ayer una nueva configuración de servidor para hacer que WordPress vuele.

La hemos probado este fin de semana.

Si queréis experimentar con una instalación de WordPress muy rápida, la más rápida que se puede conseguir de forma sencilla hoy en día, leer este post con la traducción de los pasos de instalación: “La instalación del servidor para WordPress más rápida (2018)“.

La publicación original (en inglés) de WPIntense está aquí: “Installing the fastest WordPress stack with Ubuntu 18.04 and MySQL 8 (Dave Hilditch)“

Después de la publicación del otro día sobre como configurar el servidor para WordPress más rápido, hoy una recomendación de plugins de caché para los que uséis otra configuración.

Si la configuración está basada en NGINX o APACHE os recomendamos usar: 

• Swift Pro
• WP Rocket

Swift Pro es más potente pero más difícil de configurar y más inestable; es tan agresivo cacheando que de vez en cuando guarda archivos en la caché que no debería (revisiones de posts por ejemplo).

WP Rocket es sólido, rápido y fiable.

Y si la configuración está basada en LiteSpeed:

• LSCache

¡Buena semana a todos!

Si hay un tema de WordPress que nos gusta es ASTRA, aunque con todas las actualizaciones que van sacando, también se rompen cosas.

Si al actualizar ASTRA a la última versión notáis que las imágenes destacadas no tienen el tamaño correcto (deberían tener el tamaño definido en AJUSTES / MEDIOS / Tamaño grande), podéis solucionarlo definiendo el tamaño con este código que hay que incluir en el archivo functions.php del child theme activo:

<?php
/**
 * Update the featured images size from Astra
 */
add_filter( 'astra_post_thumbnail_default_size', 'update_featured_images_size_callback' );
 
function update_featured_images_size_callback( $size ) {
    $size = array( 1200, 600 ); // Actualiza 1200(Ancho) y 600(Alto)
	return $size;
}

Si no queremos definir un alto podemos poner 0 y entonces se ajustará el ancho y el alto será automático en función del ancho escogido.

Mola cuando cambian cosas pero hay que vigilar siempre si se rompe algo. Lo que es

Además de nuestro editor de páginas en WordPress preferido, ELEMENTOR, seguimos utilizando también BEAVER BUILDER (que es el primero que empezamos a usar a gran escala).

Hoy os traemos un código que solemos añadir a los proyectos que hacemos con Beaver Builder para optimizar la velocidad de carga de las páginas que hacemos con este editor de páginas:

<?php
add_action( 'wp_enqueue_scripts', function() {
	wp_dequeue_style( 'font-awesome' );

	wp_dequeue_script( 'jquery-magnificpopup' );
	wp_dequeue_style( 'jquery-magnificpopup' );

	wp_dequeue_script( 'jquery-waypoints' );
	wp_dequeue_script( 'imagesloaded' );
	wp_dequeue_script( 'jquery-throttle' );
	wp_deregister_script( 'jquery-waypoints' );
}, 9999 );

add_filter( 'fl_builder_google_fonts_pre_enqueue', '__return_empty_array' );

Esto se añade al archivo functions.php del child theme y deja de cargar todas esas librerías y CSS que normalmente no nos hacen falta. Si hay algo que no funciona porque si que se usa, pues se quita la línea. Por ejemplo si se usan iconos de FONT AWESOME hay que quitar la primera línea que los elimina.

Cómo el editor de páginas para WordPress: Elementor cada día está más de moda, hoy os traigo unos vídeos de formación para aprender todo sobre Elementor. Eso si, están todos en inglés; en castellano de momento no hay nada avanzado y recomendable.

Vídeos de formación gratuitos de Elementor

El mejor recurso gratuito para aprender todo sobre Elementor es el canal de YouTube de Ferdy Korpershoek.

Luego está también el canal de YouTube de Design Build Web.

Vídeos de formación de pago sobre Elementor

Sniffle Valve – WordPress Training and Free Video Tutorials. 

Curso en UDEMY de Khalil Ibrahim.

Dave Foy y su curso “No Stress WordPress“. Es un curso no explica todo lo que se puede hacer con Elementor pero si todo lo necesario para crear y lanzar un sitio web. Particularmente si estás empezando, Dave tiene maravillosos tutoriales y su curso es aún mejor. Lo malo es que el curso no siempre está abierto a inscripciones.

WordPress 5.0 con Gutenberg está al caer y esto significa un cambio sustancial en cómo editamos los contenidos dentro de WordPress. Y esto va a traer muchos problemas con temas y plugins que no están preparados para Gutenberg.

Pero hay una solución temporal: El plugin CLASSIC EDITOR.

Ese plugin nos permite seguir utilizando el editor “tradicional” anterior a la nueva época de Gutenberg y WordPress 5.0

El plugin CLASSIC EDITOR va a estar soportado oficialmente hasta 31 de diciembre de 2021.

Hoy nos han confirmado oficialmente la fecha de caducidad de ese plugin: El 31 de diciembre de 2021 ese plugin dejará de estar soportado. Por tanto hay 3 años para adaptar todas las instalaciones de WordPress a Gutenberg y de paso Gutenberg también tiene tiempo de solucionar todos sus fallos y problemas.

Algunas preguntas y respuestas a este anuncio

• ¿Qué significa “con apoyo oficial”? Se garantiza que funcionará como se espera en la versión más reciente de WordPress, y en la versión principal anterior.
• ¿Se puede prorrogar esta fecha? En 2021 evaluaremos el mantenimiento continuo del plugin, basado en el uso. Esperamos que el mantenimiento continuo sea bastante trivial.
• ¿Funcionarán otras opciones (por ejemplo, Custom Post Types o Meta Boxes) durante los próximos dos años? Mientras que todavía será posible que los CPTs y Meta Boxes sean marcados como incompatibles con el editor de bloques, los futuros comunicados de WordPress moverán esta funcionalidad al plugin de Classic Editor. Cuando esto suceda, WordPress recomendará que los propietarios de sitio instalen y activen el plugin Classic Editor cuando se desencadene una emergencia.

Si al intentar editar una página compleja con ELEMENTOR el servidor te da un error 502, aquí tienes la solución.

Lo primero que hay que hacer es en los ajustes de ELEMENTOR cambiar el “Switch Editor Loader Method” y ponerlo en ENABLE.

Por defecto está desactivado y tenemos que activarlo.

Pero luego también habrá que modificar el archivo .htaccess del WordPress añadiendo las siguientes líneas:

<IfModule mod_substitute.c>
SubstituteMaxLineLength 10M
</IfModule>

Que requiere que el módulo mod_substitue esté instalado; pero salvo en casos muy raros es uno de los módulos por defecto.

Y con esto ya no tendremos el error 502.

¡Saludos!

Aunque tengáis distintas IPs configuradas en un VPS o servidor de OVH o de GIGAS, si hay tiene una IPv6 saldrá por esa IP en vez de usar las IPv4 que haya configuradas. Os explicamos como deshabilitar IPv6 en un VPS o servidor con UBUNTU.

Lo primero comprobar si IPv6 está activado o no en el servidor:

cat /proc/sys/net/ipv6/conf/all/disable_ipv6

0 = activado
1 = desactivado

Por defecto en los VPS de OVH o GIGAS debería de dar como respuesta 0 (activado) porque cada máquina tiene asignada una dirección IPv6.

Para deshabilitar IPv6 en un VPS o servidor con UBUNTU

OJO: Supongo que no os hará falta para nada pero por si acaso preguntarle a Juanjo a ver si le hace falta para que funcione el servidor.

Editar /etc/sysctl.conf y añadir al final:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Luego ejecutar:

sudo sysctl -p

Y dará la siguiente respuesta (si está correcto):

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Y entonces ya se puede volver a comprobar con:

cat /proc/sys/net/ipv6/conf/all/disable_ipv6

y dará como respuesta 1 con lo que estará deshabilitado.

Hoy os dejamos un fragmento de código que usamos bastante en las webs hechas con DIVI. Lo que hace es colpasar los submenús en móvil para no tener un menú interminable desplegado.

DIVI: Menú móvil estándar

Este código se publicó en la web oficial de ELEGANT THEMES en mayo de 2016: “Summary: How to Collapse Nested Sub Menu Items on Divi’s Mobile Menu” pero ahí hay muchísimo contenido y esto que es interesante no se encuentra fácilmente.

Este es el código que hay que añadir a: Divi Theme Options > Integrations > Add code to the body

<style type="text/css"> 
#main-header .et_mobile_menu .menu-item-has-children > a { background-color: transparent; position: relative; } 
#main-header .et_mobile_menu .menu-item-has-children > a:after { font-family: 'ETmodules'; text-align: center; speak: none; font-weight: normal; font-variant: normal; text-transform: none; -webkit-font-smoothing: antialiased; position: absolute; } 
#main-header .et_mobile_menu .menu-item-has-children > a:after { font-size: 16px; content: '\4c'; top: 13px; right: 10px; } 
#main-header .et_mobile_menu .menu-item-has-children.visible > a:after { content: '\4d'; } 
#main-header .et_mobile_menu ul.sub-menu { display: none !important; visibility: hidden !important;  transition: all 1.5s ease-in-out;} 
#main-header .et_mobile_menu .visible > ul.sub-menu { display: block !important; visibility: visible !important; } 
</style>
<script type="text/javascript"> 
(function($) { 
    function setup_collapsible_submenus() { 
        var $menu = $('#mobile_menu'), 
            top_level_link = '#mobile_menu .menu-item-has-children > a'; 
        $menu.find('a').each(function() { 
            $(this).off('click'); 
            if ( $(this).is(top_level_link) ) { 
                $(this).attr('href', '#'); 
            } 
            if ( ! $(this).siblings('.sub-menu').length ) { 
                $(this).on('click', function(event) { 
                    $(this).parents('.mobile_nav').trigger('click'); 
                }); 
            } else { 
                $(this).on('click', function(event) { 
                    event.preventDefault(); 
                    $(this).parent().toggleClass('visible'); 
                }); 
            } 
        }); 
    } 
    $(window).load(function() { 
        setTimeout(function() { 
            setup_collapsible_submenus(); 
        }, 700); 
    }); 
})(jQuery); 
</script>

DIVI: Menú móvil colapsado

DIVI: Menú móvil colapsado desplegado un nivel

Los iconos de los menús se pueden cambiar modificando:

content: '\4c';

y

content: '\4d';

Aquí está el listado completo de iconos que se pueden usar en DIVI.

A ver si con esto mejoramos la usabilidad de los sitios de DIVI en el móvil.