 I've been I've been doing this for a long time. So I always like to put the title slide up first So everyone can see like you are in the right place. Let's hope I was joking that 10 people would show up because like You know Drupal sort of a nerdy little hobby thing for a lot of people And this is like the nerdiest little corner of that nerdy little hobby And so either this is a real pain point for you or you will have no idea what I'm talking about or why it matters But that's fun. So we have an agenda. I put an agenda together I'm gonna explain who I am Give you some issue background and some use cases because use cases are important. I'm gonna show you what we've done in the past I'm gonna show you what's up in Drupal 8. I'm gonna make a modest proposal for what we do in core And we're gonna talk about things that block this from actually happening. I Wow 25 people Two and a half two hundred and fifty percent more than I expect That's awesome I'm Ken Rickard. I work for Palantir.net, which is a Chicago based Drupal strategy design and development firm. I've been around Drupal since 4.5 I think 12 years now I'm the domain access maintainer We'll show you some slides of that Domain access actually goes back to Drupal 5. I'm working on the Drupal 8 port right now I was one of the co-authors of pro Drupal development. Someone was asking me at launch if like Palantir, we know Drupal. I'm like, yeah, yeah, I've kind of laughed at it. I'm like, yeah, we know What's really interesting to me a lot of the co the foundational work that we're gonna be talking about I Did the last time I was in Dublin for dev days in 2013 And I got to work with Gabor and Alex Pott who were doing the configuration management initiative I'm gonna talk a lot about the work that they've done particularly around translation The other thing that I think is a little interesting is I just came out of the I just came out of the imposter syndrome session and it's funny This is my 20th Drupal con and probably like my 30th presentation But my first core conversation is the last time I was on the schedule to do a core conversation I got bumped because the the one in front of me went long and they thought it was more important than mine So there's some imposter syndrome To be fair that was Greg Dunlap talking about configuration management back in like 2013, I think Okay issue background Fun issue background. So I'm the domain access maintainer. How many people know what that is? See I have groupies. It's real fun. I Met one at lunch. She was like you do that. Oh, wow. It's great. So yeah, it comes from Drupal 5 I will tell you for a minute where where some of your domain access comes from just so you know It lets you run a group of sites, of course And one of the things we realized very quickly We were trying to build a bunch of city-based magazine websites. We were based in Georgia And the sales team wanted to be able to go out and sell in other cities And they immediately said well We want to sell this in Los Angeles and we had worked it out so that you could change the theme and present The right content for those markets, but then one of the other developers went wait, Los Angeles is in a different time zone What do we do about that? And it turns out that settings dot PHP is a PHP file so you can do whatever you want to in there including run lots of code to run Configuration overrides which we used to do raw in settings dot PHP and everyone's good friend the conf array So I will show you some stuff. These are Screenshots that I took from Drupal 6 the other day, but here's the use case, right? So if Hungarian is a default language context We want the time zone to be a certain thing and if it's Japanese we want it to be another thing Perfectly legitimate use case for what I would consider when I talk about contextual configuration. This is what I mean changing some core value in Drupal's Underlayer so that things are presented differently Depending on the context you come to I use domain as my proper my normal context Languages a context we'll talk about some others Groups are contexts, right? That's another common use case and so yeah the Gujarat group on groups dot Drupal dot org might want to have a different time zone presented Right, that's a contextual configuration Can you do it? I already answered that the whoops. Yeah, you can this is how we did it in Drupal 5 6 and 7 actually is we created giant arrays of forms that let you override Selected variables that were popular Actually, that's not true in 5 and 6 and I think in 7 I provided default support for every configuration form in core And then if it was in contrib it was up to the contrib module to use the the hook here to Add their own array of doom this worked It gave you this lovely page that showed you all the things that were configurable Which gave you this lovely form that showed you all the configurations and you could change them all that ones right and it worked This is this is actual Drupal 6 Do so hey different site different site Very exciting We actually realized in the Drupal Lateness Drupal 6 cycle there was an easier way to do this and I wrote a domain settings form in Drupal for the Those of you who don't remember Drupal 6 and 7 there's a system settings form function That was used anytime you wanted to build a system settings form and you can actually in a hook form alter You could read in and say oh this is using system settings form It must be a config form and then we just overlay our own stuff So you got this which said hey, this is a domain sensitive form. You're gonna set a contextual variable. Oh Isn't this nice and I have you know, here's an example. This is The lovely blue marine theme used for admin on one of my sites So This is all really cool. It's really nice. It's been Expected functionality in some small segments like I've like I said the people who really use this are in the domain world and in the og world I Don't know if anyone else has content context that they care about But what I wanted to do is so there's the background then I want to talk about what's going on in Drupal 8 Why you can't do this in Drupal 8 and why we should or should not be able to do this in Drupal 8 And it's a little bit unfair I said I was here in 2013 working on this stuff And and I remember Gabor and Alex were both thrilled because I can do contextual Overrides in Drupal 8 right now and I'll show you how and then you'll cry Because they work which is great, which means the underlying code system works, but I can't do this right and I'll show you why and What do we do in core so core configuration as everyone knows is giant stacks of YAML files Ray Then there are a couple things you can do you have config overrides You have config schema and config translation are all different parts of the system will touch a little bit And this is what a config file looks like everyone's seen these before right? and You can using the domain config module import All or part of a config Schemas config schemas are so broad and so Complex in in my world I don't bother trying to force you to clone the schema and I don't keep up with that Domain config will actually just recursively load as much config as you care to override for a specific context By default it actually supports both domain and language, which is really cool But if you want to change like the site name you have to upload a YAML file Following a naming convention right What's nice is you can act the naming confection actually also supports a dot language element in the string For those of you who really care about this stuff if you have a dot language dot domain It'll look for that first and then if it doesn't find the dot language It'll fall back to the dot domain which is really awesome and does show the power of what we have in config management and config overrides And look it works Like one. Yeah, I made a change Now my assumption had always been the stuff that they're doing in in config translation Once that's done all I'll have to do is clone their user interfaces and boom I'll have forms for all this stuff And the rest of the presentation is about why that doesn't work hooray So this is what you get again with languages right and I went ahead and installed Irish on my site because that's the proper thing to do And you get this config config translation screen which actually looks a lot like the domain access screen We saw from Drupal 6. Here's a list of all the things you can translate Right, that's awesome What I want to show you I mean how many of you have actually ever poked at this code That's one person sheepishly in the front That doesn't surprise me This is Really complicated stuff. I actually figured this stuff out about nine months ago And then when writing the presentation had to spend an hour and a half refreshing my understanding of it So what happens to make all this work? There are three things that we're looking for in the translation space and these are all Eligible to be contextually Configured config entities Language translation the config translation understands how to read those Just perfectly Fields it can handle those perfectly to config objects config objects are the things that actually store like your site name and your email address things like that config objects Core doesn't actually know how to handle those You have to register them either through a hook or through a custom YAML file and we'll get to that in a minute And I can already see people nodding about why this is a bad thing or problematic if you're in contriv And then it what it does is it produces these nice lists of things you can translate What's what's really interesting here? It's this is selective the first thing I noticed is this is very selective handling number one It yes, it reads config entities and fields automatically the reason it reads fields by the way is that fields are in fact config entities Talk about them as if they're different things. It's maybe wrong only if they're type label or type text and I figured figured this out because I Had a thing that was type string I think and it wasn't showing up in the translation interface I'm like, why is this not in the translation interface because it has to be type label or text not String or whatever I had it as Config objects again. There's I think there's only two instances the instances of these in core module dot config dot Translation dot YAML those things That's how it registers Config objects and those also have to be type label or type text There's a really good logical reason for that. Can anyone guess what it is? It translated ability only cares about strings We'll talk about that in a minute, too So yeah date and time formats are in fact strings. That's great What's really really interesting also though is that this form doesn't look like this. This is the config translation form right, this is the regular form and Translate shows up as an operation here, but this information about the pattern doesn't show up here So the user interface is actually not replicated. We'll talk a little bit about why that is too But it's fine, it's great the the sort of fundamental things you need to build an interface like this are What's the URL to the translation going to be what's the URL to the the base form? And it would be nice to be able to read the base form itself so you can replicate that base form And what actually happens is when we're translating something They have to do a couple of really weird things in the config translation module They have to do some route mapping to understand where the configs are so that you can provide those links And they have to create some local actions. There's a lot of dynamic route handling that I can see a Puzzled look it's it's weird This is where things get to me really strange. This is the normal form This is the normal form if you're editing a date format This is the form if you're editing a translation of a date format you'll notice these are not the same thing Why are they not the same thing and I can show you the the secret answer as I jump ahead is Because the code that makes up this form is not readable anything except the class or a class that Extends the class That generates this form so back in Drupal 6 and 7 when I'm just reading. Oh, this form uses system settings form I can assume it's a system settings form hooray That doesn't even happen anymore. You can't even Go in and say find me all instances of things that look like they're saving config There's no way to do it So that's interesting As we find out ux change is hard to there are a couple of things that are happening happening in config translation that they have to do Again, the forms are all just raw formatting and then they have these five custom form element handlers that basically Replicate form elements based on the type of string. They're translating This is very weird one-off code that makes me cry a little bit because it's one-off code and You couldn't use these either even if I could read the elements that were configurable in my module I can't I don't have any access to these classes either So they're useless to me. So that brings me to the big question. What about non-string data? So setting a time zone is not a string data. That's not a string thing So config translation doesn't do it right. So here's the problem as I see it. We have no support for non-string values We do not have abstracted code it's all hard-coded to languages use case which makes me cry and They only do schema discovery which is Interesting and when I say schema discovery they can discover config entities But again not config Objects and if you want to say oh, this is a config object that cares you again have to write extra code for that So why is this a problem? This is so here's now. We're getting to the argument part Why is this a problem as me the domain access maintainer? If I want to build a user interface so that you can change the time zone I have a couple of options right I could certainly just build it and I'd have to build like a one-off implementation for every variable. I want you to be able to edit No, I'm not gonna do that I've done that before I could do that for all of core I would actually be willing to do that and then immediately people will come into my issue queue and say but what about oh The classic for me is always Google Analytics module Well, you'd have to take that up with the Google Analytics module maintainer You can't support something like this in contrib the other problem of course is and some of you who use domain access Saw this in the D7 cycle when the variable API module came in there was a fork And how do you handle contextual configuration in domain access and you use my my way or Jose's way? Which are both equally valid and that's fine But you have this competing solution problem which might be good at getting the best solution But is also a huge waste of time and effort which George was talking about in his session earlier today So I have no real impetus to do that either There are the pieces we have a lot of single-use code. We have a chance to remove so Contrib is really not an option for fixing this stuff So here's my modest proposal So this is actually what you'll see in one of those config translation YAML files This is the config translation YAML file for the system module. Oh look, it's out You got to the the proposal portion so I spent the last half an hour ranting and Setting up why I want to make these changes to be happy to talk to you about later So these config that config translation YAML files do the following things Well, they do one thing they map config objects to routes. That's all they really do They don't help with these other three things that we need we need to be able to abstract the form handling if we want to replicate forms We we need to be able to link a schema for configuration to a specific route and we need The way I see it need to let modules select data. I said with config translation. It throws out anything that's not type label or text Well, that's fine and for its use case it should what we need is an API that actually says here's all the things you can configure Which ones do you care about like you could write one that just cares about dates, right? You saw this is a date or just cares about booleans or something like that. So What's again kind of weird about this one again in the in the YAML file for config translation All that's really saying is well, this is a this is a configuration thing It has a title. Here's the base route if you want to go to its settings form And this is the name of the config schema that it pulls It's a very weird piece of mapping. And so of course my my dumb brain says number one Why is this not on the route? Why why don't we just add the schema to the route and Alex probably have a good reason why but maybe not So this is option number one that I recommend we do immediately. Let's add schemas to routes when it's appropriate Option number two. Okay, you don't like that. Let's add routes to schemas. I Don't want another YAML file that yeah Just one one or the other either one is fine. This one actually might be better now that I think about it No, you want schemas on routes? Yeah, it's an interesting the only interesting challenge here to me is that I mean routes are alterable Right The schema if if necessary. Yeah. All right decision number one. We're gonna put it on the route That's that's awesome So that actually gets us sort of halfway there because once I have the schema on the route That means I can now build a user interface that says Okay, here are the default settings for this thing and here are my links to contextual overrides for that thing Okay. Yeah You you could potentially put the schema on the class. I'm not sure how you would do discovery of the of that without plug-ins Mm-hmm that might be available and I'll show you why we don't do that now so This is you could put the route here on this is This is the base config form that you're talking about. I think this is the base class the the actual blocker here The reason we cannot replicate Even config translation can't replicate the date string forms is because the of this Actually of that right there Right, it tells you this is the config that goes with this form. Oh, but it's a protected function because we don't want you to read that So yes, you probably could put the route on here And that would be a question of what collecting all implementations of the config form base. I don't know I'm open there. There already is an issue and it's been out there for like a year. So I have a list of issues. I Have issues Yeah This one is actually a little more challenging custom form submit handlers need to be accounted for in the in the old olden days when we had Systems system form submit What I used to do is read whether or not that was the only submit handler on the form And if it had more than one submit handler, I would ignore it and say I'm sorry This form is too complex for me to handle because I can't like date the date stuff in Drupal 7 has like complex Handling of form submissions that I couldn't replicate So this is an interesting question and you do have to answer the question of can you should you actually be able to contextually Override any setting via the user interface. Yeah, and Alex is like no, there are certain things we should ban We should bar right and I can tell you this because I've worked on it in the schema API Not the schema API there the config override API one thing that you cannot contextually configure is a domain record Because if you try to do that it creates an infinite loop because the domain records are looking for Don't even so yes, there are possible exclusions to things where we would say this should never be overridable. I don't know Yeah What so what Alex pot the the are you still the CMI maintainer? So Alex bought the CMI lead is saying please. No you cannot put the it's Yeah, core.extension.yaml should never be contextually available and that's perfectly legitimate There's probably three or four other cases But a good one a nice one to test is I like time zones great test. I also love Maintenance mode. I love to contextually configure maintenance mode for that. That's a lot of fun Huh maintenance mode is not in config It's in state. Oh my I haven't even thought about the issue of contextual state changes and let's not go there I'm really only concerned with Time zones would keep it simple time My two use cases time zones and Google analytics codes Which might actually well their text so they might actually be anyway Here so here the blockers If done correctly it actually is going to cause a major rewrite of config translation Because what you'd want to do is rip out all of its custom code Abstract it so that everybody could use it as a baseline API. I was pointing out Alex that like there's five or six custom form element handlers That are single purpose in config translation Moving them out would be a good thing the the whole discovery process that it uses could all be moved out. I don't know So there's the big blocker test cases. This is the other big question Does anyone else actually have use cases for this? Let me ask this question since everyone's sat through this much How many people care about this issue? Okay, what's funny was funny when I asked how many people knew what domain access was like 90% of the hands went up And when I just asked how many people care about 40% of the hands went up So I told you this is like the nerdy corner of the nerdy corner. This is like very much out there So that goes to the title of the session right number one. Can we do it? Well kind of and the other issues really do we care? Do we actually care enough to get this done? Because otherwise my my statement to people right now is well, yes, you can You can override variables on a per-domain basis by editing a YAML file Here's instruction on how to do that and I'm okay with telling people that I'm perfectly fine with that if that's what we decide to do Yeah, so my here's my related issues allowed discovery of configuration UI. That's the issue that I filed. That's the big Rant basically that has all the details in it. Yeah make get editable config names public That's been out for a while The other one that's that's there that I don't think we've cracked is this one Which is actually kind of nasty the no indication of config on configuration forms if there are overridden values Which is a really nice UX piece and really important And I'm not quite sure what to do about it, but those are the three big issues And that's all I have prepared So questions solutions people want to take free time. I'm not going to be offended 10 after 4 which means we finish very quickly, which is great Are there questions if so there is a mic might be better if somebody could pass it around Getting up might be hard in this tiny room About your question there about the last question I was at the session before this about configuration and he talks about You have two different modes of fetching configuration either by mutable or non mutable So you can see it either fetches as a read-only value or a read-write value So in that case you should be able to detect if it's overridden Yeah, I don't know Alex do you want to come up so you can like share the mic and be recorded you don't have to again you I Only know enough to solve the problem that I have And so I could be totally wrong about most of this stuff But these are the again the blockers that I read into so the let's repeat the question And you can repeat your answer it might be helpful because they're recording the question was about Immutable versus non immutable configuration. Doesn't that help you in the UX? Yeah, and and so if you look at the final issue here, there's a lot of discussion about when When do you want to tell the user that it's overridden or when do they just know it? So if you're looking at a translated Configuration form telling them that that's overridden is the whole point it is overridden You're editing the override or are you just looking at the the first? Part the normal form the untranslated bit and if that bits over overridden settings PHP What does that mean and how can you identify the actual form element that's related to the thing that's overridden? We could never make it work. So that's why there's been no progress But ideally if you have an override in settings PHP the form element would actually be disabled because you can't actually change it and so what what happens Well, no not disabled what happens now in in we change we swap the behavior between triple seven and triple eight in Drupal seven if you override something And you go and edit the form The override will be set to the value and then you save and then I'll actually get saved to the database in Drupal 8 We get the unoverridden value and we put it in the form so that you can deploy changes Which aren't from your settings PHP overrides, which is a better way, but it's hidden from the user Yeah, but it's it's but it's also very confusing in Drupal 7 when you go and you press edit on a form and you change your value And you press save and it doesn't change Press save again why not why not and then eventually you go and look in settings PHP And then maybe there's another include in there to an environmental file to include to include to include And you eventually get to why it was over in the first place and it's probably worth noting right there at least two different ways To override config in core now right you can still hard code things in settings dot PHP Or you can use like I'm doing I actually load schema files. Well partial schema files And knowing which is which like in Drupal 7. I'm always editing the conferec Dynamically and in 8 I want I eat as a module maintainer. I want everything in config. I want everything in yaml And that would cause me problems too actually Now they think about it. So we need We need a way to identify. Oh, this came from settings dot PHP Which would basically mean oh joy probably setting some global thing that you could read and say Okay No, if you want you Am I aware that there are issues with environmental overrides Is there a solution to the environmental override problem I think because it's related because The environment you could expand the use case You know that's actually probably a good way to get at this problem instead of If the problem that I'm laying out is we need an abstract API for doing configuration overrides Probably the use case that we could actually get into core is development environment, right? And so you could have I'm just remembering the pain of I know they've prod toggle issues I know two years of arguments about like how many like types of environments you want, right? Well, you just That's that's actually solvable, right again. I again my code's naive, but it lets you do Partial overrides of any schema you want to oh That's awesome, I don't even see So right I can I can create a domain specific config file I can even create language specific domain specific config files that contain partial config overrides We could certainly do that and it would give us a use case that everyone could agree on and You'd end up with a file that was something like environment dot Name of environment dot name of config and boom I can see it The problem is the problem that I have without that you missed was I don't think you can write that module and contribute right now You can write that you could write the management piece, but then there'd be no UI for it It'd be just like you get with domain config, which is well Here's a way to load environment specific You wanted a modular load environment environment specific config files. I could show you code I have now you could have it done in two days So like from my perspective what you're saying is like I've been waiting for someone to like take the Like the the base work that we did with overrides and then generalize it and it's like complete music to my ears It's like wow at last someone has taken the idea because it getting Configuration schema into call we wrote it three times And then after getting the idea of schema and building the config translation on top of it took a lot of time So it's it's not a surprise that there are bits which are less reusable than others And and the stuff that you're saying about trying to get more information into Bit to be discoverable it makes a lot of sense I want to see things like being able to control the list of allowed values or regex is on the schema so you can you can Validate configuration much more just using the scheme and build whole forms from the schema so you don't need to know anything about They're saying yeah for again the recording someone is actually building forms for typed data But not for typed config and the point I was making so I don't want to build forms for typed config I just want to steal the forms that already exist and piggyback on them and That's what I want Yeah Yeah, but those are all developer tools right they're great for developers they're not they're not interfaces I would want Non-developers to look at Essentially are there other questions Are there people eager to take on this challenge? You don't necessarily have to rewrite config translation what you can do is actually just write it so that Configure translation thing can start taking bits and pieces, but I would unless you have a better idea I would start from the use case of environmental Overrides It's it's one that's required and most people have a use case for and then if we can build it so that We we have is the discovery We need discovery we need form-handling We need the sort of what the blacklist the these are things you cannot alter Of course funnily enough one of the primary concerns that people have with environmental overrides is to be able to have modules installed in Development like deval and stuff so they want to override the core extension stuff Maybe maybe there's a way to say this module actually doesn't have an install hook and therefore is safe to just turn on and off Yeah Baby steps If anyone wants to talk about it more, I'm happy to stick around Otherwise, there's plenty of things to do in lovely Dublin and at the conference and I give you some time to hear some Thank you The piece you missed was me saying oh we worked all this out in 2013 when we were in Dublin the last time