Config Pages: The Missing Admin UI for Your Custom Site Settings

This talk focuses on the Config Pages module, which enhances the Drupal experience by providing a user-friendly interface for managing site-wide settings while maintaining security and control. The speaker, Anna, a senior software engineer at Pixel with extensive Drupal experience, emphasizes the need for a balance between user freedom and site safety. She explores the requirements of content managers and developers in utilizing this module, demonstrating how to create customizable administration pages directly within the Drupal UI. Various use cases are discussed, such as setting up sitewide alert banners and managing contact information efficiently. The speaker highlights the module's capabilities, including token integration and feature toggles, making it a powerful tool for non-developers. Ultimately, Config Pages aims to empower editors and streamline the management of site settings.

Welcome everybody to Config Pages, the missing admin UI for your custom site settings. >> Hi. >> Um, I am Anna and I have been building with Drupal since Drupal 6. So, I've been around a little while. I'm a senior software engineer at Pixel and I focus on UX, uh, UI, accessibility, front end architecture. Um, basically I just want to make sites that work for the users. I've

been with Pixel for about nine years and I really love that they have a very people first approach to technology and just how we can use technology to make people's lives better. The technology should serve us. So let's start with the problem. Why are we here? We've chosen [laughter] we have chosen Drupal as a solution because we need to give users the power to make changes but

we also need to protect the site from those same users. Finding that balance is the job. So, you know, it happens every time you go ahead and you need one person to update a phone number, but the phone number is on a screen with 12 other settings and one of them, if not all of them, are going to, you know, just evaporate inside. It's a balance. It's

dance. It's control versus freedom. And so, the permissions to give them access to something small usually gives them access to something large. So without the right tools, giving them edit access can feel like handing them a big red button and just hoping they don't press it. Our job is to give them what they need without giving them the option to blow it up. So who are the

players and what do they want? We have our content managers who make change. They want to make changes quickly without tech support. They want a simple UI. They want to reuse content across the site and they want fast, low friction changes. And then we have our admins, developers and security. So they want granular permissions that follow the least privilege access principles. You want no exposure of risky

settings. You want to reduce reliance on custom code and provide tools that reduce confusion and prevent user error. Enter the config pages module. So this module provides a userfriendly interface to manage sitewide settings and it's easier for editors and it's safe for admins. So what is it? What is config pages? Um it's a module that allows us to create custom administration pages uh right within the Drupal

UI. So it has your familiar UI to build forms and it works just like creating a content type or a block type. So you don't need to build customcoded admin forms. And out of the box it allows us to limit access to settings based on permissions and lets us create simple clean configuration interfaces. So what else do I need to know? The admin interfaces that we create

in this module live within the admin UI. So they live in the location where you need them to be. For an example, you can choose to put them under structure or under content or under people. So it's just not stuck in some like config pages interface. It's actually where you need it to be in context with your other administration menus. The values or settings can be used

within templates, pre-process functions, custom code. Um, it can be used within tokens and it respects your roles and permissions. But wait, there's more. Out of the box, the entity can be placed as a block. And this is a fully themable and supporting view modes. Um, and then creating it also has the ability to create custom context plugins. So you can swap out values based on route, user,

or other conditions like location or time. These are all custom, so you can write them to do what you need them to do. We're not going to go into too much detail there, but you know that is available. That was a lot. So let's look at some examples and explain the real power of config pages. Let's see it in action. Most of my work has been in

government. So, we're going to go ahead and see all of the demos are done using the USWDS theme. So, [sighs] how do you create a config page? Well, if you've made a content type or a block type, the process will feel instantly familiar. It's the same flow, but with options that are specific to your config pages. So, here we go ahead and add a title. We can

choose whether we want to expose this for tokens and where should the settings page live in the site structure. So this is where setting that path up. And then just like any other entity you add and manage fields in the manage display and manage form display tabs. And I'm not going to go into too much detail here because you have all seen this being created before. So

that's it. That's all it is to creating a new administration page. Nothing new. So I want to use some show you some use cases. And that's what a lot of this presentation is about. How do you use this in clever ways on your site? Number one we're going to look at as a sitewide alert banner. So this is a super common request. I might have gotten this

request on every site I've worked at since Drupal 6. um and sitewide messaging for closures, for emergencies, for presidential uh notices. Instead of using a contrib module, we can use the config pages with some fields. Editors can update it quickly without full access anytime, day or night. And we might need to give this permission to someone who does not regularly update content on the site. So this

might be someone super limited like a facilities manager. So, they need to be able to say that the, you know, the ice in the in the parking lot is causing nobody able to be able to park or something like that. So, stay home today. So, we create an entity and we add the fields just like any other entity. Here's what I've created. Um, it's pretty straightforward. It's

an alert type. So we can choose if the alert is. So first we can choose if the alert is active or not. We can give it a type. We can add a heading and we can add a body. We could make this much more complex um with extra features, but this one's just pretty simple and straightforward and allows for a single alert. We want to show this

at the head of each page of the site. So we're going to use a block to do that. So, config pages exposes each configuration entity as a You have all of your typical block and then you choose which config page you want to generate the block for. So, they'll all be listed in this select list. And because it's just entity like any others, you can go ahead

and choose your view mode. Next, we'll add permissions. Because we need this super special user that only can handle alerts and can't do anything else, we go ahead and add some permissions. Um, we add up we set up those edit permissions for them. And remember, you still have to add the, you know, view administrative theme, view admin pages, text format, all that stuff. But this is what

is really control what they have access to. Now, when the alert manager logs in, they will see the alert configuration appear in the menu structure where you set it up. And this example is less impactful since I only have one item, but if you're creating configuration for a site manager, you can place this exactly where they need it. So, the configuration is all set up. Let's go

ahead and theme it. Config pages comes with their own template suggestions like nodes and blocks. So you can target specific config pages with custom templates. And when theming config pages, you can use the content variable to output the Here we can see we're outputting the variables into the US WDS site alert markdown. This is a straightforward expected way for it to work just using an entity. No

surprises. But I do want to go on a little tangent. Config pages has a little helper that gives it a bit more power. You're not limited to the config page template. You can output your config page fields into any template file using the config page field function to grab those values directly. Um, this is a great way to add a value into a sitewide element like a

header or a footer or a banner or something like that. We're not going to go into too much into pre-press functions, etc., But you have access to how you uh call entities from with a pre-process function. You can call these entities in that same way, those same ways. So, and that's it. Our start alert was built from the ground up. The special alert editors can change at

any time and we just build it for one specific purpose. So, let's see how we can use configuration that can be reused across the whole site. Our next use case is contact info. Every site has contact info. So this info is often used in various places. It's in the footer. It's on the about page. It's inside blocks or content. And instead of risking inconsistencies, you can manage

it all in one place and change it all at one time. So, I set up a new config page that stores the structured content details. Right here, I have organization, address, phone number, email, etc. You can have social links, you can have like anything you need to deal with the organization. And so, this is where we pull the token module into play. The config pages automatically exposes

their fields as tokens if we tell it to. When I set up this config page entity, I checked the option that we talked about a little earlier that exposes those values as tokens. This means we can reference our contact anywhere within the tokens are supported. Here's an example of some of the tokens that are available to us. So these are the different fields that we have set

up. We need one more thing to get this going for our content creators. There's one more module we're going to add and that's the token filters module. So the token filters allows us to go ahead and use these tokens in places like text fields. So here we have an example of an about page. We're putting those tokens directly within to the Wizzywig editor. And those tokens um

when we save the node, Drupal swaps out those tokens for the real data. So our about page stays accurate even if the details change later. So let's use those again, but let's use them in theme settings. We can allow users with access to the contact info update these details without touching theme configuration. So keeping them out of areas that they do not need access to. So out

of the box, USWDS theme has some configuration um for context that will appear in the footer. So we want to use our tokens to populate the footer. Now there is a small disclaimer. I did a little bit of work on this theme to make sure that it can accept tokens, but that's simply in a pre-process function. So you should be able to work that out. So we're

not going to go into detail there cuz that's theme specific. So those tokens now render in the footer pulled directly from the config pages. Updates happen sitewide without touching theme settings. So where else can we use these contact details? How about a call to action block? As we do this, you can see how it easy it is to reuse these in different contexts to change it once

and see it everywhere. So developers can make polish styled versions of the config data and place them anywhere on the site or allow content creators to place them. So you could put these in places like layout builder, twig templates, entity reference, embedding it, all of the million ways you could add a block to a I just created one example here, but you could see versions of this

using different view modes like a visit us page or a sidebar widget. I also did see that there was an update of this module recently to allow it to work with Drupal Canvas, but I have not tested that yet. Another interesting use case is grouping new features behind a feature toggle. So, this allows us to enable or disable features without code deployments. really you push the code

up, it's already there and it's just sitting there waiting to be turned on. So you can this another thing you can do is test new functionality with specific user groups before the full launch. You can quickly and enable or disable features if something goes wrong. And this empowers non-developers to control feature availability. So this lets you roll out a feature on a schedule with a low risk

because no deployment needed at go time. Okay. So this for for this example the client has requested that we need a new content form added to this about page. The form is being generated somewhere else n Drupal third party application embed code and we just need to turn it on and off. We need to set it up so they can turn it off and on. So, we're

going to walk through what this looks like. So, we're going to go ahead and we go up to our config pages and we can see these are a list of all the configuration pages we have on the site. We come over to our config page and we add a new config page. Here we can give it a label and this is contact form settings. So we can

add additional settings in the future but for now we won't. We can expose it as a token but we don't really need to in this use case. And we go ahead and choose where it's going to fit. So we're going to put it under config system. We're going to save it. And here we can see our new one. So let's go ahead and add our field. We're

going to get super crazy with the fields here, so bear with me. We're going to add a single boolean, turn it off or turn it on. So, we're going to enable our contact form or not. So, once we go ahead and create that, we're going to take a look at our form. So, we come over to system or configuration system and we see new contact form settings.

It's there already. We head over and see our crazy form. Enable the contact form and save it. Now we've created the form. We've played with the fields, but it isn't doing anything yet. So, we're going to use blocks in this use case to go ahead and just place this onto the page. We're going to go down and choose the region where we want it and add our

config pages block. So all of the config pages blocks are of this type. Give it a more reasonable name and then go ahead and choose the contact form that we just created. We can choose here to go ahead and update our display mode. And now we're just going to limit it to the about All right. the blocks on the page. Let's check it out. Okay, this doesn't

look like a contact form. [laughter] So, this is just outputting that single um field that we created. So, now we're going to come over to the template and we can see that we're using the config pages template and regularly outputs just the content which is that field we created. So I'm just going to paste in a snippet here. And basically all this snippet is doing is it's

checking whether that value of that field is on or off. And then it's just including some arbitrary code which would, you know, be our embed code or whatever. I just created some arbitrary HTML. And we can see if it's on, we're going to show that. We're going to head back over to our page, give it a refresh, and we can see our form. So, now we can

turn that form off and on. We can push it up without it going live. Easy peasy. So, at the beginning, I said I really wanted to use this as a brainstorming session, a way to see how this could actually be useful on your site. There's dozens of ways to use this module. Some are practical, some are a bit clever for their own good, and I'm not going

to go into detail on each one. This is just a brainstorm I did. Um, but you could take this in a million different ways. I'll just highlight a few more that we've looked at here. So, you can have ba boiler plate text. So, stuff like disclaimers. Maybe legal has given you these lists of disclaimers and different things that need to appear in different places. You can just

give a token to your user so whenever they need to use it they can pop it onto the page. Then when that notice gets updated they have it. You can have common blurbs regular things that are used throughout the site and you can manage those all centrally. AB test configurations so you can test the site behaviors and design configurations as you set them up to automatically display

to different user sets. You can highlight content. So, I really like this one. So, you can allow users to handpick content such as news or resources or events and by selecting it in an entity reference field on a config page and then those are the items that are highlighted. So, for example, you can have cards, teasers, lists. I know we've all done something like this with dragable

views. So, this is a pretty straightforward way without even using wheel. It's just using a field. You don't need flags. And you go ahead and just choose the things that you want highlighted wherever you need them. And another fun use case is oneoff pages. This is like the homepage. So this is that one special page that h does have to be structured content, but not everybody needs

access and it needs to do different things than the whole rest of the site. So, so many pages of your site that structured content is consistent, but the homepage is is different. It's never the same as any other page on the site. So, this allows you to create this one special page and then instead of telling your content creators, okay, this is the homepage node type. Only

ever create one, only ever use it once. So, in this use case, you can go ahead and create this special page and allow them to edit it just for this use case. This can work for different kinds of pages just than this. But I think the homepage is a really cool use case. Important thing to note is while the structure lives in config, the values live in

content. So your configuration is going to be exportable. The config page type definition, the field definitions, um the permissions, all of that is exportable just like on a node. But the content itself, this is still content, um is ex is not exportable. So to to export this content between environments, you're going to have to use another module um that has content at config. Um so some options

are things like default content module, the content sync module, and I know there's a config page export module, but it does not look like it's ready for 11. So, I don't know if that's something that they're looking at doing, but has I think it hasn't been updated in a while. So, might look into a different solution. All right. So, TLDDR, why use config pages? It's editor friendly.

Editors can update it without summoning a dev. You can lock it down. Permissions keep risky stuff out of the wrong hands. You can reduce, reuse, and recycle. Turn one source of truth into blocks, templates, or custom code. You get a speed boost because changes happen fast without that ticket backlog dense. And the bottom line is config pages makes happy editors, chill developers, and safer sites. All right.

Are there any questions? [applause] Thank you. Um, so I use workbench access and so my editors log when they log in they go to my workbench. Can we put this >> it? I have not tried but you're setting up the route to where you want it to live. So >> that's what I wondered if it still can >> I I would give it a go. I know

[laughter] give it a go. I haven't tried >> Um, and my other question was so maybe homepage. But what about um like campaign landing pages? >> Yeah, any sort of oneoff pages that you really need to be structured. Campaign pages um can be flexible. So if you need to develop the whole thing with a structured content at the beginning, that might be a good choice. Otherwise, like

layout builder or something like that, maybe even canvas where they need a little more control because a lot of times on campaign pages, they go a little bit more wild on those. So I don't know, it might work great for your >> Depends on that. Yeah, really really does. Yeah, >> thanks. >> Two questions. Uh, one question is about the deployment. So if we create something beautiful

for example homepage on the staging and need to deploy it to production, what is the recommended way to use it? Because this is content we just deploy in production and everything disappear and same problem with edited content. For example, we deployed the new version then uh developed the new version stage and on the production user changed something and if you deploy this production changes will disappear. How

to handle this? >> Yeah, it's going to be the same problem that you find in nodes or any other sort of things where you have to move. So those same solutions for example the config export or what is it content export content sync those are the sort of solutions you'll have to look at in updating here as well because they are in essence and the base they're

entities so they work very similar to other entities yeah >> and one more question about the other models so we have not only captic pages but site settings and labels site settings content builder they resolve the same uh issue you provide almost the same functionality. So having some comparison of them and maybe what features are better in this module >> what are the other modules that you

mentioned >> site settings and labels site settings and content NC builder they provide almost the same and I always [laughter] have hard times to choose which one to install. >> I have not experimented with those other ones. I was excited when I saw this one. I believe early last year because I remember building so many sites where I had to come up with just a couple configuration

and I didn't want to go build a form and that's that's where I found this. Um but I had not experimented with those other examples but like that sounds super interesting. I'll have to look those up later. >> Yeah, they're very similar the same features actually. [laughter] Everybody's thinking the same thing. Just just nobody's like, "Yeah, I I I because I know I'd been thinking about it

for years and years." My first project I ever worked on Drupal, I'm like, "How do I make a configuration page?" Like I I don't know how to do that. So like that was that was way back early when I'm just UIing it. And I'm like, "How do I make something super simple?" And and it wasn't until last year that I even saw this. So, so I don't

think that people know about these really cool modules. So, I'm going to have to look those up and and play around. >> Yeah, the usage is pretty similar. >> Oh, cool. >> So, check them out. Uh, yeah. And also you mentioned about the storing content as uh is it possible? So if you create for example u page with uh API credentials uh can be stored as configuration

and not as a >> I'm sorry I didn't catch that. >> Uh for example if you create a page with uh API configuration username and password >> okay >> uh we can use uh config uh pages module but it's better to store in the configuration. So is there any way to store it not as a content but as a configuration? >> I as far as storing these

as configuration I have not experimented beyond using the the typical export um >> the export content um things. I have not done that. I would probably just go and I would probably just go and hard co like code out a module at that point if I was worried about like yeah usernames and passwords and things like that. Yeah. >> Actually today I'll present another model that provides

forms from the creation. >> Oh cool cool. >> This is [laughter] totally another approach but uh the result forms the same idea. So we can try to make this something together [laughter] something. >> Wonderful. >> Okay. Thank you. >> So, he asked if we can move the config pages into other areas, which here, I'll just go back here for a second. >> I just I guess I'm

wondering like to make it more you can just do it but like I wonder if there's a better location. >> Yeah, you can use the dashboard module if you're if you're using that and put put output some stuff there. Um I mean if they're entities so as block so you mean just like another page you can just put a link on the dashboard that sends >> Yeah,

I guess just like somewhere that's more visible for that. Yeah. So, so we went in this use case here we were looking at. See if I can find this. So, here we can see that when we created this form, we set where we want that that that form to live. So, we want it to live in this case that we wanted it to live in system settings.

But if we wanted it to be, for example, under content or under any other things, you can go ahead and add it. And I know they have that new sidebar um maybe that's a location that you can set it up. I'm not sure in the new navigation um how you would do that. You would probably have to you would probably have to set up some routing and

your own icons and things like that to do that. But if you wanted to put on a dashboard, which I have done, is I would just create like a quick link section on the dashboard and this would be one of them. >> Yeah, I look at where they click and wherever they click, I go ahead and put a link there. [laughter] Where do they hang out on

the site? >> All right. Is there anything else? >> Wondering if you have any recommendations on how to handle versioning um for the config files like like saying you know the information is really handled like content. Um I use config pages um in conjunction with feeds and to kind of give like advanced users the ability to change some settings um so that it can manipulate the data

before it you know is finally processed. Um but it's easy to make mistakes or have things where you know you need to make adjustments and maybe you know go back to an earlier version. Do you have any recommendations on >> um I do not think that right now as of now that revisioning is supported with this module. I haven't found anything to show that. Um so I

would I would not have an answer for you there. >> Yep. That's what I found. [laughter] >> I did look I did look. I was like all right all right I'm expecting revisioning but no no that's not there >> actually should be easy because it's a content entity it's just one check box should be from the pro program side >> yeah yeah but yeah it isn't at

this point I mean if you wanted to patch it you probably could get it working >> all right any questions well um if you guys could all help me uh level up at this point. If you can just go ahead and leave me a little bit of feedback, I would be grateful and I know the the Drupal Association will be grateful as well. So, this is not

a pop quiz. [laughter] It's pretty simple. Um, thank you guys all for coming for all your questions um I think you should all go forth and be brilliant. >> [applause]