 All good now? No three, okay, sorry. All right, so hello everyone. Thank you very much for coming. Today I will be talking about best practices for long-term management of Drupal sites basically. Before I start talking about specific items that I want to bring up, I'll just quickly say something about myself, about my experience. I'll cover what would long-term best practices mean and I'll basically set the stage before I start talking about specific items. About me, I've been working as a Drupal developer for 14 years now. I have pretty wide experience when it comes to teams, companies, and industries. With teams, I've been working on projects where I was the sole developer that did everything. I also worked on bigger teams where there was more than 20 people. With regards to companies, I worked with startups, I worked with enterprises, I worked with everyone in between. I worked also with organizations, meaning nonprofits and so on. And when it comes to industries, I also was lucky enough to be involved in many different industries. So from healthcare, education, government, sports, insurance, and so on. Over time, over these 14 years, I've been involved to more than 200 websites. I think I was trying to count these days and the number was a bit more, but so let's say around 200 sites for the clients. The oldest Drupal site that I'm still working on is 17 years old. And the one that I've maintained the longest since the time I've built it is 12 years old. So this is really all to mention that I've seen many common pain points across different industries, across different projects, across different companies and so on. And those pain points are really what I want to talk about today. So before I start, I mentioned that I'll try to clarify what the long-term best practice would be. So I'll try, I try to boil it down to, it's hard to specify, right? Because you don't know what's coming. And when we talk about something that is long-term in website sense that could be five, 10 years or even more. So it's basically flexibility to respond to whatever comes next because things might change within the company, things might change within the market or simply new features are being added. One of the things that really helps with being future-proof is consistent setup that is easy to follow and a solid foundation that minimizes future limitations. Now these are all very generic terms I know but as we get into the future's next slides I will try to elaborate on each one of those. And basically for the people involved in the project what we are trying to do is to lower the friction whenever they deal with it. So and we lower the friction for people that already work on the project as well as for the ones that will be joining. So we look at the project that is being used for 10 years, 12 years. There are very high chances that most of the team that is involved will be new, right? There will be new developers, new administrators, editors, managers, designers and so on. So it all needs to make sense or at least we need to try to create it in such a way that it makes sense for all of them in the five or 10 years when they joined the project. This will result in shortening the onboarding process because if things make sense for developers they can be productive quicker. And they can reduce the necessary background knowledge. So many times when you join a project there is this whole story that you need to understand before you can actually be productive. And that story can be, oh, this is how the product evolved or this is where we were before, this is how we changed and this is where we are today and that's why things are a mess. So those kind of things we would hopefully try to minimize at least. It's impossible to really completely eliminate all this but we should try to minimize and try to do things in such a way so that there are less chances of encountering those problems. So the focus of this session are going to be three things. So first of all, universal pain points. Not all projects are the same, not all industries are the same, not all companies are the same. So giving very specific set of examples that would be universal is hard and it's not very productive. But I'll try to, I picked up several items that I saw that were reoccurring in all sorts of projects and I will be talking about Drupal specific practices only. Now this is not to say that other practices shouldn't be in place, things such as good coding principles, good infrastructure setup, DevOps documentation and so on. All those are very important but since we are at DrupalCon I wanted to focus really on something that is very specific to Drupal. And my hope is really to provide a way of looking at things rather than strict instructions. So more like a guideline or a state of mind that you use to approach especially new projects and also that you can maybe implement in projects that you're working on already. So with all this said, I can start talking about the first big section that deserves to be mentioned and that is the field strategy. So I mean I've been long enough around with Drupal to remember the CCK or the content constructor kit. That was one of the things that actually hooked me up on Drupal and because it gave you a way to back in Drupal five days, you couldn't create, you didn't have all the great tools that you have right now. So you needed to install this contrib module in order to create fields and create content types. And this really, I still remember how it blew my mind because you got so much power to do right from the admin because you could just create stuff, you can shape basically the structure of your site no matter how many content types and how many fields you want to have. Now, fields are basically are attached to entities and they store individual pieces of data to simply put it. And there are several reasons why fields are so important to talk about and I think this is often overlooked. So first of all, every single Drupal project is going to use fields. Fields define the structure. They do belong in the business logic. So in one way or another, you will be using those fields to calculate stuff, show different workflows or simply use them in different places on the website. And fields, as I will show on the next slide, affect a lot of different parts of the site. And most importantly, fields are very hard to change later, structurally. And that is why I think it is important to mention them, especially within this context of long-term maintenance of websites. So that we can pay attention to those things and at least understand how will that impact us later down the road. So the areas that fields affect, so first of all, whenever you create a field using the field UI module, the Drupal in the background creates actually two new tables. So if you have 50 fields, that means that your database grew by 100 tables. Those database schema is basically the structure of the database that powers the site and that database schema is directly impacted by the fields you add. Next would be the queries. So whenever you add a field, that field will be used in one way or another and it needs to be fetched from the database. So the field name and the field itself will be part of the queries. Those queries will be, are used by contrib modules. They can also be used in the custom modules. Custom logic is also one of the areas where you will be using fields a lot most likely if the website is doing any kind of calculations, analytics or simply displays different things based on conditions, it will be relying a lot on fields. Configuration itself can also rely on fields such as form display or managing the display views of certain entities. Templates and styles are also something that is not usually mentioned, but most likely you will be having, you will use those fields within the templates. Now fields can be used within templates in parent entities if you want to print a specific field in a specific container or in a specific location. And they can also be, you can also override a specific template for a given field. And styles, quite often you will simply use the machine name of the field to set a specific style. And the list goes on. I mean if you have for example a headless setup, you will be again exposing those fields to the frontend app. Now we have one more thing that actually depends on the fields. And same thing goes if you expose a simple API that another third party would use on the website. There are several things to consider when we talk about fields. First one is the machine name. And the reason I mentioned and the reason I stress so much this fields and the naming is that you cannot change machine name after it's done. So you can only migrate it to a new field and this is not a smooth process. This is not something that is supported by Drupal. This is something you need to do on your own. Done it many times and it's not, it involves several steps. You need to create a new field, migrate the data, update the logic, update the styles and then only then you can remove the previous one. So especially for bigger projects, this is not something you want to spend time on. So ideally you would create machine name field that makes a lot of sense for a given use case because it will be used everywhere. On the previous slide I showed you all the different areas that are affected by it. So if you have for example, an API that uses a specific, that exposes specific machine name and then you have a headless setup or a third party service that is using it, all those things need to be updated. It is also important to understand the difference between shared fields and dedicated fields and to know what can and what cannot be shared. So when you have shared fields, not everything can actually be shared between the instances and some things will be automatically shared. So for example, if you have a field image and you use it in one content type and as a single upload image field and in the second one you want to have unlimited or more, if you change that setting it will actually affect the first content type as well. So from that point of view it is important to understand what actually is shared and this is heavily dependent on the field type you are working with and to really know what will be affected. So in those cases for example with the image what I tend to do is to create a generic field underscore image and field underscore images. The one that is called images is the one where you can upload multiple. The one that is called image is always a single one. And shared fields can often are easier to work with if you can find the shared fields. So for example, when talking about shared image field you can actually share the logic and you can share templates even though the same field is used across multiple different entities. So that makes things easier to manage for you as a developer or for you as a site builder. There is one more thing to consider here and that is the fields added through the field UI module versus code. So when you use the, most of the time you will be using the field UI module, right, you will create fields through the admin panel. This is different to creating fields through the code when you add a field to entity definition or you add a specific field to an existing entity. This is a lot more verbose but has a lot smaller footprint within the database. Just something to bear in mind. There is no right or wrong answer here. Most of the time, field UI module is the one you want to use because it is a lot easier to manage and also to create initially. What, so having said all this, what would be the recommendations for fields? So my first big recommendation is plan ahead. And I think of several times in the past annoyed teams with extensive planning on fields. But I think after a few months then it was apparent that it was a good call. So my biggest recommendation is really to choose the naming carefully and to understand the pros and cons and understand fully the choices you are making because the fields will be storing all your data and the fields will be powering so many different areas of the site that you cannot change. And the worst thing is as the website grows bigger and more work is added, you become even more dependent on your wrong choices. So that's why it is very important to really try to plan as much as possible ahead and choose the names carefully. So for example, my personal preference is to go with verbose names versus abbreviations. Simply because you should be always thinking long term and when new people join the project. So abbreviations might make sense for everyone involved right now. But in a one, two, three, four, five years that might not be the case anymore. So, and one more thing really when it comes to naming that is consistency. So if you use plural, use always plural in the same context. Same with singular, same with the way you name, same with the order in which you name fields and so on. This will just lower the friction you have in understanding what's going on and building the site. It is also important as I mentioned to understand the pros and cons of all the choices you make. So shared fields versus dedicated fields, fields added through field UI and code and so on. And lastly, I want to say that I think fields, all the fields on the site should always be documented. It doesn't have to be some big elaborate project to do that but just a full list, machine names, what do they do, that kind of thing so that developers and also site builders can reference that. I'll give one example of how things can go really bad. And that was one of the projects I joined midway through, halfway through. It had about 70, 80 fields across three content types. Now, all these fields were heavily used in business logic. So there was a lot of conditions, a lot of, there were some calculations, there was all sorts of things going on. So those fields were really used a lot. I think there was maybe a few hundred references to those fields. Those fields were also used in templates and they were also used in styles. So they were very tightly, they were in the roots of the site, let's put it that way. And even though there were three content types, there was no sharing of those fields whatsoever. So you would have the same field named differently for a different content type that does pretty much the same thing. And the main problem came when they decided to use unofficial industry-specific abbreviations for fields. So it would have things such as D2C, ACC, three-letter abbreviations that made sense at the time for the owner and for the product owner and for everyone. But first of all, they were unofficial. Second of all, developers were outside of that industry so they had no clue what did they mean out of the box. And the main problem arrived when these evolved or changed at one point. So the project was actually successful and the company grew and their scope slightly changed. So because those were unofficial abbreviations after some time they started referring to them in a slightly different way. So ACC became something else and so on. And that created a big mess because no one wanted actually to deal with that. In the admin, no one wanted to deal with it in the code. No one knew really what to do and you would spend five times more time just to get something done. So it was a big, really source of big confusion for everyone. It was very hard to make changes. And what they ended up doing after assessing what's needed to change all that, which was humongous basically would need to change a lot. It was a several weeks project which they couldn't afford at the time given what was going on otherwise. So what they ended up with was a crosswalk document that was very cumbersome to use. So not a deal solution and I think in this case what they would have benefited from would be if they used more verbose names for fields they would more explain what it is and then the label itself can always be changed. Label, description, the things that are not intertwined with the rest of the site. So having said this, I can move on to the next area and that is the entity strategy. The entity strategy is going to be a bit similar to fields with several key differences. So first off, entities are basically containers for your structures, for your structure, the folders, nodes, the terms, the users, whatever custom entity you create and so on. They store all the data that will be powering your site. Again, just like with fields I'll mention a few reasons why entities are important to talk about and they are that every project will use them. They are tightly again coupled to business logic and they have same affected areas as fields. So if you go back, they affect everything from database to code to configuration to the theme. So there are several considerations here. First off, you need to weigh in a few different options that you have. Unlike with fields, you have more options to choose from with entities. You can choose between what core gives you or what contrib modules give you or you can decide to create custom entities. Creating your own entities through code comes with maintenance, but also with big flexibility. Using existing entities is a lot easier, at least initially, but you will in most cases be adjusting what they give you out of the box. When we talk about entities, I think it's important to logically group the data. So, and the reason I use logically here is that I've seen many times using a single content type or an entity for multiple purposes, where it might not always be, might not always make sense. So you would have entity types, which means basically a different type of entities and bundles, which are different types of those types. Let's say subtypes, entity type would be a node. A bundle would be a page article or anything else that you would have as a node type. Another entity type would be a user or a block. So entity types would be big groups and basically bundles would be inner categorization of those. I will come back to this article problem in a bit, but it is also important to think about how will that entity be used? Is it a single purpose or the purpose is shared across multiple areas of the site? Another thing to take into consideration is are the custom content versus configuration entities. So when you're creating entities on your own, you have two options basically. They can be content-based or they can be configuration-based. Content, the main difference is where the data lives. So does it live in the database or should be part of the configuration so that you can export it and store within your Git repository? Another thing also is how you want to manage those fields. Do you want to manage them through the field UI or you want to manage them through code? Field UI is of course more appropriate for content-based entities, whereas the code ones are for the ones that are configuration-based. There are several recommendations here and the first one, the biggest one, differs from what fields do. So the first thing I would say for entities is to avoid sharing entities for different purposes. Coming back to the article entity, I've seen it many times where article is actually used for posting actual articles, knowledge-based articles. It's also used for press releases, news, and so on. Initially, this is always fine, but if again, we think about the long term of the project, those press releases after a while might need a few extra fields. Knowledge-based articles might need a few extra categories. Something else might need different logic, maybe two different ways of displaying. So after a while, this really becomes too hard to maintain because you need to have a lot of overrides to cover all use cases and usually it ends up in a more convoluted setup where editors are not exactly sure why do they have all those fields available, when do I use this, when do I use that? And so my really strong recommendation would be to avoid sharing the entities for different purposes. If the purposes align, that's great. You save yourself a lot of time because you can share a lot of things from templates to logic to so on. But more often than not, it's better to split entities for different purposes. Next one is, again, the naming. I think the naming should again be chosen carefully. Verbose is better than abbreviated. Use a consistent pattern. If you use singular, use always singular. If you use plural, use always plural. That kind of things. And finally, just understand the all the different options you have. You have core or contrib entities or custom. You have custom content versus custom configuration. You have separate entity types versus bundles. Now, when it comes to this, there is nothing I can tell you to use as a rule of thumb, but you just should understand all the different options and what are the trade-offs. That would alone help you plan better. And lastly, I think just like with fields, this has to be documented and has to live somewhere before you even start making something. And just like with fields, I'll give you an example of how things can go actually well. And so for one of the projects that I'm still involved in is needed a custom content entity. I actually needed an entity initially. Entity was very specific in a way that it had a lot of fields. It had 128 fields. I actually counted that yesterday. And all of them were required and there was no sharing needed. So if this was created, my initial thought was really to create it through the field UI, but luckily I created a proof of concept. So basically I created a new clean installation where I have presented myself with two different options and then I started using them. So the first option where you would use field UI would result in 256 new tables added to the database. So this would be big, big increase in the database footprint, not to mention the rest that is already going on there. And this was, I did not like this and there was of course a performance penalty because in order to load a single node, you would need 128 tables to be joined and data loaded from. And alternative to that was a lot more verbose because it involved code, but that was a lot cleaner solution in the end. So the solution was a custom content-based entity that where all the fields are actually created in the code, so all the fields are still added to the database, but not as separate tables, but as columns within the base entity table. And this resulted in good performance. Another future looking win was at one point the company wanted to get the reports on which data was used and how, what were users entering and so on. So reports were very easy to build because everything lived in a single place. So queries were very fast. You could do all sorts of things versus if you were trying to look up through 128 tables. The database footprint was smaller and the admin was cleaner. Cleaner in a way that since it was a custom content entity, again, more code initially, but it was easier to control and to choose where is that actually being displayed. It wasn't part of the regular content. It wasn't part of the rest of the site. Now, next section I want to talk about is less serious than the previous one, but still I think the wizard mentioned. And that is, that's the roles and permissions. So roles are basically job titles on the website, right? You have, they're usually something that you set initially and you pretty much leave it to that. And, but they do have a lot of implications and they can cause to the general confusion on how the website is built. Roles are important for two main reasons. First one is obviously the security. First one is the security. And the second one is to make sure that the right people have the right kind of access. The common problems I've seen with wrong permission and role setups is that they tend to be forgotten. They tend to end up in a mess. You would have either a lot of roles or a lot of permissions that are over sharing. So people, everyone would have an administrator account. You don't care how, what exactly can they do? You just give them administrator account and move on. Because it works in the short term but on the long term it can create issues. There are two main approaches that you can have when it comes to roles and permissions. The first one is something that I would call role centric where that revolves around the role of the user on the site. So this is what is used by default and this is something that everyone can recognize instantly. So you would have roles such as administrator, editor, manager, subscriber, and so on. On the other side of things, you have permission centric approach. Permission centric approach would revolve around capabilities rather than the role. So what does that really mean? That means that every role is not a job title of a person on the site but it rather explains the capabilities on the site. So you would have roles called manage configuration, manage content, manage users, and so on. With this approach, it's a bit more explicit because then if you're editing a user account, you see manage users, okay, so this person can actually manage users or this person can manage content, configuration, and so on. Whereas if you look at something generically called manager or editor, you don't know if they can actually edit users or content or where is exactly the border. There are several recommendations. Even though the other approach can be alluring, I think most of the sites would benefit from the role centric approach, simply because it's how most of the projects would work. It's automatically appropriate, I think, when you have different types of front end users. Because if you have different types of front end users, be it subscribers or customers or something like that, you already have a business name for them and it's easier then to identify them in the admin by that rather than their capabilities. Permission centric on the other side, I think is more appropriate when you have different levels of people using the back end and when on a person to person basis, you might need to mix and match the permissions. So instead of creating a new role, for example, editor level one, two, three, four, five, just so you, some editors can edit this, the other ones can edit a bit more and the third ones can edit even more. Instead of that, what you would have, what would be more appropriate would be if you had a basically permission centric approach and then you would, for each individual user, you would select several roles that they need to have. That way it would be easier to manage and it would be a lot more easy to understand. And last recommendation, kind outside of this, but I think it's worth mentioning, especially because one of the clients has recently had issues with that, is to really use role expire for accounts with back end access. So role expire simply expires the role after some time and just make sure that people have, the correct people have access to correct things within a given time. So you don't have someone that has worked on the site 10 years ago and they still have administrative rights. I will hurry up a bit. There are some quick mentions that I will go through, but then there's going to be some time allocated for questions and yeah, you can ask me to elaborate on any of these things. Quick mentions are, first one is custom admin theme. This one is a bit strange, but I personally, for the past maybe seven or eight years, I've used it on every single project. Basically sooner or later, you will need to customize the admin panel, the admin theme, style of reports, or if some big views have a lot of filters with a lot of fields, with a lot of buttons and out of the box, the admin themes will not always cut it, right? Sometimes they will break in a certain way and especially if upper management needs to go in and have a look at something, they will not like it. You have a couple of different options, but I think storing this in modules is easy, but not the most optimal. Since anyway, Drupal gives you the way to have a custom theme for the admin, custom theme for the frontend, I think you should do it then properly and decouple that logic or that's those tiles and overrides to a custom admin theme. So all those adjustments should live in the theme, not in a module, I believe. Last thing is just because I use a lot, gen-admin theme is that it doesn't really play well with child themes, but for basic overrides, you can be just fine. The next thing to mention is the in-admin documentation and again, this one is a bit, maybe a bit unusual, but I think that since Drupal makes it so easy, I think it is a very good practice to put into place. So basically, in-admin documentation is documentation that is part of the Drupal site. So you would have literally a content type, maybe a taxonomy, maybe a set of views and pages that are accessible only to people with back-end access and that give them documentation on what's going on on the site. I found that this really gives them zero excuses and zero friction because if you're already logged into the site, you can access it. It's not confluence and you need to find it. It's not another system where you need to log in and where you need to figure things out. So, and the most important thing here is that it can be contextual. So you can always have a block or you have something else that is displayed on the page where they do something important and you can link it to the page that gives them more information. And since it's part of Drupal site, you can actually allow them to edit that. So over time, they really have no excuses in the sense that it wasn't clear. It's not useful or something. They can always create, make a screenshot, put it there, save the node. All the editors can see it and you can move on. So it really empowers the editors and the managers and reduces the load on developers. The next item, there is two more items I would like to mention and I'll try to speed up, would be entity logging and tagging. So all data with a context can be invaluable. I think many times, at least in my case, clients would come with requests to get some data that was not collected. And I think with Drupal, it's very easy to have additional entities to store extra data and reference an entity and it just lives somewhere in the system, knowing that no one else can access it without sufficient permissions. But you can always attach important logs and tags to entities. Tag, logs, I mean, for example, if we take user accounts in a subscription-based site, what happened? Your account expired on this date. You purchased a new one on this date and so on. If you have this kind of logs, it's a lot easier to debug. It's a lot easier to understand what happened and it can also provide additional information to management. And of course, you can always store the data first and then afterwards make use out of it. So think about this because I think a lot of times, it's easy to make it initially and then you can later figure out how to use it. You cannot do this the other way around. And the last one is really to rely on core as much as you can. So choose core over contrib whenever you can. I think core will always, it's safe to say that core will always be more future-proof than any contrib modules. And lower number of contrib modules is a lot easier to maintain. So you would have people that are familiar with a bigger, deeper, let's say groups or modules that provide bigger pieces of functionality and then you would have people that have never used it. So whereas if you rely on what core gives you, there are a lot less chances to have someone who is not familiar with something. And last one is to understand what's given with core. And I say this for a couple of reasons. First, you can achieve a lot with what Drupal gives you. And second, you can always use core as for creating own features and as a blueprint as an example. Again, long term, if you follow what core does, you're safer than if you follow what contrib module does or some creative approach. I'll speed up. So thank you very much. Now would be the time if you have any questions. I, thank you. I know I can be intense with things, but I hope you, if you have any questions, you can remember them now and yep, sure. Let me. A quick question. In the good case where you have your custom entity with 128 custom fields. If after two years you have two other fields, you have to go absolutely with code, no fields UI, right? No, you don't have to. You can use fields UI, but I mean, in that particular case, it was, it has happened over time that we added more fields and more fields were added through code. Again, for the same reasons to keep everything in the same table and so on, but you don't have to do it that way. So it's an option. First of all, thank you for such an interesting topic. I have a question. For example, we have a content type and several fields and the client wanted to change some field, just a caption, just a title. But it's, yes, it's still text, but it has different meaning. So what do you recommend? First option, just to rename it. Second option, remove it and move it to the next. Or maybe just leave it and create new one. It depends on the level of change. If it's something that is, now that field becomes something else, then maybe you can consider redoing a field. But I would generally strongly advise against making those structural changes for labeling purposes. Unless, try to make sense with the original ID, with the original machine name. Label can change, description can change. Those are disposable in a way. You can change them over time, they don't affect anything. But the machine name, try not to change it. It's doable, but there is no easy way to do it. So you need to create a new one, migrate the data, update the code, update the templates. It can have quite a few steps and it also needs thorough testing. So from that point of view, it's a time sink. I would advise against changing the IDs or creating new ones where you want to migrate all that. So thank you. I have a question. You mentioned text and logs for entities. And maybe you can explain a little bit more because I imagine that you have an entity, you have a log and a description and you have fields of description. You press a button maybe and then you have your data model explanation. Is it in this way or is that program? So that's, I mean this in an open ended way. So for example, tagging would be a literal vocabulary, vocabulary and a taxonomy term reference field that lives on the entity that references it. And you would update that programmatically or administrators would do that. Same thing with logs. Logs can either be fields or what the thing with logs is that you might have a lot of entries over time. So I don't think a field with multiple, you know, with many different, many values would be performant. So maybe it would be better to have a log field, log entity type for a given entity and then store that. It's a bit more verbose, but it's not that much more work but it gives you a lot more flexibility and opens up a lot of options. You can have a look at how commerce log does it. So Drupal commerce, Drupal commerce has a sub module called commerce log. And that one is used for storing logs and log messages for commerce orders. And that's exactly the same principle. You know, you have a separate entity type for storing logs for another entity. And that entity type is kind of hidden, hidden away. It's updated programmatically, but it's there where you need it. And you can have, you know, 100 entries if you want. I hope that made sense. Yeah, yeah. Yeah. Yes, please. Hello, thank you. Just getting back to the custom fields question. Yes. I want to make sure that I understood well. You do not recommend every time to recreate a new table for fields. No, no, no. No, it's not that I don't recommend. I'm saying bear in mind that if you have 200 fields on the site, you will have 400 tables. Just bear that in mind. You know, if that was all, all this was, wasn't something very strict. What I would recommend you is to have a strict naming pattern and to use more verbose names versus abbreviations, but definitely make use out of, you know. It was a specific example for migrating an old website for a new one or that's it. It's not because if we're going to do that, we can lose a lot of feature if we want to enable the multilingual sometime or some country module that will add new formatters to the fields. So it's gonna impact all the Drupal. Yes, absolutely. I didn't mean to say not to use the field UI module. So it was more to highlight the options. And sometimes field UI, when I was over time, and I still learn, when you check a lot of times the way fields are being added, it's, oh, you just come in and you create a field and you move on. But you need to live with that field forever till that project is alive. And then if you use that field in 10 other places, I just wanted to highlight what else, what is impacted and what are your options. So I think a lot of times, especially when we talk long-term, first of all, not all industries are the same, not all projects are the same. And if you add who knows what's gonna happen in five, 10 years, it's hard to predict. But I think sticking to this would at least know the options. Sure. And also just to add a little bit on it, if you have a content type with 128 fields and about 90 of them are programmable and about 30 of them are translatable, you program the 91 and add the 31 with the field UI. So you can have best of both worlds. Exactly. And I think that was one of the questions. You can combine all this. I actually had another question. And that was when you were talking about having, like article and you're having multiple content types with similar fields, what about just using paragraphs? That's another option, exactly. Because sometimes we forget that you can, my content types only have three fields. Title, content paragraph, and heading paragraph. No, sorry, and preview image. Yes. Yes, yes, yes, totally one of the options. And especially now with paragraphs giving you paragraphs and layouts and everything, so many options. So, yeah. I have a question about paragraphs. We have a strategy of prefixing all the paragraphs with the field underscore paragraph, underscore image, or link, et cetera. Yes. And I've always been wondering, I think it's in Drupal 7, you couldn't share, like you couldn't have like a field image because it was already in use on the nodes. But then since Drupal 8, Right now it's not the case. You can use like field image on the paragraphs too. Yes, I've seen exactly the same. It was just underscore P, underscore, just to make it shorter. That's another pattern I see, underscore P. Yes. What do you recommend about it? It's, what makes more sense to you and the team? So I think the main thing is, when you use the fields in the code, then you know exactly, okay, so this field belongs to a paragraph. So if you work with a generic entity, in code if you have a variable called entity, you might not always be immediately clear what it is. The node is the paragraph is something else. So when you see underscore P, okay, so this is data coming from paragraph. So, but otherwise, yeah, it's not going to conflict if you have the same name because it will have a separate dedicated set of tables basically. Can you tell me what type of strategy do you have to be up to date with documentation in a big project? Ha ha ha ha. A, diligent assigned person. Well, I mean, honestly, it's a good point because over time, no matter how, especially in bigger projects, documentation tends to lack, tends to fall behind. Me personally, I always then think, I am loud about it. Okay, so we are changing this name. Put it in a common channel, tag the person that is supposed to make the change and just say update confluence, update documentation or whatever. That way you don't need to come back to it later. If you make a change immediately, for me it's kind of automatic. I immediately think if there is someone I need to notify, you do it and then you move on and then it's up to them. But there is no specific strategy, honestly. I would just say that whenever you make those changes immediately mention it because you might be doing 10 other things after that and it's hard to keep coming back to it, especially if you have already 10, 20, 30 fields attached to it, it's hard to remember which one did you add right now, sir. Hi, I have one last question. Do you think that managing the annotations when it comes to custom entities might affect the maintenance of a website like Futurewise or because there were like, for me for example, like many cases that I spent time just debugging to find out that there was a single line missing from annotation and breaking everything up with not sufficient, let's say, feedback. So that is a possible issue, yes. I would say try to test things before they're in use as much as you can. I've seen the same issues, so I know exactly what you mean. It's not always intuitive, it's not an option, it's an extra line that is required for you to add in order to have a specific feature, but yeah, just testing things. And that's why I was stressing so much on planning ahead. So if you plan ahead, you already know, okay, so we need to achieve this. Then it's a lot easier to say, okay, one by one, did we achieve this? Yes, did we achieve this? Yes. Then if you just go ahead and start doing it because then you don't have a checklist and you might lose track of something. Sure. Thank you, thank you everyone.