 I am going to get started. So we're here for the schema.org Blueprints module for Drupal. Quick introduction. My name's Jacob Rockwoods. You can learn more about me at jrockwoods.com. I'm not even going to do more than that, because there's a lot to go through. And this slide I struggled with, this is my big what if. The what if here is what if there was a standard way to build content models for CMSs, even outside of Drupal. There's been talk about this in the content management system community, like an open standard that we all follow. And when someone creates a blog post, the fields and properties match this standard, and everyone understands it and can use it. And we're not reinventing the wheel every time we build a site. And that's the big what if that I'm exploring here. And then the what if extends to what if when someone's building a site, you understand what they're trying to build. It actually changes how we would build modules. Instead of just creating a date module, you'd understand that that date module probably is used for an event content type. You actually wouldn't even know it's a probable, because if they're aligning and saying, I am creating an event and you have a spec to say, OK, you are creating an event, you can use that date and leverage it. And you're going to start seeing that come into play. I broke this presentation up to target different audiences. And I felt like Site Owner was basically selling this idea to the people that are responsible for a site. And it's all about schema.org. And schema.org is an open standard and spec. It's a collaboration between Microsoft, Yahoo, Google, and Yandex to find things on the web with structured data. And search engines do use it to improve search results. Any lots of systems use it. You can use it in emails so that when Gmail gets an email, they'll know what the unsubscribe link is. And the approach, and this is on my blog that I'm JRockets.com. I've been talking about for the past few years, is taking schema.org and saying, that's the first thing you want to think about. These content models, the standard, bring it in to Drupal and say, this is where we're starting from. In contrast, right now we do a schema.org last approach where we build out our site. And then we apply this spec onto the site and we write the JSON LD. And then we expose it. And that's the whole goal of this module, is to take this schema.org first approach and bring it into Drupal. And I'm just going to do the lay of the land when I'm talking about this. Let's see, I got Wi-Fi. That's a good start. This is schema.org. I'm not going to spend a long time on it, but I want to show it to a really simple spec. If I go to event, it describes an event. What they give us is a description of the event, the properties that are possible for the event, the expected data types, and labels. And just breaking it down, like for example, you get end date, start date. If you want to schedule multiple events, there's an event schedule. And then you can click through and see a schedule object. Just to, you know, this is a module on Drupal.org. There's documentation. Everything I'm talking about in this presentation is kind of on this project page or at the bottom. There's a link to an FAQ. And the FAQ is like everything I'm saying is listed here. So for site owners, if you're making arguments to clients or agencies, there's a lot of information here that you can use. Lastly, I'm going to jump into the module and talk about help and just say, there's a lot of documentation. It's something I take a lot of pride in. I think it's very important. So if I go over to the help section, there's actually, and you're going to get a hint to this, there's a schema.org help module. What that does is organize the help for the entire module because there are a ton of sub-modules. Lots of developers should be thrown off by this. And I will justify it and explain it as I go through. But I can start by looking at the address module and kind of making the point. Everyone uses the address module, and you want to leverage address with schema.org. And there's a postal address spec. So you're going to want to align it. So this module does the integration of address to match align with schema.org's postal address. And by the way, the help sections, all the readme markdown files are just being listed here. And lastly, there's videos. I like recording videos. This is the starting point, and at some point, there'll be a lot more training videos as it evolves. And I'm recording, including other people's videos here. So let's get into it. And I realized I usually build up, and I've decided to start really fast. And so where we start fast is let's just talk about schema.org types and go to one immediate type recipe. I picked it because everyone knows what a recipe is. We use them in the Yamami demo theme. They're easy to understand, and I'm just going to show you how this would work in this model. Or really, how it works. So I can go in and say I want to create a content type. And instead of sitting there going through and building each field, each property, and configuring it, I can say I want to add schema.org type. And you get to this starter page, and I can say I want to add a recipe. This is entirely configurable. And go in, and I'm going to spend a moment on this because this is the catch all. This is in the UI where the magic happens. I'll admit there's a lot of code underneath this. But this is taking a content type creation form, which you see right here. It's bringing in schema. It says, hey, you're going to create a recipe type. Even here, you can browse schema.org in Drupal. I want to come back to this. You say the name of it, the machine name, the description. This is an interesting one. It is blank because there's a dedicated module that manages schema.org descriptions in Drupal so that everything just pulls. It's blank because everything's pulled from schema.org spec. So when you go to edit, you will get a description, but you don't need it here when you're creating it. That description, by the way, is right here. And we'll come back to it in a second. So then you get a mapping. And so this is the field UI of building individual fields. Yellow means a new field is going to be created. The first three are about is to do relationships. So it's going to do an entity reference to content. And I'm going to come back to about cooking method. And this is, by the way, there's a lot going on. A lot of decisions going on. What's going to happen here is it's going to create an entity reference to a taxonomy term. It's actually going to create a taxonomy cold cooking method and take care of all of that for us. And I have the duration module installed. So it's going to do cooking time is duration. So we get nice, clean UI. And I'm going to pause on these three green ones. These are existing fields that are getting mapped to schema.org. And it's a great moment to highlight how well thought out schema.org is. So in Drupal, we have our properties created and changed. Those labels technically are wrong. They're not descriptive enough. Created and changed are actions in a vocabulary in English. Schema, the team was like, no, you got to say date created, date modified, even with translations. They're like, no, language and line code. Language is an object. Line code is a code. You need to say this document is in a language. And we'll see that nuance all throughout schema.org. Like, for example, on web pages, they have primary image of the page. That's the right property name for web pages, because that's what people are really looking for. And they have thought this out. Now, this is existing defaults, totally configurable. But in this UI, you can say, show me some unmapped fields. And I could say, I want to do some alternate names. And this allows us to go in and say, by the way, you can map to existing fields. But generally, what you're going to do is say, I want to create a new field. This is all figured out, but you can tweak this. You can go in and change the labels. Actually, there's configuration to say, I want to add multiple names. So it turns on unlimited. Changes the label. You could say it's required. I generally don't require too much. Schema.org doesn't require anything, except you're, I think, nothing, technically. So I'm going to add this as an example. And I'm going to close unmapped. There's also a search here if you need to just find things by keyword, because there are a lot of properties here. It is mapped. Like, if I do show unmapped, I will have to scroll forever, which, you know what? It's trying to illustrate to the point. Go all the way down to the bottom. And I am generating a content type in a click. And this is, you know, let's think about this. This is probably 20, 30 minutes of work. And just to illustrate what just happened, I'm going to go in and populate it. I'm going to just put recipe. I'm going to create one. This is the develop generate module. It's very useful for kind of testing what we're getting. I threw one up here. We've got a recipe. And what's great? We've got a view. It's structured. The field group module is installed. It started to group the field in a logical way. We have media set up. Go down. I want to just promote. It has nutrition information using a wonderful module called custom field. I will never remember maintainer names, but this module. This is field collections for Drupal. Anyone who's looking for that, this is very powerful, because you don't always want to use a power. I love paragraphs. You don't always need to use paragraphs for key value pairs. At the bottom, we start seeing the taxonomies kicking in. Develop generate does an OK job filling in information. Yeah, I know. On whoever laughed, the joke here is you cannot hit Save because it will fail, because develop generate kind of messed up some of the modeling underneath. But I want to emphasize you get a very clean UI for anyone who's not using the Jin Admin theme. That's the starting point of a clean UI. It automatically starts configuring your node edit forms to sort out that you would want the duration field, for example. By the way, this is the description kicking in. But at the bottom, I even, by the way, there's a dedicated demo module, because I think, yes, we're building structured data, but content authoring is equally important when you're building a site and thinking about it. So the demo module does other augmentation of just putting choices. I think this is the chosen widget. If I go down, you see, for example, taxonomy set up, but I like this taxonomy tree widget, which gives you a very quick browser. All this, as you turn on these modules, that's where things start to get. That's why there's all those submodules. I'm going to keep going. I'm even going to speed up here on something. So yeah, we just created one content type. But what about building a whole site? How does that work? And I'm just going to spin up a very simple architecture for a site. I'm going to go over here. By the way, in the demo, I'm doing everything. Just a little pop-up. There's a module to make sure you don't lose data when you leave a form. I'm going to go over something what I'm calling mapping set. So to build a site, you need multiple content types working together. So there's generally some sequencing you want to think out. And that's what mapping sets are trying to do. So for a common website, when I say common, it's just like you want to demo someone what's going on here. You're going to want person, place, and thing, events, pages. But obviously, you've got to create a place before you can create an organization because an organization has to have a place that it might go. A person would be part of an organization. And events would come later because you need people, organizations, and a place for the event to happen. So right here, I'm going to hit Setup Types. I'm going to click it. And it is basically building out an entire content architecture for us. If I go to Event, it's spinning it up. This is telling us what's going to happen, what properties are going to be created, whether it's unlimited or not. I'm going to fill it into. By the way, you can still preview some of it here. And I'm going to click Content. And let's go look at Event. I like sticking to that one. It's very similar to recipe, but you have an event here, a shout out that you get event scheduling, you get smart date. That's the power of what I'm going to keep going through. But I just want to be, we just built an entire content architecture that takes a, OK. But I want to, you know what, I'm going to level set because it's a good point. This is really simple, right? We all have our own use cases that we need to address. And that's what I'm after to kind of explore it and make it clear to you that, yeah, I spun up a quick site. But if I work for a hospital, we're able to do this to spin up a hospital website. So I'm just going to highlight the features of what I just demoed, structured data. That's what this is all about, schema.org defines structured data. You're seeing it in action. And you're seeing it now that we're able to let, we know what we're doing. And we can do amazing things with the content authoring experience because we can generate it. We can, this is Drupal at its finest. As you install modules, you get a better authoring experience. SEO, I haven't shown it, but it is here. So we're following a spec that is meant to improve SEO. Therefore, you can expose your content using just own LD. And APIs, the same thing starts to happen. Because you have a standard, your API starts to align with the schema.org spec. You don't have Drupalisms in your field names and properties. You can use schema spec. You can automatically have schema's description. And I'm going to start showing how that works. But I want to emphasize some general philosophy things that I've kind of learned a long way. Standardization, this is what this is all about. Taking a standard, leveraging it. You get huge gains from doing that. With that, this is Drupal. Drupal is about composing a great content management system with lots of modules and ideas. And this is leveraging that 100%. And everything you see, I cannot. And I feel like when you ask questions, you could throw curveballs at me. Everything is configurable. You can change every screen thing property you saw. It's like taking the blueprint that schema's offering us. And then we can just, you adjust it. You can configure it. And I want to emphasize the importance of automation. We are building ridiculously complex sites. De-coupling is overwhelming. And the best way to get there is to automate repetitive tasks and to think about it when you're doing it. I actually put the questions here to be like, think about your questions. And I get to take a sip of water. If it's a good question that will, like, what? Oh, custom field module. Yeah, and that's a good question. Yeah, any quite, like, and when I'm asking for questions, is there general broad questions? I'm happy to answer one or two. One more. Oh, boy, you know what's good? I don't know the answer to that one perfectly. Because that schema.org spec ranges the types that you could use. Like, they basically say there's data types. And I think they're kind of synonymous. I want to be clear. Like, I'm not trying to become a master of schema.org. I took the spec, brought it in, and then you're just mapping it to Drupal. Range is definitely the list of types. So if you have a relationship like an event could have attendees, and they could be organization or person. That's the range. Domain I am unclear on. But let me keep going, because this is, and keep thinking about your questions. I think asking questions that help move the conversation more, I'm more than open to bringing them in. So you're a site builder. You're trying to, where do you start? How do you really start? It's all about types and properties. It's understanding them. And in Drupal, there's a dedicated report module. And part of it is to show that we really, I brought schema.org into Drupal. This is what you see on schema.org. You can click over to event. You're gonna see what you see on schema with some augmentation. First, I am trying to track references to help us get the best content model. So these are articles related to how Google wants your events to look. And that's a configurable thing that we can keep adding to. At the bottom, I wanna highlight that this little list is really helpful. It tells us what the default properties are for any entity type that might create an event. And then below it is if I created a node, which is a content type. These are the default properties. These are all the properties available. There's a blacklist to ignore some properties. It just helps clean the UI up. By the way, completely configurable. I just saw these and I was like, I have no use for them. Identifiers should be handled. There's a module dedicated to managing identifiers. You don't wanna actually create an identifier field. From here, it gives you this way, this report gives you a way to a little browse and get some understanding. So for example, structured values kind of align with paragraphs. Like there's a contact point structured paragraph and a contact point. By the way, I appreciate this one a lot. Solves that problem. You have people and they have phone numbers and you want different types of phone numbers like a mobile phone number or a home phone number. That's what a contact point for. It's a point of contact. And it actually is a really well thought out type. Similarly, so I'm in types right now, but if I click on properties, you get all the properties which are 1500 but inverse of I'm gonna keep coming back to, this is relationships. So it says 52, there's actually 26 relationships that schema.org is recommending. And inverse means, I'll show it and it explains it perfectly. If I go to member, this is awesome. So when you create an organization, you can say someone's a member of the organization or the organization has members, the person, and you can build an entire org tree. And basically schema has a spec for it and Drupal supports this because we have entity references and we have the corresponding entity references module allows us to manage this inverse relationship. From here, once you start to have an understanding, you just need to understand how I'm doing this. I'm calling these mappings. So we're gonna create a mapping type for schema.org and mapping sets we went through, but let's go back to that. It's under configuration search schema.org. So we were creating mappings and I wanna emphasize what we did so far. You can see recipe got created here. Media, when you install the schema.org medium integration module, it will create the mappings for you automatically. You'll see everything, oh, see if I click show unmapped. Everything's green because really, our media entity is aligned pretty perfectly with the image object that schema.org expects to. So it's just doing that alignment so then we have an understanding of it. When we generate JSON-LD, we know that our media image aligns with an image object. I'm gonna give a hint of what's gonna happen in a little while is there's all these paragraph types. It is possible to do layout that aligns with schema because schema has small structured values so you could have quotes, statements, videos. From here, mapping types. This is something most people should never have to adjust. It just says I would like to take the node entity and map it to schema.org. This is doing a nudge because our standard installation profiles, articles and pages, and says well we wanna map those to the article or webpage schema.org type. That list of recommended types is here. There's a lot of settings that I'm not gonna go through anymore. And look, the one that showed out, see how media works? It just takes our media entities and maps them to schema.org. Mapping sets. This is just our opportunity to kind of, and by the way, there's even more to this but it's like to test different sets of content types. For example, I could build out an entire podcast by just clicking here and getting the episode series this season and you can adjust that configuration. You can also do a lot of testing here which I wanna emphasize when I show the operations. This is for modeling. You can spin it up, you can kill the content, you could tear down all the types and start over. You can even click view details and export this for content architects. That generates a CSV which I can't, I'm showing that would be too much. This single page ready, this is where I get to emphasize. Everything is configurable. Every screen you see you can adjust and also by saying everything configurable, it makes it very easy for site builders to contribute ideas. If they're like, oh, this mapping set's off or maybe you should have that one, it's trivial because it's just configuration. Now, this might be overwhelming. I'm taking a dual approach to managing this configuration where it's a list of strings where it shows you the convention. Most people, and I might switch this around, can do YAML and this is just YAML to say, here's our mapping sets that we wanna create. They're required because really most sites are gonna have to have their mappings for media but the common one, very simple, machine name, a label and then a list of types. There's a convention that you start to see where I'm saying entity type colon schema.org type and that's where we're doing our mappings and being able to create it. This gives us an opportunity to talk about settings. This will be the longest part of this demo but it's important when I do something like this it's a lot of modules, it's a lot of settings. You shouldn't feel overwhelmed but you just take your time going through it and we're gonna go over to settings and broke it down into general. I talked about descriptions before so there's a dedicated description module. This allows us to change some of the schema.org descriptions. They're not gonna align with what we always want. I also am nullifying some of them where we don't, main entity, you just can't really describe that, that's the main entity and you'd use that to build layout. I'm trimming them, you're getting a hint that there's some next.js support but if I move over to types when we create our schema.org types this is cleaning some things up. Schema.org needs to be very specific. If it's a, they need to say web page in Drupal we can map to, not map but we can still use the name page because we're building a website and like they say FAQ page we can still, the machine name can be FAQ so that's doing a little cleanup here. When I talked about those default properties that's what's happening in this list here and you know what, I'm gonna make it, that's a lot better than I think people can see. This is defining all the default properties so when I create a podcast series I want an actor and a web feed. When I create a TV series I might wanna say actor contain season. I'm gonna make it smaller because I'm gonna have problems going through other things. So this is like the default core configuration but then when I close this you're gonna get a whole list of details elements where these are enhancements. We were talking about events so there's a module, the scheduler module which allows you to schedule publishing and unpublishing content types. This is configuration to be sensible. I know when people, it kinda makes sense. If so much create in certain content types they're gonna wanna schedule it. Most content types don't need scheduling. I've been on sites where they turn on scheduling for everything, it makes no sense to me. It's actually, it makes the UI too complex. So this is just basically saying anything that's an article or subclass of article you should be able to schedule when it's published. Events, you should be able to schedule when it's published and unpublished. That makes a ton of sense for events and episodes generally you wanna schedule publishing. And when I say subtypes so it's a giant tree of data types so when I'm saying episode that means a TV episode or a podcast episode will have the ability to schedule when it's unpublished. Going over to properties, you're gonna see a similar pattern, massaging properties as they're created. Schema.org supports, they don't tell you whether they want single values or unlimited value so we're going to in Drupal have to make that decision and of course this is changeable but right here, just list out. And by the way, this is a better example of some of the tweaks I'm doing. You could say something's unlimited but here, look, scheme is right. The proper machine name for first name and last name and middle name is family name, given name and additional name because that's an international spec. But in Drupal, it kind of made sense to change it to first name and last name because we're used to that convention but this is all up to you to decide. Once again, the same pattern starts to occur that that address module that I turned on is very minor configuration setting was kind of important. I'm trying to map it to postal address. These four properties that address has turned on by default and are required really should be optional. You could hide them too but I felt like that's too much of a decision here. You could see corresponding entity references. This says it generates these automatically if you have a member of or a member field it will turn on a corresponding entity reference and manage those relationships for you. Jason API, so I talked about we're gonna create clean APIs. I just have a fundamental thing is with APIs only expose the data you want people to use. So there's this little trick here where it's saying these are the fields out of core that I think are important for people to see. For example, revision ID is not listed here because no one needs to know what your revision ID is. It doesn't make sense that we're including that out of the box and it says like these internal fields should also like feel meta tags should be exposed. Like we should expose meta tags to end users. Oh, actually it's tags, I misspoke on that one but that's okay. Little adjustments, I'm just trying to massage we have so much information that we can just improve the defaults. Just own API, it expose an API that's just the data, just the content. It's not everything, it's not a fire hose. And there's a preview and you're gonna see that in a second. It gets really juicy. Just own LD, I think this is a very funny setting. It just sorts the order of just own LD properties. Obviously machines could care less about this but for your business owners who are looking at it it helps them have it have some logical sense. At the bottom there's one to show like there's support for custom just own LD to add to the just own LD. That's like the hidden data that search engines would understand. For example, every creative work including recipe is a subtype of creative work gets a copyright. Automatically you could decide not to do that. Lastly, this is important one to pause on. Don't touch this. This is schema.org has a different naming convention than Drupal. It is a camel case unlimited number of characters and Drupal has a 32 character snake case limit. So we have to sort that out. I hate abbreviations, I wanna say that. I hate that when programmers do it I never ever do it but we are stuck because it's just past limitations I think it's a database limitation. So this is just doing that truncation abbreviation figuring out what the proper conventions are. There's actually a report to track it. You don't ever really need to touch this and my hope is this will stabilize our mappings unless schema.org starts to push properties that are totally unexpected then we might have to make some adjustments. That was a lot to go through but now let's go just content authoring I wanna reinforce all that configuration I'm talking about is just about creating a great content authoring experience. Taking that truck to data and making it easy for someone to edit it. And I wanna emphasize that when people talk about decoupling they always forget that you still have to author content. It is a really key thing. It almost becomes more challenging because you don't always get the perfect preview. So you gotta make sure when they're editing it they see exactly what's happening. Just to reinforce some additional features that I kind of skipped over in content authoring. I will stick to my event. We start getting other things happening. Let me see if I can show. Over here is kind of worth pausing and saying so if you turn on schema.org meta tag module it just adds meta. I wanna be just kind of a simple thing that meta tag can't really do out of the box but it adds meta tags to every content type as it's created. Cause we all do that. It may as well set it up. In the demo I'm even doing a, it's a few lines of code that personally I find meta tags to be a fire hose of information. This streamlines, it's literally just an alter hook to say listen these are the four properties I think are important. That's in the demo which will never be stable. It's kind of code that you should just copy out if you ever thought that was useful. But similar thing, XML site map. Every content type should probably go into an XML site map so it just automatically configures and sets it up for you. Scheduling, what I talked about before it just sets it up. Let's see what else we got. Okay, this is a good moment for any questions. I don't mind. I would play with the demos and I need help sorting this out. That's why I built the demos. Cause the demos is everything all at once and what you're seeing here if you installed the schema.org demo and I'm even playing with a profile that will never be stable. I wanna make that statement. This code will never ever be stable but it's a way to get you started to help answer that question. Also a trick for anyone trying to look at what someone else is doing you gotta look at their composer files. There's a composer JSON file which will list required dependencies and there's even a readme file where I track all the modules with notes. There's a composer libraries file which will bring in those modules with the proper patches. This is Drupal. You'll need some patches. So that's a great question by the way. It's a challenge. I just wanna emphasize like but I also decided I'm not gonna hold back. If I see a module that adds a feature that I need I'm gonna do it. Experiment with it. And the fact that they're smaller makes them very stable. I'm gonna show some code on the address integral and you'll be like this is really simple and that's one of the reasons to break it down. Front-end is hilarious because I have one slide for front-end. I'm a back-end developer but I think this is the coolest, I won't curse, cool stuff. And it just gives us like I've avoided talking about JSON API and JSON LD. So let's talk about, oh you know what I'll stay on this content type because I really wanna just give a, talk about Next.js. I think Next.js is gonna take over in the Drupal community. And there's JSON API, first off you turn it on. This is, by the way it's a funny thing. I went in so far as there's a dedicated preview module which does this behavior which it just adds the details here. And there's a preview of JSON API. And I wanna emphasize this is the whole point of there's not that many Drupalisms in here. Yes, Drupal internal node ID but when we go down we start seeing body is changed to description because that's schema.org spec. Event schedule is event schedule. There's no prefix of field or schema underscore. So front-ends can easily understand that. Now with Next.js integration here's a preview, live demos. That's good. Someone made a joke. It's not live unless you have a problem. Let's see. I am so not a front-end developer if it doesn't fix itself I will cry. Okay. That's sad. What is supposed to happen? That's hilarious. Is you're gonna get a preview of this page in Next.js. It's a very, very simple preview. I wanna emphasize it looks like what you're seeing on the front-end in the admin. And what's a drag that's not showing is the more interesting part is I am not gonna build all those previews. I am lazy. I am not gonna sit there generating all those components. So there's, I'm experimenting and we'll see if my team uses it, generating react components from Drupal. Because in Drupal, we know a lot about what's going on here. We know we have a content type called article. It has a title. As general, I'm even pulling in the field groups. Here's the field group. Here we have the body field description. By the way, it's lining with the API. It's not body, it's description. It's process text, how to structure that. You go down to image, it generates the image. So this is just like a quick skeleton of a react component that you can copy. You can download it or you can copy and bring it into your react. If there's even a drush command. So in drush, I could, all those content types I've just created, I could just run a command and it will generate scaffolding, starting points for you to work off of, your front-end devs. To take this a step further, one of the biggest concerns, and I wanna emphasize, this is not 100% meant to be a decoupled solution. I personally lean in the progressively decoupled space these days, where we do wanna start thinking about the future and the future's going to be kind of a decoupled back-end approach. With that, layout is one of the biggest concerns people have. Think about even the Pittsburgh thing, where people are, those are two of the things we're talking about. How do we improve layout in Drupal? I personally am a fan of paragraphs layout module, layout paragraphs depending on how you wanna say it. And I lose track of what's the right order. Because it's structured data. And what we've been talking about is structured data here. So I'm gonna create an about page to illustrate what's going on there. By the way, I want subtyping for one second, is this notion that you could have a content type with a little extra level of specificity without having to create a whole bunch of subcontent types. So I'm just saying this is an about page. Just helps gives schema a little extra information. But what I wanna really spend time on is layout. And I'm gonna click and these components, I just, these all align with schema, so I'm gonna create a call to action. I'm gonna say, I'm really lazy, hello world. I'm gonna use behaviors to style it a little bit. I hope we can grab an image that was generated. There we go. Insert it, hello. We're adding some text. I'm adding a link. I'm gonna link to Yahoo. It makes me feel really old when I still use Yahoo. But I'm gonna say someone's gonna have a text that says search, I'm gonna make it a button and here's a nice, this is something that I haven't explored heavily, but it is really an impressive part of scheming. Is they have something called actions. And action is when someone comes to a webpage, you're saying, hey, this is what I think someone might wanna do when they come to this webpage. This is the next course of action. This link, this information is important. So instead of saying it's a view action, I'm gonna say, hey, I think someone might wanna search here. I work in healthcare, someone might wanna register for an appointment or schedule. I think it's more like schedule and appointment. It is a really powerful spec that they're, I don't see, to a Google, I don't think it's 100% leveraging yet, but it is a really interesting concept. So I'm gonna add my little CTA. And this wouldn't be layout if I didn't say, hey, let's do two columns, 101 is a two column layout. But I do like going really simple now. Of course, you can add a quote. That makes sense at Schemeward Habit. This is a quote. I'm gonna add it, it gets added here. Scheme is even so well thought about that they have something called the statement. Instead of just a component that's like text, obviously it's a statement about your organization and you could say, no, we are great. Okay, I'm gonna hit save. I mean, things to say about layout progress is to say it's amazing. You can edit things on the front end easily, the accessibility is beautiful. But what's more important is how do we start decoupling here? So at the bottom, if we go down, let's close here, talk about JSON API for a second. So JSON API exposes all this information about layout to the front end. People are doing this. We haven't totally tied on it. I don't wanna emphasize the entire layout that's being exposed here as main entity, the JSON LD. I'm gonna stick to the JSON API for a second to say we have all that layout data here. Here's our, let's see if we can get to one. Boom, our CTA, which I'm, it's saying, here's the CTA, here's the styles, here's a bug, it's interesting that the CSS classes don't come through, they come through as numeric values. But here's the button, here's the attributes I want on the button and front ends can start building out a decoupled front end. Going back up, and I wanna emphasize the search engine optimization here because most home pages don't have this level of SEO. Every single component we put there is being exposed. They're called main entity, so we have a webpage, we have an image object, I put a quote in, here's the quote, here's the creator of the quote, here's the statement, and here's the potential action. That's actions kicking in at the bottom. Gonna keep going, back end. Okay, so I got 13 minutes, I think I can pull this off. I don't usually go into code, but there's some stuff that is so simple and cool that it's worth showing. Let's just take it for granted, there are hooks, right? We know what hooks are, there are ways to alter things. In configuration, I don't even need to spend more than saying there's a lot of configuration you can change. But on hooks, if I go over, so I'm inside the Schema.org Blueprints module, I'm gonna go to the API PHP, everything's entity, so you already have those hooks out of the box. I'm gonna make this a lot bigger and show you my favorite hook that I've ever created, probably. Okay, and this is hard, because it's such a massive hook. It is a massive hook. It is doing so many things at the same time, but it kind of makes sense. When we're creating a Schema.org property, it is allowing you to alter it. It's telling you, I am adding to an event a event schedule, and I'm using these storage values, and inside storage values will be the type of element, maybe a smart date or something like that. So this is how I'm gonna store this property. Here's the values, the field values on how it's gonna be attached to the node, and then even how it's going to look on the form. That's a widget ID. What are the settings? What's the formatter ID? What are the formatter settings? So this is like a catch-all. There are like five hooks being merged into one, so you can literally in one place just start changing things that are happening on the fly. And that's how I'm doing all those integrations. So we install module, the address module, you can go in and tweak it. From the actually worth going into the address module to talk about it. So you could assume, I just wanna emphasize, of course there's a Schema.org settings module, very simple, lots of configuration here. It's easier to show you something simpler and say address. So I'm going to address. I will start with configuration and say that, I showed that in UI. This is a very simple configuration object. The module, just to keep in mind, there's not a lot going on here. It's just integrating addresses from top to bottom. I'm using that altar hook to basically say, okay, I'm gonna create an address field. Let me alter the field overrides. Let me take that, those settings, and apply them as this property is being created. This one, which should not, oh, this is taking the address field and mapping it to Schema.org's postal address. Doing some concacation, sorry, stutter. And at the very bottom, I do wanna emphasize, if anyone saw Vim's presentation on the, what is it, it's such a complex, what? Yeah, configuration validation. There's some huge opportunities going on if we start getting our configuration aligned properly where we have the validation in or we have data types that say more. So even the fact I am leveraging a simple concept, you don't need to do a lot. If you know someone uses this arrangement, ready? I am saying what the settings file is, schema.org underscore address.settings, and here's the property and here's the settings. I don't even set the default value. There's code in the background that's doing all the configuration management for this module's alter, you know, it's altering that one page, but it's figuring out here's the default value because I know where the settings are coming from. And when I'm saving it, this is how it should be structured. I'm gonna keep going. I'm gonna, oh, I like that. I'm actually good then. I think it's like slow down and breathe for a second. Okay, Drush, I'm not gonna do a lot of Drush stuff, but I wanna emphasize everything I showed you can be done with Drush. You can automate everything. I will type Drush, I'll get the list of, and I'll just show you like every action I've taken during this presentation, you can do it. You can set, the mapping set, I just abbreviate to set. You can run a mapping set and command line to tear it down, generate it. You can generate individual types, that React component stuff is there, and there's some utility download schemas for me to download schema.org spec into Drupal and get it working. But there's a lot more to show on supercharging this because I wanna talk about starter kits. And I wanna, this is my big finale on this. There's not the recipes initiative, but there's some alignment that's gonna happen with the recipes initiative because I'm doing something similar. I'm giving people a starting point, I'm generating configuration, I'm getting your site set up. What you've seen so far is, I'm just generating content types, but we need more than that, we need views, we need to adjust it. So I've been experimenting with a starter kit and I work for a healthcare system, so I'm gonna show you their starter kit and we've contributed it back. It's called the schema.org hospital starter kit. And you're seeing I need a sequence, I need to create people first, organizations, business, medical clinic. Wanna emphasize something about schema which I think they're right on? You gotta distinguish organizations from businesses and organizations, a bunch of people working together. I tend to be inclined to say, organizations do not have locations and they have members versus business, has employees and has an address, it has a place. And medical clinic, physician, hospital are all subtypes of medical business. And I can give you a demo of it. Let's go. Okay. So starter kit, it is a module. It's a fairly simple module. I'm gonna go in and just install the starter kit which actually will turn on geolocation and mapping which I'm going to not demo, but I wanna emphasize, this is this idea, we have these types, we have this information, what can we do with it? Well, if we're building locations, obviously we might wanna map. So it's installing the module, it is setting up, give it a second, the entire hospitals, basically the hospital information website, like what is a hospital? We're gonna build other starter kits for other parts of the hospital, like there'll be a medical information starter kit I'm expecting. And you can generate some content here for it. Yeah, I'm really good on time. Okay, let's see if I pick one that's kind of good to look at. Let's see. Could do medical clinic. It just sets up a medical clinic with geolocation set up with our address just working the way we'd expect. I'm not gonna start showing you any contact points kicking in because lots of locations have multiple contact points, ways to contact them. I'm leveraging in a great module called office hours. It's the perfect module to manage multiple office hours. At the bottom we start getting all these relationships, taxonomies. Now I'm gonna dive into the code and I wanna emphasize there's not a lot of code here. What the code is, is, okay, we're in the starter kit for a hospital. There is a YAML file. Think of this like a manifest of the types I wanna create. Really the goal in this file is to say I wanna create a person. These are the properties I must have on the person content type. These are the ones that like I want contact points. I even went so far as you can turn off properties. Now you cannot, if someone else has created a medical organization with an address, it's not gonna delete an address. But when I, in this starter kit, go to create a medical organization, I am saying explicitly I do not want addresses created. If someone configured it that way, it's going to turn it off. This file is read before the module is installed. It generates all these types. Then it goes through a step of configuration management. It basically looks at your optional config, what else needs to be installed. I am doing some path auto stuff because that, I can't make that decision. You can't really automate the idea that if someone's creating a hospital, a medical clinic, and a medical business, you're gonna want the path auto to be locations and all them grouped together. Similar thing as I'm creating admin views. Just to get people started, and I'll show an admin view fairly here. Right down here, by the way, this is dashboard. The demo is just trying to leverage it. I'm just sticking these admin views in shortcuts, but you get all your locations and some geolocation turned on. It's just to help push things forward. But what I emphasize, it's not a lot going on here. It's a path auto of views, and then I will give a huge shout out to this pattern, which hopefully will make it into the recipe, and it's called config rewriting. It's where you can adjust, exist, and config, make minor, minor tweaks. And the best minor tweak that I could point out is when I'm creating these content types, I don't really want people to add them to the menu. So it just says, hey, you know, it assumes you have the menu UI and it turns off adding it to the menu and it removes the last updated date stamp at the bottom. You'll see similar augmentation here. I'm going in and just saying the view display mode, I don't want to show the labels for address and image. So that's all the code needed to generate an entire hospital website. Now, my developers criticized the hell of this, like, okay, you're doing so much here, what the, how do we know it's going to work the way we expect? So they pushed back and they were right to do it. And they forced me to think about, well, how do you prove that this is going to work every time? How do you set expectations reasonable? And I'm taking this five minute marker, good. I'm taking a cue from visual regression testing where you have a website, you run this test suite and it takes a snapshot of all these images of what it looks like and saves it. And then if someone's working on it and something changes, the test fails and you know what just happened. And I am doing this test and I'll show you the snapshot. And I want to emphasize the snapshot here shows you most of the config that's generated for everything that was dynamic. It's right here. So this is stable snapshot. Anyone using this module should leverage these snapshots once they start setting up their site. This allows you not to, by the way, the moment you export configuration, not my problem. That's the whole goal of this. And what's great is if you're not happy with what you see, you still have all of Drupal to configure the hell out of it. But up to that point, this snapshot ensures you're getting what you expect. If something changes which it will, you'll see it. You'll see a diff, you'll know. And most of the changes will be sensible. They'll be minor fixes. And the snapshot test is one of the easiest tests I've ever written. It is two pieces of information. You are literally giving it a list of modules and you could even say I have these extra modules for your snapshot and here's the directory. In the background, it's checking those things. Even to generate that initial snapshot, you run the test once, it fails, but while it's failing, it generates a snapshot for you. Because basically, if there's directories empty, it's going to fill it. With that, I am wrapping up the benefits. Standardization, this comes back to, we can standardize. It really does start to simplify things because we know what we're doing. As soon as we start the site, we have a concept. And this all leads to making things. It accelerates the whole process. We're able to get things in so much faster. Yeah, easier, simpler, and faster. I have this conclusion. I think people are going to be thrown off by it. Because this is what the lesson I learned. Drupal's for content. That's what I think we need to think about a little bit more. We do a lot in Drupal, but at the end of the day, when I look at all the modules and what's happening here, it's all about we have an amazing tool to do great content authoring. And that's what distinguishes us. And I think the ambitious type of thing is really important to go back to it. I think that's what's going to happen in the CMS market, where the people who can do content right are going to have a certain space, and they're going to hold on to it. I'm going to end there. I have one minute more for questions, but we're all going to lunch, so I will stick around. And this is going to keep recording. And I make me repeat the question. So yeah. Clear when you're starting to build a new site. What about those of us? So I have an old site, and I'm building a new site, and I'm migrating using Drupal Migrate, Drupal to Drupal, and redoing the architecture, because we have so much technical debt, it's better to start over. You could do in-place migrations, too, which is on my radar, but we have too much technical debt. Like the in-place migration would be you'd generate the event content type, you'd prefix it maybe with schema underscore, and then you'd migrate. You can do mappings of existing sites to the Gison LD, but it's really meant for new sites. I've got to admit, because then you are getting the best out of it. You're like, you can keep iterating on it. There's some token integration. I mean, the custom Gison LD that I set up, that really is the secret. Like that's giving us the potential to take existing sites and sort out. I think there is token support. I don't know if there's token support in there, because I run into some problems, but I understand the question in the sense of we've got to keep working on it. I exported their CSV. It's directly, it's in a data directory. The good part is, they've been working on it for a year. They're not committed to any updates, but it seems like every six months, they're pretty committed to backwards compatibility, so they're only adding things. And they're generally only improving descriptions. Occasionally, I am using pending specs that are fine. A note on that is, this scheme is not the same as Google. Google has their subset called Structured Data, and only certain properties will be paid attention to. Not my problem. No. No, but I've seen it in my organization. I think it's kind of becoming a given. It's sometimes it's not SEO. It's the fact that you're rea- I didn't even call it out. FAQs, I don't demo it. If you have FAQs on your site, that's immediately there. It appears in schema. I'm being told to wrap it up. I'm going to take two more questions and say we're done, and I'm going to stick around. Yeah, you both of you, it's fine. Yeah, 100%, that's the beauty of this. Like, I have struggled with naming properties forever, and now you can create a property, primary image of a page, and that's primary image of the page. You can do different, like, if you need to change a property so much, I'll give an example. Some properties could use entity references, but in some contexts, you might not use entity references. You might want to use strings. You could create a different field name and still have it mapped to schema.org properly. Well, the biggest plea for help is writing about this. I am actually in a vague way getting sponsored for this because my organization is using it. If you write a blog post, that helps me immensely. With the starter kits, it's just trying it out and giving feedback. I mean, the big thing I need feedback on is getting these types right, the defaults. And that's easy. Anyone could contribute to that by looking at their organization and being like, well, we need this. This property makes sense in a broader, making the argument, saying like, with events, it was like we need repeating events. We need event scheduling. That's an important feature. The starter kits I feel like is the thing that's going to evolve heavily over the next year. My joke would be if I was to get another presentation to next year's DrupalCon, it's going to be those starter kits. Because that would be where you start. You'd be like, now we've solved sectors in the community. Now we have ways to just spin up different areas. And the other part about starter kits is, yeah, it's like I'm going to do health care. But there's other industries. There's opportunities here to experiment with. And I think people can collaborate. And the other part is what's great is you can do whatever you want. They can use it, spin up the site. And I'm struggling with this one notion of what is stable? I don't know if this should be stable. Because really, you use it, you get your site, and you move forward. And we should be able to keep iterating and improving what's coming out of the box. So I'm going to say it's over. I'll stick around for at least 10 more minutes if people have questions. And I don't mind.