Here's the model again.

You're going to mess with quite a few of the model elements. You'll:

Download Drupal's program files

Start the terminal, and cd into the subdomain's folder. Here's what the ls command shows me:

Suppose I wanted to install Drupal on the domain https://learnweb.skilling.us. It's root folder is learnweb.skilling.us. So I would cd into that folder.

cd learnweb.skilling.us

Now I want to grab Drupal from the internet, and put it into the current folder. Composer, a program that should be installed on your server, knows how to do that. Type:

composer create-project drupal/recommended-project:^8.8 .

"8.8" tells Composer to grab at least version 8.8.

Composer will churn away, and eventually tell you that it's done.

Try the ls command now, and you'll see that Composer has installed files and folders for you. Here's what I see when I type ll, a cousin of ls:

Great! The Drupal files are there.

Make the student data files folder

We need a secure place to store student data files they upload, like their spreadsheets, Word documents, whatevs. Let's make that now.

You can make it with the terminal, using the mkdir command. Make sure that the current folder is the root of your subdomain. For me, that's learnweb.skilling.us.

We'll need the full path of the folder later. It's easier to get it now, do we don't have to come back. cd into the student-files folder. Then use the pwd command. It stands for print working directory.

You'll see the full path of the folder, the /home/... thing. You'll need that later, so copy it. You can select it, and copy it onto the clipboard, if you want, and paste it somewhere safe.

(Hint: you may need to set group write permission on the folder. We'll talk about setting permissions later. If you need to, use the same process to set group write permission on the student data folder.)

Change the root of your subdomain (a little)

If you go to your subdomain right now, you'll see something strange:

What? Where's your website?

When Composer download all the Drupal files, it put them in the folder web. Argh! No worries. It's easy to change https://learnweb.skilling.us, to that it points to the server folder ~/learnweb.skilling.us/web, rather than the folder ~/learnweb.skilling.us (~ is your home folder, remember).

Making this change also helps secure the student-files folder, which will be outside your website when you make this change.

Go to the subdomains in cPanel. You'll see the subdomain you created. Mine is:

Click the edit icon, the pencil thing. Add /web to the subdomain's root folder.

Click Change, and you'll see:

Look at your domain list, to confirm:

Run the Drupal installation program you downloaded

OK, now point your browser at the subdomain again, or refresh the one you have open. In the last step, you changed the subdomain's server folder to where the Drupal programs actually are. Drupal starts up, and runs its installation program.

Choose your language, and go to the next step. You can add language packs for other languages.

Next, the installation program asks which installation profile you want. Choose the standard one.

Now Drupal will ask you about the database it should use. Fill in the form, using the data you saved earlier.

The installation program will crunch away. Eventually, it will ask you for some basic site configuration information.

The site maintenance account is the most important account on your site. Many people use the username admin, but I recommend using something else, like explodingtentacles. Make sure you enter an email address that you check often, since Drupal.Org will send security update announcements there.

You'll also choose a region for the site.

Most of my students live in the Detroit metro area, so that's what I chose. Students who live in other regions can set their accounts accordingly.

Save, and you'll see the front page of your new Drupal site.

(Your menu may be on the top. Depends on how big your browser window is.)

Hooray!

Improve security

OK, click on Configuration.

Huh? How can there be a problem already? Click on the link to the status report. Scroll down, and you'll see:

There's a change we can make to one of Drupal's settings to improve security. We can tell Drupal what subdomain its programs should be running on. We hard-wire that in, to prevent shenanigans. Let's do that.

Let's use cPanel's File Manager. You can use the terminal if you want, with the editor Nano, but the File Manager is easier.

Look at the folder <your domain's folder /web>/sites/default. Here's where it is on my server.

That folder container settings.php, the file we're going to change.

There's the file, settings.php. It has lots of stuff in it, like the database name and password entered during installation. The file has sensitive data, so Drupal locks the file down tight.

Notice that the permissions of the file are circled, that rather unhelpful 0444 thing. 0444 means that we can't change the file, even though we want to. Hmm. We want to edit the file to improve security, but we can't because the file is locked, to improve security.

What we'll do is loosen the file's permissions to allow us to edit it, make the changes, then tighten up the permissions again. A pain, but, well, security work is like that.

OK, let's give ourselves permission to edit the file. Actually, it's worse than that. We also need to give ourselves write permission to the folder the file is in! Sheesh! Paranoia, much?

Right-click on the file, and choose Change permissions.

Give the user (that's you) write permissions, and click the Change permissions button.

Now we've given ourselves permission to change the file settings.php. But we need to do the same to default, the folder that settings.php is in. So, go up level to the sites folder (that contains the default folder). Right-click on default, and give yourself write permission.

OK, now we can edit settings.php. Right-click on it, and choose Edit.

An editor opens. Find the code we want to change, by looking for the word trusted. (I hit Ctrl+F, typed trusted, and jumped through them with the arrow buttons on the right of the search field.)

Here's what you'll find:

Drupal's programmers have added the code we want in comments. The * in the front of a line means it's a comment, and the server will ignore it.

Copy the lines between @code and @endcode, and paste them after the section, at about line 733. Remove the *s. Here's what I got:

OK, now we need to put in our domain. Put the domain name between the ^ and the $, replacing what's there:

But we're not done yet!

The .s (periods) in learnweb.skilling.us have a special meaning to the server. We need to tell the server:

No, dude, we really mean ., not something special.

The way you do that is put \ (back slash) in front of each ., like this:

Notice it's back slashes (\), not forward slashes (/).

Save the changes, by clicking, er, the Save Changes button.

To see if it worked, go back to the status report. The error should be gone.

OK, while we're here, let's make another change to settings.php. Remember we created a folder called student-files, to hold files that students upload. It’s outside the /web folder that’s the file root of your subdomain. That means that files in student-files can’t be accessed directly over the web.

Now, let's change settings.php, to tell Drupal about this folder. Around line 547, you'll find what you need to change.

Remember the file path you copied earlier, when you created the student-files folder? Paste it in, and remove the # (otherwise, Drupal will ignore the line). I ended up with:

Save settings.php. Now, Drupal will know where to put private files. Skilling is set up to use the private file path for student data. We'll check later, to see if it worked.

Don't forget to change the permissions back! On both settings.php, and the folder default that contains settings.php, remove the user write permission.

OK, that's the end of this step. Just one more to go.

We should see our private file folder in there.

Yay! There it is!

Bogus error in the status report (maybe)

You might see the following error in the status report:

This isn't a real problem. The message should go away by itself, after you install some more stuff on the site.

At last!

Installing Drupal to be secure has a lot of steps. It's worth it, though. Getting your site hacked, or having students steal each other's work, is a Bad Thing.

Remember, if you need help, you can contact Kieran.