` con la clase `.cta`. El editor comprobará si este elemento coincide con nuestro *template* y, de ser así, lo inicializará.
Nuestro código final quedaría así:
```javascript
CKEDITOR.plugins.add( 'cta_widget', {
// Dependencia del plugin "widget"
requires: 'widget',
icons: 'cta_widget',
init: function( editor ) {
editor.widgets.add( 'cta_widget', {
template:
'
' +
'
Insert title here...
' +
'
Insert your text here
' +
'
' +
'
',
editables: {
title: {
selector: '.cta__title',
allowedContent: 'strong em',
},
content: {
selector: '.cta__text',
allowedContent: 'strong em mark br; a[!href]',
},
link: {
selector: '.cta__link',
allowedContent: 'a[!href]',
}
},
// No es necesario, se configura en Drupal, pero es bueno mantenerlo por si cambia en el futuro.
allowedContent:
'h3(cta__title); div(cta__text, cta__link)',
// No es obligatorio pero permite reconocer widgets en copy & paste.
upcast: function( element ) {
return element.name == 'section' && element.hasClass( 'cta__widget' );
},
});
// Imprescindible en Drupal
editor.ui.addButton('cta_widget', {
label: 'CTA Widget',
id: 'cta_widget',
command: 'cta_widget',
icon: this.path + 'icons/cta.png'
});
}
});
```
### ¿Cuándo y por qué es mejor un *widget* que un paragraph?
La idea principal de este artículo es que **los widgets de CKeditor** ***pueden*** **sustituir en algunos casos a paragraphs y fields**. Esto puede sonar mal de entrada: ¿por qué prescindir de las capacidades de Drupal 8 para delegarlas en un editor de texto? ¿No existen precisamente los campos o los paragraphs para *evitar* la tentación de solucionarlo todo en el editor? ¿No introducirá más problemas de mantenimiento a largo plazo de los que elimina en el corto?
Hay que insistir en que solo deberías considerar esta opción en **algunos casos** muy controlados en los que se cumplan los siguientes requisitos:
1. La naturaleza del componente a insertar es de **totalmente estética o visual**, es decir, no depende ni interactúa *de ninguna manera* con Drupal.
- ¿Necesita control de acceso, hacer una referencia a una entidad, acceder a las traducciones, etc.? Olvídate de los *widgets*.
- ¿Es una manera bonita o diferente de presentar una información que podría perfectamente mostrarse sin estilado alguno? **¿Es puro** ***front-end*****?** Entonces es un buen candidato.
2. **No se prevén grandes cambios en su estructura HTML,** al menos en el medio plazo: puede haber cambios de estilado, pero el HTML permanecerá intacto.
Si un componente cumple ambos requisitos, es **muy recomendable plantearlo como** ***widget***, ya que introduce varias mejoras sobre paragraphs o fields:
- **Evita la sobrecarga** de nuestros tipos de contenido con campos y paragraphs innecesarios.
- Proporciona al usuario editor una **verdadera experiencia WYSIWYG** en la que poder comprobar en tiempo real cuál es el resultado de su trabajo. Esto, además, suele ser una de las principales quejas que los editores tienen sobre Drupal.
- Permite un **marcado más sencillo e inmediato.** Para estilar el HTML y CSS de un paragraph en ocasiones es necesario intervenir a varios niveles, usando varios *templates,* *hooks o* *field fomatters*. Con un *widget* de CKeditor, el marcado se escribe directamente en un template. En un cierto sentido (repito: *en un cierto sentido*), se acerca más al paradigma del diseño guiado por componentes (Component-Driven Design) de Vue, React o Angular.
- Gracias al sistema de Allowed Content Rules de CKEditor, permite **definir con granularidad el HTML permitido y prohibido** en cada zona editable de un modo más detallado e individualizado de lo que permitirían los campos de Drupal. Ello nos permite darle más poder al editor sin introducir el riesgo de HTML malformado o erróneo.
- No nos ha dado tiempo a profundizar en ello, pero **es posible exponer opciones de configuración del widget** usando la API de *dialog*. De este modo, se podrían exponer opciones como añadir margin o padding, eliminar ciertas zonas editables, cambiar el color de fondo, etcétera.
En resumen, los *widgets* de CKEditor son una alternativa para algunos tipos de componente que solemos solucionar con herramientas de Drupal. En el caso de componentes puramente visuales, pequeños y con requisitos estables, los *widgets* aportan muchas ventajas de cara al usuario final y son mucho más fáciles de desarrollar y mantener.
[Paragraphs (módulo de Drupal)](https://metadrop.net/es/articulos?text=Paragraphs%20%28m%C3%B3dulo%20de%20Drupal%29)
[CKEditor](https://metadrop.net/es/articulos?text=CKEditor)
[Site building](https://metadrop.net/es/articulos?text=Site%20building)
[HTML](https://metadrop.net/es/articulos?text=HTML)
[JavaScript](https://metadrop.net/es/articulos?text=JavaScript)
[Desarrollo de módulos e integraciones de terceros con Drupal](https://metadrop.net/es/servicios/drupal/integraciones " See Desarrollo de módulos e integraciones de terceros con Drupal")
Metadrop conecta Drupal con tu CRM, ERP, pasarela de pago y stack de marketing — Salesforce, Microsoft Dynamics, TPV virtual de BBVA, Workday y Keepeek — mediante módulos personalizados y APIs seguras y conformes con el RGPD.
Ver más