Tipos de bloques

Cada bloque en Chinaski, desde una franja de llamado a la acción hasta una tabla de precios, pertenece a un tipo, el vocabulario que le dice al sistema qué campos acepta y cómo se renderiza. Esta página cubre el registro de tipos en sí: los tipos integrados que vienen de fábrica, cómo registrar los tuyos propios y las reglas que mantienen a ambos sincronizados.

El registro

Los tipos de bloques viven en una tabla administrada, la única fuente de verdad sobre qué tipos existen. Lo que decide el registro:

• Si un bloque de ese tipo puede crearse (crear un bloque requiere que su tipo esté registrado; cambiar un bloque existente a un tipo no registrado se rechaza).
• Qué aparece en el editor de bloques, las pantallas de la Library y los menú desplegable(s) de tipo de autoría en el resto del admin.
• Qué tipos de bloques puede referenciar un archivo de importación de bloques.

Al arrancar, el registro se mantiene sincronizado con el vocabulario incluido en el software: los tipos estándar se vuelven a insertar, conservando cualquier edición que hayas hecho en sus etiquetas o descripciones. El conjunto incluido, listado alfabéticamente en la pantalla Block Types, es deliberadamente amplio:

accordion, audio, button_group, callout, citations, code_block, columns, cta, divider, embed, faq, feature_grid, form, gallery, grid, heading, hero, image, logo_bar, newsletter, page_list, pricing_table, promo, quote, schedule, spacer, stat, table, team, testimonial, text, timeline, video

Crear un tipo de bloque personalizado (el formulario)

En la pantalla Block Types (solo para administradores), el formulario Register Custom Block Type toma tres campos:

• Name: solo letras minúsculas, dígitos, guiones y guiones bajos; este se convierte en el identificador del tipo (lo que vive en la columna type y en los formularios).
• Label: el nombre legible usado en las listas (por defecto es la forma corta en mayúsculas; puedes sobrescribirla).
• Description: texto libre opcional.

Al enviarlo, el tipo se registra al instante; no hay archivos de renderizado que agregar en el servidor. Los mensajes flash del sistema hacen el resto:

• “Block type registered” si ambos archivos requeridos ya existen (ver abajo).
• El mensaje flash te dice con precisión qué rutas de archivos faltan. El tipo registrado permanece en el registro, simplemente no renderizará ni mostrará su formulario de admin hasta que existan esos dos archivos.

Qué necesita un tipo personalizado

Dos archivos, colocados por ti:

• builder/block_templates/<type>.tt, la plantilla del builder: es lo que se renderiza en el site (ver Blocks in Themes para el contrato de variables).

• templates/admin/blocks/types/<type>.html.ep, el formulario de admin: qué campos expone el editor del bloque (lo que suele significar sus campos planos, o un editor de filas JSON para datos repetitivos al estilo grid/gallery/columns).

• El registro no mueve los bloques. El tipo determina qué campos aparecen en el formulario de admin; la plantilla del builder decide el renderizado, y el nombre del bloque, no su tipo, es lo que referencian los {{block:name​}}.

• Los tipos personalizados no reciben scaffolding. El formulario de registro te indica qué dos rutas de archivos crear, pero nunca fabrica las plantillas por ti.

Eliminar un tipo

En la pantalla hay dos clases de tipos de bloques, y las dos categorías se comportan de manera distinta:

• Los tipos integrados no se pueden eliminar. El proceso de arranque vuelve a sembrar la lista estándar en cada inicio, y el contenido existente de un tipo integrado no puede quedarse editable-less.
• Los tipos personalizados se pueden eliminar, pero solo si están vacíos. Cualquier bloque que aún esté en el tipo impide la eliminación con un error (“blocks of this type still exist”); primero debes enviar a la papelera o destruir cada bloque de ese tipo (luego, desde la pantalla Blocks, solo los tipos personalizados registrados pueden eliminarse/quitarse del registro).

Por lo tanto, la pantalla del registro se mantiene limpia: cada entrada en ella es un tipo activo al que los formularios de admin referencian, o uno personalizado listo para eliminar una vez vaciado.

Agregar un tipo sin programar bloques desde cero

Crear una variante de un tipo existente, compartiendo los mismos campos pero con otro nombre y otra intención de estilo, es legítimo:

1. Registra el nuevo nombre en la pantalla Block Types.
2. Copia la plantilla de bloque del builder (<name>.tt) y el partial del formulario de admin (<type>.html.ep) del tipo más cercano a lo que necesitas; esos dos archivos copiados son el mismo contrato.
3. Ajusta los campos del formulario y el HTML de la plantilla según sea necesario.

El mismo cuidado aplica si vienes de fuera del conjunto integrado (ver la sección de la página Blocks sobre qué campos aceptan HTML vs. auto-escape).

La versión corta

Los tipos integrados son el vocabulario fijo para el que se construyen las plantillas de bloques y los formularios de admin; el registro decide qué tipos existen; los administradores pueden registrar los suyos (copiando a mano dos archivos de plantilla), y un tipo personalizado puede eliminarse una vez vaciado, mientras que los integrados permanecen para siempre porque la semilla los ejecuta en cada arranque.