Categoría: Recursos y Utilidades

Recursos y Utilidades en el directorio de INDAGA.net (2002 – 2019), web de recursos, utilidades y directorio de enlaces

Publicado el

Pexels, fotos y vídeos gratuitos de stock

pexels

Pexels es un banco de imágenes y vídeos gratuitos que se pueden usar sin necesidad de citar la fuente, con miles de creadores compartiendo material de alta calidad libre de regalías. Además del buscador clásico, la web incluye secciones para descubrir tendencias por país, un apartado de retos fotográficos («Challenges»), vídeos gratuitos y su propio blog. Incorpora también un pequeño editor integrado (ajustar colores, añadir texto, recortar, retocar) directamente sobre las fotos antes de descargarlas, y ofrece API para desarrolladores que quieran integrar su catálogo en proyectos propios.

🔗 pexels.com/es-es

Publicado el

Función para calcular el tiempo de lectura de una entrada (post)

Valencia, 19/08/2026, G.B.
Si alguna vez has visto en un blog un texto como «5 min de lectura» justo encima del contenido de una entrada, seguramente te hayas preguntado cómo se calcula. La buena noticia es que no hace falta instalar ningún plugin para conseguirlo: con una función sencilla en el functions.php del tema hijo es suficiente.

La idea detrás del cálculo

El tiempo de lectura estimado se basa en un cálculo muy simple: se cuenta el número de palabras del contenido y se divide entre una velocidad media de lectura, normalmente entre 200 y 250 palabras por minuto. No es una ciencia exacta, pero da una idea útil y realista al lector sobre cuánto tiempo le va a llevar la entrada.

La función paso a paso

Lo primero es una función que calcule ese tiempo a partir del contenido del post:

function indaga_calculate_reading_time( $post_id = null ) {
  if ( ! $post_id ) {
    $post_id = get_the_ID();
  }
  $content = get_post_field( 'post_content', $post_id );
  $content = strip_shortcodes( $content );
  $content = wp_strip_all_tags( $content );
  preg_match_all( '/[\p{L}\p{N}]+/u', $content, $matches );
  $word_count = count( $matches[0] );
  $reading_time = ceil( $word_count / 200 );
  if ( $reading_time < 1 ) {
    $reading_time = 1;
  }
  return $reading_time;
}

Merece la pena detenerse en un par de detalles. Antes de contar palabras, se eliminan los shortcodes y las etiquetas HTML con strip_shortcodes() y wp_strip_all_tags(), para no contar código como si fuera texto. Y el conteo de palabras se hace con una expresión regular UTF-8 (preg_match_all con el patrón /[\p{L}\p{N}]+/u) en lugar de la función nativa str_word_count(), porque esta última no reconoce bien acentos ni la letra «ñ», algo imprescindible al trabajar con contenido en castellano.

Mostrarlo automáticamente en cada entrada

Con el cálculo ya resuelto, el siguiente paso es mostrarlo sin tener que tocar ninguna plantilla del tema. Para eso se engancha a un filtro que WordPress ya tiene previsto: the_content.

function indaga_add_reading_time_to_content( $content ) {
  if ( is_single() && in_the_loop() && is_main_query() && 'post' === get_post_type() ) {
    $reading_time = indaga_calculate_reading_time();
    $notice = '<p class="indaga-reading-time">Tiempo de lectura: ' . $reading_time . ' min</p>';
    $content = $notice . $content;
  }
  return $content;
}
add_filter( 'the_content', 'indaga_add_reading_time_to_content' );

Las tres comprobaciones dentro del if son las que marcan la diferencia entre que esto funcione bien o dé problemas: is_single() asegura que solo se muestre en la página individual de una entrada, in_the_loop() y is_main_query() evitan que el aviso aparezca duplicado en widgets, feeds o bucles secundarios, y la comprobación del tipo de contenido lo limita a entradas de blog, dejando fuera páginas u otros tipos de contenido.

Personalizar el estilo

El aviso se genera con la clase CSS indaga-reading-time, así que basta con añadir unas líneas al style.css del tema hijo para darle el aspecto deseado, por ejemplo:

.indaga-reading-time {
  font-style: italic;
  color: #666;
  margin-bottom: 1em;
}

En resumen

Con menos de treinta líneas de código, sin dependencias externas y sin necesidad de un plugin adicional, es posible añadir una funcionalidad que mejora la experiencia de lectura y encaja perfectamente con la filosofía de mantener el sitio ligero y bajo control propio.

Nota: Descargar de mi cuenta pCloud el código completo (en formato .txt)

Publicado el

Plugin Autores revisado y actualizado (versión 3.9)

autores-plugin

Valencia, 18/08/2026, G.B.
El pequeño plugin que hice para insertar publicaciones, Autores, me fallaba en Puntocomunica.com y en este sitio Indaga.net. Tenía que crear la tabla «a mano» desde phpMyAdmin.

En la web para la que hice este plugin funcionaba perfectamente. La diferencia es que esa web tiene la última versión de mariaDB y las otras dos, las mías, una versión más antigua de MySQL. Además, la seguridad no estaba del todo «afinada«.  Ahora creo que sí. Para mostrarlo hay que insertar el shortcode (entre corchetes[ ], como todos los shortcodes): autores_form

Una muestra:

Añadir nueva publicación

No tiene permiso para agregar autores.

Publicaciones listadas

Este es el enlace de descarga de mi cuenta pCloud: descargar autores-plugin.zip

Publicado el

Eliminar hipervínculos de títulos en WordPress: Cómo crear un plugin sencillo

eliminar_enlaces_en_titulo

Valencia, 17/08/2026, G.B.
Los títulos con enlaces en WordPress pueden ser un problema cuando necesitas mantener la consistencia visual o evitar navegación innecesaria. Si administras un directorio o catálogo de productos y tus títulos contienen HTML con hipervínculos, te voy a mostrar cómo crear un plugin personalizado para eliminarlos automáticamente.

El problema

Durante un tiempo, estuve poniendo el enlace en el título a las entradas de la parte del directorio de Indaga.net. No sé, en ese momento me pareció una buena idea… Con el tiempo comprobé que era un error, por lo que he decidido quitar el código HTML en el título de las entradas afectadas., las cuales, además, deben tener una etiqueta (tag) específica: en mi caso «directorio».

Un ejemplo de título de una entrada con el enlace incluido, el que quiero borrar, para que veas a qué me refiero:

<a href="https://www.ejemplo.com" target="_blank" rel="nofollow">Título de la entrada</a>

Esto no solo afecta la apariencia, sino que también puede generar problemas de SEO y navegación indeseada. ¿La solución? Un plugin personalizado que elimine estos enlaces automáticamente.

La expresión regular

La clave está en esta expresión regular: /<a[^>]*>(.*?)<\/a>/i

Desglosándola:

  • <a[^>]*> – Captura la etiqueta de apertura con cualquier atributo
  • (.*?) – Extrae el texto dentro (no greedy)
  • <\/a> – Captura el cierre de la etiqueta
  • i – Ignora mayúsculas/minúsculas

Crear el plugin en 3 pasos

Paso 1: Crear el archivo del plugin

Accede a tu servidor mediante FTP,  SFTP o el administrador de archivos de tu hosting, y crea un nuevo archivo:

/wp-content/plugins/eliminar_enlaces_en_titulo.php

Más rápido:
También puedes crear una carpeta con el mismo nombre del archivo .php e incluirlo ahí. Luego la comprimes como .zip y navegas en tu escritorio de WordPress a  Plugins: Añadir plugin. Subes el archivo .zip, lo instalas y lo activas.

Paso 2: Agregar el código

Copia y pega el siguiente código:

<?php
/**
 * Plugin Name: Eliminar Enlaces en Título
 * Description: Elimina hipervínculos del título solo en entradas con tag "directorio"
 * Version: 1.0
 * Author: Guillermo Beltrán Pilato
 * Text Domain: eliminar-enlaces-directorio
 */

function eliminar_enlaces_de_titulos_directorio($titulo, $id = 0) {
    // Solo aplicar si el post tiene el tag "directorio"
    if ($id && has_tag('directorio', $id)) {
        return preg_replace('/<a[^>]*>(.*?)<\/a>/i', '$1', $titulo);
    }
    return $titulo;
}

add_filter('the_title', 'eliminar_enlaces_de_titulos_directorio', 10, 2);
?>

Paso 3: Activar el plugin

  1. Ve a Plugins → Plugins instalados en tu panel de WordPress
  2. Busca «Eliminar Enlaces en Tag Directorio»
  3. Haz clic en Activar

¿Cómo funciona?

El plugin actúa como un filtro invisible que:

  • Detecta todas las entradas con el tag «directorio»
  • Elimina el código HTML de los enlaces en los títulos
  • Conserva el texto original sin el hipervínculo
  • No modifica la base de datos (solo afecta la visualización)

Ejemplo:

AntesDespués
<a href=»…»>Traductor online Deepl</a>Traductor online Deepl

Personalización

Usar un tag diferente

Si tu tag no se llama «directorio», simplemente cambia el nombre en la función:

if ($id && has_tag('mi-tag', $id)) {

Aplicar a múltiples tags

if ($id && (has_tag('directorio', $id) || has_tag('catalogo', $id))) {

Filtrar por tipo de entrada

Si solo quieres que funcione en páginas en lugar de entradas:

if ($id && has_tag('directorio', $id) && get_post_type($id) === 'page') {

Ventajas de este enfoque

  • Automático: No necesitas hacer nada manualmente
  • Seguro: No modifica la base de datos
  • Flexible: Solo afecta las entradas que especifiques
  • Reversible: Desactiva el plugin y vuelve al estado anterior
  • Lightweight: Código mínimo, sin impacto en rendimiento

Actualizar títulos existentes en la base de datos

Si prefieres que los cambios se guarden permanentemente en la base de datos, puedes usar esta consulta SQL (con copia de seguridad previa):

UPDATE wp_posts 
SET post_title = REGEXP_REPLACE(post_title, '<a[^>]*>(.*?)</a>', '$1')
WHERE post_type = 'post' AND post_title LIKE '%<a%';

Conclusión

Con este plugin personalizado, tienes control total sobre cómo se muestran los títulos en tu sitio. Es especialmente útil para directorios, catálogos y sitios donde importas contenido regularmente. Fácil de instalar, sin configuración necesaria, y totalmente gratuito.

Bonus Track

Enlaces a páginas para aprender sobre expresiones regulares:

RegexOne: Tutorial interactivo donde practicas directamente en el navegador con ejercicios progresivos. Muy práctico para aprender haciendo

Regular Expressions Info: Aunque el sitio principal está en inglés, tiene una sección traducida en español y es muy exhaustivo. Excelente como referencia

MDN Web Docs de Mozilla – Expresiones regulares es probablemente tu mejor opción. Es completo, autorizado, tiene ejemplos claros y está bien traducido al español. Cubre desde lo básico hasta conceptos avanzados.

Publicado el

Cómo añadir un honeypot a un formulario de contacto de Contact Form 7

Valencia, 14/08/2024, G.B.
Para ampliar la información del artículo Cómo evitar el spam en los formularios de Contact Form 7 en WordPress, vamos ahora a ver cómo añadir un «honeypot» o «tarro de miel» a un formulario de Contact Form 7 para engañar a los bots y evitar así el maldito spam, en la medida de lo posible…

Son tres sencillos pasos:

1) Añadir el campo oculto al formulario

En el editor de Contact Form 7, dentro de la pestaña Formulario, añade este campo en cualquier parte del formulario (por ejemplo, justo después del campo de nombre):

[text website-url]

Esto genera un campo de texto normal llamado website-url. El nombre es arbitrario, pero conviene que suene «atractivo» para un bot (website, url, phone-number… campos que suelen rellenar automáticamente).

2) Ocultarlo con CSS

Añade esta regla a la hoja de estilos del tema (o al Personalizador → CSS adicional):

.wpcf7-form p:has(input[name="website-url"]) {
position: absolute;
left: -9999px;
top: -9999px;
}

Si prefieres no depender de :has() (por compatibilidad con navegadores muy antiguos), puedes envolver el campo en un <span> con una clase propia desde el editor de CF7 en modo HTML:

<span class="cf7-honeypot">[text website-url]</span>

y luego:

.cf7-honeypot {
position: absolute;
left: -9999px;
top: -9999px;
}

Ambas opciones son válidas; la primera es más simple si no necesitas soportar navegadores muy antiguos.

3) Validar el envío en functions.php

Contact Form 7 incluye desde la versión 5.1 el filtro wpcf7_spam, pensado justo para esto:

add_filter( 'wpcf7_spam', function ( $spam, $submission ) {
if ( $spam ) {
return $spam; // ya marcado como spam por otra regla, no seguimos
}

$data = $submission->get_posted_data();

if ( ! empty( $data['website-url'] ) ) {
return true; // el honeypot llegó relleno: es un bot
}

return $spam;
}, 10, 2 );

Con esto, si el campo website-url llega con cualquier contenido, Contact Form 7 marca el envío como spam internamente y lo bloquea antes de que se envíe el correo, sin mostrar ningún error confuso al bot (simplemente no pasa nada, como sería el comportamiento esperado desde su perspectiva).

Nota importante sobre el name del campo

Evita nombres como honeypot o trap: los bots más elaborados ya los reconocen y los saltan. Cuanto más «normal» parezca el nombre del campo (address, company, fax-number), más probable es que un bot lo rellene sin sospechar nada.

Publicado el

Qué es honeypot

honeypot

Valencia, 1508/2026 G.B.
Un «honeypot» en WordPress es una técnica anti-spam sencilla que consiste en añadir un campo oculto a un formulario (como uno de contacto o comentarios) que los usuarios humanos no ven, pero que los bots sí detectan y rellenan automáticamente.

Cómo funciona:

1. Se añade un campo extra al formulario (por ejemplo, uno llamado «web» o «nombre_completo»)
2. Ese campo se oculta visualmente mediante CSS (`display:none`, posición fuera de pantalla, opacidad 0, etc.), nunca con `type=»hidden»`, porque muchos bots ya lo detectan
3. Un usuario real no lo ve, así que lo deja vacío
4. Un bot que rellena todos los campos automáticamente sí lo completa.
5. En el servidor, al procesar el envío, se comprueba: si ese campo llega con contenido, se descarta el mensaje como spam (o se marca como sospechoso)

Ventajas:

– No requiere librerías externas ni servicios de terceros (encaja con tu enfoque de soluciones ligeras y sin dependencias)
– No añade fricción al usuario real (a diferencia de un captcha).
– Fácil de implementar en formularios propios o incluso combinarlo con Contact Form 7 mediante un hook

Limitaciones

– Los bots más sofisticados que ejecutan JavaScript y respetan el CSS pueden evitarlo
– Conviene combinarlo con otras medidas (verificación de tiempo mínimo de envío, nonce, rate limiting) para mayor robustez

Si quieres, te preparo un ejemplo de implementación en PHP puro para un formulario propio o específicamente como complemento a la prevención de spam que ya tienes en Contact Form 7

Publicado el

Cómo evitar el spam en los formularios de Contact Form 7 en WordPress

Valencia, 13/08/2026, G.B.
Cualquiera que administre un sitio en WordPress con un formulario de contacto conoce el problema: tarde o temprano, la bandeja de entrada empieza a llenarse de mensajes automáticos, ofertas de SEO milagroso o enlaces sospechosos. Contact Form 7, uno de los plugins de formularios más usados del ecosistema WordPress, no incorpora protección antispam por defecto, así que esa tarea recae en quien lo instala. La buena noticia es que evitarlo no requiere grandes conocimientos técnicos, sino combinar bien un puñado de técnicas.

Por qué llega el spam a un formulario de contacto

El spam en formularios no suele venir de personas, sino de bots que rastrean la web en busca de campos <form> y <input> para rellenarlos automáticamente. Cuantos más elementos «adivinables» tenga el formulario (nombre, email, mensaje), más fácil es para un bot completarlo sin intervención humana. Por eso las soluciones eficaces no se basan en dificultar la vida al usuario real, sino en tender trampas o barreras que solo detectan a las máquinas.

El método más eficaz y menos invasivo: el honeypot

La técnica del honeypot consiste en añadir al formulario un campo invisible para las personas pero visible para los bots, que recorren el HTML sin ejecutar el CSS que lo oculta. Si ese campo llega relleno al servidor, se descarta el envío sin más. Contact Form 7 permite implementarlo fácilmente combinando un campo de texto oculto con CSS y una validación en functions.php que rechace el envío si ese campo no está vacío. Es la opción que menos fricción añade, porque no exige nada al usuario legítimo.

Un honeypot («tarro de miel» en castellano) existe en el HTML, así que cualquier bot que analice el código lo detecta como un campo más a rellenar.
Está oculto para las personas, normalmente con CSS (display: none o posicionándolo fuera de la pantalla), así que un usuario real jamás lo ve ni lo rellena, por lo que debería llegar siempre vacío cuando el envío lo hace una persona.

Un bot que rastrea formularios no «ve» el CSS, solo el HTML crudo, así que interpreta ese campo como uno legítimo y lo completa automáticamente (a menudo con texto basura, o incluso su propia URL). En el servidor, la lógica es simple: si ese campo llega con algo escrito, el envío se descarta sin más, porque solo una máquina pudo haberlo rellenado.

Es una trampa en el sentido literal: no impide que el bot rellene el formulario, sino que aprovecha su propio comportamiento automático para delatarlo. Por eso es tan eficaz y tan poco invasivo a la vez —no le pide nada extra al usuario real, solo tiende una trampa que solo un bot puede pisar.

reCAPTCHA: la barrera más conocida

Google reCAPTCHA (en su versión v3, invisible) es la integración nativa de Contact Form 7 y sigue siendo una de las defensas más sólidas frente a bots más sofisticados. Se configura desde el propio panel de Contact Form 7, introduciendo la clave del sitio y la clave secreta que genera Google. Su ventaja es que analiza el comportamiento del visitante en segundo plano, sin mostrar los típicos rompecabezas de «selecciona las imágenes con semáforos», lo que evita perjudicar la conversión.

Validación estricta de campos

Otra capa de protección, complementaria a las anteriores, es endurecer la validación de los campos del formulario: exigir que el campo de email tenga un formato válido, limitar la longitud del mensaje, o bloquear la presencia de etiquetas HTML o enlaces en campos que no deberían contenerlos (el nombre, por ejemplo). Contact Form 7 admite expresiones regulares personalizadas en sus campos, lo que permite filtrar patrones típicos del spam antes de que el mensaje llegue siquiera a enviarse.

Filtrado adicional con Akismet

Si el sitio ya usa Akismet para proteger los comentarios de WordPress, se puede aprovechar el mismo servicio para los formularios: existen extensiones de Contact Form 7 que envían cada envío a Akismet para su análisis antes de reenviarlo por correo. Es un paso extra útil cuando el volumen de spam sigue siendo alto pese al honeypot y el reCAPTCHA.

Qué evitar

Conviene ser prudente con los bloqueos por IP y las limitaciones agresivas de frecuencia de envío: son medidas que, mal calibradas, terminan bloqueando a usuarios legítimos con más facilidad que a los propios bots, que suelen rotar de IP constantemente. Tampoco es necesario desactivar el formulario ni añadir capas de fricción visibles si con un honeypot y reCAPTCHA v3 ya se resuelve la mayor parte del problema.

En resumen

La combinación más razonable para un formulario de Contact Form 7 en WordPress es: honeypot como primera barrera invisible, reCAPTCHA v3 como segunda capa de análisis de comportamiento, y validación de campos para cerrar el paso a los patrones más evidentes de spam. Con estos tres elementos bien configurados, la gran mayoría de los envíos automáticos quedan filtrados sin que el visitante real note ninguna diferencia al escribir su mensaje.

Publicado el

Cómo crear un tema hijo en WordPress: el caso de Twenty Seventeen

Child Theme

Si mantienes un sitio en WordPress durante años, tarde o temprano te enfrentas a un problema clásico: has personalizado el CSS, quizás también el header.php, y cada actualización del tema te obliga a repetir esos cambios desde cero. La solución habitual es un tema hijo (o child theme), y en este artículo repaso el proceso completo que he seguido en Indaga.net, incluyendo las dudas que me han surgido por el camino (hacía mucho tiempo que no hacía esto…).

Comentar que todo el proceso sirve para cualquier tema o theme de WordPress, no solo para Twenty Seventeen.

¿Qué es un tema hijo y por qué usarlo?

Un tema hijo es un tema que hereda toda la funcionalidad y las plantillas de otro tema, el «padre», pero permite sobreescribir archivos concretos sin tocar el original. La gran ventaja es que las actualizaciones del tema padre no borran tus personalizaciones, siempre que estén en el sitio correcto.

En mi caso, el tema padre es Twenty Seventeen, y el objetivo principal era mantener un CSS personalizado sin perderlo cada vez que WordPress actualiza el tema.

Estructura mínima necesaria

Contra lo que podría parecer, no hace falta replicar toda la estructura de carpetas del tema padre. Con dos archivos en la raíz ya es suficiente para tener un tema hijo funcional:

wp-content/themes/tema-hijo/
├── style.css
└── functions.php

El stylee.css necesita una cabecera específica que le indica a WordPress cuál es el tema padre:

/*
 Theme Name:   Indaga Child
 Template:     twentyseventeen
 Version:      1.0.0
*/

Y el functions.php se encarga de encolar primero el CSS del padre y después el propio, para que las reglas personalizadas puedan sobreescribir las originales:

<?php
add_action( 'wp_enqueue_scripts', 'indaga_child_enqueue_styles' );
function indaga_child_enqueue_styles() {
    wp_enqueue_style( 'twentyseventeen-parent-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'indaga-child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'twentyseventeen-parent-style' ),
        wp_get_theme()->get('Version')
    );
}

Con esto ya se puede activar el tema hijo desde Apariencia → Temas.

Carpetas opcionales

Solo tiene sentido crearlas si de verdad se van a usar:

  • /assets/css/: para separar el CSS en varios archivos en lugar de amontonarlo todo en style.css.
  • /assets/js/: si se añade JavaScript propio.
  • /inc/: para dividir functions.php en varios archivos PHP si crece mucho.
  • /template-parts/: solo si se van a sobreescribir plantillas concretas del padre (la ruta y el nombre de archivo deben coincidir exactamente con los del tema original para que WordPress detecte la sustitución).
  • /languages/: si se traducen cadenas propias del tema hijo.

La duda del «AdSense desaparecido»

Al activar el tema hijo, me surgió una duda: si tuviera código de AdSense no aparecía en el sitio, y mi primer instinto fue pensar que si lo tuviera, tendría que copiar el header.php del padre al hijo para «recuperarlo».

Aquí está el matiz importante: WordPress hereda automáticamente los archivos de plantilla que el hijo no tiene. Si el tema hijo no incluye su propio header.php, WordPress usa sin más el header.php del tema padre, con todo su contenido, incluyendo cualquier código insertado directamente en él. Así que, en teoría, no debería haber ninguna pérdida solo por activar el hijo.

Antes de tocar nada, conviene descartar por orden:

  1. Caché activa. Con un plugin de caché como WP Fastest Cache, es fácil estar viendo una versión antigua de la página. Vaciar la caché y probar en incógnito resuelve muchos falsos problemas de este tipo
  2. Que el tema activo sea realmente el hijo
  3. Ver el código fuente de la página (Ctrl+U) para comprobar si el fragmento está presente en el HTML aunque no se vea (podría ser un bloqueador de anuncios del propio navegador, no un problema de plantilla)

En este caso concreto, el sitio todavía estaba en fase de revisión y por eso no se mostraban anuncios: no era un problema del tema hijo en absoluto.

¿Qué pasa si actualizo el tema padre?

Esta es probablemente la pregunta más importante de todo el proceso, y la respuesta no es igual para todos los archivos:

  • functions.php del tema hijo: totalmente a salvo. Es un archivo propio, en su propia carpeta, y una actualización del tema padre jamás lo toca.
  • header.php / footer.php editados directamente en el tema padre: aquí está el riesgo real. Si el código de AdSense (o cualquier otra personalización) se editó directamente en el header.php de Twenty Seventeen, una actualización del tema sustituye ese archivo por el original del repositorio, y esos cambios se pierden.

La solución es sencilla: copiar el header.php (y cualquier otro archivo modificado directamente en el padre) a la carpeta del tema hijo, manteniendo el mismo nombre. A partir de ese momento, la herencia de plantillas hace que WordPress use la versión del hijo en lugar de la del padre, y esos archivos quedan protegidos frente a futuras actualizaciones.

El detalle estético: la miniatura en blanco

Un último detalle menor pero visible: al crear el tema hijo desde cero, la miniatura que aparece en Apariencia → Temas queda en blanco. Esto es simplemente porque falta el archivo screenshot.png en la raíz del tema; WordPress no lo genera automáticamente.

Basta con subir una imagen (idealmente en proporción 4:3, por ejemplo 1200×900 px) con ese nombre exacto a la raíz del tema hijo. No requiere ninguna declaración adicional en style.css ni en functions.php; WordPress la detecta solo por estar ahí.

Así es como queda el mío:

child-theme-indaga

Resumen del proceso

  1. Crear style.css y functions.php en wp-content/themes/tema-hijo/ (en mi caso wp-content/themes/indaga/ al haber llamado así al tema hijo o child theme.
  2. Activar el tema hijo desde el escritorio de WordPress.
  3. Antes de dar por buena cualquier «desaparición» de contenido, descartar caché y confirmar el tema activo.
  4. Copiar a la carpeta del hijo cualquier archivo de plantilla (header.php, footer.php, etc.) que se haya editado directamente en el tema padre, para blindarlo frente a actualizaciones.
  5. Añadir un screenshot.png para que la miniatura del tema deje de aparecer en blanco.

Con estos pasos, el sitio queda preparado para recibir actualizaciones de Twenty Seventeen sin sobresaltos, manteniendo intactas todas las personalizaciones (que son bastantes…).

Publicado el

Cómo avisar a tus lectores de que un artículo es antiguo (sin plugins abandonados)

plugin aviso contenido antiguo

Valencia, 13/08/2026, G.B.
Necesitaba un plugin para Indaga.net que avisara a los posibles lectores en el caso de acceder a un artículo con más de 5 años de antigüedad. Busqué en el repositorio de WordPress y encontré alguna opción, pero o llevaba tiempo sin actualizarse o no se ajustaba del todo a lo que quería (control por artículo, umbral configurable, sin dependencias). Así que decidí crear mi propio plugin: Aviso de Contenido Antiguo.

Se trata de un plugin independiente, sin dependencias externas y con estándares de seguridad (nonces, current_user_can, sanitización).

Continuar leyendo «Cómo avisar a tus lectores de que un artículo es antiguo (sin plugins abandonados)»

Publicado el

Qué es un archivo .har y por qué a veces te lo piden cuando algo falla en tu web

archivo .har

Valencia, 12/08/2026, G.B.
Seguro que alguna vez te ha pasado: una página tarda una eternidad en cargar, un formulario no envía los datos o una web se queda a medias, y cuando pides ayuda a un desarrollador, la primera respuesta es: «¿me puedes mandar un archivo .har?»

Si esa pregunta te ha dejado con cara de póker, no eres el único. Vamos a explicarlo con calma, sin tecnicismos innecesarios, porque en el fondo es una herramienta bastante sencilla una vez que entiendes la idea que hay detrás.

La idea, en una frase

Un archivo .har es como la caja negra de un avión, pero de tu navegador. Guarda un registro de absolutamente todo lo que ha pasado mientras cargabas una página web: qué ha pedido el navegador, qué le ha respondido el servidor y cuánto ha tardado cada cosa.

Cada vez que entras en una web, tu navegador no descarga «una página», descarga decenas o incluso cientos de piezas por separado: el texto, las imágenes, las hojas de estilo que le dan color y forma, los scripts que hacen que los botones funcionen, las fuentes tipográficas, los datos que vienen de una base de datos… Un archivo .har apunta cada una de esas idas y venidas, como si fuera el diario de a bordo de esa conversación entre tu navegador y los servidores.

De hecho, el nombre lo dice todo: HAR son las siglas de HTTP Archive, es decir, «archivo de HTTP», el protocolo que usan los navegadores para hablar con los servidores web.

Qué información guarda exactamente

Dentro de un .har puedes encontrar, entre otras cosas:

  • Cada petición que hace el navegador: cuando pide una imagen, un script, una hoja de estilos o unos datos.
  • Cada respuesta que da el servidor a esas peticiones.
  • Los encabezados técnicos de esas peticiones y respuestas, que llevan información sobre el tipo de contenido, el navegador usado, etc.
  • Los tiempos: cuánto ha tardado en cargarse cada elemento, lo que resulta clave para saber dónde está el cuello de botella.
  • El contenido transmitido, a veces incluso el texto o los datos exactos que se han enviado y recibido.
  • Cookies y sesiones, es decir, la información que identifica que has iniciado sesión en un sitio.

Todo esto se guarda en un archivo de texto con formato JSON, así que si lo abres con un editor de texto verás un bloque enorme de datos estructurados. No es para leerlo a simple vista, sino para que lo analicen herramientas específicas o un desarrollador con experiencia.

Cómo se genera, paso a paso

Generar un archivo .har es más fácil de lo que parece, y se puede hacer desde cualquier navegador moderno:

  1. Abre las Herramientas de desarrollador (con la tecla F12 o haciendo clic derecho sobre la página y eligiendo «Inspeccionar»).
  2. Ve a la pestaña Red (o Network, si el navegador está en inglés).
  3. Con esa pestaña abierta, recarga la página para que empiece a registrar toda la actividad desde cero.
  4. Espera a que la página termine de cargar por completo.
  5. Haz clic derecho sobre cualquiera de las peticiones que aparecen en la lista y selecciona una opción similar a «Guardar todo como HAR con contenido».

El nombre exacto de esa opción cambia ligeramente según el navegador, pero la idea es siempre la misma: exportar todo lo que se ha registrado en un único archivo.

Para qué sirve realmente

Puede parecer un archivo muy técnico y, sin embargo, es una de las herramientas más prácticas cuando algo no funciona como debería:

  • Depuración: ayuda a averiguar por qué una página carga despacio o por qué una parte de ella falla directamente.
  • Análisis de rendimiento: permite ver qué elemento concreto es el que más pesa o el que más tarda, ya sea una imagen enorme, un script mal optimizado o una petición que se repite sin necesidad.
  • Diagnóstico compartido: cuando le envías un .har a un desarrollador, no tiene que confiar solo en tu descripción de «se queda cargando» o «me da un error». Puede ver exactamente qué ha pasado en tu navegador, con datos concretos.
  • Optimización: sirve para detectar peticiones innecesarias, rutas ineficientes o recursos que se están cargando más veces de las que deberían.

Un consejo (y una advertencia) antes de compartirlo

Aquí está probablemente el motivo por el que más se usa en el día a día: cuando reportas un problema a un desarrollador, un archivo .har vale más que mil palabras. En vez de intentar describir con precisión qué ha ocurrido, le entregas una prueba objetiva de lo que ha vivido tu navegador.

Ahora bien, precisamente porque registra tanto detalle, conviene tener cuidado con quién comparte ese archivo. Como hemos visto, el .har puede incluir cookies de sesión y otra información que identifica tu cuenta en un sitio web. Antes de enviarlo a alguien, merece la pena revisar que no contenga datos sensibles, o asegurarse de que se lo mandas únicamente a una persona de confianza, como el desarrollador que va a solucionar el problema.

En resumen: la próxima vez que algo falle en una web y te pidan un .har, ya sabes que no es nada del otro mundo. Es, simplemente, el registro fiel de lo que tu navegador ha vivido en esos segundos, convertido en una herramienta que ahorra tiempo, malentendidos y muchas idas y venidas de correos intentando explicar lo inexplicable.