Brand New Day: la canción que necesitaba hoy

Valencia, 09/09/2026, G.B.
Llevo un tiempo dándole vueltas a esto: la sensación de estar demasiado encasillado, de repetir siempre el mismo patrón ante según qué situaciones o personas. Y creo que parte de aprender en serio, de vivir en serio, es justo eso: no quedarte fijo en una única forma de ver las cosas, aunque tengas anclas —principios, gente, costumbres— que te sostengan. Se puede cambiar de aires sin perder el rumbo.

Porqué esta canción

«Brand New Day» se publicó como single en septiembre de 1999, con Stevie Wonder a la armónica, y da título al sexto álbum de estudio de Sting. La escribió casi como un pequeño homenaje a Wonder, y el tema acabó funcionando como un contrapunto optimista a todo el miedo apocalíptico que rodeaba el cambio de milenio: en vez de esperar el fin del mundo, propone la idea de empezar de cero. Le valió un Grammy al año siguiente. Si te interesa la historia completa, Songfacts la cuenta bien.

Lo que más me gusta es precisamente ese mensaje: no hace falta esperar a un cambio de año, de década o de milenio para «empezar de cero». Cada día es, en potencia, un Brand New Day.

El vídeo

Aterrizándolo

Al final, esto no va solo de música. Va de permitirte, de vez en cuando, cuestionar la rutina, el rol que has asumido, la forma en la que sueles reaccionar. No es inconsistencia, es simplemente seguir vivo, seguir aprendiendo. Y si además tiene banda sonora, mejor que mejor. Como ya he dicho en varias ocasiones, la música es una de las mejores vacunas contra la rutina, la desidia y la desilusión…

 

PD: Haré un crossbloging con Focus On Learning English sobre la frase «Brand New Day». En breve… Hasta pronto!

Mu-plugins en WordPress: qué son, para qué sirven y un ejemplo práctico

Valencia, 09/09/2026, G.B.
Si llevas un tiempo trasteando con WordPress, seguro que conoces la carpeta wp-content/plugins, donde viven los plugins que activas y desactivas desde el escritorio. Pero existe otra carpeta, mucho menos conocida, que merece la pena tener en el radar: wp-content/mu-plugins.

Qué son los mu-plugins

«MU» viene de Must-Use (de uso obligatorio). Son plugins que WordPress carga automáticamente en cada petición, sin que tengan que activarse desde el panel de administración. De hecho, ni siquiera aparecen en el listado habitual de plugins junto al botón de «Desactivar»: aparecen en una sección aparte, de solo lectura, llamada «Uso obligatorio».

Las diferencias clave respecto a un plugin normal son:

  • Se cargan siempre. No hay riesgo de que alguien los desactive sin querer desde el escritorio.
  • Se cargan antes que los plugins normales. Esto es importante si necesitas engancharte a hooks muy tempranos en el ciclo de carga de WordPress.
  • No admiten subcarpetas. WordPress solo lee los archivos .php que están directamente dentro de mu-plugins/, no los que están en subdirectorios (aunque sí puedes tener un archivo suelto que a su vez incluya otros ficheros desde una subcarpeta).
  • No tienen pantalla de ajustes activar/desactivar. Se gestionan a nivel de sistema de archivos, subiendo o quitando el .php correspondiente.

Para qué sirven

Los mu-plugins son la herramienta adecuada cuando necesitas que algo se ejecute siempre, de forma incondicional, sin dejarlo al albur de que un cliente, un editor o tú mismo en un despiste desactivéis un plugin importante. Casos típicos:

  • Funcionalidad crítica del sitio: cosas de las que depende el funcionamiento correcto y que no deberían poder desactivarse por error.
  • Ajustes de seguridad: por ejemplo, desactivar la edición de archivos desde el escritorio, forzar SSL en el admin, o bloquear XML-RPC.
  • Configuración de hosting o multisitio: en instalaciones multisitio son muy usados para forzar comportamientos comunes a toda la red, ya que se cargan en todos los sitios sin necesidad de activarlos uno a uno.
  • Pequeñas utilidades propias que no justifican un plugin completo con cabecera, opciones y demás, pero que quieres tener siempre disponibles.
  • Parches o correcciones rápidas, ideales cuando necesitas asegurarte de que algo se aplica sin depender de que nadie recuerde activarlo.

Cómo se instalan

No hay instalador ni pantalla de subida. El proceso es manual:

  1. Si la carpeta wp-content/mu-plugins/ no existe, se crea.
  2. Se sube el archivo .php directamente a esa carpeta.
  3. Listo. WordPress lo detecta y lo ejecuta en la siguiente petición, sin activar nada.

Ejemplo práctico: mostrar la fecha de última actualización en las entradas

Un caso de uso muy típico en un blog: mostrar al lector cuándo se actualizó por última vez un artículo, además de (o en lugar de) la fecha de publicación. Es útil para dar señales de que el contenido se mantiene al día, algo que además ayuda en SEO.

Vamos a crear un mu-plugin que añada esa fecha automáticamente al principio del contenido de las entradas, solo cuando la fecha de modificación sea distinta a la de publicación (para no mostrar información redundante si el artículo nunca se ha tocado).

<?php
/**
* Plugin Name: Indaga – Last Updated Notice
* Description: Displays the last updated date on blog posts.
* Version: 1.0
* Author: Guillermo Beltrán Pilato
*/

// Exit if this file is loaded directly.
if ( ! defined( ‘ABSPATH’ ) ) {
exit;
}

/**
* Prepends the last updated notice to the post content.
*/
function indaga_show_last_updated_notice( $content ) {

// Only run on single posts, within the main content loop.
if ( ! is_single() || ! in_the_loop() || ! is_main_query() ) {
return $content;
}

$published_date = get_the_date( ‘U’ );
$modified_date = get_the_modified_date( ‘U’ );

// If the difference is less than a day, we consider there was no
// real update (avoids false positives from minor resaves).
if ( ( $modified_date – $published_date ) < DAY_IN_SECONDS ) {
return $content;
}

$formatted_date = get_the_modified_date( ‘F j, Y’ );

$notice = sprintf(
‘<p class=»indaga-last-updated-notice»><em>Last updated: %s</em></p>’,
esc_html( $formatted_date )
);

return $notice . $content;
}
add_filter( ‘the_content’, ‘indaga_show_last_updated_notice’ );

Descargar plugin desde mi cuenta de pCloud

Menudo batería…

Valencia, 08/09/2026, G.B.
¡Uauh! Este vídeo llevaba días circulando por redes en clips de pocos segundos, pero el solo completo es otra cosa.

El batería es Daniel Varfolomeyev, ucraniano, y el vídeo tiene ya diez años: en diciembre de 2016 ganó el DrumQuest Ucrania, un concurso bianual fundado ese mismo año por Tobi «Medic Drums» Fatonade —un estudiante nigeriano de medicina afincado en Ucrania— y promocionado en su momento como «el mayor concurso de batería de Europa».

La segunda edición se celebró el 2 y 3 de diciembre de 2016 en Dom Pechat, en Járkov. En la gran final, Daniel, con solo doce años y natural de Dnipropetrovsk (la actual Dnipro), se impuso a otros quince baterías. Su interpretación de «Tiempo De Festival», el tema de Dave Weckl, quedó grabada y circuló bastante por YouTube en su momento — casi con toda seguridad es ese el «solo completo» al que se refiere el tuit, del que normalmente solo se veían fragmentos recortados.

El jurado de aquella edición lo formaban Alexander Lyulyakin (batería de Boombox y The Erised), Paul Kholdyansky (batería de Prime Orchestra) y Vadym Samosyuk, de Los Samos. Fuente: Wikipedia

Diez años después, el vídeo sigue impresionando igual que el primer día. Ese es el poder de un buen solo de batería. Aquí va:

¿Y qué fue de Daniel?

Diez años después de aquel solo viral, Daniel Varfolomeyev sigue detrás de la batería. Hoy comparte proyecto musical con su hermano Ilya, también batería, a través del canal de YouTube Drummer Daniel Varfolomeyev (@varfikdrummer), dedicado a la trayectoria y el día a día de ambos hermanos. Su actividad también se puede seguir en Facebook, donde la página «Барабанщик Даниил Варфоломеев / Drummer Daniel Varfolomeyev» —con base en Dnipro— suma ya más de 32.000 seguidores.

Un apunte que da contexto a todo esto: al tratarse de una familia ucraniana afincada en Dnipro, en plena guerra, el propio canal de YouTube incluye datos de cuenta (PrivatBank, PayPal) para quien quiera apoyar económicamente a los hermanos. Un recordatorio de que, detrás del vídeo viral de un niño prodigio de hace una década, hay hoy una familia que sigue haciendo música en circunstancias muy distintas a las de 2016.

Feeds, sitemap y una cabecera que sobra: pequeña auditoría de un sitio WordPress con curl

curl

Valencia, 08/09/2026, G.B.
Hay comandos que uno lanza casi por rutina y que, sin embargo, acaban destapando cosas interesantes. La semana pasada me tocó revisar el sitemap nativo de uno de mis sitios en WordPress y, de paso, aproveché para repasar algo que tenía pendiente desde hace tiempo: los feeds del sitio y una cabecera HTTP que no debería estar ahí.

Qué es el feed de un sitio en WordPress

El feed es una versión del contenido en XML —normalmente RSS 2.0, aunque WordPress también sabe hablar Atom— pensada para que lectores de noticias, agregadores o scripts consuman las entradas sin tener que «leer» el HTML de la página. Es una de esas piezas del núcleo de WordPress que llevan ahí desde siempre y que casi nadie mira hasta que algo deja de funcionar (a mí me pasó hace poco con un gadget de Blogger de terceros que dejó de refrescar entradas porque un Disallow: */feed/ en el robots.txt se lo estaba impidiendo).

Lo interesante es que WordPress no genera un único feed, sino uno por cada «vista» relevante del sitio:

  • Feed general, con todas las entradas: /feed/
  • Feed de comentarios de todo el sitio: /comments/feed/
  • Feed de una categoría: /category/nombre-categoria/feed/
  • Feed de una etiqueta: /tag/nombre-etiqueta/feed/
  • Feed de un autor: /author/nombre-autor/feed/
  • Feed de comentarios de una entrada concreta: /nombre-entrada/feed/
  • Feed de una búsqueda: /?s=termino&feed=rss2
  • Feed de un tipo de contenido personalizado, si el CPT lo soporta: /tipo-contenido/feed/

Y todavía hay una capa más: dentro de cada uno de esos ámbitos, el formato de salida se puede forzar con el parámetro ?feed=, con hasta cuatro variantes: rss2 (el que usa WordPress por defecto), rss (RSS 0.92, un formato ya legado), atom y rdf (RSS 1.0). En total, contando ámbitos y formatos, un sitio WordPress típico expone bastantes más «puertas de entrada» XML de las que uno recuerda a primera vista.

El sitemap no es un feed

Conviene no confundir los feeds con el sitemap. Desde WordPress 5.5 (2020), el núcleo genera automáticamente un sitemap XML nativo en /wp-sitemap.xml, sin necesidad de plugins de SEO. No es RSS ni Atom: es un índice que agrupa entradas, páginas, taxonomías y usuarios en sub-sitemaps independientes (wp-sitemap-posts-post-1.xml, wp-sitemap-users-1.xml, etc.), pensado para que los buscadores rastreen el sitio de forma eficiente.

Para comprobar rápidamente si el sitemap responde bien, sin descargarlo entero, uso el comando curl:

curl -I https://midominio.com/wp-sitemap.xml

El -I fuerza una petición HEAD: solo pide las cabeceras HTTP de la respuesta, no el cuerpo. Es la forma más rápida de saber si una URL existe, qué código de estado devuelve y qué tipo de contenido sirve, sin gastar ancho de banda en el XML completo.

Lo que las cabeceras cuentan (y lo que delatan)

Al lanzar ese curl -I contra uno de mis sitios, obtuve algo así (he sustituido la versión de PHP que aparecía por X.X.XX en el código que adjunto por motivos de seguridad):

HTTP/2 200
content-type: text/xml;charset=UTF-8
date: Fri, 04 Sep 2026 06:42:34 GMT
server: Apache
x-powered-by: PHP/X.X.XX

Todo correcto salvo un detalle: x-powered-by: PHP/X.X.XX está anunciando al mundo, con número de versión exacto, qué motor PHP corre detrás. No es una vulnerabilidad en sí misma, pero sí información gratuita para cualquiera que esté buscando qué CVEs probar contra esa versión concreta. Es el tipo de cabecera que no aporta nada al visitante legítimo y sí algo a quien está reconociendo el terreno.

La buena noticia es que server: Apache ya venía sin número de versión, así que esa parte no hacía falta tocarla.

Cómo quitar la cabecera con php.ini

Yo tengo creado el archivo php.ini (o .user.ini) propio en el directorio del sitio. El mío ya incluía algunos ajustes habituales:

upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
memory_limit = 512M
zlib.output_compression = 1
zlib.output_compression_level = 9

Simplemente basta con añadir una línea más:

expose_php = Off

Tras guardar el archivo -y en algunos casos esperar unos minutos a que el hosting recargue la configuración- un nuevo curl -I me ha confirmado que la cabecera x-powered-by había desaparecido. Un cambio de una sola línea, pero de esos que conviene no dejar pendientes.

Resumiendo

  • Un sitio WordPress puede exponer más de media docena de feeds distintos, cada uno con hasta cuatro formatos posibles.
  • El sitemap nativo (/wp-sitemap.xml) es una pieza distinta, propia del núcleo desde la versión 5.5.
  • curl -I es la herramienta de cabecera rápida para auditar cualquier URL sin descargar su contenido.
  • Si tu hosting lo permite, expose_php = Off en tu php.ini o .user.ini es un cambio mínimo con un beneficio de seguridad nada despreciable.

Un plugin propio para aprender comandos básicos de Linux en WordPress

plugin comandos linux

Tal y como comentaba aquí, he preparado un pequeño plugin para mostrar comandos de Linux, para aprender, vaya. Insertaré el shortcode en una nueva página, en vez de en una entrada o post

Valencia, 06/09/2026, G.B.
Llevo tiempo trabajando en plugins a medida, sin dependencias externas, para cubrir necesidades muy concretas sin cargar el sitio con librerías de terceros. El último que he montado va dirigido a quien empieza con Linux: Comandos Linux, un plugin que permite gestionar una pequeña base de datos de comandos —con su explicación y un ejemplo práctico— y mostrarla en el front end mediante un shortcode.

Qué hace

El plugin crea su propia tabla en la base de datos con cuatro campos por registro:

  • Nombre del comando (ls, grep, chmod…)
  • Explicación, en lenguaje sencillo
  • Ejemplo práctico, listo para copiar y probar en terminal

Desde el panel de administración se pueden crear, editar y eliminar comandos con un formulario simple, y el listado incluye un buscador y paginación para cuando la lista crezca.

El shortcode

Para mostrarlo en cualquier entrada o página basta con insertar, entre corchetes []:

comandos_linux

El front end reproduce la misma lógica que el panel: buscador propio y resultados paginados, sin necesidad de recargar toda la página gracias a los parámetros por URL. Si se quiere ajustar cuántos comandos se muestran por página, se puede indicar con (entre corchetes []:

comandos_linux por_pagina="10"

Porqué así

Como en el resto de plugins que he ido publicando aquí, la idea es mantenerlo ligero: sin librerías externas, con consultas preparadas contra la base de datos, y siguiendo el patrón POST/Redirect/GET para evitar reenvíos accidentales de formularios. Es la misma filosofía que ya apliqué en el plugin de recursos o en el de autores: cubrir una necesidad concreta con el menor peso posible.

De momento arranca con comandos básicos como ls, cd, grep o chmod, pero la idea es irlo ampliando poco a poco a medida que vaya cubriendo más terreno, desde gestión de permisos hasta redes o procesos.

Así queda insertado el shortcode en una página  (iré añadiendo más y mejorándolo): Comandos Linux


Descargar el plugin desde mi cuenta de pCloud

Hooks, actions y filters en WordPress: la diferencia que todo el mundo confunde

Valencia, 05/09/2026, G.B.
Si llevas un tiempo tocando el functions.php de WordPress o escribiendo plugins, seguro que te has encontrado con add_action() y add_filter() mil veces. Pero cuando hay que explicar la diferencia entre ambos, es fácil quedarse en un «bueno, son parecidos». No lo son tanto, y entender bien la diferencia te ahorra bugs raros el día menos pensado.

Hook es el concepto general

Lo primero es aclarar la terminología. En español solemos traducir hook como «gancho», y es el término general que engloba a los otros dos: cualquier punto del código de WordPress donde puedes «engancharte» para ejecutar tu propia función. Ese término general se divide en dos tipos:

  • Actions (acciones)
  • Filters (filtros)

Todo lo demás son matices de estos dos tipos.

Actions: «haz algo aquí»

Una acción es un punto del código donde WordPress simplemente dice: «en este momento ha pasado algo, si quieres, ejecuta tu función». No espera que le devuelvas nada.

// Se ejecuta cada vez que se publica una entrada
add_action( 'publish_post', function( $post_id ) {
    wp_mail( 'admin@midominio.com', 'Nueva entrada publicada', 'ID: ' . $post_id );
});

Aquí no hay ningún dato que recoger de vuelta. La función hace su trabajo (enviar un correo, escribir un log, mostrar algo en pantalla) y punto.

Filters: «toma este dato, modifícalo y devuélvemelo»

Un filtro, en cambio, existe porque WordPress necesita un valor para seguir funcionando: un título, un contenido, un booleano que decide qué hacer. Tu función recibe ese valor, opcionalmente lo cambia, y tiene que devolverlo siempre.

// Añade un emoji al final de cada título
add_filter( 'the_title', function( $title ) {
    return $title . ' 🚀';
});

Si te olvidas del return, rompes el filtro para todo el sitio — es el error clásico de quien empieza con filtros viniendo de acciones.

La tabla que lo resume

ActionFilter
¿Qué hace?Ejecuta código en un punto concretoModifica un dato y lo devuelve
¿Recibe un valor?Opcionalmente, como parámetrosSí, el dato a modificar
¿Debe devolver algo?NoSiempre
Ejemplo típicoEnviar un email al publicar una entradaCambiar el texto de un título

Una forma rápida de identificarlos si estás leyendo código fuente de WordPress: si ves do_action(...), es un hook de tipo acción; si ves apply_filters(...), es un filtro. Y add_action() / add_filter() son las funciones que usas tú para «engancharte» a esos puntos.

Un ejemplo real: desactivar el editor de bloques

El otro día leí un artículo de Ayudawordpress.com (Fernando Tellado) sobre cómo desactivar el editor de bloques de WordPress (Gutenberg) para desactivarlo en una instalación multisitio. El filtro que se usa es un buen ejemplo de por qué tiene que ser un filter y no una action:

add_filter( 'use_block_editor_for_post_type', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );

WordPress necesita saber, para cada tipo de contenido, si debe cargar el editor de bloques o el clásico — y eso es exactamente un booleano que hay que devolver. Por eso no podría implementarse como acción: una acción no tiene forma de decirle a WordPress «no, usa esto otro en su lugar». Necesita el mecanismo de ida y vuelta que ofrece el filtro.

Por qué merece la pena tenerlo claro

Más allá de la teoría, esto tiene una consecuencia práctica muy directa: si alguna vez te preguntas «¿por qué mi función no está haciendo efecto?», una de las primeras cosas que hay que revisar es si te has enganchado a una acción cuando en realidad necesitabas un filtro (o viceversa). Es un error tonto, pero muy común, y entender la diferencia de raíz evita perder tiempo depurando algo que en realidad es un fallo de concepto, no de sintaxis.

Once in a lifetime, again…

Momentos musicales…

De vez en cuando, dependiendo de mi estado de ánimo, me gusta («necesito»…) volver  a ecuchar esta canción de Talking Heads, en concreto Once in a Lifetime

¿Por qué? Porque ya soy muy mayor y estoy bastante desilusionado de como van las cosas. Pero la música es, y siempre será, una vacuna contra la insidia de la vida cotidiana, de la rutina,. Y sí, sé que no debemos quejarnos….

Aquí va de nuevo. Disfrutadla los que estéis en mi estado emocional, y los que no también… Esto es  un momento especial para mí; momentos musicales. Ahora sí, aquí va:

PD. Un pequeño artículo en Focus on Learning English sobre la expresión «into the blue again«, Spoiler: esto es crossblogging…

GentleOS: el sistema operativo que resucita ordenadores de los años 80

GentleOS es un proyecto creado por el desarrollador Luke S. (luke8086) capaz de arrancar un escritorio gráfico completo en PCs de hace más de 40 años. Existen dos variantes: GentleOS/32, para máquinas i386 con solo 4 MB de RAM, y GentleOS/16, aún más ligero, que funciona en procesadores 8086/80186 de 1978-1982 con apenas 192 KB de RAM y gráficos CGA.

No requiere disco duro ni conexión a internet: todo corre en memoria y arranca casi al instante, a costa de renunciar a multitarea, red o almacenamiento persistente. Es software libre bajo licencia GPLv2.

📥 Descarga:
GentleOS/32
GentleOS/16

🔗 Fuente: ComputerHoy (20minutos)

Instalar Brave en Linux

brave browser

Artículo de la página oficial del navegador Brave que nos explica cómo instalar el navegador en nuestro sistema Linux.

Brave es compatible con arquitecturas 64 bits AMD/Intel (amd64 / x86_64) y ARM (arm64 / aarch64). Consulta nuestros requisitos del sistema completos para las versiones mínimas del sistema operativo.

Las claves actuales de firma también están disponibles en https://brave.com/signing-keys/.

## Instalación vía terminal para distros Debian, Ubuntu, Mint:

sudo apt install curl

sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg

sudo curl -fsSLo /etc/apt/sources.list.d/brave-browser-release.sources https://brave-browser-apt-release.s3.brave.com/brave-browser.sources

sudo apt update

sudo apt install brave-browser

Visitar artículo: https://brave.com/es/linux/

De solución casera a plugin: Indaga Menu Search ya funciona también en Puntocomunica.com

Valencia, 03/09/2026, G.B.
Ayer os contaba cómo había sustituido Ivory Search por un buscador propio, integrado directamente en el menú mediante unas pocas líneas en el functions.php del child theme de INDAGA.net. Funcionaba bien, pero tenía una limitación evidente: estaba atado a este sitio en concreto. Si quería el mismo buscador en otra web, tocaba copiar y pegar código a mano, sitio por sitio.

Así que le he dado una vuelta y lo he convertido en un plugin independiente: Indaga Menu Search.

Por qué merecía la pena convertirlo en plugin

El código en sí no cambia demasiado —sigue usando exclusivamente el buscador nativo de WordPress, sin dependencias externas ni llamadas remotas—, pero empaquetarlo como plugin da varias ventajas:

  • Se activa y desactiva desde el panel, sin tocar el functions.php de ningún tema.
  • Sobrevive a un cambio de tema, porque el código ya no vive dentro del child theme.
  • Es reutilizable en cualquier proyecto WordPress, no solo en los que usan Twenty Seventeen.
  • La ubicación del menú se elige desde una pantalla de ajustes (Ajustes → Buscador en el menú), con un desplegable que muestra las ubicaciones que registra el tema activo y qué menú tiene asignado cada una. Nada de shortcodes ni de editar código: se elige la ubicación y el icono aparece automáticamente en todo el sitio.

Para quien quiera forzarlo por código en un proyecto concreto, sigue existiendo el filtro indaga_menu_search_location, que tiene prioridad sobre lo que se elija en el panel.

Primera instalación real: Puntocomunica.com

La primera prueba fuera de INDAGA.net ha sido en Puntocomunica.com, donde lo he instalado y activado sin ningún ajuste adicional más allá de seleccionar la ubicación del menú correspondiente desde el panel. En cuestión de minutos, el buscador nativo de WordPress estaba ya funcionando ahí también, con el mismo comportamiento: icono discreto en el menú que despliega el formulario de búsqueda al pulsarlo.

Poder instalar el mismo plugin en dos sitios completamente distintos, sin adaptar una sola línea de código más allá de un clic en un desplegable, es exactamente el objetivo de convertir una solución puntual en una herramienta reutilizable.

Descargar plugin de mi cuenta de pCloud