logo

Extra Block Types (EBT) - Nueva experiencia con Layout Builder❗

Extra Block Types (EBT): tipos de bloques con estilo y personalizables: Presentaciones de diapositivas, Pestañas, Tarjetas, Acordeones y muchos más. Configuraciones integradas para fondo, DOM Box y plugins de JavaScript. Experimenta hoy el futuro de la construcción de diseños.

Módulos de demostración EBT Descargar módulos EBT

❗Extra Paragraph Types (EPT) - Nueva experiencia con Paragraphs

Extra Paragraph Types (EPT): conjunto de módulos basado en párrafos de forma análoga.

Módulos de demostración EPT Descargar módulos EPT

Scroll
18/05/2025, by Ivan

El módulo JSON:API expone las revisiones de entidades como versiones de recursos, de una manera inspirada en la RFC5829: Tipos de relaciones de enlace para navegación de versiones simples entre recursos web.

Limitaciones actuales:

El soporte de revisiones no es parte oficial de la especificación JSON:API. Sin embargo, se están desarrollando varios “perfiles” (tampoco son parte oficial aún de la especificación, pero ya están comprometidos en JSON:API v1.1) para estandarizar cualquier comportamiento personalizado que el módulo JSON:API haya desarrollado (todos aún cumplen la especificación).

De este modo, el módulo JSON:API debería ser lo más compatible posible con otros sistemas y minimizar los “drupalismos” que un desarrollador necesitaría conocer al trabajar con una implementación de JSON:API.

Una “versión” en el módulo JSON:API es cualquier revisión que haya sido o sea una revisión predeterminada. No todas las revisiones se consideran una “versión”. Las revisiones que no están marcadas como “revisión predeterminada” se consideran “copias de trabajo”, ya que normalmente no están disponibles públicamente y son las revisiones sobre las que se aplica la mayoría del trabajo nuevo.

Cuando el módulo Content Moderation está instalado, es posible que la revisión predeterminada más reciente no sea la última revisión.

Solicitar una versión de recurso se hace mediante un parámetro de consulta en la URL. Tiene la siguiente forma:

            identificador-de-versión
                  __|__
                 /     \
?resourceVersion=foo:bar
                 \_/ \_/
                  |   |
  negociador-de-versión  |
               argumento-de-versión

Un identificador de versión es una cadena con la información suficiente para cargar una revisión en particular. El componente negociador de versión nombra el mecanismo de negociación para cargar una revisión. Actualmente, puede ser id o rel. El negociador id recibe como argumento de versión el ID de revisión deseado. El negociador rel recibe como argumento de versión la cadena latest-version o la cadena working-copy.

En el futuro podrían desarrollarse otros negociadores, por ejemplo, uno basado en timestamp o en workspaces.

Para ilustrar cómo se solicita una revisión específica de una entidad, imagina un nodo que tiene una revisión “Publicada” y una revisión posterior en estado “Borrador”.

Usando JSON:API, se podría solicitar el nodo “Publicado” usando: /jsonapi/node/page/{{uuid}}?resourceVersion=rel:latest-version.

Para previsualizar una entidad que aún está en proceso (es decir, la revisión “Borrador”), se podría solicitar: /jsonapi/node/page/{{uuid}}?resourceVersion=rel:working-copy.

Para solicitar un ID de revisión específico, se puede usar: /jsonapi/node/page/{{uuid}}?resourceVersion=id:{{revision_id}}.

Aún no es posible solicitar una colección de revisiones. Esto está en desarrollo en la issue #3009588: Proporcionar un recurso de colección donde se pueda obtener el historial de versiones (version-history, predecessor-version y successor-version link relations).

Artículo de la Documentación de Drupal.