Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
In the last video, we created a rule that prevented people from changing their usernames to include the word foo in them, but although it basically worked, it had several problems. In this video, I am going to go improve and debug that rule. We won't be able to solve every problem, but we will get pretty far. This is a process that you'll find yourself doing quite a lot, so it's worth showing with a practical example. Once again, just to outline exactly what we did, we created a user named nonstaff. We also created a Staff role here.
The idea is that only people with the Staff role should be able to change their name to include foo somewhere in the name. I will sign in as nonstaff, and show what happens if somebody tries to change their name who is not a staff person. Go up to My account > Edit, change it to foo, and Save. It stays as nonstaff, and we get this warning message. But the first problem is that that affects all users.
It also happens to people who do have the Staff role. Well, that's easy to change. We will just add a condition. I will go back to my Administrative browser, go up to Configuration, and then down to Rules, and edit that rule, which is, Block non staff from the name foo. We will add a condition, and let's see what our options are. Ah! User has role(s); perfect. We want it to happen whenever a user who doesn't have the Staff role tries to change their name, so staff, and Negate.
In other words, this is going to be tripped unless they are a member of staff, and Save. And just to be sure, I am going to add an and in here. In other words, both of these conditions have to be true. So click Add and, and then we can rearrange this. Go down and Save. Now let's test that again. I will go back to my browser where I have nonstaff logged in. I will change that name, once again, to this is foo, and it should be turned back.
Yeah, it was turned back. Now I will go in and I'll create a new user who is a staff person. Go to People > Add user, the name will naturally be staff, and we will give them the Staff role. Then I switch over to my browser here, Log out, and re-log in as the staff person. Now I will try the same thing. Edit the name, and change it to staff foo.
If all goes well, that should pass through just fine, and it did. Now we come to the second problem. While we have stop nonstaff from changing their names to include foo, they can still create accounts that include foo. Now, there is an obvious solution, but like many obvious solutions, it's wrong. We could go back here, go up to our rule, edit it, and simply add an event up here, so that it's after updating or creating an account.
The problem with that is what the actions actually are. They will try to set a data value that doesn't exist. That is, it will look for the unchanged account name, which didn't exist before; see, right here. So what we actually have to do is create an entirely different rule. This is where things gets a little confusing, because you might have conflicting rules with the same event. If that's the case, I recommend you simply take out a piece of paper, and start writing down what your rules actually do. So let's create that rule. Now, we could create it from scratch, but a lot of what we want is actually here in this existing rule, so we will go back to our Rules, and we will clone this one.
Before I do that, I am just going to rename this, so that it has a more distinctive name. Go down to Settings, and this will be Block non staff from editing to the name foo, and we could change the machine name if we want, but that's not really necessary, and Save changes. Now I will go back up to my Rules, and I'll clone that. Block non staff from creating with the name foo. The good news is, the Machine name also changes here, so we know that there are going to be two separate rules, and we Save the changes.
Now we will change the event that triggers it. Instead of updating, it's going to be after creating a new account. So we look down at user, and see what our options are. Yup; After saving a new user account. Now, since we are allowing it to be saved, we then have to delete it once it's been created, and we Add. Then of course, we delete the old event after updating. To take into account that change that I just made, we have to look at our actions. We'll show a message on the site; that's still good.
Set a data value; once again, we're creating a new account, so this account-unchanged doesn't actually exist. I will delete that action, and then I will add a new one. This one is going to be Delete entity, and the selector is simply account; that is to say, the account that the user attempted to create, and Save. I think we're okay. Now let's test it.
I am going to switch to the other browser, and Log out from staff foo. Now I will try to create a new account, but before I do that, I am just going to go back and make sure that that person can create an account by going to Configuration, and Account settings. Yup, Visitors can create accounts. So let's give it a try. Create a new account. I'll call this person I really am foo. Now, if this works correctly, then of course, it will be rejected.
Create new account, and you see it did not log us in the way that we expected. If we go back to our administrative browser, and look at the People, that role would've shown up here at the top of the list, but it's not there, so it simply rejected it. Now, that's not really the best user interface, though, so I am going to improve it just a little bit more. I want to tell the user who tries to set up such an account that they really aren't allowed to do that. Now, we could flash a message but we can do something even better. I will go back up to Configuration, and down to Rules, and then I'm going to open a new tab, where I create a page. It's going to just be a Basic page, we'll say Forbidden username, and in the Body, You can't create a username containing "foo".
Go down to the bottom, and Save it. Let's just note this URL. It's /content/forbidden-username. Now when I go back to the Rules, one of the actions I can take when someone attempts is to redirect them to that page. So Block non staff from creating with the name foo, edit, and add one more action. This one is down under System; Page redirect, and the place it's going to go to is /content/forbidden-username.
By the way, watch out for the leading and trailing slashes. That can mess you up quite a bit. One way that I can tell that I don't need the leading slash is I look down here at the example, which doesn't have one. It will force to redirect, and you can do some other things, like put on a destination parameter if you're using those on your site. I wouldn't worry about that unless you're doing some pretty fancy stuff, though. If you don't know what it is, you can ignore it. I will Save, and give it another try. So back to my non-logged in user. I'll go back and try to create a new account.
Click Create a new account, call this one foofoo, and let's see what happens. We got that page, just as we expected. So our rule is just getting better and better, but believe it or not, it could still be improved even further. For example, the rule doesn't work right now when an administrator creates a staff account that contains foo. Also, we never addressed that annoying message that says your changes have been saved when you edit a name that gets rejected. As far as I know, that can't be solved using rules.
You would have to hide it with custom programming, or some fancy site configuration, or possibly with a contributed module. Actually, as I was going through this, I found that the Omega Tools module, and the Omega theme would give you this feature, and if you want to find out more about that, I would play with Omega Tools as you learned about in the video about the Omega theme. I also want to mention that what I showed you here could have been put together in several different ways, including using variables, components, and other aspects of rules that we didn't cover, and won't have time to in this course.
But at this point, you have the ammunition you need to go forth and learn more. The place to start, once again, is on Drupal.org in the documentation linked from drupal.org/project/rules.
Get unlimited access to all courses for just $25/month.Become a member
61 Video lessons · 105134 Viewers
56 Video lessons · 116911 Viewers
71 Video lessons · 86119 Viewers
131 Video lessons · 41183 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.