• Bienvenido a XenForo Hispano. Somos una comunidad independiente sin vínculos comerciales ni legales con XenForo Ltd. Ofrecemos asistencia en español para su software y traducciones exclusivas de complementos oficiales y de terceros.

XF 2.3 Novedades para desarrolladores en XenForo 2.3

https://ginernet.com/cdn/imagenes/banners/720x90-es.gif
Como prometimos, esta semana vamos a echar un vistazo rápido a algunos de los cambios más centrados en los desarrolladores que llegarán con XenForo 2.3.
1700274400254.png

Si algún tema te interesa más que otros, haz clic en uno de los enlaces de abajo:

Aunque tenemos algo más que mostrarles, las próximas dos semanas van a estar centradas en conseguir que XenForo 2.3 esté listo para ser instalado aquí y algunos posts adicionales de "¿Has visto...?" pueden llegar entre entonces y el lanzamiento de la beta pública. Hasta entonces, gracias por acompañarnos en este viaje.
 

JavaScript​

En nuestro segundo HYS anunciamos nuestra decisión de alejarnos de jQuery y algunos de ustedes ya están publicando actualizaciones de sus complementos, lo cual es estupendo de ver. Lo que sigue sirve como referencia no exhaustiva para cualquier cambio específico en el marco que pueda afectar a la forma de escribir código JavaScript en sus complementos en el futuro.

XF.extendObject

Este es un nuevo método que reemplaza al método $.extend() por defecto de jQuery. Funciona básicamente igual, incluyendo la opción de hacer un clonado "profundo".

XF.createElementFromString

jQuery permitía crear un nuevo elemento con varias propiedades y atributos completamente a partir de una cadena, por ejemplo:

JavaScript:
const $input = $('<input type="text" readonly class="input" />')

Queríamos tener algo parecido a esto, así que hemos añadido un método que funciona de forma similar:

JavaScript:
const input = XF.createElementFromString('<input type="text" readonly class="input" />')

También tenemos un concepto completamente nuevo llamado XF.createElement sobre el que podrás leer en un post posterior.

Gestión de eventos​

Algunas de las cosas de gestión de eventos en jQuery son bastante interesantes, así que las hemos replicado tanto como ha sido posible. Notablemente, soportamos eventos namespaced de forma similar a jQuery, junto con métodos equivalentes a jQuery llamados XF.on(), XF.off(), XF.trigger() y XF.customEvent(). Para manejar eventos delegados tenemos un nuevo método XF.onDelegated. Si antes usabas el método one de jQuery para que un evento fuera eliminado después de ser disparado por primera vez, ahora puedes simplemente pasar { once: true } en tus llamadas XF.on().

Cambios en XF.ajax

Aunque el uso de XF.ajax() no ha cambiado en su mayor parte, está claro que ya no utilizamos $.ajax() de jQuery, que es una envoltura de XMLHttpRequest. Hemos decidido abandonar XMLHttpRequest en favor de la más moderna API Fetch.

XF.ajax devuelve ahora una Promesa similar a la que devuelve jQuery, aunque los nombres de los métodos de las promesas son ligeramente diferentes. Ya se mencionaron en el post original.

El otro cambio notable es cómo se cancelan las peticiones AJAX si es necesario. Anteriormente, el objeto devuelto por jQuery tenía un método de abortar que podía ser llamado. La API de Fetch tiene una forma diferente de conseguirlo, que es un poco más enrevesada, así que hemos creado un nuevo método XF.ajaxAbortable que hace que sea un poco más fácil trabajar con él, pero vale la pena tener en cuenta que tu uso actual de XF.ajax donde una llamada puede necesitar ser abortada, necesitará ser cambiado.

Aquí hay un ejemplo de uso de form.js:

JavaScript:
const {
    ajax,
    abortController,
} = XF.ajaxAbortable('post', this.options.descUrl, { id: value }, this.onLoad.bind(this))

if (abortController)
{
    this.abortController = abortController
}

// ... elsewhere in the code

if (this.abortController)
{
    this.abortController.abort()
    this.abortController = null
}

XF.proxy

El método XF.proxy se utiliza normalmente cuando se desea cambiar el contexto de la variable this al llamar a otra función. Por ejemplo, si pasas una función como callback al escuchar un evento de carga de imagen (o similar), this en ese callback sería normalmente una referencia a la propia imagen. Eso no suele ser deseable, por lo que XF.proxy nos ayuda a mantener la coherencia de este contexto.

Aunque, por supuesto, XF.proxy sigue existiendo y permanece sin cambios, por favor considéralo obsoleto y marcado para su eliminación en el futuro.

En su lugar, ahora recomendamos y utilizamos el enfoque nativo de JavaScript para esto. Esto se ve así:

JavaScript:
XF.on(form, 'reset', this.formReset.bind(this))

Principalmente, esto debería ayudar a reducir los errores y ayudar a navegar por el código en su IDE.

Animaciones JavaScript y transiciones basadas en CSS​

jQuery tiene una serie de funciones de animación que pensamos que valía la pena mantener, así que las hemos reescrito. Estos nuevos métodos se encuentran en un nuevo espacio de nombres XF.Animate e incluyen varios enfoques para deslizar/desvanecer contenido.

Este es un ejemplo en el que desvanecemos un contenedor existente para ocultarlo, reemplazamos su contenido y lo volvemos a desvanecer para mostrar el nuevo contenido:

JavaScript:
XF.Animate.fadeUp(containerEl, {
    speed: XF.config.speed.fast,
    complete ()
    {
        containerEl.innerHTML = html.innerHTML
        XF.Animate.fadeDown(containerEl)
    },
})

Puede que también esté familiarizado con nuestros métodos personalizados addClassTransitioned y removeClassTransitioned. Antes se añadían como extensiones de jQuery. Ahora se han trasladado a un nuevo espacio de nombres XF.Transition y requieren que se pase un elemento como primer argumento.

JavaScript:
XF.Transition.addClassTransitioned(this.errorElement, 'is-active')

Cambios en la librería de proveedores​

Esta sección resume los cambios en las librerías de proveedores que pueden afectar a sus complementos actuales.

Select2​

Desafortunadamente, Select2 todavía está escrito con jQuery como dependencia, por lo que ya no se incluirá a partir de XenForo 2.3. Sólo utilizamos Select2 para nuestro sistema de "token input" que se utiliza como entrada de etiquetado y para la selección de múltiples usuarios (como conversaciones). Para mantener esta funcionalidad ahora estamos incluyendo una librería llamada Tagify.

Esto tiene más o menos la misma funcionalidad a la que estás acostumbrado pero, ooh, mira, avatares para la entrada de múltiples usuarios:

1700275767414.png


Generación de códigos QR​

Incluimos una librería de generación de códigos QR principalmente para ayudar a la configuración de TOTP como método de autenticación de dos factores. La versión anterior de esta librería dependía de jQuery pero las nuevas versiones han sido reescritas sin dependencias específicas. Si estás utilizando códigos QR en alguno de tus complementos, esto es algo que querrás tener en cuenta. La versión específica de esta biblioteca que estamos utilizando ahora se puede encontrar aquí.

Calificación por estrellas​

Las calificaciones por estrellas, como puedes ver tanto en la Galería multimedia de XenForo como en el Gestor de recursos de XenForo, dependían anteriormente de una libreria de terceros. No existía un reemplazo directo, así que lo convertimos nosotros mismos a JavaScript. Ahora es una nueva clase llamada XF.BarRating que puedes encontrar en rating.js.
 

SwiftMailer a Symfony Mail​

El anuncio relativo al fin de la vida útil de SwiftMailer se anunció en 2021 y rápidamente implementamos Symfony Mail como sustituto... allá por 2021. Aunque podríamos haber implementado esto durante la vida de XenForo 2.2, hay algunas pequeñas rupturas de BC.

Cualquier extensión de clase a XF\Mail\Mail y XF\Mail\Mailer probablemente se verá afectada y necesitará cambios para trabajar con XenForo 2.3. Esto afectará principalmente a los métodos que actualmente reciben cualquier objeto con una clase que tiene un prefijo Swift_ y el uso de los objetos que pueden tener una API diferente.

En general, Symfony Mail es esencialmente una reescritura de SwiftMailer por lo que el proceso de conversión de código para utilizar Symfony Mail no debería causar demasiados problemas.
 

De Doctrine Cache a Symfony Cache​

Doctrine Cache también ha quedado obsoleto, y ha sido sustituido por el componente Symfony Cache. Aunque este cambio tiene un alcance similar al de Symfony Mailer, tiene más posibilidades de romper sitios que utilizan complementos que tocan el almacenamiento en caché de alguna forma.

Con esto en mente, hemos proporcionado una capa de compatibilidad para reducir la probabilidad de problemas significativos. Cuando se obtiene un adaptador de caché del contenedor de servicios, se envuelve en un objeto con el mismo FQCN e interfaz que un proveedor de caché Doctrine. En la mayoría de los casos, esto debería permitir que los complementos sigan funcionando sin cambios. Utilizamos la envoltura de Doctrine Cache en \XF\CssRenderer para mantener la compatibilidad con versiones anteriores. Otras clases que no utilizan nuestro sistema de extensión se han actualizado para utilizar directamente el adaptador de Symfony Cache.

Para facilitar la migración al adaptador Symfony Cache, puedes recuperarlo con un nuevo tercer argumento booleano para el método \XF\App::cache:

PHP:
$cache = \XF::app()->cache('context', true, false);

// setting a cache item
$item = $cache->getItem($id);
$item->set($data);
$item->expiresAfter($ttl);
$cache->save($item);

// retrieving a cache item
$data = $cache->getItem($id);

Puedes consultar la documentación de Symfony Cache para más detalles.
 

Emogrificador actualizado​

Hemos actualizado la biblioteca Emogrifier incluida. Hemos actualizado la librería Emogrifier incluida, que convierte las clases CSS utilizadas en las plantillas de correo electrónico en estilos en línea para mejorar la compatibilidad de la representación del correo en una amplia gama de clientes de correo electrónico.

Esto ha dado lugar a un ligero cambio en la clase XF\Mail\Styler donde si ha añadido una extensión de clase aquí que extiende el método __construct específicamente, tendrá que hacer cambios, ya que ya no recibe una propiedad inliner:

PHP:
public function __construct(CssRenderer $renderer)
 

Evento de precarga del registro​

A veces, ciertos datos almacenados en el registro son necesarios para la mayoría o potencialmente todas las peticiones. Cuando una instalación de XenForo no está configurada para utilizar el almacenamiento en caché, la carga de datos desde el registro incurre en una consulta a la base de datos. En el núcleo, podemos precargar datos comunes en una sola consulta cuando se inicializa el marco, pero esta funcionalidad no estaba disponible para los complementos porque los datos de los complementos se almacenan en el registro. ¡Catch-22! (¿O caché-22...?)

Hemos introducido un evento de código app_preload_extra en XF 2.3, permitiendo a los complementos precargar datos del registro. Esto significa que todos los complementos pueden cargar datos del registro juntos en una sola consulta, en lugar de consultar los datos individualmente. El objeto \XF\App también se pasa para que las claves puedan ser asignadas a una aplicación específica:

PHP:
public static function appPreloadExtra(\XF\App $app, array &$keys): void
{
    if ($app instanceof \XF\Pub\App)
    {
        $keys[] = 'myRegistryKey';
    }
}
 

Métodos de conversión de IP nativa​

En versiones anteriores, utilizábamos nuestros propios métodos para convertir direcciones IP entre texto y binario. En XF 2.3, hemos dejado obsoletos los métodos \XF\Util\Ip::convertIpStringToBinary y \XF\Util\Ip::convertIpBinaryToString en favor de los nuevos métodos \XF\Util\Ip::stringToBinary y \XF\Util\Ip::binaryToString. Los nuevos métodos hacen uso de las funciones PHP inet_pton e inet_ntop, que son más fiables y no dan lugar a ambigüedades potencialmente inseguras.

Si utiliza los métodos obsoletos en un complemento, los nuevos métodos deberían funcionar como un reemplazo directo en la mayoría de los casos. Sin embargo, hay que tener en cuenta algunas advertencias. Los nuevos métodos no intentarán manejar situaciones en las que la dirección IP ya haya sido convertida al formato de destino, y lanzarán una excepción si se les pasa una dirección IP inválida por defecto. Puede pasar false como último argumento para devolver false en lugar de lanzar una excepción. El método \XF\Util\Ip::binaryToString también mantiene el soporte para la expansión de direcciones IPv6 cuando sea deseable.
 

Soporte para cadenas de clase​

Desde XF 2.0, hemos hecho un uso extensivo de los "nombres cortos" de clase para expandir los nombres de clase y asociar objetos relacionados, como entidades y buscadores. Aunque conveniente, muchas herramientas modernas extremadamente útiles no entienden esta convención, necesitando soluciones como la generación avanzada de metadatos PhpStorm o extensiones personalizadas para herramientas de análisis estático.

En XF 2.3, ahora soportamos el uso de nombres de clase completamente cualificados en todos los lugares donde se soportan nombres cortos. Esto incluye la obtención de entidades, buscadores, repositorios y otros objetos, así como la definición de metadatos como relaciones de entidad y comportamientos. Cuando se utilizan nombres de clase completamente cualificados, los IDEs son más capaces de manejar refactorizaciones como renombramientos de clases, y los analizadores estáticos son más capaces de determinar qué objetos son devueltos por métodos de contenedor y fábrica.

PHP:
use XF\Entity\User;

// ...

$user = \XF::app()->find(User::class, 1);

// ...

$structure->relations = [
    'User' => [
        'entity' => User::class,
        'type' => self::TO_ONE,
        'conditions' => 'user_id',
        'primary' => true,
    ],
];
 

Actualizaciones de las etiquetas <time>: formato de fecha abreviado​

Mientras desarrollábamos lo que ahora es el estilo de XenForo 3, hicimos algunas mejoras en la salida HTML de las etiquetas <time> (que se muestran cuando se emplea la etiqueta <xf:date> en la sintaxis de la plantilla de XenForo).

Aunque esta característica no se usa activamente en la versión 2.3, no cambia la apariencia de la salida de la plantilla, así que en lugar de echar atrás los cambios, los hemos dejado en esta versión.

¿Qué hace realmente?

En XenForo 2.2, las etiquetas de tiempo se muestran así:

HTML:
<time datetime="2023-11-15T09:49:23+0000" data-time="1700041763"
   data-date-string="Nov 15, 2023" data-time-string="9:49 AM"
   title="Nov 15, 2023 at 9:49 AM">51 mins</time>

A continuación, se actualiza con Javascript para mantener la hora relativa al presente.

Para el nuevo estilo, queremos tener la capacidad de mostrar una cadena de fecha corta cuando el espacio es limitado, por lo que hace 51 minutos se mostraría como 51m. Para ello, incluimos un nuevo atributo data-short que contiene el formato de fecha/hora abreviado.

HTML:
<!-- 2m (2 minutes ago) -->
<time datetime="2023-11-15T10:43:14+0000" data-timestamp="1700044994"
    data-date="Nov 15, 2023" data-time="10:43 AM"
    data-short="2m" title="Nov 15, 2023 at 10:43 AM">2 minutes ago</time>

El mismo Javascript que actualiza la salida principal también actualiza el atributo data-short con el formato corto actual.

Otros ejemplos:

HTML:
<!-- 13h (13 hours ago) -->
<time datetime="2023-11-14T21:00:23+0000" data-timestamp="1699995623"
    data-date="Nov 14, 2023" data-time="9:00 PM"
    data-short="13h" title="Nov 14, 2023 at 9:00 PM">Yesterday at 9:00 PM</time>

<!-- 2d (2 days ago) -->
<time datetime="2023-11-12T22:46:15+0000" data-timestamp="1699829175"
    data-date="Nov 12, 2023" data-time="10:46 PM"
    data-short="2d" title="Nov 12, 2023 at 10:46 PM">Sunday at 10:46 PM</time>

<!-- Sep 14 (September 14 this year) -->
<time datetime="2023-09-14T14:50:24+0100" data-timestamp="1694699424"
    data-date="Sep 14, 2023" data-time="2:50 PM"
    data-short="Sep 14" title="Sep 14, 2023 at 2:50 PM">Sep 14, 2023</time>

<!-- Nov '18 (November 12 2018) -->
<time datetime="2018-11-12T15:26:22+0000" data-timestamp="1542036382"
    data-date="Nov 12, 2018" data-time="3:26 PM"
    data-short="Nov '18" title="Nov 12, 2018 at 3:26 PM">Nov 12, 2018</time>

Naturalmente, estos formatos de fecha cortos se integran con el sistema de idiomas y frases, de modo que si 2m no significa 2 minutos en su idioma, es libre de editar la salida del mismo modo que puede hacerlo para el formato de fecha largo.

Por defecto, cuando se muestra una fecha de un año anterior al actual, el formato corto excluye el día del mes (Nov '22 M 'y en lugar de Nov 15, '22 M j, 'y), pero si desea incluirlo, puede hacerlo con un formato de fecha personalizado como M j 'y.

1700277570600.png


Así que, aunque no lo verás realmente en uso en 2.3, lo hemos dejado para que los diseñadores de CSS y JS emprendedores puedan hacer uso de él como mejor les parezca.
 

Nombres de plantillas en la salida HTML​

Ver una página de XenForo HTML y tratar de averiguar cómo se construyó, cuando puede contener fragmentos de muchas plantillas diferentes puede ser un reto.

O al menos, lo era.

Mientras que anteriormente hemos emitido un atributo data-template en la etiqueta <body> para ayudar a los desarrolladores y diseñadores a identificar la plantilla de contenido principal en uso, ahora hemos ampliado el sistema considerablemente.

Ahora, al activar la opción Incrustar nombres de plantillas en HTML de la sección Opciones de apariencia, su salida HTML incluirá atributos data-template-name que facilitan la identificación de la plantilla responsable de la parte concreta de la página que está inspeccionando.

1700277803579.png


Estos atributos sólo se muestran a los administradores autenticados.

HTML:
<html data-template-name="PAGE_CONTAINER" id="XF" lang="en-US" dir="LTR" data-xf="2.3" data-app="public" ...>

HTML:
<div data-template-name="thread_view" class="block block--messages" ...>

Estos atributos data-template-name no forman parte de las plantillas en sí, sino que son añadidos por el renderizador de salida final, por lo que no tienes que preocuparte de mantenerlos actualizados, o de desordenar tu experiencia de edición de plantillas.

En la práctica, los atributos data-template-name se añaden a la etiqueta HTML renderizada más externa de cada plantilla. Hay un puñado de casos en los que hay contenido en una plantilla antes de una etiqueta HTML, en cuyo caso el renderizador mostrará ese contenido antes de la etiqueta etiquetada, pero seguirá siendo mucho más fácil identificar la plantilla responsable que antes.

El valor del atributo data-template-name no se limita únicamente a los nombres de las plantillas. En los casos en que la salida proceda de una macro de plantilla, el valor del atributo incluirá tanto el nombre de la plantilla como el de la macro.

HTML:
<article data-template-name="post_macros::post" class="message message--post" ...>

1700278018109.png


Tenga en cuenta que, cuando están activadas, estas etiquetas data-template-name sólo se muestran a los administradores autenticados, por lo que no debe confiar en ellas como selectores CSS, a diferencia del selector original body[data-template], que puede utilizarse sin problemas.

Hemos utilizado data-template-name en lugar de reutilizar data-template como se utiliza en la etiqueta <body> para evitar cualquier posible colisión CSS donde el estilo en la página se ha unido al atributo data-template, aunque probablemente utilizaremos data-template para esta función en XenForo 3, y moveremos el atributo data-template de la etiqueta <body> a la etiqueta <html> con un nombre más descriptivo como data-content-template o algo así...
 

AbstractCollection método nth​

En respuesta a una sugerencia reciente, hemos implementado la posibilidad de devolver fácilmente el elemento nth de una AbstractCollection.

El caso de uso más común para esto va a ser la extracción de elementos indexados específicamente de una colección de Entidades devueltas por una consulta.

Por ejemplo, si se consulta una colección de entradas y se desea acceder a la tercera entrada de la colección devuelta, basta con llamar a ->nth(3).

PHP:
$posts = $finder->fetch();
$third = $posts->nth(3);
$fifteenth = $posts->nth(15);
 

Eliminador inteligente de caché Javascript​

¿No es molesto cuando se desarrolla javascript tener que forzar un hard refresh cada vez que se hace un cambio en el código?

Nosotros también lo pensamos, así que hemos creado un nuevo eliminador de caché inteligente, que se activa cuando utilizas la opción fullJs config.php.

Sin entrar en demasiados detalles, cada carga de página contendrá la última versión de tus archivos javascript sin tener que hacer un hard refresh, mientras se mantiene la caché de cualquiera que no haya cambiado desde la última carga de página.

Son los pequeños detalles...
 

XF.createElement

Esto no es estrictamente un reemplazo para cualquier funcionalidad jQuery, pero acorta algunos bastante tedioso vainilla Javascript que se utiliza comúnmente.

Considere el siguiente Javascript:

JavaScript:
const el = document.createElement('input')
el.type = 'text'
el.name = 'title'
el.value = 'Hello, world'
parentEl.appendChild(el)

Eso es escribir un montón de elementos, ¿verdad?

Con 2.3 y XF.createElement(), ahora podemos hacer lo siguiente:

JavaScript:
const el = XF.createElement('input', {
    type: 'text',
    name: 'title',
    value: 'Hello, world'
}, parentEl)

Aquí, en una sola declaración, creamos el elemento input, le asignamos un montón de propiedades y lo anexamos al parentEl. Ni siquiera necesitamos asignar el valor de retorno a una variable si no es necesario para el código posterior.

Tanto el objeto de propiedades como el nodo al que anexar el elemento son parámetros opcionales, aunque si no vas a anexar el elemento al DOM, sería inútil no asignar el valor de retorno a una variable 🤔.

El objeto properties también admite un único nivel de anidamiento, por lo que también puedes hacer algo como lo siguiente:

JavaScript:
const el = XF.createElement('span', {
    className: 'spanny-spanny-moo-moo',
    title: 'This is a span',
    dataset: {
        foo: 1,
        bar: 2
    },
    style: {
        color: 'red',
        fontWeight: 'bold'
    }
}, parentEl)

También existe una propiedad de atributos para casos especiales, cuyos valores se establecerán mediante el.setAttribute(name, value) si necesita utilizarla.
 

Cambios en la sintaxis de las macros de plantilla​

Si editas plantillas usando un IDE, probablemente harás uso del panel de esquema de estructura para navegar rápidamente entre las secciones de la plantilla. Realmente ayuda cuando el IDE te da un resumen útil de los elementos, y cuando se trata de macros de plantilla XenForo, que realmente no ha sido el caso hasta la fecha.

Aquí hay una vista mayormente colapsada de la plantilla pública PAGE_CONTAINER de XenForo 2.2 en el panel de estructura de PhpStorm y en el panel de esquema de código de Visual Studio:

1700279026706.png
1700279052629.png


Bastante inútil, ¿verdad?

La razón de esto es que estas vistas de árbol ignoran el atributo de name en las etiquetas en su vista de resumen. No me hagas hablar de lo estúpido que es esto, especialmente cuando el atributo de name es de importancia crítica para elementos como <input>, pero es lo que es.

1700279219422.png


No podemos hacer nada con <input>, <select> o <textarea> pero podemos hacer algo con <xf:macro> para que tenga una representación más útil en la vista de esquema.

<xf:macro name="m" /> <xf:macro id="m" />​

Es un cambio bastante simple, y sólo implica cambiar el atributo name por un atributo id. Esto puede causar que tu IDE se queje de que la misma etiqueta id está siendo usada en múltiples elementos, pero esto es seguro de ignorar, ya que esos atributos no se mostrarán en el HTML final donde importa.

Cambiemos la plantilla PAGE_CONTAINER para usar <xf:macro id...> en lugar de <xf:macro name...> y veamos cómo cambia la vista del esquema.

1700279571956.png
1700279597162.png


¿No es mejor así?

El atributo name todavía está disponible pero obsoleto, así que debería actualizar sus plantillas.

<xf:macro template="t" name="m"> ➡ <xf:macro id="t::m" />​

También hemos dejado obsoleta la sintaxis <xf:macro template="template-name" name="macro-name" />, en favor del formato id="template-name::macro-name", que de nuevo ayuda a ver un esquema razonable de la estructura.

1700279731168.png
 

Mensajes directos​

Ya lo hemos mencionado en otro lugar, pero hemos tomado la decisión de cambiar el nombre de "Conversaciones" a "Mensajes directos". Esta terminología es más familiar para la mayoría de los usuarios de Internet y tiene un mejor acrónimo "DM". A lo largo de los años, la gente ha seguido llamándolos "PM" para mensajes personales o "PC" para conversaciones personales y esto puede ser confuso para aquellos que no están familiarizados con el software.

En XF 2.3, este cambio es totalmente visual. Todas las referencias de código, nombres de clases y plantillas siguen siendo los mismos. Hay nuevas rutas canónicas llamadas mensajes-directos y mensajes-directos/respuestas, pero todas las rutas existentes para conversaciones y conversaciones/mensajes redirigirán correctamente a las nuevas rutas. Sólo han cambiado las frases.

Así que no hay cambios que hacer si actualmente tienes complementos que tocan conversaciones y todo debería seguir funcionando. Pero pensamos que merecía la pena aclararlo.

Es posible que hagamos cambios más extensos en una versión futura y, si ese es el caso, avisaremos con suficiente antelación.
 
Volver
Arriba