Expanding On Site Building With Components To Truly Achieve No-code Drupal

[00:00:00] Welcome to Expanding on Site Building with Components to Truly Achieve No-Code Drupal. I'm Peta Hoyes, chief operating officer of Tag1 Consulting, and I'll be presenting with Fabian Franz, our vice president of software engineering. Many of you know Fabian from his performance and scalability expertise and his contributions to Drupal over the years.

[00:00:34] For those of you who aren't familiar with Tag1, we work with many different technologies, but we happen to be the number two all-time contributor to Drupal, with a very large concentration of core contributors. We're an enterprise partner of the Drupal Association, and we donate full-time senior resources to help run drupal.org, its infrastructure, and its tooling so the community can build Drupal. If your company profits from Drupal, consider supporting the project financially, either by funding the association or a module maintainer, so Drupal continues to thrive.

[00:01:16] To learn more about components, check out our Tag1 Team Talks podcast and vlog. We also cover other innovations there, including real-time collaboration and Goose, our open source load testing framework.

[00:01:40] Today we'll cover the what and the why of low-code and no-code technology, and where Drupal sits on that spectrum. Then I'll hand over to Fabian for the second part, where he'll talk about how we're closing the gap between the perception and the reality of no-code Drupal. He'll demo the Tailwind CSS framework and talk through some of the challenges of Drupal's theming system and the solutions he's been working on.

[00:02:20] For those who don't know what low-code and no-code are, it's simply a software development approach that requires little or no coding to build applications and processes. A low-code or no-code platform uses visual interfaces, simple logic, and drag and drop instead of extensive coding. The idea isn't new; it's been around for twenty-plus years. The benefit is being free from having to depend on software engineering resources, and there are benefits to the engineers themselves. We get to unblock non-technical users like editors, marketers, and designers, increase their productivity, and reuse things instead of building everything from scratch.

[00:03:51] Low-code and no-code also simplify stages of the development process like debugging, testing, deploying, and the almighty reverting. The market implications are large. Internal applications can improve a company's core functions like HR, sales, marketing, and finance. Customer-facing apps can have rich user interfaces and mobile capabilities. And a lot of legacy applications can be replaced or upgraded with more modern low-code or no-code approaches.

[00:04:58] Drupal has been around a long time, and it has always been low-code or no-code, even if it's rarely recognized for that the way tools like Wix, Squarespace, or WordPress are. Site building is the perfect example. It's no-code development: getting Drupal up and running and configuring options quickly to build a functional site. That covers building content types and fields, creating custom lists with Views, specifying access controls, roles, and permissions, and setting up navigation and menus.

[00:05:51] Out of the box, Drupal is pretty no-code. But as soon as you want to do more, you have to write some code. That's the case with Layout Builder, which was a wonderful addition in Drupal 8. It becomes low-code rather than no-code when you have to customize or override templates and layouts, or make one-off landing pages that aren't tied to a content type. We all know a lot of people add custom CSS and HTML in the WYSIWYG editor to get control over the layout and styling of pages. End users are hacking things to get them the way they want, and that highlights the problem: non-technical users need control that Drupal didn't provide until now.

[00:07:06] On one hand, Drupal is extremely powerful, secure, and customizable. The downside is that, compared to other low-code and no-code tools, it's complicated, which is why people don't immediately associate Drupal with low- and no-code. There are many ways to do one thing in Drupal, with trade-offs you might not be aware of without experience. Business users can have anything they want; there's a module, or five, for it, plus countless integrations, custom workflows, admin UIs, and easy ways to build Views into data buried deep in database tables that most of us would cringe at querying by hand.

[00:08:13] Drupal is, in my opinion, the ultimate cross-functional collaboration tool for every kind of subject-matter expert: marketers, editors, copywriters, designers, developers, and stakeholders. Unfortunately, it has a steep learning curve when it comes to theming, which is not for the faint of heart. Cross-functional teams need to engage with their tools at their preferred level, whether that's no-code, low-code, or high-code.

[00:08:53] You can have a wonderful site with all your content types set up and everything working great, and then it just doesn't look as great as it works. Drupal's base themes are basic and look outdated. WordPress has a big commercial ecosystem where people are used to paying for plugins and themes, and those themes are good and usable. For Drupal, there aren't many good commercial themes, and custom theme development has been expensive and required a lot of expertise. Until now, it wasn't really possible to build a great theme without writing code. I'll hand it over to Fabian to explain how Drupal is closing that gap.

[00:10:33] Thanks, Peta. As Peta said, the base themes look outdated, even though Olivero and Claro are a big step in modernizing things. Older themes like Seven and Bartik were rough. I've tried commercial themes for Drupal several times and they've all been pretty bad, and custom theme development is expensive. On top of that, Drupal theming is genuinely complicated. Even a simple template like menu--main.html.twig makes me think, no way, this shouldn't be so complicated. A simple template should be simple.

[00:12:19] Fortunately, in 2021 we have a whole new world. There are new technologies like Vue, Alpine, and React, and Tailwind CSS is a real change for the industry. I know that because I've shown it to people who had no CSS experience, and using Tailwind they could style things nicely. That was always the goal of its founders. They even wrote a book, Refactoring UI, to give everyone a way to start theming. Alpine is a new kit on the block that makes interactivity simpler. And modern browsers make styling easier than ever; layouts that used to need complex CSS are now straightforward with flexbox and other features every browser supports.

[00:13:37] So what is Tailwind CSS? I define it as a styling language that bridges the gap between developers and designers, and my take is that everyone can learn it. Back-end developers can finally style things, and site builders can tweak and change things even without front-end experience. Designers, on the other hand, can finally constrain their layouts, because there's only a certain set of utility classes available. A designer can say, you're not going to choose the colors, I'm going to choose the colors, so there are no more one-offs. You build your own design system in Tailwind.

[00:14:41] How do you use it? Three simple steps: install the theme, tweak tailwind.config.js with your design system, your fonts, and your spacing, and then start your site. There's a great example at celebratedrupal.org, built with a completely open source Tailwind development theme, and it's worth checking out in action. Oliver Davies also did a Tailwind workshop recently where he rebuilt Bartik entirely in Tailwind and Vue. Using those utility classes, you can style everything.

[00:16:07] Let me do a little demo. We have a test component. If I want this background to be lighter, I put in a 300 value, and it's nicer. Now it's a little too dark, so let's make it a 500. Let's adjust the headers, and instead of red let's use a gray. You can see I'm not a designer and this is ugly, but you can see the potential. There's also a commercial offering, Tailwind UI. I'm all for open source, and there are lots of free components and a community around building things, but if you want to just buy something and use it, like in the WordPress world, you can purchase a Tailwind UI license. I'm not affiliated, I just like it, and you can use it as a learning tool.

[00:17:53] Here's a Tailwind UI example. If I edit it, we're looking at more complex code, but all I did was copy the sample over from the free Tailwind UI menu component, add a placeholder for the title and the image, and put it in a simple loop. There's a nice CodeMirror editor for the template. It takes a moment to load because I'm screen sharing. When I click preview, we see the menu, and when I hover and click, I can open a little user menu, and it's styled nicely. You don't need to know all the pain; you copy things and use them.

[00:20:02] My sister could do this. She used Drupal once, back in 2007, and built everything herself: the fields, the content types, a huge database. The project failed for two reasons, one being time, but the other was theming. If she'd had this tool, I bet she would have finished. That's the potential here. In the long run this is much simpler than learning all the CSS tricks. Even if you already know CSS, having something that always has the best browser support and the newest features, handling prefixing for you, is a real advantage. CSS and markup go together, and there was always an artificial separation. This removes it.

[00:21:53] If you're overwhelmed, it's a new language; give it time. You learned site building, you learned how to export configuration; you can learn this. The live preview really helps: you tweak it until it works. And for localized changes it's much easier, because CSS on projects that have grown over seven years or more becomes append-only. No one dares touch it or delete anything, because it could have side effects all over the site. That was one of the motivations for a utility-first approach.

[00:23:24] I've never seen a team disciplined enough to keep pure CSS consistent. You end up with ten different font sizes and thirty colors. There was a study of professional teams, including GitHub, with something like ten font sizes and a hundred different colors. Huge professional sites built by world-class teams have CSS that just isn't consistent. Tailwind gives you that consistency. Compared to Bootstrap, where every site wants to look the same, Tailwind is bring-your-own design system. Every design change is visible in code review, so if someone changes the design system, you'll know. As a gatekeeper you can make sure no new font size is introduced unless design asks for it.

[00:24:42] I was never able to review CSS and HTML in a code review; it was one parsing step too much. I can read PHP and JavaScript in my head and find logic errors, but not CSS. With Tailwind I finally can, and I can even picture how something will look. You can too, once you learn it a little. That's great for designers and developers. And components are great building blocks and design systems in their own right. Shout out to John Albin's session on Tailwind earlier this week, where he showed how to use CSS variables to build design systems. I'm still a Tailwind fan, but if that's not for you, there's another approach.

[00:25:53] The upside is you essentially never write CSS again; you can style a complete site without a single line of CSS by combining utility classes. The drawback is that Tailwind wants you to create HTML with classes, which means you need to control the markup, and that's a challenge for Drupal. Tailwind plus a decoupled front end is a dream combination, because you have full control of the markup, but that's not really low-code. React is nicely split into components but isn't no-code, so it's not for us today. If you do want simple React without the tooling, try Preact and HTM; it's the closest to low-code React you can get, and we use it in production.

[00:26:56] Controlling the markup in Drupal is a real problem. Dries has been saying since 2011 that he wants to control the markup, no divs everywhere, and Drupal keeps saying no. The render tree and theme system are a huge advantage, but it's really hard to control the markup in a logical way. I helped implement Twig in Drupal core, and the class attribute has made things easier, but I don't think it's enough. I don't want to lose people to Squarespace or WordPress just because theming is easier there. Someone builds a whole site with site building, and then theming ends it. That's sad, and we don't want that.

[00:27:57] Theme suggestions split the markup across many templates, which is another problem. Drupal has little snippets here and little components there; it's too granular. That comes from its history with PHPTemplate and theme functions, going back to Drupal 5. And a site builder can add new things arbitrarily, so a theme template always has to deal with that.

[00:28:37] Decoupled is front-end first; Drupal is back-end first. But we can make Drupal front-end first, so let's do that. One approach I presented at DrupalCon Amsterdam in 2019 was adding a data attribute to all the data passed to the theme system. It hasn't happened yet, but I've made progress on it. There's also UI Patterns, which is very Pattern Lab heavy, so you can create a theme completely outside of Drupal and integrate it via UI Patterns. There's a great presentation on that from the last DrupalCon, and we'll be integrating with UI Patterns too, thanks partly to Component Blocks by Larowlan. The drawback is you have to create YAML files for every theme hook, which takes you back out of site building.

[00:29:46] The first small step was on the Tern project, which Michael discussed in his session on Monday. We gave it an opinion and added classes directly to Views fields, field groups, and formatters. There are three ways to integrate with Layout Builder in this more naive approach. We created components like the Tern tagline component, we added classes you can apply directly around a Layout Builder element, and we added styles, where you configure your content block, add a class, click update, and it's styled.

[00:30:25] Let me talk about layout classes. You get amazing flexibility, and you can decouple the inner content from the outer presentation, which is suitable for translation. You can add HTML everywhere in the blocks, but then when you translate, you have to do everything again. That's an advantage of Layout Builder translation: if you're only translating little snippets of text with no markup, translation is simple. The drawback is a lot of repetition; you repeat the same classes over and over.

[00:30:55] Then there's Layout Builder Styles, which already exists as a contributed module. You map a style to classes directly. The problem is the styles are global and there are lots of checkboxes, and maybe you don't want that. Then there are Layout Builder Components, my own approach, where you grab the block with a component through a free-text field and decouple the inner content from the outer presentation, so it's suitable for translation. But it's not really no-code. I'll show it anyway.

[00:31:49] My idea was to create a complex page completely out of components, outside of Drupal, in pure platform-agnostic PHP that could even be translated to JavaScript. It's like React: we have a function component, Tern tagline, and it's really similar to how a React component looks. I'm using a special syntax I came up with after hours of experimenting with how to make PHP look a bit like the inline templating you see in JavaScript. The nice thing is you don't have to deal with quoting, because the only thing escaped is that special syntax with the dollar sign.

[00:33:06] So I can call one component from another. I call the Tern tagline, use the children as text, and build my thing. That way I can build a complete landing page, like the accessory page, completely without Layout Builder, quickly, in PHP, with Tailwind and automatic reloading and preview. I used a proxy for automatic reloading, PHP performance is great, and I had a custom menu callback to show me the preview. Later we integrated with Layout Builder, and it mostly worked except for a bit of field formatter handling.

[00:34:00] It worked, but it's not really no-code; it's more for JavaScript developers who want to write PHP. Integration with Layout Builder used a new module, Layout Builder Components, which comes out tomorrow. It's a dev release, not for production, but it's a powerful approach. In summary, this first attempt gives us a free-text field to call any component function, Layout Builder Styles to define a style, the mapping to classes, and arbitrarily defined classes on the blocks. We could merge this with the Layout Builder classes work, also out tomorrow.

[00:35:11] But there was another dream. You see a menu, you enable the contextual link, you click edit component, change a class, preview the change, save, and it's done. A Tailwind-based theme is perfect for that: you don't like orange, you put in red, it's done. Those changes are stored and then override the theme's Twig templates. You could also override theme suggestions, and add more complex fields to the component fields, so if you have a more design-centric entity you can build it without Layout Builder. That's why we integrate with UI Patterns.

[00:36:19] And this is reality. I pushed it into my sandbox for now, but it will be on drupal.org as the Component Library project; we already registered the namespace. You can test it out: install the module, enable it, and go to the component library. It's integrated with UI Patterns. It's still work in progress and some things will change, like the UI Patterns integration and using a config entity, but it's a great start. Let's look at a demo.

[00:36:56] Here we are in Umami, Drupal's demo. I love Umami for demos. Normally the recipe page just shows the recipe category, the main courses, the tags, and so on. But now I've put the recipe category, the tags, and the description into a little preview component that gives a completely new layout. I can select this component via a contextual link, or go into the component library and edit the recipe category, text, and description block directly.

[00:41:08] When I edit it, I can see how we built this template using Tailwind classes. This is the Component Library module: you have a library, you find all your components there, and you use them. Here I've put the category title and text, I loop through the tags, and I have the description. We can preview it, and change the colors. This is a much simpler template than what you'd see in Drupal normally.

[00:42:29] There was a great question in the chat about making a little inline editing tool where you could change the class right on the preview. That would be fantastic, because you'd know where you are. We could also add buttons for color in the editor, so you'd select one of the Tailwind colors from your designer's design system. For now I can change this by hand: let me put a red background, and a red hover on the first item. Now my design change is implemented. These are classes, and yes, it's overwhelming at first, but give it time and you'll love it.

[00:43:34] If you look at how this is hooked up in Layout Builder, we go to the layout and configure this block. Here's the contextual link I wanted to show earlier, where you can edit the component directly. Imagine implementing it with Quick Edit: a little pop-up shows up, you change something, update, and you see it on screen. For every field in my data structure, it automatically registers as a UI Pattern, so you can map things from the entity to the template directly. That's UI Patterns and the Component Blocks module working together.

[00:47:00] (Question from the audience.) Is there a particular time to choose entity reference revisions versus entity reference, and a time not to use one or the other? If you like entity references, that's a good idea in general. If you want revisions, I suggest using Workspaces. For a custom theme, use a basic theme or put CSS in blocks and Views. If you don't have access to the theme, it's fine to add CSS in blocks and Views, or, even better, if you have everything template- and component-based, just edit the component.

[00:47:59] (Question from the audience.) How does Tailwind compare to Bootstrap? Essentially you build your own Bootstrap, a design system you can use.

[00:48:14] (Question from the audience.) At what point does it become no-code, and are the components accessible to content creators through some kind of selection menu, what-you-see-is-what-you-get? Yes. Every component created is a UI Pattern, so it's available in Views, in Layout Builder, and in Display Suite. Because it registers directly with UI Patterns, that already helps site builders a lot; this is just the last bridge. The strategy is twofold: let UI Patterns shine and be what-you-see-is-what-you-click, and also let you take any Drupal template, right-click, and make it editable.

[00:49:23] (Question from the audience.) Have you considered reducing the interaction with markup, with cleaner markup, a type builder, and in-place editing? I like that a lot, and we'll see what we can do. My main next idea is that you could not only create components but add a little form builder, allowing configuration like colors. UI Patterns already has a component for every form field, but you have to do it in YAML. Let's put those approaches together and have a form builder for the component library, so you could write not just templates but template builders. Then someone placing a template and hooking it up with Layout Builder could choose the variation and configure it.

[00:51:12] (Question from the audience.) If this exports into configuration, how do you handle source control and revisions, and reverting if needed? That happened to me while preparing this demo; I really wanted to go back. There's a trade-off. A config entity is great for exporting, but you don't get revisions. A content entity would have revisions and full control, but it's not as easily exportable unless you use Default Content, which is a bit fiddly. Maybe we need more innovation there.

[00:52:29] Now let me show more of the component library. I have a simple Alpine example. Alpine lets you add interactivity without writing a single line of JavaScript, and I think most people can learn it. If you can add a field, or you know a little coding but aren't into hardcore coding, Alpine is a nice middle ground.

[00:53:24] Here's a very little Alpine example: a select-country button. When I click it, a menu with some hover styles appears, I can select a country, and it goes away, or I click away and it goes away. To do it, we just have x-data with open false, a click that sets open to true, x-show tied to open, and click-away setting open to false. That's the whole interactive application, and it's easy to learn.

[00:54:29] I have a more extensive Alpine example too. This component library needs a tag or something to organize it so we can sort it better, or make it content and then configuration, like Views did in the old days. In this example I added a preview, so I can show debug output: whether the country menu is open, or which country is selected, using the Alpine directives x-text on open and on selected.

[00:56:22] After a short moment, there's the Alpine application. I select Germany or Switzerland, where I am right now, and you can see the interactive application. You can do so many things with Alpine, again with little code.

[00:56:40] The last thing I wanted to show: I made it possible to override the main menu. For now I've chosen a magic naming scheme, drupal_overrides__menu_main, for the template you're overriding, and I just edit it. It's also possible to embed one component in another. Right now you'd use a Twig syntax to call a component library item and pass the data, but I hope we can do something simpler, like passing the menu title through and calling a nice header component. That goes back to the original idea: build up all your components individually, then build one component you never embed anywhere, where you put everything together. All the components have previews, so you get a full landing page built completely in the browser.

[00:59:02] Here we can now see Home, Articles, Recipes, and so on at the bottom, exactly like our main menu. If I change this, the menu in Drupal changes too, though right now performance for that is poor, so I won't do it live. This also lets you add a contextual link and click edit. Essentially, a site builder can edit any template directly from the UI, change it, export to configuration, and be done, with special naming for now on the machine name. I think this has a lot of potential.

[01:00:57] (Question from the audience.) Aren't you the person doing Drupal Celebrate? Yes. It's fun; I featured your theme as one of the first Tailwind themes in the presentation. I actually used your theme as a starter kit for the sites first, and then we built our own. There's also a Tailwind Umami theme on my GitHub, under lines-ad, which is my agency username. It's Umami with Tailwind layered over it, with several preprocessors removed. Button styles were a little tricky, but overall it made the best demo.

[01:02:18] Follow us: Fabian Franz on Twitter, and Tag1 Consulting. Follow the Tag1 blog; we'll be doing more YouTube videos demoing this until we've achieved the dream of making theming much easier.

[01:02:47] For those who joined late, here's a quick summary. I have this component library where I can create components, which are essentially theme hooks and UI Patterns. The code is on GitHub for now but will be on drupal.org as the Component Library project soon. I can add a component or a library item, define some preview data, write my template, and click preview. If a gray is too dark, I can make it lighter, or darker, right in the browser and then deploy. And if you combine it with Alpine, you can even write interactive applications.

[01:05:30] This Layout Builder integration lets you edit the component directly from the form, or configure the block and do the mapping like a normal UI Pattern.

[01:06:05] Thank you, Fabian. This is truly some revolutionary, game-changing stuff, as you mentioned. Shout out to all the other Tag1 developers who collaborated on this, and recognition to the clients who inspired this work. I won't mention names for NDA purposes, but you know who you are.