• Usar, o no usar, WWW en tu web

    por

    Cuando empiezas un proyecto web, una de las primeras decisiones técnicas y estratégicas que debes tomar es si utilizar o no las famosas «www» en la dirección principal del sitio. Aunque podría parecer una elección sencilla, la realidad es que tiene implicaciones técnicas, de rendimiento y SEO que conviene entender antes de decidir.

    Aspectos Técnicos

    Ventajas de usar www

    • Flexibilidad en DNS: Puedes utilizar registros tipo CNAME en DNS, permitiéndote apuntar fácilmente a CDNs, servicios cloud y hosting específicos.
    • Arquitecturas distribuidas: Facilita el uso de diferentes servicios técnicos como balanceadores de carga o CDN, sin las limitaciones de DNS del dominio raíz.

    Desventajas de usar www

    • Dirección más larga: Es menos amigable visualmente, y puede considerarse menos moderna desde el punto de vista de branding.
    • Configuración adicional: Exige gestión extra en redirecciones y certificados SSL.

    Ventajas de no usar www

    • URL corta y limpia: Ideal desde la perspectiva de marca, fácil de recordar y comunicar.
    • Modernidad: Percepción más actual y sencilla.

    Desventajas de no usar www

    • Limitación DNS: El dominio raíz no admite registros CNAME, aunque esto ya se soluciona mediante registros ALIAS o ANAME en proveedores DNS avanzados.
    • Problemas potenciales con cookies: Almacenar cookies en el dominio raíz hace que estas sean accesibles por todos los subdominios.

    Implicaciones en SEO

    Google y otros motores de búsqueda no penalizan ni benefician específicamente a una u otra versión (con www o sin www). Lo fundamental desde el punto de vista SEO es:

    • Definir claramente cuál versión es la principal y mantener la coherencia.
    • Utilizar redirecciones 301 hacia la versión elegida.
    • Configurar correctamente las etiquetas <link rel="canonical"> en todas las páginas.
    • Asegurar la coherencia en herramientas como Google Search Console.

    Consideraciones sobre cookies y privacidad

    El uso del dominio raíz para cookies implica automáticamente que todos los subdominios tengan acceso a estas cookies, lo cual puede no ser deseable desde el punto de vista de rendimiento y privacidad. Si tu arquitectura usa diversos subdominios (por ejemplo: api.example.com, admin.example.com, etc.), utilizar www.example.com puede resultar preferible.

    Rendimiento y CDN

    Si planeas una infraestructura escalable, el uso de www simplifica la adopción de CDN, balanceo geográfico y failover. Aunque actualmente existen tecnologías avanzadas (ALIAS, ANAME) que mitigan esta desventaja al no usar www, sigue siendo una ventaja clara en escenarios empresariales grandes y complejos.

    Certificados SSL/TLS

    Ambas opciones requieren un certificado SSL que cubra ambas variantes del dominio (con y sin www). Hoy en día, soluciones gratuitas como Let’s Encrypt simplifican considerablemente esta cuestión. Incluso, cuando compras un certificado, incluye por defecto ambas opciones para un dominio.

    ¿Cuál elegir finalmente?

    La elección dependerá en gran medida del tipo de proyecto, objetivos y contexto técnico:

    • Utiliza WWW si
      • Tienes una infraestructura compleja o planeas escalar significativamente.
      • Vas a gestionar cookies cuidadosamente y utilizar subdominios adicionales.
      • Requieres máxima flexibilidad en tu configuración DNS.
    • No utilices WWW si
      • Priorizas la simplicidad, branding moderno y URL cortas.
      • El proyecto es pequeño o no se planea una arquitectura compleja.
      • Tu proveedor DNS soporta ALIAS o ANAME de manera efectiva.

    En definitiva…

    …no existe una elección «correcta» absoluta, pero sí una decisión adecuada según las necesidades específicas del proyecto. Lo que siempre es crucial es mantener la consistencia y configurar técnicamente bien el dominio, evitando errores comunes como duplicidad de contenido y problemas de redirección. Y si tienes dudas, siempre usa www, que te facilitará todo.

    Evalúa con atención tu proyecto, haz una elección consciente y configura correctamente todas las herramientas SEO y técnicas relacionadas.

  • Cachear AJAX POST en WordPress

    por

    Por defecto, WordPress no cachea las peticiones AJAX, y mucho menos cuando se trata de peticiones POST, ya que son consideradas no idempotentes (es decir, se espera que cambien algo en el servidor). Sin embargo, en muchos casos, realizamos peticiones POST que solo devuelven datos sin modificar nada. En esos casos, podríamos aprovechar los transients de WordPress para cachear los resultados y mejorar el rendimiento.

    Vamos a ver cómo podemos cachear peticiones AJAX POST usando transients de forma segura y eficiente.

    NOTA: Este código no es para cachear todas las peticiones, sino para un plugin o algo que tú estés desarrollando. Se usa un ejemplo de WP_Query como llamada a la base de datos.

    El código

    /**
     * Callback para manejar peticiones AJAX POST y devolver resultados cacheados.
     *
     * Esta función sanitiza los parámetros recibidos, construye una clave única de caché
     * basada en los valores relevantes, intenta obtener los resultados desde un transient,
     * y si no existe, ejecuta la consulta, guarda en caché y devuelve los datos en formato JSON.
     *
     * @return void
     */
    function robotstxt_ajax_request_callback() {
      // Validamos y saneamos los parámetros necesarios.
      $query = isset( $_POST['query'] ) ? sanitize_text_field( $_POST['query'] ) : '';
    
      // Si no hay parámetros válidos, retornamos error.
      if ( empty( $query ) ) {
        wp_send_json_error( array(
          'message' => 'Parámetro "query" no proporcionado.',
        ));
      }
    
      // Preparamos el array que influye en el resultado (excluyendo datos volátiles).
      $cacheable_post = array(
        'query' => $query,
      );
    
      // Generamos la clave única del transient.
      $transient_key = 'ajax_cache_' . md5( wp_json_encode( $cacheable_post ) );
    
      // Intentamos obtener los datos cacheados.
      $data = get_transient( $transient_key );
    
      if ( $data === false ) {
        // Ejecutamos la consulta real.
        $results = robotstxt_custom_query_function( $query );
    
        // Si no se obtienen resultados, respondemos con error.
        if ( empty( $results ) ) {
          wp_send_json_error(array(
            'message' => 'No se encontraron resultados.',
          ));
        }
    
        $data = array(
          'results' => $results,
        );
    
        // Guardamos en la caché (60 segundos por defecto, modificable mediante filtro).
        $expiration = apply_filters( 'robotstxt_ajax_cache_expiration', 60 );
        set_transient( $transient_key, $data, $expiration );
      }
    
      // Devolvemos la respuesta cacheada o recién generada.
      wp_send_json_success( $data );
    }
    
    /**
     * Ejecuta una consulta a la base de datos para obtener publicaciones que coincidan con el término de búsqueda.
     *
     * Esta función utiliza $wpdb para buscar entradas del tipo 'post' cuyo título contenga la cadena proporcionada.
     *
     * @param string $query Término de búsqueda.
     * @return array Lista de resultados con ID y título de cada publicación.
     */
    function robotstxt_custom_query_function( $query ) {
      global $wpdb;
    
      // Construimos el patrón de búsqueda.
      $like = '%' . $wpdb->esc_like( $query ) . '%';
    
      // Ejecutamos la consulta.
      $results = $wpdb->get_results( $wpdb->prepare( "SELECT ID, post_title FROM {$wpdb->posts} WHERE post_type = 'post' AND post_status = 'publish' AND post_title LIKE %s LIMIT 10", $like ), ARRAY_A );
    
      return $results;
    }
    
    add_action( 'wp_ajax_robotstxt_ajax_request', 'robotstxt_ajax_request_callback' );
    add_action( 'wp_ajax_nopriv_robotstxt_ajax_request', 'robotstxt_ajax_request_callback' );

    Análisis del código

    1. Registro del AJAX: add_action('wp_ajax_my_ajax_request', 'robotstxt_ajax_request_callback'); add_action('wp_ajax_nopriv_my_ajax_request', 'robotstxt_ajax_request_callback'); Esto permite que tanto usuarios conectados como no conectados puedan ejecutar la función AJAX.
    2. Generación de la clave de caché: $transient_key = 'ajax_cache_' . md5(json_encode($_POST)); Se utiliza un hash MD5 para generar una clave única basada en los datos del POST. Es una técnica eficaz, aunque se puede mejorar (ver mejoras más abajo).
    3. Lectura y escritura del transient: $data = get_transient($transient_key); if ( false === $data ) { // Generar y cachear }
    4. Respuesta JSON: wp_send_json_success($data);

    Cachear peticiones POST en WordPress puede parecer contra intuitivo, pero si sabes que una petición no modifica datos y su resultado puede ser reutilizado, puedes aprovecharlos para reducir la carga en tu servidor y mejorar los tiempos de respuesta para tus usuarios.

  • Cloudfest Hackathon 2025: CMS Cloud Manager

    por

    Por tercer año consecutivo, ROBOTSTXT va a estar presente en el Cloudfest Hackathon. En 2023 participamos en el proyecto de MariaDB, en 2024 en el de WordPress PHP Unit Tests y en este 2025 en el CMS Cloud Manager.

    No es muy difícil de imaginar un evento que reúne a las empresas de cloud-hosting más grandes del mundo. Tampoco sería difícil que ese evento tuviera un hackathon asociado y, por tanto, que se unieran los mejores desarrolladores de código abierto para participar.

    Con más de 9.000 registrados al evento, este año el código abierto y WordPress en particular tienen un nuevo lugar con la WP Zone en la que se espera que los proyectos de código abierto tengan más peso que nunca en el evento.

    Pero, aunque el evento está muy bien, lo mejor sin duda es el Hackathon. En 2023 me invitaron a asistir. Como tenía que volar y estaba un poco despistado de todo, llegué tarde, y al final acabé en el proyecto de MariaDB, que acabó con la creación del plugin oficial de MariaDB para WordPress (MariaDB Health Checks).

    Teniendo en cuenta que no sabía a lo que iba, he de decir que volví de Alemania con ganas de volver a asistir, mucho más preparado. Y eso es lo que pasó en 2024. Esta vez no como asistente, sino como líder de uno de los proyectos; un proyecto que llevaba en el cajón del equipo de hosting de WordPress y que avanzó mucho. Avanzamos tanto con el PHPUnit Test Runner como con el PHPUnit Test Reporter. Estuve preparándome el proyecto durante 3 meses.

    Este 2025 me lo voy a plantear de una manera algo distinta. Por un lado, voy a liderar, de nuevo, un proyecto llamado CMS Cloud Manager (uno de los 10 proyectos que se presentan); pero por otro, a diferencia de los años anteriores, voy con las ideas más claras de cómo funciona el evento y con ganas de pasarlo bien, así que, con mucha menos presión.

    Además, este año no voy solo, porque Markus Kostrzewski, de Hetzner, me acompañará en el liderazgo del proyecto.

    ¿Qué va a ser el proyecto? No está claro. Aún. Hay una idea inicial que es crear como una web / panel en el que configures una serie de opciones, y te haga la instalación de un servidor. Por ejemplo, decir que usas un proveedor A, y que quieres instalar un CMS llamado B, y mediante las API y demás, te montará el servidor seguro, optimizado, y con el CMS correctamente funcionando.

    Y sí, hay muchas herramientas que te montan con un clic, un CMS, pero aquí la diferencia es montar el servidor correctamente optimizado.

    Entre el viernes 14 y el lunes 17 de marzo, horas y horas para hackear el mundo.

  • WordPress 6.8: configuración del servidor

    por

    Se acerca el lanzamiento de WordPress 6.8, y esto nos lleva a plantear qué configuración de servidor va a ser la óptima para esta nueva versión mayor de WordPress.

    Recomendación de ROBOTSTXT

    Existen distintas fuentes de información cuando hablamos de las configuraciones de WordPress con respecto al servidor. Las principales son las que dan el equipo de Core y el equipo de Hosting de WordPress.

    Nuestra recomendación, por compatibilidad, para WordPress 6.8 es la siguiente:

    • PHP: 8.2.x, 8.3.x
    • MySQL: 8.0.x, 8.4.x
    • MariaDB: 10.11.x, 11.4.x

    Es importante tener en cuenta que estas recomendaciones son para instalaciones nuevas de WordPress, aunque, dependiendo de los plugins instalados, se podría actualizar cualquier WordPress existente.

    Nuestras instalaciones, para WordPress 6.8, van a ser con esta configuración:

    • PHP: 8.2.x
    • MariaDB: 11.4.x

    Requisitos de WordPress

    Los requisitos oficiales para WordPress 6.8 son:

    • PHP: 7.2.24+
    • MySQL: 5.5.5+
    • MariaDB: 5.5.5+

    Recordatorio: Desde WordPress 6.6 ya no se da soporte a PHP 7.0 y PHP 7.1. Puedes revisar la compatibilidad de versiones anteriores de WordPress en la documentación.

    Compatibilidad en el lanzamiento

    ¿Qué versiones son las compatibles y funcionales con el lanzamiento de WordPress 6.8? O sea, qué es lo que existía el día del lanzamiento (que no significa que sea la compatibilidad, pero sirve para establecer un entorno base).

    PHP

    • PHP 8.1 (solo correcciones de seguridad)
    • PHP 8.2 (solo correcciones de seguridad)
    • PHP 8.3
    • PHP 8.4

    MySQL

    • MySQL 8.0 (el 30 de abril finaliza el soporte)
    • MySQL 8.4 (LTS)
    • MySQL 9.1

    MariaDB

    • MariaDB 10.5 (el 24 de junio finaliza el soporte)
    • MariaDB 10.6 (LTS)
    • MariaDB 10.11 (LTS)
    • MariaDB 11.4 (LTS)
    • MariaDB 11.7

    Apache HTTPD

    • Apache HTTPD 2.4

    nginx

    • nginx 1.26 (versión estable)
    • nginx 1.27

    WordPress y PHP

    WordPress funciona sobre PHP, el lenguaje en el que está programado. Es importante mantener este software al día tanto por seguridad como por compatibilidad con WordPress.

    WordPress da soporte a muchas versiones de PHP, incluso algunas obsoletas. Puedes ver la documentación oficial de compatibilidad entre WordPress y PHP.

    WordPress 6.8 (core) es:

    • compatible con PHP 7.2.24+*, PHP 7.3*, PHP 7.4*, PHP 8.0*, PHP 8.1 y PHP 8.2.
    • compatible en beta con PHP 8.3 y PHP 8.4.

    * IMPORTANTE: Estas versiones no cuentan con mantenimiento oficial por parte de PHP, por lo que se consideran versiones inseguras y obsoletas y no deberían utilizarse en producción. Consulta con tu proveedor de hosting sobre el mantenimiento de seguridad que tienen sobre estas versiones.

    Actualizando WordPress

    Si tienes versiones anteriores a WordPress, deberías plantear hacer actualizaciones de la siguiente manera.

    WordPress 6.2 – 6.7 (WordPress 6.8)

    • Actualizar a WordPress 6.8
    • Actualizar a PHP 8.2
    • Actualizar a MariaDB 11.4

    Si tienes cualquier versión de WordPress entre la 6.2 y la 6.7, actualiza PHP a la versión 8.2, actualiza MariaDB a 11.4 y actualiza WordPress a la 6.8. El núcleo de WordPress debe funcionar correctamente.

    WordPress 5.3 – 6.1 (WordPress 6.2)

    • Actualizar a WordPress 6.2
    • Actualizar a PHP 7.4
    • Actualizar a MariaDB 11.4

    Si tienes cualquier versión de WordPress entre la 5.3 y la 6.1, actualiza PHP a la versión 7.4, actualiza MariaDB a 11.4 y actualiza WordPress a la 6.2. El núcleo de WordPress debe funcionar correctamente.

  • ¡Hola, mundo! Por enésima vez

    por

    Hace unas semanas publicaba en mi blog personal algunas ideas sobre por qué creo que hoy en día es muy importante retomar los blogs como forma de publicación, la importancia que tienen. Y entre esas cosas que explicaba era que quería montar un blog para ROBOTSTXT.

    Llevo más de 25 años generando contenido en Internet, principalmente en modo texto, algunas fotos, y unos cuantos pódcast.

    Y es que ahora hará 3 años que monté la empresa y siempre he estado con la tentación de publicar, pero nunca encontraba ni el momento, ni la idea y, a veces, ni las ganas. ¿Por qué ahora? Por WordPress, pero no en el buen sentido.

    Desde hace un tiempo que WordPress es un proyecto radiactivo, y aunque hay maneras de gestionarlo, nunca está de más ponerte el traje correspondiente y tomarte unas pastillas de iodo.

    Esto nos ha hecho plantear ciertos cambios y estrategias en la empresa. Un ejemplo fácil ha sido reorganizar toda la web, que en su día estaba completamente centrada en administración de sistemas para WordPress. Ahora WordPress es una simple sección.

    Ofrecer un servicio completo y artesanal de sistemas, y no el que ofrecen proveedores de hosting masivos con todo automatizado y a pocos clics, es lo que llevamos haciendo desde el primer día. Ahora tenemos todas las cartas sobre la mesa… desde la gestión de dominios, DNS, certificados y correo electrónico, que puede parecer fácil, pero no siempre lo es, hasta la gestión de infraestructura propia para empresas y agencias que tienen muchos sitios o VPS.

    Aunque sin duda donde más esfuerzo estamos haciendo es en la parte de los VPS, ya sea simplemente montándolos de forma específica para proyectos, como el sistema de aplicaciones de código abierto que estamos acabando de optimizar, pero que algunos clientes que llevan tiempo con nosotros ya han comenzado a probar. Eso sí, sin olvidar el trabajo que ya hacíamos principalmente con Plesk, extendido a cPanel y a otros paneles de control.

    Y después de explicar algunos cambios, en realidad creo que una de las cosas que nos falta es explicar mejor todo lo que tenemos y hacemos. Aunque eso va a llegar en próximas entradas, que esta es simplemente de bienvenida.