 Okay, muy buen día, gracias a todos por venir. ¿Qué tal? Hello, I'm Josef Dabernick. And who of you has used the rules module in Drupal 7 or 6? So I guess more than half of you. That's cool, awesome. And today I'm talking about rules in Drupal 8. It's not ready, disclaimer. But we can already see a lot of things and hope there will be stuff that gets you interested. My name is Josef Dabernick. My Twitter handle and wherever in the community you can find me as Dasio. I'm originally from Austria. That's in Europe. That's a capital city in Vienna. But I recently moved to Zurich to work with the amazing guys from Amazelabs. So I work as a deputy head of technology together with Michael Schnitzel. You probably know him from taking pictures of Drupal cons. Together we run a team of 12 developers. And we also have sister companies in Austin and another company, Amazemetrics, which is specifically dedicated to SEO solutions. Yeah, that's our team. So we're very dedicated to design. And we always have job offers open if you want to move to Zurich or Austin and you feel like you want to be part of that amazing team, obviously let us know. Well, you might also know me from contributed modules like the Facet API Pretty Paths or my master thesis that I wrote into your cluster which is about how can I put millions of points on a map and still have a performance user experience. But what really keeps me passionate for Drupal is not just the technology, but you guys, the community. And actually I started using Drupal extensively when I lived in Central America. And there I started doing Drupal tours. So I traveled from down Nicaragua through El Salvador, Guatemala, Belize and Mexico. And two years later I traveled again down to Costa Rica doing presentations about Drupal because I think the ability to share is what helped me being a successful contributor and successful like doing a successful business with Drupal. So I think it's very crucial that we share this knowledge. And this also makes me very happy to be able to be part of the first Latin American DrupalCon. Yes. Okay, so far for the intro. DH Rules is an initiative that is not just me but we are actually a team. Surprise all of those five guys, we are from Austria. There is the creator of the rules module, Fago. You might know him also from other modules like the entity API field collection profile too and much, much more. And Klaus is his commentator. We also have Fubi on the team. He's the creator of the Omega-4 module and they are very dedicated Drupal core contributors. I'm responsible for communication and we also have a designer on board. Nico has also done quite some designs. They have the Drupal website, maybe you know that. Drupal is a website where you can have a nice overview of all the Drupal events. Well, and so together we figured the rules module in Drupal 8, it's gonna be difficult. The reason is rules is a very complex module. Has anyone ever debucked the rules module? Has anyone ever tried to step debug through rules? How do you like it? Yeah, I had the same experience. So we figured it's gonna be hard because those guys are really, really busy. Klaus is working on the security team. Fago is maintaining Drupal core modules. He's running his own business. But we kind of want to do this. So we formed the team and we did some other steps that I will explain later. But what is rules, actually? I mean, there's this great presentation from Amitabh. You should look it up. It's from DrupalCon Copenhagen, which was my first DrupalCon. It's about organic groups. And Amitabh was interviewing different people from the United Nations. And there he has a quote where Angela Merkel, the German chancellor, she says, there must be rules on the rules. So I guess at some point we all need rules. We also need rules in our community. We even have a code of conduct which helps us be respectful with each other. But rules, obviously, in terms of Drupal, it's more about I wanna have some logic in the system. I wanna make something happen on the website. So there's an acting user or something that's happening on the system. It doesn't have to be a person per se. It can also be like a cron job that's running. That's generating an event. And then we have some conditions to validate. Do we really want to do something right now? For example, the content has been updated. And if the condition, the content offer is different than the acting user, then I want to invoke something. Let's have an action. And in this case, I will send out a notification. That's the very basic concept of rules and by just combining any kind of event with any kind of condition and any kind of action, we actually can create what we call a software engineering touring complete machine. So it basically allows us to do any programming. The cool thing is, I mean, you can do this in code, but the rules module allows you to do this via the admin user interface. So it really is an efficient way to create those events, specify the conditions based on all the metadata that is available in the system and then react on it. So rules really is about building flexible workflows using those events, conditions and actions. And for example, we often give it to our clients so that they can customize the emails they want to send out. Have you ever had the experience that the client wants to change some string that has to be sent out? And you have to ask your developer to change that string in the code and you have to deploy it. It's really tedious, right? And it's not the work that we want to do on a daily basis. So why not just set up a rule that the client can configure themselves? Yeah, we can also create custom redirections, system messages, and the rules module has shown to be pretty successful. It's not something that you would install on every site. I also know a lot of people that say, I don't need rules, I don't like this module. It's not the way that the developer should work with the system. It's like this clicky thingy, right? But on the other hand, we consider, there's hundreds of integration modules. It integrates into the whole system that makes Drupal so powerful. We expose all the entity-mated data, the fields. We can iterate upon views. We can access all the data from hundreds of integration modules. So on one hand side, rules might be considered as a toy that site builders want to play with, but on the other hand, it's also very, very good for the developers so they can be forced to specify the important APIs. And so rules, for my feeling, is a very good system that allows the bridge between the developer and the site builder to be as efficient as possible. Because when you provide an integration with rules, you will be sure that anyone can integrate. Well, that was kind of the success story of rules in Drupal 7. And for Drupal 8, we obviously had some ideas. In general, we've seen from the keynote, there's a lot of excitement about the object-oriented programming. Rules in Drupal 7 already embraces some of the object-oriented programming, but now we can really rely on the plugins and all the systems that are already in place for Drupal 8 and we don't have to bring in our own plugin system, for example. And yeah, I mean, that's like the base, the general excitement for Drupal 8. But what we wanna bring as a rules initiative to developers is really align how you work with rules with the Drupal 8 developer experience. So the object-oriented style, the dependency injection and everything should be as aligned as possible. And also, as we are one of the first big country modules, we wanna show developers how the coding style of Drupal 8 should look like from our perspective. That's by using extensively the plugin system. We are relying on all the good things that Fago brought into the Drupal project as the entity API, which now has a spin-off called typeData, which is actually more of an abstraction, sorry. So typeData is really a low-level API that allows you to specify how the data is structured. And we can use that in entities, we can use that in fields, but we can also use that just for parameter configuration because the way that rules works, we always need to specify some input parameters that we can then process upon and then forward it, for example, to the next action. And all that system can now be based on the generic type data API that is shared across the whole Drupal 8 ecosystem. Low-integrations, like who has used panels? Penals module, yeah? So you remember the confusion about context in panels and the context module. Context in panels is actually the very same thing as we are dealing with in rules because we wanna specify the data that we need and then we wanna forward it and so on. And the way that panels context work is really the same, I mean you specify you want an input parameter of type user and then I'm gonna use the email address of the user, for example. So we have some common problems across Contrip in Drupal 8 and as earlier as possible, we're gonna tackle those. The better, like the whole consistency of the system will end up being. Deployable config via CMI. I mean, who doesn't love CMI? Rules in Drupal 7 already had its own exportables but now we can really be aligned with the whole system. So I think from a developer perspective, those are like the big wins that we kind of envision for rules in Drupal 8. And then there's this whole topic I already mentioned a bit about the reusable components. So we're trying to share the context API with projects that already exist. So page manager is like a spin-off of C tools in Drupal 8. It's already using the Drupal core context API. So we're working together on fixing core bugs or improving those APIs that all the systems can work well together. We will need tokens. You remember, specifying email. Within the email, you wanna have the username being printed. And there's, who had problems with tokens in Drupal 7? Incompatibilities, yeah. So I'm not sure if we're gonna be able to fix all the problems, but at least we are trying. Yeah, so we wanna make tokens reusable. And then type data. So the way that you can specify parameters on top of the specification, what rules usually does is exposing a form. So that the user, for example, can enter the date that is required to execute this component. And that's also used, for example, in use bulk operations, right? So when you, I mean, that's probably something that not everyone has used, but in Drupal 7, you can specify rules components. And then you can tie them into the views bulk operations. And then the user can input the data that is additionally being configured. So such widgets for inputting the data and also formatting any structured data, we will have to do it in rules in Drupal 8 and we wanna make it reusable. Because it's not something that is specific to the rules use case, but it's something that we can solve on a general level. And if you have been to the talk of Eclipse, you see yesterday, all the thing about making components better decoupled, I think it's really important that it's something that we wanna embrace during the rules Drupal 8 port. And then I think, yeah, embeddable UI components. So for example, you could right now, you can already the Drupal 8 conditions API is already tied into the block system. So what you could also do is then a rules condition could just be exposed into the block UI configuration as a selection rule. So specify the visibility of blocks via rules conditions. As for example, a possibility that we see here. And finally, I think one of the major advantages of the rules module is obviously the UI and you remember the data selector. I mean, there would be so many places in Drupal where we can reuse the same data selector. When we in panel specify a context, we could just use the very same data selector as we have it available in rules. So that's kind of our vision here. Site builders, site builders should obviously get all the admin UI improvements that we have seen on a general level in Drupal 8. So Drupal 8 has a much more consistent UI. Unfortunately at the very same moment, but there's a very good session from Luis Neiman about how they created a style guide for the seven theme. So we're working hard on solving the problems that we see for the rules UI. We haven't implemented it yet. But the idea is that all the UI components that we have to implement for rules, they should be shareable because there will be similar problems that other modules have to solve. For example, okay, you need kind of a complex ad dialogue. We have already seen that in the views UI, right? So in views, you kind of say add a filter and then you can select from all the available filters. I mean, in rules, it's pretty much the same. I wanna add an action. I wanna have the actions grouped by category. So why don't we just rely on the same UI patterns? And that will also help site builders use the site more efficiently because when we have the similar approaches across the system, it just makes more sense to them. Yeah, site builders, as mentioned, the views bulk operations that Larry showed in the morning, they are part of Drupal core. So, and there's also an action and conditions API in core. So if we would be able to expose rules actions using the standard actions API, then we would be able to use just right away the simple bulk operations. I think that's pretty cool. And who has worked with rules components? I have this experience that working with rules components sometimes is a bit hard or creating advanced logic. Maybe advanced logic should not be in rules at all, but if we already have the tools available, I wanna do an if else or I wanna do this kind of logic and you really, really quickly hit the boundary where rules forces you to build the logic bottom up. You have to first create the components that you then call in the parent rule that you then call above. And nobody understands the system at all anymore. There's a contract module. You should check it out in Drupal 7 that's called rules conditional, which allows you to create those advanced logics. But for Drupal 8, we kind of feel that inline rules is a concept that will just help us get rid of all of those problems. So if you're able to nest rules and rules using a top-down approach, and we haven't figured out the UI on that yet, but I think that will really help us. And if you're like, if any of those ideas gets you interested, you should really come tomorrow to the sprints and discuss details on that with us. So that all sounds nice. I think you already should already go online and download the rules module, right? And then you can just try it out. Before that, we have to do it. And it was almost a year ago, just before Drupal developer days, where I talked to Flago about the concerns that we have, that rules will never be ported to Drupal 8 because everyone is just too busy trying to work on Drupal Core and Contrib is usually an afterthought. But we felt like it's really, really important and this is why we came up with the DEAD rules campaign. So probably have seen such stickers around. So we're really trying to make some, to get some momentum there. And the vision is that as far as earlier as rules is there, the earlier other contributed modules can also get their integration supported. So the big goal of DEAD rules is accelerate all the Drupal 8 uptake altogether. Obviously site builders will be able to create their flexible workflows. And the whole initiative for us is also about making a statement that contribution just takes a lot of time. And we are in an open source society where we kind of rely on each other. And I would really recommend like, I don't want to go too much into detail because this session is more about developers, what we can expect for Drupal 8 in rules. But I think the whole discussion about sustainability in Drupal is really important to have. And Street did a very, very great keynote in Amsterdam that you can watch online about his vision of how the whole Drupal ecosystem can make contribution more sustainable. Check this out. We decided, okay, we will do some crowdfunding. And thanks to those more than 300 individuals donated to help us get the rules more important. Because as said, the developers they don't have enough free time. So our decision was the companies that employ Fago and Clausi, they provide a community rate of it's 45 euro. So in Austria that's like, usually in Austria you would charge your clients like 100 euro for example. But it's like the base cost where they can employ their developers to work on it but they don't make any money anymore. And all those individuals and also those generous companies help us gather funds to kind of, kind of, yeah. The funds that we need to get the rules module ported. And how can we up with this number? It's basically a bit more than 1000 development hours that have been estimated to port the whole rules module from Drupal 7 to Drupal 8. And as you can see, milestone one we have successfully funded. We haven't figured out the solution for the other milestones yet. But it was really a great success for us to being able to motivate so many people to just chip in and help us free up some very precious top Drupal Core developer time to not only work on Drupal Core but also work on the rules module. So we did that. We did that campaign about April to May last year. Then we had the money. Then we just had to do it. And we came up, like the development roadmap looks like this. So in milestone one, we worked on the rules core engine, implement all the plugins, the rules actions and conditions APIs of Drupal Core. Our vision was really to match them to, like if we can decide to fork the system or we can try to fix it in Drupal Core. And as long as Drupal Core is not frozen, that's the thing to do, obviously. So all of these steps, they have like an error. So they are like almost, almost complete. Mystone two is about completing the rules engine features, the advanced plugins like events and loops, the entity token support, the CMI integration that has already started and some generic integrations. And then in milestone three, we'll tackle the user interface, the reusable UI components. We also have to upgrade the scheduling. And finally, the existing integrations, rules, ships, which with quite some actions that integrate with Drupal Core. For example, there's an action to send out the mail. And together with the community and sprints, we've already ported lots of those core conditions. And that's also, it's really a great thing where we work together with the community to train all of you on the new Drupal 8 APIs. And we did that at several Drupal camps and Drupal cons. And so right now, we already have 45 forks of the rules model, which is developed on GitHub. All those people have patches committed or pull requests being merged. So that's really cool and thanks to all of those. And if you wanna be part of that, find me tomorrow in the sprints. Okay, so that's how that works. Now, if you're a developer, like how many of you are developers that kind of would be interested? Awesome, cool. So, and who has already written rules integration let's say in Drupal 6 or 7? Implement action condition, cool, cool. Awesome. So the way we gonna do this in Drupal 8 right now is, well, we need a working Drupal 8 installation, obviously, and then we go on GitHub and just fork the rules module from Fago's repository. It's pretty straightforward, as mentioned, already 45 people have forked it. And then we kind of have to figure out what to do there. There in the issue queue, we have some novice tasks. So there's like some pretty easy tasks to get started, but most of them are a little bit more advanced. And I'd like to walk you through the different APIs that you will work with. Because to make a disclaimer, I'm not a professional, like on a daily basis, I'm not developing anymore. I have a background in computer science, but I wouldn't consider myself as the best developer at the Maiselabs, I'm more like specifying tasks and reviewing all that stuff. So bear with me if there's any errors or in there. But I tried my best to understand what Fago and Klausie and Fubi did there. Okay, so there's different APIs in Drupal 7 for rules, and one of them allows you to expose structured data to the rules. So in Drupal 7, we have the rules data info, and we can also, like the whole entity API, the entity property system is exposed. So there's those two hooks. One to add new data. If you wanna expose, for example, you have some custom table in your database and you wanna make rules aware of the custom structured table, you can do that by a rules data info. Or if you wanna add some additional properties, you just do it with the entity property info alter and rules will automatically pick up. That's the same process, for example, that we use when working with search API. If we wanna index something in addition, we just create our own properties, which is cool. So in Drupal 8, we have the whole type data system. And the type data system, as said, allows us to access the structured data, and there's some interfaces, there's the primitive types and the complex types, and I will show you some examples. So you can see that there's a, let's see if I can do, oh yeah, okay, there's a primitive base that, for example, the floating class extends, and we can already see that there's some annotations being used, and yeah, it's pretty straight forward. The primitives need some castings, and then there's more complex properties that would, so for example, if something is like a structure, what we do here is specify all the properties in the property definition function, like for example, the link item has a URL and the title and so forth. I tried to reduce those examples to the most important stuff. So that's the way that we can describe data in Drupal 8. So basically, all you have to do in Drupal 8 is implement your own data type plugins. So it's just a plugin class that will be picked up by the system, and then rules can also deal with that. And the entity property info alter is now a standard Drupal hook that is called hook data type info alter. Okay, but the usual stuff that you do when working with rules is you wanna create your own actions, you wanna create your own conditions, you wanna create your own event, and to do that, let's get like a quick introduction in the whole object-oriented programming style that has changed quite a lot from Drupal 7 to Drupal 8. So we're using annotations to describe the plugins that we have instead of info hooks. We have auto-loading, so it just puts the plugins under a specified folder and file structure, and the system will automatically recognize them. Yeah, and there's also like discovery is basically together with the auto-loading and derivatives, we have not implemented any derivatives for rules yet, but we will certainly have them. So imagine there is a create entity action. We could create derivatives that says create entity of type note action or create a user action, create a taxonomy term action. This would basically be derivatives of a standard plugin based on their entity type. So how do we provide conditions? In Drupal 7, we had some info hooks and some callbacks, not very well structured. I think that the way that we have it now in Drupal 8 is much more approachable because you have everything self-contained as the following example. So this is the class that says node is sticky. So I have a condition that checks if a node is sticky. And instead of the info hook that is somewhere else in the system, I really have it right next to the class in the annotation, which is a, there's no first class annotations in PHP, but we use the doc blocks. To get there. So the condition itself, what we usually expect in an info hook is now within the annotation. And we can see that for example, there's some add translation tags which allow us to make that translatable. I will get into the context later on. But that just tells the system, okay, I will have now the machine name rules node is sticky in the category of the nodes. So this condition is now based on that annotation being registered. And that's it. Then what do I have to do? I will just extend the rules condition base and implement the evaluation function. I will explain the context later, but what the condition usually does is return a true or false value. So in this case, we are checking if the node is sticky and that's all what the rules do. So who thinks this is too complicated? Cool. Awesome. Okay, actions. It's pretty much the same. We again have the annotation. In this case, we have an action that deletes any entity. We could have derivatives which allow us to delete just nodes. But for the sake of simplicity, let's just keep it with the entity delete. And instead of an evaluate, we have an execute function and that's it. We just straightforward. Finally, events. We don't have events yet. So yeah, it just hasn't been implemented yet. So what we have right now is all the actions and conditions. We already have like 10 conditions, 10 actions ported and it's pretty cool. I mean, it's not only this, but we will see how to test them later on. But it's a really good way to get into the whole plugin system of Drupal. Good. Context. So rules have to act upon a specified context. So all the data that the rule gets, for example, the event would be entity has been created. Obviously, there is an entity to be expected that we wanna work upon in the system. And the way we do this is in the annotation, we also have the context keyword which allows us to specify the context that this action expects. So in this case, the entity delete needs an entity which should be deleted. It's pretty easy. We can see it down there. We can get the entity by this get context value and the value just corresponds to the key up there. And yeah, in this case, it's of type entity, but this could be any type data. So I could also get a parameter of type float, for example, and then it would just be the same. So that's the way we specify the context. And for using the context, I have a more complex example here. So there's an action that's called data list item remove. So I will get a list of items and I will also get just a single item. And what this basically does, it's just iterating over all the items in the list, checking for the items that match. It's removing them. And in this case, we're not only getting the context, we're first getting the list of items and the individual item, but we also have to update the context. So the new list will now be used, like kind of similar to if it's being treated as a reference. And that's how the context here works. And then we have, so we have been working with the context that we receive. We have updated the context, but in some cases, the actions also provide new values. So in this case, fetch entity per ID, we'll get an entity type and the entity ID, and then do its magic using the entity manager by loading the specific entity. What it will do in the end is set a provided value so that all the subsequent actions in the rules execution stream will be able to access it with this name. That was using context, so we can get a context, we can set a context, and we can set provided values. I guess this is really the basics that you really, really need when you work with the rule system. There's also a way to use rules programmatically. So what we can see here is there is an expression manager, so everything in rules is an expression, like an action is an expression, an event is an expression, a condition is an expression. So the expression manager allows us to create a rule, and in this case, we specify that there should be a context of type string, and then to the created rule with the context, we can add a condition, and what we do now is a context mapping. So the text that's needed, it should be a select, and that's then mapped to the test here. And finally, we can add an action to be executed and set the value test to be the test value, and then execute it. So that's, when you're not using the user interface, I did that in, has anybody used the rules API without the interface? We did it quite some time because, I don't know, you have used the entity metadata wrapper, and it's just a bit easier from the command line. All right. And then, a bit more of an advanced example with context is that, for example, consider a condition that provides the provided text variable. Then there's an action which provides a concatenated variable, variable, sorry. In the end, we sometimes need the context mapping because if the same action was executed twice, it would just override the previous provided parameter. And if we specify the mapping here, we can say that the second action, the second rule test string, instead of concatenated, the variable should be named concatenated to. That's basically what rules does internally. Maybe you have noticed that when adding the add variable action several times, the variables will just get different names. Obviously, it makes sense to do so. Yeah. All right. About storing configuration. So in Drupal 7, we have different systems, how to export configuration data. We have the whole C26 portable ecosystem and features. And rules kind of had its own system in terms of, because for readability, we decided to provide some kind of JSON export. So whenever you look at an exported rule in Drupal 7, you will see that it's pretty well indented and it's not just a serialized array or just a serialized dump, but it's actually a pre-defined JSON output of the rule. Yeah, and that's all the functions that we have in Drupal 7. In Drupal 8, it's gonna be much easier. So we will just rely on the YAML files. We're still working out some details there and it's not implemented, but it will just be easier to operate. Yeah, so that concludes the basics that you deal with. When working with rules in Drupal 8, you will wanna specify additional metadata to be exposed to rules. You will have to implement the actions, the events and conditions, and you will obviously deal with the context API. Context API, by the way, is part of Drupal Core, so it's also used in other systems. If you wanna look a little bit deeper, you can also specify your own plugins. So one example would be the rules conditional module in Drupal 7. It provides a separate plugin for the if and else statement, and that you're gonna do just by extending the rules expression plugins. Then there's specific, there's the possibility to specify input evaluators, and the possibility to specify data processors. So an example for a data processor would be the numeric offset. And I guess you have seen this when you import, when you have an action that requires a number, you can also use the data selector to select, for example, the, let's say, the count of users or whatever you have stored there, but the numeric offset would allow you then to just add a number as an offset to that. Yep, user interface. It's not there, sorry. You don't need it, yeah. I mean, the APIs are so beautiful, why would you ever need a UI? Yes, yeah, we should do a console integration tomorrow. There have been some proposals. I mean, I think the rules UI is kind of controversial. It's some say it's too overwhelming, some say it's too limited. It's, I guess it's really hard to make a perfect user interface for such a generic tool that we have. So there was a research project called FluxCraft. It's really interesting. It's not just about the UI stuff. FluxCraft is about creating the whole web automation, like if this then that, dot com, but based on open source technology. So the idea of FluxCraft was to use rules and all the user interface capabilities to create an if this then that based on open source technology. And part of that was creating UI proposals to make it more simpler. So the rules you use the interface sometimes is considered to be just too complex. And I have a ticket in the queue that lists all the references. So if you're interested in studying those proposals, there's the FluxCraft UI. There's a module that's been around for quite a while, but it never was really picked up. I guess it's not that the concept is not so cool, but maybe the implementation was not great, but that already exists. Rules Transformers already exists in Drupal 7. It would be just another way of how you do the programming in a visual style that you have like the individual actions and then input parameters and output parameters that can just be connected in a flowchart style. There's also the no flow project which got quite some momentum on Kickstarter. And some of like Fubi is thinking about we should experiment with the JavaScript-based front end for the rules configuration. Yeah, there's a ticket 2251267. If you're interested in chiming into the discussion, I think this is the time where we can incorporate feedback, but the 1,000 hours that we have estimated will not include any fancy user interface. So the plan for the initiative still is pretty much poor. The existing rules interface to the new technologies of Drupal 8, but iterate like in smaller pieces where we kind of see opportunities to streamline. At the moment, we do not plan to make a crazy rewrite, but as everything is pluggable, anyone can come and implement the rules user interface at their taste. So while the UI is not there, how can we do stuff with rules? I mean, it's super boring. We implement our actions, we implement our conditions, but we don't know if they really work. And as everything in Drupal Core, we embrace automated testing quite extensively. We have some unit tests to test the individual components internally, but rules is really more about integration because we kind of need the action manager, condition manager, type data manager. It doesn't really make sense for us to mock all the systems. So mocking in automated testing is you really focus in a unit test, you really focus on that unit that you wanna test. And if that unit has interdependencies on other systems, you usually create mocks for them. So we are kind of in a hybrid situation where we don't bootstrap all the Drupal system for performance and we don't really need it. But still we're writing more integration tests because it doesn't really make sense to, as you've seen before, the execute statements are usually just one or two lines of an action. It doesn't really make sense to just test this part or we feel that it makes more sense to test the integration here. Okay, let's look at an example. Data list count is a condition that checks if the count is equal, less, or more. So you have two, basically three important parameters. You have the list, you have the operator and the value. And based on the combination, it will just return if the data list count is greater, equal, or lower than. Okay, pretty straightforward condition. And the test, that's a abbreviation. We have lots of more test cases. But how it looks like it extends the integration test base. And then what we do is we create a condition and we set all the context values, like the list should be one, two, three, four, operator greater than two. So the list count of a list with four items should be greater than two. So what we do is assert that this condition evaluates to true. Easy. And vice versa should not be equal to zero, the count of a list that has three items. So we are asserting false that it's equal. That's the way how the tests look like. And then we also have the entity integration test base which brings in the whole entity system. So usually in those tests, when you look at them, you would have to do a lot of bootstrapping. You have to mock all the systems, get all the managers ready for you. So this is why we have some test bases that allow you to do so. Let's look at another condition, entity is of type. So we get the entity, we get the type string, and then we just return if the entity type matches. Now when we look at the test for this, this took me a little longer to figure out how it works. So what we do is we create a mock for the entity. So we don't really create, we don't do an entity create or we don't instantiate a real object, but we get a mock that implements the entity interface. And then we set expectations. So we expect this entity, I mean it's like you create something that's not there, but you specify how it should look like because that's the only thing that you really care about. So what I care about here is that get entity type ID should be called twice later on. And that kind of struck me because right now I already have to think about what's coming down there and that's not the way my programming mind worked so far. Well, anyways, let's just assume this is how we do it. So we expect get entity type to be called twice and it will always return node. So we now have a fake object that on two times on get entity type, it will return node. And what we're gonna do with it. Down here, we set, we have the condition and we set the context value entity to be the mock entity and we set the context value of the condition to be node. And then we check this condition should evaluate to true because we have a mock object that returns node and we are checking for node, so this should be true. And then in a second test case, we set the context value to taxonomy term and now we assert to false. And like all those two together matched exactly to... Yeah, that's it. All right. Just a quick mention, if you dive into the rules APIs, you will deal with the rule state that keeps track of all the variables that allows rules to deal with or to apply the data selection. So based on the current execution state, which obviously changes from every action being executed or every condition being executed, the state kind of changes. If the condition is being executed, rules usually knows a bit more about the variables that are available. This is for example, the reason why often you have to put an entities of type or entities of bundle condition in the beginning of your rule so that you later can access properties. So the system differs automatically based on conditions it knows more about the entity. That's all handled in the rule state. Also auto-saving is a feature that rules has. So for performance reasons, it doesn't do a save on every single action but it does in a more intelligent way. Traits, yeah. Who has used traits? Anyone has used traits? Yeah. Okay, we use them and what are traits? Traits kind of solve the problem of multiple inheritance. We're not able in PHP to inherit from two parents. So if I'm a car, I cannot be both a vehicle and an object if they're not parents of each other. So, and there's a quote that says, traits are basically copy and paste on the compiler level or on the, is it really the compiler? Correct me for more. Well, there's one trait that you really, when you deal with Drupal 8 code, you will quickly find it. It's the string translation trait. All you provide us is the T function. As in Drupal 8, we do not want to use globals. Like in Drupal 7, the T function is just a function that you call globally. But in Drupal 8, we usually rely on services that provide us the functionality and bootstrapping those services is just like, takes a bit of instantiation with all the dependency injection that I will not show today but you will definitely find it out in other sessions. So basically, the string translation trait is something that can be used in as many classes as we want to. String translation will be a requisite that we wanna, for example, have in my class. I wanna use string translation. And then in any function, I can just call this the methods T if it was declared in my class. So a really powerful concept. You have to use it wisely. You can also rename classes. So if you have two traits that conflict with each other with the same method names, you can use traits a bit more in an advanced way. But maybe it will also freak your developers out when they try to debug stuff. Yeah, we use traits for the context. So there's a rules context trait. So there's a context that we're a plugin base in Drupal core but we need a bit more to being able to deal with the provided values, for example, that's not part of the course context system. And we use it both in the action base and in the condition base. So that's a use case where we kind of need traits because we want to inject functionality in a horizontal way into many classes without them being crazily inherited from each other. Yeah, so just a reminder, if you want to be part of this, that sounds fun. Contribution can be many things, can just give us money. We use it, we don't waste that money. We really use it for solving hard problems and we try to give back as much as possible to the whole community. So I guess if you know anybody interested in donating to rules, I wouldn't encourage yourself being for it because you're already part of this community. It's, we should talk to the people that have much money to get this done. Yeah, you can just talk about it. You can help us with graphic design. You can set up a sprint. We're happy for any help regarding documentation, bug reports and so there's lots of opportunities to help us out. So currently we're porting actions and conditions and you can find more information here or just directly at the sprints tomorrow. And that kind of concludes my session. So I'm happy to take your questions. Thank you.