A día de hoy, con unos 300€ puedes comprar un ASUS Vivobook Go E510KA-EJ680 con procesador Intel Celeron N4500, 8GB RAM (no ampliables) y 256GB SSD.

O puedes comprar reacondicionado un Thinkpad X13 G1 con procesador Core i5 10210U, 8GB RAM (ampliable a 64GB) y 256GB NVME.

Ambos equipos cuentan con 3 años de garantía.

El ASUS, a pesar de ser nuevo, no deja de ser un equipo de gama baja, donde prima el ahorro máximo de costes en su proceso de fabricación. Cuenta con un procesador mediocre y bastante lento, no apto para ejercer de equipo principal de trabajo en la mayoría de casos. Además, al llevar casi todos los componentes soldados a la placa base, lo hacen un equipo de difícil reparación y prácticamente nula ampliación. Lo que se dice un equipo de usar y tirar.

En cambio el ThinkPad, aún siendo usado, es un equipo de gama profesional, con materiales y calidad de construcción de primer nivel, equipado con un procesador de rendimiento muy superior a un equipo nuevo de igual precio y a pesar de ser 5 años más antiguo, solo compara…

Entonces la respuesta es clara… ¿es mejor un equipo reacondicionado?

A igualdad de precio, SI, rotundamente.

Mi experiencia con los Lenovo ThinkPad

En 2010 compré mi último portátil nuevo, un ASUS K50IJ, con procesador Intel Dual Core T4400, 4GB RAM y 320GB HDD, por unos 500€.

El equipo ha estado funcionando hasta 2019, aunque como equipo secundario desde 2012 junto a un sobremesa que hacía de equipo principal. Ya en su día, era un portátil de gama media-baja.

Y no es que haya dejado de funcionar en 2019, de hecho aún enciende y con una distro GNU/Linux liviana es incluso usable. El problema es que ya no rendía para mi trabajo del día a día, salvo tareas ofimáticas muy básicas (consultar correo, navegar con paciencia…).

Por eso en 2019 empecé a buscar nuevo portátil, con un presupuesto similar (500€), buscaba algo que en potencia se acercase al equipo de sobremesa, que contaba por entonces con un Intel i5 2500K, un procesador que ya tenía sus 7 años, pero que rendía muy bien para mi trabajo diario.

Fue cuando se me cruzaron los portátiles reacondicionados, en concreto los Lenovo ThinkPad. ThinkPad es la gama empresarial de Lenovo, por lo que la calidad de componentes, construcción y durabilidad está garantizada. Solo hay que elegir el hardware adecuado para tu actividad y que así te dure a buen rendimiento el mayor tiempo.

Me decidí por un T540p con procesador i5 4300M y 8 GB de RAM y pantalla de 15″ Full HD, por 330€ con 3 años de garantía. Un equipo que ya contaba con unos 5 años, pero totalmente revisado y limpio, parecía estar estrenándolo.

Una configuración un pelín inferior a mi sobremesa, pero mucho más potente que mi anterior portátil, aquí podemos ver una tabla de los 3 procesadores.

Aunque el T540p rendía muy bien, su punto débil era su procesador de 2 núcleos frente a los 4 del equipo de sobremesa. El equipo sufría un poco de lag en algunas tareas, se demoraba algo más en renderizar sitios webs, sobre todo trabajando con builders, como Divi, Elementor… Tardaba bastante en renderizar vídeos para mi canal de Youtube…

Un par de años después, decidí ampliarlo y para ello busqué uno de los procesadores más potentes que pudiera ponerle (por compatibilidad), y dí con un i7-4700mq, un procesador con 4 núcleos y 8 hilos. Lo compré por 65€ en una conocida web de compra-venta y adquirí además un segundo módulo RAM de 8GB para completar su capacidad máxima (16GB).

Una vez recibí el nuevo procesador, yo mismo llevé a cabo la sustitución, no sin algún que otro inconveniente, he de decir que acceder a la CPU de un T540p es bastante complejo, obligándote a desmontar el teclado y gran parte de la carcasa para extraer la placa base. Nada que ver con su hermano, el T440p del que hablaremos después.

Pero tras sufrir un poco lo conseguí. Y ahora tenía un equipo portátil más potente que el propio sobremesa y con un menor consumo.

Fué así que empecé a usar el T540p como equipo principal de trabajo y a día de hoy, 6 de Enero de 2025, continúa siéndolo.

Tras esta ampliación, estaba tan satisfecho con el rendimiento del T540p que decidí comprar otro ThinkPad, esta vez el T440p (desde el que escribo), que prácticamente es el mismo portátil pero con pantalla de 14″ y sin teclado numérico). Un poco más pequeño aunque igual de gordote.

Lo compré esta vez por eBay por 190€ a una tienda alemana (de hecho tiene el teclado en alemán), con un i7-4600M, con la idea de ampliarlo también a un i7-4700mq. Cosa que hice a los pocos meses, y mucho más fácil.

El T440p es una maravilla para acceder a su interior. Es quitar 2 tornillos, retirar la tapa trasera y ya tienes acceso a toda la placa base (disco duro, memorias, CPU, antena wifi, bluetooth…).

Así que desde entonces tengo el T540p como equipo principal en mi escritorio, el cual tengo anclado a su DockStation que adquirí para ampliar su conectividad, sobre todo los USB, salidas de audio y pantallas. Mientras que el T440p es el que llevo a todos lados.

Por otro lado, debido a mi trabajo, no me puedo permitir estar sin equipo. Por lo que si un día tengo una avería en el equipo principal, solo tengo que sacar el SSD, ponerlo en el T440p y a seguir funcionando.

Equipos válidos pero que Windows ya no quiere…

Tanto el T540p como el T440p venían con Windows 10 instalado (con licencia OEM), aunque con fecha de caducidad…

Y es que Microsoft te dice que estos equipos, perfectamente válidos, ya no son aptos para su Windows 11, con la excusa del TPM 2.0. Los procesadores de 4ª generación que tienen estos ThinkPad solo llegan hasta TPM 1.2. Así que Microsoft te invita amablemente a que desheches tu equipo y adquieras uno nuevo.

Por suerte yo soy usuario 100% Linux desde 2018 y los ThinkPads son perfectos para estos sistemas, tanto en rendimiento como en compatibilidad.

Ambos llevan en su interior Debian 12 y estoy seguro de que en este año que comienza, me seguirán acompañando en todos los nuevos proyectos que inicie.

En el futuro, seguiré apostando por reacondicionados…

No se cuánto podré alargar la vida de mis ThinkPads, todo depende de cómo avance la tecnología, de la optimización del software futuro y de las nuevas tareas que me toque acometer.

Pero cuando llegue el momento del cambio, seguiré apostando por el reacondicionado. Seguramente invertiré en 2 nuevos equipos (principal y secundario) pero de generación más actual. Que pueda reemplazarlos rápidamente en caso de (improbable pero no imposible) avería. Para mí es sin duda, una gran tranquilidad.

Referidos

Si te interesa el mundillo de los reacondicionados, te dejo por aquí el enlace al mayor grupo de Telegram en español dedicado al ThinkPad: https://t.me/Thinkpad_es

Un capítulo muy interesante de Podcast Linux sobre los ThinkPad en general, para que entiendas sus modelos, nomenclaturas, curiosidades: https://www.ivoox.com/129-hardware-thinkpad-audios-mp3_rf_69575979_1.html

Un nuevo portal con información, comparativas, artículos…: https://todothinkpad.org/

Y sin más, me despido hasta el próximo post

Esto es algo muy peligroso, ya que al de volver al editor de WordPress romperíamos toda la edición realizada con Elementor.

He buscado hooks o filters para ver si hay una opción que deshabilite el mencionado botón, pero finalmente he optado por ocultarlo mediante CSS.

Así que en todos mis child-themes para Elementor añado un fichero estilos-admin.css para la parte de administrador:

functions.php

function estilos_admin(){
    wp_enqueue_style('estilos-admin', get_stylesheet_directory_uri().'/css/estilos-admin.css', array(), '1.0');
}
add_action('admin_enqueue_scripts', 'estilos_admin');

estilos-admin.css

.elementor-editor-active #elementor-switch-mode{
    display: none !important;
}

Con este pequeño código CSS hacemos que en páginas donde esté Elementor activo, no se muestre el botón de volver al editor de WordPress y además, permitimos que se muestre el botón de «Editar con Elementor» en páginas normales.

¿Cómo es posible?

Como sabéis (o deberíais saber), WordPress es un proyecto de software libre bajo licencia GPL, esta licencia permite la modificación y distribución del software siempre que las modificaciones (y distribuciones) adopten la misma licencia GPL a su vez. ¿Qué significa? Que cualquier software que se desarrolle en base a WordPress (una plantilla o plugin) automáticamente adopta la licencia GPL, de forma que puede ser modificado y redistribuido.

Lógicamente los desarrolladores no van a ponerlo tan fácil, y normalmente las versiones PRO de sus plugins solo puedes descargarlas desde sus sitios web (previa compra), así como las futuras actualizaciones y soporte técnico, pero una vez que descargas el software, legalmente podrías hacer lo que quisieras con él. Desde usarlo indefinida y en cuantas instalaciones quieras, hasta modificarlo para tus propios propósitos e incluso revenderlo, siempre y cuando lo distribuyas bajo la misma licencia con la que lo adquiriste (GPL).

Artículo disponible en vídeo:

¿En qué consiste PRO Elements?

Básicamente toman el código de Elementor Pro, deshabilitan el bloqueo que te impide usarlo sin licencia activa y eliminan toda la parte privada o bajo copyright dejando únicamente el código libre que los desarrolladores están obligados a distribuir.

De esta forma tendrás todos los módulos de Elementor Pro, todo su maquetador de plantillas, ventanas emergentes, configurador de fuentes, etc.

¿Que no tendrás con PRO Elements?

Lógicamente no tendrás acceso a las actualizaciones de Elementor Pro, tendrás que esperar a que el equipo de PRO Elements adapte y libere esas actualizaciones.

Tampoco tendrás acceso a los kits y plantillas PRO para importar en tus proyectos ni tendrás soporte técnico ni ninguna garantía de funcionamiento.

Resumiendo, ¿es aconsejable usar PRO Elements?

Depende de para qué, por ejemplo yo no lo usaría en mis clientes de mantenimiento, donde es vital tener las últimas actualizaciones directamente del desarrollador y contar con soporte técnico en caso de problemas.

Pero si que lo usaría para pruebas en local o para la enseñanza, ya que no hará falta comprar una licencia (que no es barata precisamente) para aprender a usar el maquetador o para usarlo particularmente en algún proyecto.

Puedes descargar PRO Elements desde Github:

https://github.com/proelements/proelements

Tenemos a nuestra disposición una extensa guía desde la documentación oficial de WordPress en https://wordpress.org/support/article/editing-wp-config-php/, aunque vamos a intentar resumir las más interesantes.

Forzar al protocolo HTTPS

Con estas constantes podemos forzar tanto el login como el panel de administración de WordPress (/wp-admin) a usarlo exclusivamente bajo el protocolo HTTPS, por lo que es necesario que el servidor cuente con un certificado de seguridad SSL.

define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

NOTA: No lo actives si estás trabajando en modo local o en un servidor provisional sin certificado SSL.

Conexión con la base de datos

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );
/** MySQL database username */
define( 'DB_USER', 'username_here' );
/** MySQL database password */
define( 'DB_PASSWORD', 'password_here' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

Cuando instalamos WordPress, lo primero que el instalador nos pregunta son los datos de la base de datos con la que vamos a trabajar. Pero si necesitamos modificar estos datos a posteriori, podemos localizarlos en el archivo wp-config.php en el apartado MySQL settings.

define( ‘DB_NAME’, ‘database_name’ ); Nombre de la base de datos en nuestro servidor.
define( ‘DB_USER’, ‘username’ ); Nombre de usuario de la base de datos.
define( ‘DB_PASSWORD’, ‘password’ ); Contraseña de la base de datos.
define( ‘DB_HOST’, ‘localhost’ ); Dirección del servidor de la base de datos. En muchos hosts suele ser «localhost», aunque en otros hostings como IONOS o Arsys, puede ser una dirección concreta.

Otras opciones en la base de datos

define ('DB_HOST', 'localhost: 3306' );

Especifica el puerto utilizado por el gestor de bases de datos. Por defecto se establece en 3306, pero si necesitas modificarlo, defínelo en esta constate.

$table_prefix = 'mistablas_'; // Only numbers, letters, and underscores please!

Establece el prefijo de las tablas de la base de datos de WordPress. Por defecto se utiliza wp_, pero para reforzar la seguridad, te aconsejo que lo cambies durante la instalación de tu WordPress.

No lo modifiques una vez instalado, o tendrás errores en WordPress al no conectar correctamente con las tablas. Cámbialo solo en los casos en que migres de base de datos y el prefijo de la nueva base de datos sea distinto.

define( 'DB_CHARSET', 'utf8' );

Establece el conjunto de caracteres de la base de datos. Por defecto, WordPress utilizará UTF-8.

define( 'DB_COLLATE', '' );

Establece el orden de clasificación del juego de caracteres. Por defecto se establece en blanco para que MySQL asigne automáticamente la colación en función del conjunto de caracteres definido con DB_CHARSET.

La colación general para UTF-8 suele ser ‘utf8_general_ci’:

define( 'DB_COLLATE', 'utf8_general_ci' );

Si necesitas definir una colación distinta para un país concreto, por ejemplo Turquía, establece:

define( 'DB_COLLATE', 'utf8_turkish_ci' );

Claves de seguridad

define( 'AUTH_KEY', 't`DK%X:>xy|eZ(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' );
define( 'SECURE_AUTH_KEY', 'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' );
define( 'LOGGED_IN_KEY', 'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' ) ;
define( 'NONCE_KEY', 'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' );
define( 'AUTH_SALT', '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' );
define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' );
define( 'LOGGED_IN_SALT', 'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+Vo<$|#_}qG(GaVDEsn,~*4i' );
define( 'NONCE_SALT', 'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );

Se definen automáticamente durante la instalación. No es necesario que las copies ni mucho menos que las memorices, pero puedes cambiarlas si lo deseas. Solo asegúrate que sean largas y complicadas.

Normalmente son usadas para las cookies de sesión, de forma que si las modificas, los usuarios con sesión en tu web tendrán que volver a loguearse.

Establecer la URL del sitio

define( 'WP_SITEURL', 'https://misitioweb.com' );

Establece la URL WordPress. (No finalizes la URL con barra invertida «/», por ejemplo misitio.com/).

Por defecto, la URL del sitio se guarda en la tabla de opciones de la base de datos, pero si defines esta constante reducirás la cantidad de llamadas a la base de datos al cargar la web.

Establecer la URL del blog

define( 'WP_HOME', 'https://misitioweb.com/misitio' );

Define la dirección de WordPress en caso de que no se encuentre en el directorio principal de tu dominio. En la mayoría de casos será la misma dirección que la URL del sitio.

Mover los directorios por defecto

Otra opción que podemos definir en wp-config.php es la ubicación de los directorios como, WP-CONTENT, PLUGINS, THEMES, UPLOADS…

Moviendo el directorio WP-CONTENT

Definiendo el PATH LOCAL:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );

Definiendo la URL:

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );

Moviendo el directorio PLUGINS

Definiendo el PATH LOCAL:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

Definiendo la URL:

define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );

Moviendo el directorio THEMES

$theme_root = WP_CONTENT_DIR . '/themes'; 

Moviendo el directorio UPLOADS

define( 'UPLOADS', 'blog/wp-content/uploads' );

Caché de objetos y compresión

define( 'WP_CACHE', true );
define( 'WP_CACHE_KEY_SALT', 'bli6w8w9zrqufbfz79:' );
define( 'COMPRESS_CSS', true );
define( 'COMPRESS_SCRIPTS', true );
define( 'ENFORCE_GZIP', true );

WP_CACHE habilita la caché de objetos. Normalmente la utilizan los plugins de gestión de caché.
WP_CACHE_KEY_SALT, define la clave de caché. Puedes poner una aleatoria.
COMPRESS_CSS Y COMPRESS_SCRIPT, comprimen los objetos de estilos y javascript.
ENFORCE_GZIP, fuerza la entrega de la caché comprimida. Esta función tiene que estar habilitada en el servidor.

Limitar las revisiones de posts

define( 'WP_POST_REVISIONS', 5 );

Si editas mucho tu contenido, debes saber que cada vez que actualizas una entrada, página, producto… se guarda una revisión de esta, para que puedas volver a ella en cualquier momento. Esto hace que nuestra base de datos pueda crecer enormemente. Personalmente me he encontrado con páginas que tenían más de 500 revisiones guardadas.

Creo que limitar a 5 es más que suficiente, incluso se puede desactivar por completo, indicando el parámetro false:

define( 'WP_POST_REVISIONS', false );

Guardado automático

define( 'AUTOSAVE_INTERVAL', 30 );

Por defecto, WordPress realiza autoguardados de tus publicaciones cada 60 segundos. Puedes cambiar este valor con esta definición.

Permanencia en la papelera

define( 'EMPTY_TRASH_DAYS', 7 );

Cuando enviamos contenido a la papelera, esta permanece ahí durante 30 días por defecto. Podemos cambiar este valor por otro número de días.

Habilitar WordPress Multisitio

define( 'WP_ALLOW_MULTISITE', true );

Si deseas habilitar varias instalaciones de WordPress en un mismo sitio (WordPress multisitio), establece en TRUE esta consante.

Redirección Blogs inexistentes

define( 'NOBLOGREDIRECT', 'https://misitio.com' );

Redirige a tu sitio principal en caso de que alguiente intente acceder a un subdominio o subdirectorio inexistente.

WP_DISABLE_FATAL_ERROR_HANDLER

Antes de la versión 5.2 de WordPress, si un theme o complemento causaba un error fatal, el usuario solo veía una pantalla en blanco. A partir de WordPress 5.2, se muestra un mensaje error del estilo:

«El sitio está experimentando dificultades técnicas. Consulte la bandeja de entrada de correo electrónico del administrador de su sitio para obtener instrucciones».

Pero en un entorno de desarrollo, seguramente necesitamos visualizar esos errores de PHP y para ello debemos ocultar este mensaje por defecto, además de habilitar el WP_DEBUG y WP_DEBUG_DISPLAY

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later 
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true ); 

WP_DEBUG informa de errores y advertencias en temas y plugins, además de errores en la base de datos.

Aumentar la memoria asignada a PHP

Por defecto, la memoria PHP asignada en WordPress es de solo 40MB. Es conveniente aumentar esta cantidad sobre todo si utilizamos un número considerable de plugins o editamos la web con builders como Elementor, Divi, Fusion, etc.

Existen dos límites de memoria, el que tiene que ver con el frontend o web visible y el que tiene que ver con el panel de administración de WordPress.

Aumentar el límite de memoria en el frontend:

define( 'WP_MEMORY_LIMIT', '128M' );

Aumentar el límite de memoria en el panel administrador:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Evitar que WordPress pida los datos FTP al instalar o actualizar complementos

Esta configuración suele estar habilitada por defecto en la mayoría de hostings, pero si WordPress te pide los datos de autenticación FTP cada vez que intentas actualizar o instalar un complemento define la siguiente constante:

define( 'FS_METHOD', 'direct' );

Habilitar un cron alternativo

Si por cualquier razón el cron por defecto de WordPress no realiza correctamente las tareas asignadas y quieres establecer un Cron alternativo, debes especificarlo con la siguiente constante:

define( 'ALTERNATE_WP_CRON', true );

Deshabilitar cron

También es posible que quieras deshabilitar el cron si no vas a hacer uso de él (programar publicaciones, programar backups, etc.):

define( 'DISABLE_WP_CRON', true );

Limitar los intervalos de cron

Establece el tiempo (en segundos) que deben transcurrir entre la ejecución de un cron y otro.

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Reparar automáticamente la base de datos

Si tienes problemas con tu base de datos y no puedes iniciar sesión, puedes definir esta constante para forzar una reparación automática.

define( 'WP_ALLOW_REPAIR', true );

Después accede a ruta: https://misitio.com/wp-admin/maint/repair.php

No es necesario iniciar sesión para ejecutar el proceso. Una vez resuelto el problema, borra esta consante o cámbiala a false.

Desactivar el editor interno de themes y plugins

Una medida sencilla de mejorar la seguridad en nuestro WordPress es desactivando el editor interno de plugins y temas. De esta forma, si alguien se hace con nuestro usuario administrador, no podrá editar plantillas y plugin insertando código malicioso. (Para ello tendrá que tener también acceso al FTP y modificar los archivos insitu).

define( 'DISALLOW_FILE_EDIT', true );

Desactivar las actualizaciones automáticas de WordPress

Es conveniente no actualizar a la ligera un WordPress, sobre todo si es una versión media o mayor. Debemos asegurar antes de que tanto el theme como los complementos (plugins) tienen 100% compatibilidad con la nueva versión.

Para impedir que WordPress se actualice automáticamente usa la constante:

define( 'WP_AUTO_UPDATE_CORE', false );

Pero sí es buena idea actualizar únicamente las versiones de seguridad y mantenimiento, para ello usamos la constante:

define( 'AUTOMATIC_UPDATER_DISABLED', false );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
define( 'CORE_UPGRADE_SKIP_NEW_BUNDLED', true );

La última constante ‘CORE_UPGRADE_SKIP_NEW_BUNDLED’, evitará que las actualizaciones de WordPress editen el directorio wp-content, evitando que se instalen los nuevos temas por defecto que incroporen las nuevas versiones.

Desactiva toda actualización automática y manual

Si quieres llevar un control o mantenimiento exhaustivo de un proyecto, puedes impedir que se instalen o actualicen complementos con la constante:

define( 'DISALLOW_FILE_MODS', true );

Ni siquiera un usuario administrador podrá instalar o actualizar nada.

Concluyendo…

Existen más constantes que puedes definir para configurar otros aspectos más avanzados de tu WordPress, puedes consultarlos en la documentación oficial: https://wordpress.org/support/article/editing-wp-config-php, aunque los comentados en este post suelen ser los más interesantes a tener en cuenta.

Espero que te haya servido de utilidad y nos vemos en el siguiente post

Actualmente estoy probando Fedora como distro principal y tenía la necesidad de configurar mi entorno LAMP tal y como lo tenía en Ubuntu.

En Fedora la paquetería difiere un poco, así como algunas configuraciones.

En este artículo vamos a ver cómo:

• Instalar el servidor web (Apache).
• Instalar el gestor de bases de datos MariaDB.
• Instalar PHP.
• Configurar php.ini con los valores óptimos para WordPress.
• Instalar phpMyAdmin para gestionar las bases de datos visualmente.
• Activar el módulo MOD REWRITE para que funcionen las URLs «amigables» en WordPress.

Instalar el servidor web Apache

Nos dirigimos a un terminal y escribimos:

sudo dnf -y install httpd

Los comandos básicos para gestionar el servidor son:

Iniciar:

sudo systemctl start httpd

Parar:

sudo systemctl stop httpd

Habilitar:

sudo systemctl enable httpd

Reiniciar:

sudo systemctl restart httpd

Recargar:

sudo systemctl reload httpd

Una vez instalado, ejecutamos los comandos de habilitar e iniciar:

sudo systemctl enable httpd
sudo systemctl start httpd

Nos dirigimos a un navegador web y entramos en http://localhost

Deberíamos ver una pantalla como esta:

En mi caso, una vez que se habilita e inicia el servidor por primera vez, ya no es necesario hacerlo en cada sesión.

Instalar MySQL (MariaDB)

De vuelta al terminal ejecutamos:

sudo dnf install mariadb-server

Los comandos para gestionar el servicio son muy similares a Apache.

Habilitar:

sudo systemctl enable mariadb

Iniciar:

sudo systemctl start mariadb

Parar:

sudo systemctl stop mariadb

Reiniciar:

sudo systemctl restart mariadb

Al igual que con Apache, en mi caso no es necesario habilitar e iniciar el servicio en cada sesión.

Securizar MySQL

Por defecto, el gestor de bases de datos viene con el usuario root sin contraseña. Vamos a asignar una contraseña ejecutando:

sudo mysql_secure_installation

Nos preguntará si queremos asignar una contraseña al usuario root, contestamos que si:

Set root password? [Y/n] y
New password: *******
Re-enter new password: ****** 
Password updated successfully!

Nos hará una serie de preguntas sobre si queremos eliminar usuarios anónimos, borrar las tablas de test, etc. Podemos contestar afimartívamente a todo:

Remove anonymous users? [Y/n] y
 ... Success!
 
 Disallow root login remotely? [Y/n] y
 ... Success!
 
 Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 
 - Removing privileges on test database...
 ... Success!
 
 Reload privilege tables now? [Y/n] y
 ... Success!

Ahora entraremos en mysql:

sudo mysql -u root

Vamos a crear un usuario distinto de root que será el que asignemos a las bases de datos que creemos después:

CREATE USER mi_usuario IDENTIFIED BY 'password';

Creamos una nueva base de datos:

CREATE DATABASE mibase;

Y asignamos nuestro usuario anterior a la nueva base de datos con todos los privilegios:

GRANT ALL PRIVILEGES ON mibase.* TO mi_usuario;

Para nuevas bases de datos el proceso sería el mismo: Crear la base de datos y asignar nuestro usuario con todos los privilegios.

Tras la asignación de nuestro usuario a la nueva base de datos no está de más hacer una limpieza de la caché almacenada con:

FLUSH PRIVILEGES;

Instalar PHP

Vamos a instalar los siguientes paquetes para PHP:

sudo dnf -y install php php-cli php-php-gettext php-mbstring php-mcrypt php-mysqlnd php-pear php-curl php-gd php-xml php-bcmath php-zip

Tras la instalación vamos a comprobar la versión de PHP con el comando:

php -v

En el momento de hacer este artículo, la versión que se instala con Fedora 34 es la 7.4.24.

Crearemos un archivo test.php para comprobar que PHP se ejecuta correctamente bajo Apache.

A mí me gusta usar nano para configurar archivos sencillos mediante la terminal, nos dirigimos a:

sudo nano /var/www/html/test.php

Y dentro pegamos la siguiente línea:

<?php phpinfo(); ?>

Guardamos los cambios con Ctrl+O y salimos con Ctrl+X.

Volvemos al navegador web a la dirección http://localhost/test.php

Debería ejecutarse el script de información de PHP:

Vamos a cambiar algunos parámetros de PHP editando su archivo de configuración (php.ini) para optimizarlo para WordPress.

La ubicación está en /etc/php.ini, por lo que de nuevo con nano, nos dirigimos a:

sudo nano /etc/php.ini

Y editamos los siguiente parámetros:

memory_limit = 128M
post_max_size = 64M
max_execution_time = 180
upload_max_filesize = 64M
max_input_time = 180
max_input_vars = 3000

Tras la edición debemos reiniciar Apache para que los cambios surjan efecto. En mi caso tuve que reiniciar el PC por completo para que se aplicaran.

Instalar phpMyAdmin

Volvemos al terminal y ejecutamos:

sudo dnf install phpmyadmin

Tras la instalación veremos que si accedemos a http://localhost/phpmyadmin nos saldrá un mensaje de error indicando que la ubicación no existe.

Tenemos que editar el archivo de configuración de phpMyAdmin de nuevo con nano:

sudo nano /etc/httpd/conf.d/phpMyAdmin.conf

Hacia la parte final del archivo, añadimos las siguientes líneas:

<Directory /usr/share/phpMyAdmin>
    AddDefaultCharset UTF-8
    Require all granted
</Directory>

Guardamos con Ctrl+O y salimos con Ctrl+X.

Reiniciamos el servidor con:

sudo systemctl restart httpd

O reiniciamos el equipo si no surje efecto. Ahora podemos acceder a http://localhost/phpmyadmin

Por último vamos a activar el módulo de Apache MOD REWRITE para habilitar las URLs amigables de WordPress que configuramos en los ajustes de Enlaces Permanentes.

Para ello nos dirigimos con nano a:

sudo nano /etc/httpd/conf/httpd.conf

Localizamos la línea:

<Directory "/var/www/html">

Y sustituimos AllowOverride None por AllowOverride All

De nuevo, reinicia Apache o directamente el PC.

Nota final

Si al descargar algún tema/plugin o actualización tienes un error de:

Descarga fallida: cURL error 7

Necesitamos configurar SElinux en modo permisivo. Para ello editamos el siguiente archivo:

sudo nano /etc/selinux/config

Y cambiamos el parámetro SELINUX=permissive

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Reiniciamos el equipo y eso es todo

Suelo activar el doble factor de autenticación en todas mis cuentas, ya sean redes sociales, servicios, login de wordpress, etc.

Lo tengo activado tanto en la cuenta de cliente de mi proveedor de hosting, como en el acceso al Plesk de mi VPS.

Sin embargo, me quedaba una puerta por securizar, las conexiones SSH.

Para mí es muy cómodo acceder vía SSH a mi servidor, ya sea para actualizar paquetes, reiniciar el servidor si hay algún problema y acceder a configuraciones concretas.

Mi servidor está basado en Ubuntu 22.04 LTS, y existe un paquete para poder configurar el doble factor de autenticación de Google Authenticator en las conexiones SSH. Así que vamos a ello.

Instalar y configurar los paquetes requeridos.

El paquete en se llama: libpam-google-authenticator.

sudo apt install libpam-google-authenticator

Una vez instalado, lo primero que haremos es reiniciar el servicio sshd:

sudo systemctl restart sshd.service

Ahora editamos con nano el archivo /etc/pam.d/sshd

sudo nano /etc/pam.d/sshd

Y añadimos al final del archivo:

auth required pam_google_authenticator.so

Guardamos con Ctrl+O y salimos de nano con Ctrl+X.

El siguiente paso es editar el archivo de configuración /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

Lo único que tenemos que hacer es cambiar el parámetro KbdInteractiveAuthentication de no a yes.

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication yes # CAMBIAR ESTO A YES

Guardamos con Ctrl+O y salimos de nano con Ctrl+X.

Configurar la autenticación

Para ello lanzamos la configuración de google-authenticator:

sudo google-authenticator 

Nos aparecerá un código QR gigante en la terminal, que es el que debemos escanear con nuestra aplicación de móvil, y además tendremos la lista de códigos de emergencia en caso de que perdamos nuestro dispositivo.

Además, nos hará una serie de preguntas. Resumiento, la configuración recomendada sería:

• Make tokens “time-base”: yes
• Update the .google_authenticator file: yes
• Disallow multiple uses: yes
• Increase the original generation time limit: no
• Enable rate-limiting: yes

Importante

Una vez repondido a todo, asegúrate de volver a reiniciar el servicio sshd

sudo systemctl restart sshd.service

De lo contrario, la próxima vez que intentes iniciar sesión vía SSH es posible que te de un error de login y tendrás que reiniciarlo desde Plesk, CPanel o pedirlo a tu proveedor de hosting.

Tras configurar correctamente, la próxima vez que inicies sesión, además de tu contraseña, te pedirá el código de Google Authenticator.

Para ellos nos vamos a valer del plugin «Advanced Custom Fields«, con el que no solo podremos guardar el contenido básico (título, contenido…), si no que podremos añadir otros campos personalizados que también serán guardados por el formulario.

Artículo disponible en vídeo

Con Advanced Custom Fields instalado vamos a crear un template o página que será la que muestre el formulario.

Para ello recomiendo hacerlo sobre un child-theme, para no perder ningún cambio en caso de que el theme principal se actualice.

Una vez creado el child-theme creamos un nuevo archivo page-nuevo-post.php con el siguiente código:

<?php
    acf_form_head();
    get_header();
?>

<main id="site-content" role="main">
<div id="content">

    <?php
        acf_form(array(
            'post_id' => 'new_post',
            'post_title' => true,
            'post_content' => true,
        ));
    ?>

</div>
</main>

<?php get_footer(); ?>

La primera functión acf_form_head(), llama a los scripts necesarios de Advanced Custom Fields que deben cargarse en la cabecera de la página. Esta función no admite ningún parámetro, solo es necesario declararla.

La siguiente función acf_form(), si admite varios parámetros. Ahora mismo ha sido declarada de la forma más básica, con los parámetros mínimos, donde en post_id indicamos que será un new_post y vamos a guardar tanto el post_title como el post_content.

Al entrar en la página Nuevo Post veremos algo así: (dependiendo de vuestro theme):

Donde lo único que podemos hacer es indicar un título y redactar el contenido del post.

Al pulsar «Actualizar», el post será guardado de forma predeterminada como borrador.

Configurar el tipo de post y su estado

Con el siguiente parámetro podemos indicar el tipo de post que estamos guardando y su estado:

'new_post' => array(
                'post_type' => 'post',
                'post_status' => 'publish'
            ),

La función completa quedaría:

<?php
        acf_form(array(
            'post_id' => 'new_post',
            'post_title' => true,
            'post_content' => true,
            'new_post' => array(
                'post_type' => 'post',
                'post_status' => 'publish'
            ),
        ));
?>

Donde en post_type podemos indicar el tipo de post o CPT (custom post type): post, page, product, project… Y en post status, el estado en que se guardará:

• publish: Publicado.
• pending: Pendiente de revisión.
• draft: Borrador.

Personalizar el texto del botón de guardado

Con otro parámetro podemos personalizar el botón de publicar, ya que «Actualizar» no es lo más apropiado si lo que estamos es guardando un nuevo post:

'submit_value' => 'Publicar'

Mensaje de confirmación de guardado

Por defecto, al guardar el post se recargará la página con el formulario vacío, algo que puede despistar a nuestros usuarios pensando que hayan podido hacer algo mal. Podemos insertar un mensaje de confirmación con el parámetro:

'updated_message' => __("¡Tu post se ha publicado!", 'acf')

De este modo, tras guardar una publicación y recargar la página aparecerá el mensaje:

Redirigir a una página tras guardar el post

Si lo preferimos, podemos redirigirle una página de agradecimiento, similar a la página de «gracias» de un formulario de contacto.

'return' => home_url('gracias-por-tu-articulo')

Donde home_url() es una función que devuelve nuestro dominio actual. Solo tenemos que especificar en su interior el slug de la página destino.

Insertar custom fields en el formulario

Si queremos añadir información adicional a las publicaciones a través de campos personalizados (custom fields), estos también pueden ser llamados en el formulario.

Para ello, en primer lugar crearemos un nuevo grupo de campos con Advanced Custom Fields al que llamaremos «Info Post«.

Dentro crearemos 3 campos:

• Campo de texto: Información extra.
• Campo numérico: Año.
• Campo de imagen: Imagen destacada.

En las reglas de ubicación vamos a indicar que estos campos aparezcan solamente en los posts de tipo entrada. Aunque esto solo afectará al «backend» de WordPress, veremos un poco más adelante cómo mostrarlos en el formulario de ACF.

Para el campo de imagen vamos a especificar que nos devuelva solamente el ID de la imagen:

Para que los campos personalizados se muestren en el formulario (frontend), solo tenemos que añadir el siguiente parámetro:

'field_groups' => ['clave_grupo']

Donde la clave del grupo podemos encontrarla en nuestra lista de grupos de campos:

De forma que nuestra función general quedaría:

<?php
        acf_form(array(
            'post_id' => 'new_post',
            'post_title' => true,
            'post_content' => true,
            'new_post' => array(
                'post_type' => 'post',
                'post_status' => 'publish'
            ),
            'submit_value' => 'Publicar',
            'updated_message' => __("¡Tu post se ha publicado!", 'acf'),
            'field_groups' => ['group_60ffb5cfa3984']
        ));
?>

Ahora al acceder a la página «Nuevo Post», veremos nuestros nuevos campos:

Usar un campo personalizado para establecer la imagen destacada del post

acf_form() no dispone de parámetros para establecer la imagen destacada del post, algo que no se comprende muy bien, pues bastaría con asociar cualquier ID de imagen de nuestra biblioteca de medios con el _thumbnail_id del post.

Para ello tenemos que valernos de un pequeño truco, el cual consistirá en usar un campo personalizado para establecer la imagen destacada del post. Para ello ello hemos creado el campo personalizado «Imagen destacada».

Pues bien, solo tenemos que pegar este snippet en el archivo de funciones (functions.php) de nuestro child-theme:

function acf_set_featured_image( $value, $post_id, $field  ){
    
    if($value != ''){
	    //Add the value which is the image ID to the _thumbnail_id meta data for the current post
	    add_post_meta($post_id, '_thumbnail_id', $value);
    }
 
    return $value;
}

// acf/update_value/name={$field_name} - filter for a specific field based on it's name
add_filter('acf/update_value/name=campo_de_imagen', 'acf_set_featured_image', 10, 3);

Este snippet lo he extraído del foro de Advanced Custom Fields gracias al usuario Jonathan.

Básicamente lo que hace es tomar nuestro campo personalizado de imagen, el cual tenemos que especificar su value en el hook, y establecerlo como imagen destacada del post.

add_filter('acf/update_value/name=imagen_destacada', 'acf_set_featured_image', 10, 3);

Y al guardar o actualizar el post se establecerá como imagen destacada de este.

Y hasta aquí el post de hoy, podéis seguir practicando y aprendiendo nuevos parámetros y ajustes de acf_form() en:

DOCUMENTACIÓN ADVANCED CUSTOM FIELDS: acf_form()

Ahh, y todo esto lo hemos hecho usando la versión FREE de ACV. Nos vemos en el siguiente post

La cuestión es que los productos denominados virtuales, que no requieren de envío, sí cuentan para el importe mínimo que hace activar el Envío Gratuito. Esto ocasiona que si hemos establecido el importe mínimo en 50€, un cliente que compra un producto virtual valorado en 45€ y un producto físico valorado en 5€, ese producto físico sería enviado de forma gratuita según la configuración de WooCommerce.

Estuve buscando información al respecto y di con este post de 2017 en Stack Overflow: Exclude WooCommerce virtual product from counting towards free delivery

Un usuario compartió este filtro:

add_filter('woocommerce_package_rates', 'custom_free_shipping_option', 15, 2 );
function custom_free_shipping_option($rates, $package){

    // HERE set the "minimum order amount" for free shipping
    $limit = 50;

    $free_total = 0;

    // Get the cart content total excluding virtual products
    foreach( WC()->cart->get_cart() as $cart_item )
        if( ! $cart_item['data']->is_virtual( ) )
            $free_total += $cart_item['line_total'];

    // Set the cost to 0 based on specific cart content total
    if( $free_total > $limit )
        foreach ( $rates as $rate_key => $rate )
            if( 'pakkelabels_shipping_gls' === $rate->method_id )
                $rates[$rate->id]->cost = 0;

    return $rates;
}

Según el código, tenemos que especificar manualmente el límite de importe para que se active el Envío Gratuito, en la variable $limit. Seguramente habrá alguna forma de tomar dinámicamente el valor que hemos configurado en el método Envío Gratuito.

Probé este código en una instalación de pruebas y mi decepción es que parece no funcionar. Según el código, el producto Álbum no debería contar para el importe mínimo del Envío Gratuito, pero vemos que si cuenta.

Además tenemos el otro inconveniente que muestra tanto el envío gratuito como el envío de pago, cuando solo debería mostrar el Envío Gratuito si este está disponible.

Pero el código me dió una idea y lo adapte de la siguiente forma:

Primero, con el bucle Foreach, recorremos el carrito sumando el importe de los artículos, pero excluyendo aquellos que sean virtuales. El importe resultante se guarda en la variable $free_total. Hasta aquí, el ejemplo funciona perfecto.

// Get the cart content total excluding virtual products
    foreach( WC()->cart->get_cart() as $cart_item )
        if( ! $cart_item['data']->is_virtual( ) )
            $free_total += $cart_item['line_total'];

Ahora comprobamos si este importe es superior al importe mínimo establecido en la variable $limit, si se cumple, buscamos los métodos de envío hasta que coincida con el Envío Gratuito, cuando coincida paramos el bucle con break y este será el único a mostrar:

//If the total reaches the minimum order, only the free shipping is shown
    if( $free_total > $limit ){
        $free = array();
        foreach ( $rates as $rate_id => $rate ) {
            if ( 'free_shipping' === $rate->method_id ) {
                $free[ $rate_id ] = $rate;
                break;
            }
        }
        return ! empty( $free ) ? $free : $rates;

Y si no se cumple, es decir, si no llega al importe mínimo de pedido, recorremos los métodos de envío QUE NO SEAN el envío gratuito, para no mostrarlos como opción de envío:

}
    else{
        //If it does not reach the minimum order, the shipments that are NOT free are shown
        $free = array();
        foreach ( $rates as $rate_id => $rate ) {
            if ( 'free_shipping' != $rate->method_id ) {
                $free[ $rate_id ] = $rate;
            }
        }
        return ! empty( $free ) ? $free : $rates;   
    }

Aquí el codigo del snippet completo:

function custom_free_shipping_option($rates, $package){
    // HERE set the "minimum order amount" for free shipping
    $limit = 50;
    $free_total = 0;

    // Get the cart content total excluding virtual products
    foreach( WC()->cart->get_cart() as $cart_item )
        if( ! $cart_item['data']->is_virtual( ) )
            $free_total += $cart_item['line_total'];

    //If the total reaches the minimum order, only the free shipping is shown
    if( $free_total > $limit ){
        $free = array();
        foreach ( $rates as $rate_id => $rate ) {
            if ( 'free_shipping' === $rate->method_id ) {
                $free[ $rate_id ] = $rate;
                break;
            }
        }
        return ! empty( $free ) ? $free : $rates;   
    }
    else{
        //If it does not reach the minimum order, the shipments that are NOT free are shown
        $free = array();
        foreach ( $rates as $rate_id => $rate ) {
            if ( 'free_shipping' != $rate->method_id ) {
                $free[ $rate_id ] = $rate;
            }
        }
        return ! empty( $free ) ? $free : $rates;   
    }
}
add_filter('woocommerce_package_rates', 'custom_free_shipping_option', 15, 2 );

Ahora volvemos al ejemplo y comprobamos que funciona:

En este caso, el importe de los productos físicos no llega al mínimo de 50€ que haría saltar el Envío Gratuito, por lo que se cobran gastos de envío aunque el importe total sí supere los 50€.

Si añadimos más unidades del producto físico hasta superar la barrera de los 50€, ahora si salta el Envío Gratuito, y además se ocultan el resto de métodos de envío de pago:

En mi ejemplo solo tengo configurados 2 métodos de envío, el importe fijo de 5€ y el envío gratuito. No lo he probado con otros métodos de envío (combinando clases, etc). Pero en teoría debería funcionar correctamente.

Si tienes algún problema, déjamelo en la caja de comentarios.

Nos vemos en el siguiente post

Usando Genesis Framework con su Sample Theme podemos dar forma a prácticamente cualquier tipo de web y las zonas de widgets nos pueden venir muy bien para estructurarla o dejarlas preparadas para que las usen nuestros clientes.

Registrar la zona de widget para la home

Primero debemos registrar una zona de widget, esto podemos hacerlo en el archivo de funciones (functions.php) del child-theme (nunca en el functions.php de Genesis).

//Registrar Widget Cabecera Home
genesis_register_sidebar(array(
	'id' => 'cabecera-home-widget-area',
	'name' => __('Cabecera Home', 'genesis'),
	'description' => __('Widget para la cabecera de la página principal', 'childtheme')
));

Como se trata de un widget que solamente queremos hacer visible en la página principal de la web, podemos crear un archivo front-page.php con este contenido:

<?php
//Mostrar Cabecera Home Widget Area
function cabecera_home_widget_area(){
    genesis_widget_area('cabecera-home-widget-area', array(
        'before' => '<section class="cabecera-home">',
        'after' => '</section>'
    ));
}
add_action('genesis_after_header', 'cabecera_home_widget_area');

genesis();
?>

Es muy importante especificar el mismo ID de sidebar que usamos al registrarlo ‘cabecera-home-widget-area’.

Nuestro widget irá dentro de una sección (<section>) con la clase CSS ‘cabecera-home’, de forma que podremos aplicarle estilos posteriormente.

En esta zona podemos agregar cualquier widget, ya dea de WordPress, de Genesis o un simple HTML personalizado para darle el formato que deseemos a nuestra cabecera. Por ejemplo, vamos a insertar un calendario:

Y este es el resultado en nuestra página principal:

Como puedes ver, lo primero que carga la página es nuestra zona de widget, ya que en la página front-page.php es lo primero que encuentra, además la hemos anclado en el hook ‘genesis_after_header’, justo después de la cabecera de genesis.

Después hemos llamado a genesis(); que se encarga de mostrar el content de la página (contenido que creamos con el editor y que se guarda en la base de datos).

Registrar una zona de widget para todas las páginas

Ahora vamos a crear una zona de widget que se mostrará al final de todas las páginas de nuestra web, algo que podemos aprovechar para insertar un banner o un formulario de newsletter.

Volvemos a nuestro archivo functions.php del child theme para registrar la nueva zona de widget:

//Registrar Widget Banner Footer
genesis_register_sidebar(array(
	'id' => 'banner-footer-widget-area',
	'name' => __('Banner Footer', 'genesis'),
	'description' => __('Widget para banner final en todas las páginas', 'childtheme')
));

La forma de mostrar este banner en todas las páginas (y entradas) de la web es ponerlo dentro del propio archivo de funciones, por lo que lo añadimos así:

//Mostrar Banner Footer en todo el site
function banner_footer_widget_area(){
    genesis_widget_area('banner-footer-widget-area', array(
        'before' => '<section class="banner-footer">',
        'after' => '</section>'
    ));
}
add_action('genesis_before_footer', 'banner_footer_widget_area');

En este caso usamos el hook ‘genesis_before_footer’ que posiciona nuestro banner justo antes del footer de la web.

Si quieres ver una guía de los hooks de Genesis puedes visitar mi artículo (en construcción): Hooks de Genesis Framework (init, header y framework).

Y el resultado:

Utilizando la clase CSS de la sección ‘banner-footer’, podremos centrarlo darle el tamaño que necesitemos, etc.

Recuerda que este widget será visible en cualquier página o entrada de la web, vemos cómo queda en una entrada:

Podemos condicionar dónde queremos que aparezca usando condicionales if y comprobando el tipo de contenido, por ejemplo:

<?php
//Aplica a todas las páginas
if(is_page()){
    //Código para mostrar el widget
}
?>

<?php
//Aplica a todo el contenido que sea de tipo entrada (de cualquier tipo)
if(is_single()){
    //Código para mostrar el widget
}
?>

<?php
//Aplica a un custom post determinado
if(is_singular('custom_post')){
    //Código para mostrar el widget
}
?>

<?php
//Aplica a la página de blog
if(is_home()){
    //Código para mostrar el widget
}
?>

<?php
//Aplica a la página de resultados de búsqueda
if(is_results()){
    //Código para mostrar el widget
}
?>

Espero que te sea de utilidad este artículo y nos vemos en el siguiente post

Esta funcionalidad no viene integrada directamente en la API de OpenStreetMap (LeafletJS) y tenemos que implementarla mediante un sencillo plugin, Leaflet MarkerCluster.

Para el ejemplo vamos a crear un mapa en OpenStreetMap como lo haríamos normalmente y como vimos en artículos anteriores: Integra OpenStreetMap en tus aplicaciones web con LeafLet y MapBox.

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <link rel="stylesheet" href="https://unpkg.com/leaflet@1.6.0/dist/leaflet.css"
   integrity="sha512-xwE/Az9zrjBIphAcBb3F6JVqxf46+CDLwfLMHloNu6KEQCAWi6HcDUbeOfBIptF7tcCzusKFjFw2yuvEpDL9wQ=="
   crossorigin=""/>
    <script src="https://unpkg.com/leaflet@1.6.0/dist/leaflet.js"
    integrity="sha512-gZwIG9x3wUXg2hdXF6+rVkLF/0Vi9U8D2Ntg4Ga5I5BZpVkVxlJWbSQtXPSiUTtC0TjtGOmxa1AJPuV0CPthew=="
    crossorigin=""></script>
    <title>Mapa con OpenStreetMap</title>
    
    <style>
    	#mimapa {height: 600px;}
    </style>
</head>

<body>
    <div id="mimapa"></div>
    
    <script>
    	var mymap = L.map('mimapa').setView([37.1698, -3.965], 18);
    	
    	L.tileLayer('https://api.mapbox.com/styles/v1/{id}/tiles/{z}/{x}/{y}?access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4NXVycTA2emYycXBndHRqcmZ3N3gifQ.rJcFIG214AriISLbB6B5aw', {
    		maxZoom: 25,
    		attribution: 'Datos del mapa de &copy; <a href="https://www.openstreetmap.org/">OpenStreetMap</a>, ' + '<a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>, ' + 'Imágenes © <a href="https://www.mapbox.com/">Mapbox</a>', 
    		id: 'mapbox/streets-v11'
		}).addTo(mymap);
	</script>
</body>
</html>

Ejecutando este código ya deberíamos poder visualizar un mapa vacío. Si no carga, revisa el código. Puedes modificar las coordenadas por las de tu zona, si lo prefieres.

Ahora vamos a añadir unos cuantos marcadores en un espacio reducido:

/*MARCADORES*/
var marker1 = L.marker([37.1698, -3.965]).addTo(mymap);
var marker2 = L.marker([37.1698, -3.966]).addTo(mymap);
var marker3 = L.marker([37.1700, -3.966]).addTo(mymap);
var marker4 = L.marker([37.1700, -3.967]).addTo(mymap);
var marker5 = L.marker([37.1696, -3.964]).addTo(mymap);
var marker6 = L.marker([37.1694, -3.964]).addTo(mymap);

Hasta aquí bien, tenemos 6 marcadores agrupados en una zona reducida, lo que a simple vista dificulta un poco la visibilidad. Para poder agrupar estor marcadores en clusters vamos a añadir los scripts del plugin MarkerCluster en el <head> de nuestra página a continuación de los scripts de Leaflet:

<link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.1.0/dist/MarkerCluster.css" />
<link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.1.0/dist/MarkerCluster.Default.css" />
<script src="https://unpkg.com/leaflet.markercluster@1.1.0/dist/leaflet.markercluster.js"></script>

Bien, lo primero que vamos a hacer es volver al código de marcadores y quitarles el método addTo(mymap), ya que no vamos a añadirlos de forma indepeniente y dejar este método puede crear repeticiones y comportamientos extraños.

/*MARCADORES*/
var marker1 = L.marker([37.1698, -3.965]);
var marker2 = L.marker([37.1698, -3.966]);
var marker3 = L.marker([37.1700, -3.966]);
var marker4 = L.marker([37.1700, -3.967]);
var marker5 = L.marker([37.1696, -3.964]);
var marker6 = L.marker([37.1694, -3.964]);

A continuación de los marcadores, vamos a declarar un grupo de clusters:

var grupos = L.markerClusterGroup(); 

Y lo único que tenemos que hacer es añadir cada marcador a este grupo:

grupos.addLayer(marker1);
grupos.addLayer(marker2);
grupos.addLayer(marker3);
grupos.addLayer(marker4);
grupos.addLayer(marker5);
grupos.addLayer(marker6);

Huelga decir que si tienes cientos de marcadores no es necesario escribir todo manualmente, usa un bucle que para eso están!

/*POR EJEMPLO:*/
for(var i=1; i <= 6; i++){
    grupos.addLayer(marker+i);
}

Por último agregamos el grupo al mapa:

mymap.addLayer(grupos);

Los marcadores se irán agrupando dinámicamente según el zoom que apliquemos al mapa.

Os dejo el código del archivo html final comentado:

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    
    <!-- API LEAFLET -->
    <link rel="stylesheet" href="https://unpkg.com/leaflet@1.6.0/dist/leaflet.css"
   integrity="sha512-xwE/Az9zrjBIphAcBb3F6JVqxf46+CDLwfLMHloNu6KEQCAWi6HcDUbeOfBIptF7tcCzusKFjFw2yuvEpDL9wQ=="
   crossorigin=""/>
    <script src="https://unpkg.com/leaflet@1.6.0/dist/leaflet.js"
    integrity="sha512-gZwIG9x3wUXg2hdXF6+rVkLF/0Vi9U8D2Ntg4Ga5I5BZpVkVxlJWbSQtXPSiUTtC0TjtGOmxa1AJPuV0CPthew=="
    crossorigin=""></script>
    	
    <!--PLUGIN MARKERCLUSTER -->	
   	<link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.1.0/dist/MarkerCluster.css" />
	<link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.1.0/dist/MarkerCluster.Default.css" />
	<script src="https://unpkg.com/leaflet.markercluster@1.1.0/dist/leaflet.markercluster.js"></script> 
    <title>Mapa con Open Street Map</title>
    
    <style>
    	#mimapa {height: 600px;}
    </style>
</head>

<body>
    <div id="mimapa"></div>
    
    <script>
    	/*DECLARAR EL MAPA*/
    	var mymap = L.map('mimapa').setView([37.1698, -3.965], 16);
    	
    	/*DIBUJAR EL MAPA*/
    	L.tileLayer('https://api.mapbox.com/styles/v1/{id}/tiles/{z}/{x}/{y}?access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4NXVycTA2emYycXBndHRqcmZ3N3gifQ.rJcFIG214AriISLbB6B5aw', {
    maxZoom: 25,
    attribution: 'Datos del mapa de &copy; <a href="https://www.openstreetmap.org/">OpenStreetMap</a>, ' + '<a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>, ' + 'Imágenes © <a href="https://www.mapbox.com/">Mapbox</a>', 
    id: 'mapbox/streets-v11'
}).addTo(mymap);
		
/*DEFINIR MARCADORES*/
var marker1 = L.marker([37.1698, -3.965]);
var marker2 = L.marker([37.1698, -3.966]);
var marker3 = L.marker([37.1700, -3.966]);
var marker4 = L.marker([37.1700, -3.967]);
var marker5 = L.marker([37.1696, -3.964]);
var marker6 = L.marker([37.1694, -3.964]);
		
/*CREAR GRUPO DE CLUSTERS*/
var grupos = L.markerClusterGroup(); 
		
/*AÑADIR CADA MARCADOR AL CLUSTER*/
grupos.addLayer(marker1);
grupos.addLayer(marker2);
grupos.addLayer(marker3);
grupos.addLayer(marker4);
grupos.addLayer(marker5);
grupos.addLayer(marker6);
		
//AÑADIR CLUSTER AL MAPA
mymap.addLayer(grupos);
</script>
</body>
</html>