Creating Drupal's Inline Formatter Field

What is the Inline Formatter Field?

The Inline Formatter Field module "allows site builders to template and style entities with a field." It is basically a boolean field that when checked will display whatever is entered on the admin managed display tab for the field. The field admin screen allows for any HTML, Twig, or Drupal Tokens to be entered which will then display on the front end of the page when the field is checked.

The start of the module

The module was first started while I was building a site, specifically I needed to render a block of HTML conditionally based on a field entered by the content authors. There were some ways of doing this without a need of a module, creating a Twig template for the field.

The problem was that this pattern was repeated multiple times for different fields and different content types. The line between what is a template and what is a file for individual instances was removed, the meaning of a theme was blurred to be site specific files.

Other theming and site building issues arose. What if a field could be rendered in different positions depending on content, or what if a field rendered in two places on the same page, but is displayed separately within each instance? The same problem exists, I hope you like making Twig templates and dealing preprocess functions to inject variables. A few of these are not bad, and even expected for any site build. But, after a while you begin to wonder if you are building a site and creating a theme or are you just code the whole site. What is the whole point of using a CMS if everything is a one off?

This is why I built the Inline Formatter Field module. I wanted to keep what was a theme in theme, and what was a part of the site (one offs) in the site and out of the theme. I needed a way to code the one offs as a site admin without going into the theme. This sounded like a use for a field, especially for the first problem I described above.

I created a field, a boolean, which had a settings form for the field format that allowed admins to enter custom HTML and Twig. How? Buy creating a textarea field and using the value entered there as the #template in a Drupal inline_template element. This works perfectly!

Improvements

The first version was just that simple. Maybe an argument could have been made that it did not need to be a module on its own at this point. This was not perfect like I might have thought at the beginning. A few things needed to be done to be worthy of being added to Drupal.org.

First, the UI. Entering code into a plain textarea just plain stinks. It is hard to read and edit. Enter Ace Editor, a JavaScript library that turns a plain textarea into an usable code editor. It even has settings for modes and themes. This makes using the module much better!

The next thing is that the inline_template component is inherently dangerous as any HTML and Twig, including <script> could be entered. This is a big security hazard. In order to bring awareness to potential problems that could arise from this, a new permission was created for the module, which should only be given to trusted roles.

The next thing I wanted was to be able to use Drupal Tokens inside the templates. This was easy to do as all that needed to be done was to run the Token replace method passing in the template and the entity as data.

This was good for the official release on Drupal.org. But one thing was still missing, a common pattern of using the field to display the full content type emerged. What was the point of the field if it was going to always be checked? And, if it was going to manage the full entity display, isn't there a better way to do that? There is.

In version 2 of the module I added a submodule that allows you to omit the field part of that pattern. Instead you can turn on the Inline Formatter Display submodule. Doing this allows you to go to the managed display tab of any entity and check the box "Use Inline Formatter Display" which will allow you to enter the HTML and Twig for the full entity bundle.

Essentially, we are moving what would have been a twig template in the theme and managed by the theme into the site's configuration. Now this is what I was after!

Conclusion

If you find that you are constantly creating child themes in order to create templates for specific fields and entity bundles, then I suggest you try this module. It saves time managing twig files, and keeps items not theme related out of the theme. If you give this a try let me know what you think! Also, for any suggestions or bugs please report your issues.