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)

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

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.

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.

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

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.

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…).

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)»

Una actualización de «Record of Consent Extension for Complianz» provoca un error crítico en WordPress

Valencia, 11/08/2026, G.B.
Una actualización reciente del plugin Record of Consent Extension for Complianz, el complemento gratuito que añade registro de consentimientos al plugin Complianz, ha dejado inaccesibles varios paneles de administración de WordPress tras instalarse. El fallo se ha detectado en varios sitios, incluidos algunos que gestiono, donde el escritorio de WordPress quedó bloqueado por un error crítico inmediatamente después de la actualización automática del plugin, mientras que la parte pública de las webs siguió funcionando con normalidad.

Cómo se detectó el problema

El síntoma es el clásico «error crítico» de WordPress, pero limitado al escritorio: el acceso a wp-admin se interrumpía por completo, sin más detalle visible para el usuario salvo que ha ocurrido un problema técnico, mientras que la web pública seguía cargando sin incidencias. Al revisar por SFTP la carpeta wp-content/plugins, el plugin con la fecha de modificación más reciente —coincidiendo con el día anterior a la incidencia— resultó ser precisamente esta extensión de Complianz. Renombrar su carpeta (lo que equivale a desactivarlo a la fuerza, ya que WordPress no puede cargar un plugin cuya ruta ha cambiado) restableció el acceso al instante, confirmando que el origen del fallo estaba ahí. Tras verificarlo, se optó por eliminar el plugin directamente en lugar de reactivarlo.

Qué dice el registro de cambios oficial

El historial de versiones publicado en el repositorio de WordPress.org confirma que este no es el primer episodio de errores fatales en el plugin: versiones anteriores tuvieron que corregir expresamente una llamada a un método inexistente que provocaba un error fatal en el almacenamiento de consentimientos, así como un fallo por el que la tabla de base de datos no se creaba durante el asistente de configuración inicial, lo que impedía guardar los registros de consentimiento. Es decir, se trata de un complemento con antecedentes de regresiones críticas entre versiones, algo a tener en cuenta por quienes lo usan en producción.

En el momento de escribir estas líneas, el repositorio oficial de WordPress.org señala la versión 2.1 como la más reciente publicada, sin que se haya localizado en foros o canales públicos un reporte específico que documente esta incidencia concreta con fecha de ayer; es posible que se trate de un problema de compatibilidad puntual con la configuración de PHP, caché o el propio Complianz en los servidores afectados, y no de un fallo generalizado reportado aún por la comunidad.

Qué hacer si os ha pasado lo mismo

Si una web deja de responder justo después de que WordPress actualice automáticamente un plugin, el primer paso es siempre identificar por SFTP o FTP qué carpeta de wp-content/plugins tiene la fecha de modificación más reciente y renombrarla temporalmente (añadiendo, por ejemplo, _OLD al nombre de la carpeta); esto basta para que WordPress lo desactive sin poder acceder al panel, y suele restaurar el acceso en segundos si el plugin es efectivamente el causante. Conviene además revisar los logs de error de PHP del hosting (error_log o el panel de errores que ofrezca el proveedor) para confirmar la causa exacta antes de decidir si se reinstala una versión anterior, se contacta con el soporte del desarrollador o, como en este caso, se opta por eliminarlo y buscar una alternativa.

Plugin de WordPress Comet Cache: lo borro

Una nota rápida…

Valencia, 03/08/2026
Parece ser que el plugin Comet Cache lleva desde 2017 sin actualizarse realmente, aunque sigue en el repositorio de plugins de WordPress (situación realmente extraña. ..). Veamos:

  • Última actualización real: 2017 (versión 170220). La ficha muestra «actualizado hace 1 año» porque WordPress.org a veces refresca metadatos aunque el código no cambie, pero el changelog no miente: ocho años sin tocar el core del plugin.
  • Las reseñas más recientes (incluida una de diciembre de 2025) lo describen literalmente como un «zombie» que aparece como «actualizado recientemente» en el listado de plugins pero cuya última versión real sigue siendo la de 2017. wordpress
  • El «Tested up to 6.9.5» que aparece en la ficha es automático/cosmético, no significa que alguien lo haya probado de verdad contra esa versión de WP.
  • Un plugin de caché sin mantenimiento es un riesgo de seguridad mayor que uno normal, porque toca puntos sensibles: wp-config.php, advanced-cache.php, reglas de .htaccess, interceptación de requests antes de que cargue WordPress. Si aparece una vulnerabilidad ahí, nadie la va a parchear.

Por eso y por lo que acabo de leer lo he desinstalado,  tanto aquí como en Puntocomunica.com,. Mantengo Autoptimize e instala el plugin WP Fastest Cache.

Creo que es una buena elección. Ya veremos…