` with the `.cta` class. The editor will check to see if this element matches our template, and if it does, it will initialize it.
Our final code will look like this:
```javascript
CKEDITOR.plugins.add( 'cta_widget', {
// Widget plugin dependency
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]',
}
},
// Not necessary, this is configured in Drupal, but is good to have it here as well.
allowedContent:
'h3(cta__title); div(cta__text, cta__link)',
// Not mandatory but allows widget recongnition on copy & paste.
upcast: function( element ) {
return element.name == 'section' && element.hasClass( 'cta__widget' );
},
});
// This is needed in Drupal
editor.ui.addButton('cta_widget', {
label: 'CTA Widget',
id: 'cta_widget',
command: 'cta_widget',
icon: this.path + 'icons/cta.png'
});
}
});
```
### When is a widget a better option than a paragraph?
The main thesis of this article is that **CKeditor widgets can replace paragraphs and fields in some cases**. This may sound bad at first glance: why abandon the capabilities of Drupal 8 to delegate them to a text editor? Aren't there precisely the fields or the paragraphs to avoid the temptation to solve everything in the editor? Won't it introduce more long-term maintenance problems than it eliminates in the short term?
It should be stressed that you should only consider this option in **some very controlled cases** where the following requirements are met:
1. The **HTML piece to be inserted is totally aesthetic** in nature, that is, it does not depend on or interact in any way with Drupal.
- Do you need to access the logged-in user, make a reference to an entity, access translations? Forget about widgets.
- Is it a beautiful or different way of presenting information that could perfectly be shown without any style? **Is it pure front-end?** Then it is a good candidate.
2. **No major changes in its HTML structure are expected**, at least in the medium term: there may be styling changes, but the HTML will remain intact.
If a component meets both requirements, it is highly recommended to consider it as a widget, as it introduces several improvements over the paragraphs.
- **Avoid overloading** our projects with unnecessary fields and paragraphs.
- It provides the editor user with a **real WYSIWYG experience** in which they can check in real time what the result of their work is. This is usually one of the main complaints that editors have about Drupal.
- It allows for **easier and more immediate markup**. To style the HTML and CSS of a paragraph sometimes it is necessary to intervene at several levels, using several templates, hooks or field fomatters. With a CKeditor widget, the markup is written directly in a template. In a certain sense (I repeat: in a certain sense), it is closer to the Component-Driven Design paradigm of Vue, React or Angular.
- Thanks to CKEditor's Allowed Content Rules system, it allows to **define with granularity the HTML allowed and forbidden** in each editable zone in a more detailed and individualized way than Drupal's fields would allow. This allows us to give more power to the editor without introducing the risk of malformed or faulty HTML.
- We haven't had time to go into it in depth, but it **is possible to expose widget configuration options** using the dialog API. This way, we could expose options like adding margin or padding, removing certain editable areas, and so on.
In short, CKEditor widgets are a valid alternative to some component types that we usually solve with Drupal tools like Paragraphs. In the case of purely visual, small components with stable requirements, widgets bring many advantages to the end user and are much easier to develop and maintain.
[Paragraphs (Drupal module)](https://metadrop.net/en/articles?text=Paragraphs%20%28Drupal%20module%29)
[CKEditor](https://metadrop.net/en/articles?text=CKEditor)
[Site building](https://metadrop.net/en/articles?text=Site%20building)
[HTML](https://metadrop.net/en/articles?text=HTML)
[JavaScript](https://metadrop.net/en/articles?text=JavaScript)
[Module development and third-party integrations with Drupal](https://metadrop.net/en/services/drupal/integrations " See Module development and third-party integrations with Drupal")
Metadrop connects Drupal to your CRM, ERP, payment, and marketing stack — Salesforce, Microsoft Dynamics, BBVA virtual POS, Workday, and Keepeek — with custom modules and secure, GDPR-compliant APIs.
See more