Viewers: in countries Watching now:
This course teaches web site designers how to take their sites to the next level with a few advanced techniques and the free and open-source Drupal software. Author Tom Geller shows how to configure the most popular add-on modules; use *nix commands and an FTP program to manage a Drupal site on a web server; change its visual appearance using the latest graphical tools; automate and speed through common tasks with Drush; integrate with social media sites; and see how "supermodules" like Panels, Context, Rules, and Features open up new worlds of code-free development.
Drupal 7 Advanced Training was designed as a follow-up to Drupal 7 Essential Training and it also dovetails nicely with our other Drupal courses, such as Drupal 7 Reporting and Visualizing Data and Create Your First Online Store with Drupal Commerce.
You've seen the theory behind how the Rules module works, we created a simple rule, and you've seen some pretty fancy applications, using Drupal Commerce. Now, in the next two videos, let's go a little deeper into the complexity of rules, using a practical example. Here's the scenario: let's say that you allow the public to create accounts on your site, and they are allowed to change their usernames, but only people who are on your staff are allowed to have the word foo in their usernames. So you need to prevent anybody who's not on staff from having a username that includes the word foo.
To make this simulation work, I'll create a rule called staff, so we can differentiate between company staff, and the general public. I won't actually make that differentiation in this video; it'll be in the next one, but here we go. We simply go up to People > Permissions, and then Roles. We create the staff role, and we move to its proper place above the administrator, and Save. Now we go into the Permissions, and we just have to make one small change. Go all the way down to the User group. We want to allow people to Change their own username.
When we click Authenticated User, of course, that also checks the staff box, since it includes all authenticated users, including those with any kind of role. And then I Save permissions. Now let's make the rule. We go to Configuration, then down to Rules, and then we Add a new rule. I'll call this Block non-staff from the name foo, and the event is going to be, let's take a look; it's something on the User group. Ah, After updating an existing user account. Now, that doesn't take care of all of the different possibilities; someone can still create an account with that name, but we'll get to that in the next video.
Then I click Save. The next thing we need to do is figure out a condition. When should we trip this rule? We go down to conditions, and click Add condition. There are many options here, and it usually takes a while to figure out which is which. For example, what's the difference between Data comparison, and Text comparison? As with the Views module, the more time you spend on these and just playing around, the better you'll understand which ones you need. I happen to know that in this case, I need Text comparison, so I select it, and then I get some additional options here.
The first question is, what I'm going to compare it to? Well, if I look at the Data Selectors, I see that I have lots and lots of options. I know it has to do with an account name, but there are some subtle differences between site:current-user:name, and account:name, and so forth. Well, after playing around with it for a while, I happen to know that the one that I want is account:name. So I'll go up here, add account, and then colon, that's shows me all the options in that group, and then account:name. Scroll down, and then I could add the various things I want to actually compare.
I want to compare that Value to the string foo. And down under the Comparison Operation, starts with, ends with; no. As long as it contains foo, we shouldn't allow them to change their name. I also want to point out this little checkbox. You can create negative rules. In other words, you can say either let everything pass if it matches this comparison, or make everything fail if it matches this comparison. I'll click Save. In this case, I'm making the action be tripped if somebody tries to enter foo in their username.
The next step is to add our actions, and I'm going to add two. The first one is going to be a warning. The action I want is under the System group: Show a message on the site. Then I have my options: You can't have a user name that contains "foo". Try again. I scroll down, and decide that I'll make that a Warning message. That sounds like an appropriate kind. Status is a green thing at the top of your screen; it doesn't look so scary. Warning is yellow, and Error is red, each with its own icon.
And I will let it Repeat, in case a person tries more than once, and click Save. Now, that tells them that they can't do it, but I also want to add an action that stops them from doing it. So I'll click Add action, and once again, a little bit of playing around has told me that the Value that I want here is Set a data value, so I'll select that, and the thing that's going to change is, once again, the account:name. This one right here. So I go back up say, account:name, Continue, and then I say what I want it to be set to. And the Value is actually going to be an unusual little token down here.
We have account-unchanged; in other words, it looks back to what it was before the person attempted to change it, and it's going to be account-unchanged:name. So I copy it, and paste it, go down to the bottom of the screen, and Save. Now let's give this rule a try. To do so, I am going to up to People, and I'll add a user. This user is going to be called, lets say, nonstaff. E-mail address will be nonstaff@ example.com, and has a password.
Now, this person is not a staff member, remember. We will create the new account, and then go over to a browser where we're not logged in. I'll login as that person. In order to change a username when you're logged in, you go up to My account, and then click Edit. Let's see what happens if this person says, my name is foo, which of course, contains the string that we want to forbid. Go down to the bottom, and click Save, and indeed, we got exactly what we wanted.
We get the Warning message right here, and the username stays as nonstaff. The thing is, if you are not careful, you might be tempted to stop here, but it's not really finished First of all, we haven't differentiated between staff members and nonstaff members. We trigger the same rule even when staff members want to change their name. Second, this rule only gets triggered when user's change an existing account. They could still create that account with foo in it just fine. Third, we still have this confusing line here that says, The changes have been saved, even though they weren't.
We'll look at each of these issues in the next video.
There are currently no FAQs about Drupal 7 Advanced Training.
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.