cPanel in WordPress: Which Tools You Need, and How to Use Them

cPanel for WordPress

In my WordPress work, I rarely go long without using cPanel, the server administration tool that most shared hosts offer their customers. cPanel’s visual interface looks like AOL used to look back when they were shipping CDs, but I’ve really come to love it because of the breadth of server administration tasks it makes possible (and even, on a good day, easy).

However, cPanel is not a fully standardized product across hosts: it carries a lot of add-ons of varying quality. Some cPanel features are absolutely crucial (phpMyAdmin comes to mind), some are functional but unnecessary (the various autoinstallers mostly fit this bill), and some do just about nothing (in the two hosts I’ve tried, opening “Domain Manager” either redirects you to your hosting account homepage or tries to log you out!).

So today I thought we’d examine the cPanel tools that a WordPress site owner really needs: the ones that I find myself actually using in my work for my clients and myself.

cPanel overview

History

cPanel has been around since the mid-1990s. It runs in a Linux server environment, and offers graphical user interface (GUI) tools to enable users to complete a wide variety of server administration tasks that would normally have to be completed using command-line tools.

cPanel is currently not manufactured by any single hosting company, but sold to hosting companies by a standalone corporation called “cPanel, Inc.”

Who uses cPanel?

The short answer: shared hosting providers.

If you have a managed WordPress host like WP Engine or Media Temple’s managed hosting (which, by the way, we recently reviewed), you’ll be using a streamlined custom-built WordPress interface, and not cPanel.

If you’re on a shared host like Bluehost, HostGator, or GoDaddy, you’ll be using cPanel to administer your site. (By the way, for shared hosting we recommend SiteGround heartily over the three names we mentioned above; check out our recent review of SiteGround for details. It also uses cPanel.)

Which services you actually need

The cPanel services circled in green below are the ones I find myself using in my WordPress work:

cPanel apps for WordPress

Let’s explore each of them! We won’t go into great depth, so I’ve linked to external resources when I could. If you’re really looking for a step-by-step that isn’t provided below, some smart Googling should get you there.

For each service I profile, I’ve also tried to include a l33t hack (that’s self-deprecating five-years-ago nerdspeak for “elite trick”): something I’ve learned over the years that makes using that tool easier, quicker, more secure, or overall better. So even if you’re familiar with cPanel, take a look and it’s likely you’ll learn something!

Email

Email Accounts

What it’s for: This lets you set @mydomain.com email addresses for all the domains registered to your account. The email coming in to these accounts will be stored on your server, just like your website itself—and, depending on your settings, can either be kept on or deleted from the server when they’re downloaded to an email client (like Outlook) running on your local machine.

l33t hack: If you use Gmail or a similar email service provider, you may not ever need this feature! See “Email forwarders” instead.

Email Forwarders

What it’s for: This is my favorite way to handle @mydomain.com email. You just create any @mydomain.com address you’d like, set it to forward to any existing, externally hosted email address (like a Gmail account), and all mail sent to the @mydomain.com address you maid up will hit your existing address’s inbox instead.

l33t hack: With Gmail’s “Send mail as…” feature (in Settings > Accounts and Import), you can send mail from the forwarding address as well—meaning, in my opinion, that nobody should ever need anything but a single Gmail account as their email client. (Again, presumably Hotmail, Yahoo mail, etc. have similar services; I just know and love Gmail.)

FTP

FTP Accounts

What it’s for: This lets you set up FTP accounts, which allow you to upload files (like WordPress itself) to your server using an FTP client like FileZilla.

One usage note: Make sure you give your accounts web root access! In most cases, this will mean putting only public_html in the little “Directory” box. Whether it’s public_html or something else, the point is not to let the account creator confine you to a subdirectory like public_html/username; otherwise you won’t be able to work in any environment but mysite.com/username.
ftp_directory

FileZilla FTP passwordl33t hack: Don’t write down your FTP password, and don’t reuse a password you’re already familiar with. Instead, click “Generate Password” and paste the garble of characters that comes up directly into the “New Site” dialogue of FileZilla—both into the “Password” and the “Comments” fields. Then you’ve got it the only place you’ll ever need it, and it doesn’t matter if it’s memorable or not.

Domains

Subdomains and Add-on Domains

What they’re for: Both services help you create multiple sites on the same hosting account.

  • Subdomains look like subdomain.mydomain.com and could be used if, for example, you wanted to host an apparel store for your blog at swag.myblog.com while keeping the blog itself unchanged.
  • Add-on domains are full top-level domains—like mydomain.com—that you point to a subfolder of another hosting account. So, for example, you might register newdomain.com, but host its WordPress install at previouslyregisteredcomain.com/newdomain.

l33t hack: Use these services all the dang time. You can put a totally separate, fresh WordPress install in each subdomain or add-on domain you establish. Add-ons and subdomains are the way you physically take advantage of the “unlimited sites” offer that most shared hosts make.

Redirects

What they’re for: A redirect points a set of URLs (which could vary from a single page to a whole domain) to another set of URLs. For example, if you’ve moved myoldblog.com to mynewblog.com, the “Redirects” app can walk you through pointing your old traffic to the new site.

Note that redirects can really be a problem—particularly an SEO problem—if not done properly. So you may want to talk to a full-fledged developer if you’re going to be redirecting a live site that you care about.

l33t hack: Use .htaccess redirect rules instead. Your WordPress install will have a .htaccess file at the root of the install, and manually doing the redirects from there makes you absolutely sure what you’re doing. .htaccess syntax is pretty obscure—it’s a set of commands directly to the Apache server running WordPress—but can be learned with a couple of good tutorials and some Googling.

Security

SSH/Shell access

What it’s for: Opening an SSH (“secure shell”) connection gives you direct command-line access to your hosting account. This is a prerequisite for many of the most technical jobs that WordPress developers do, like configuring virtual development environments or interacting with Git version control.

Basically, if you run into a WordPress tutorial that casually begins with “In the command line,…” without telling you what the hell that means, your first step can be to SSH into your server.

Like the FTP account manager, you’ll use this dialog to create an SSH account with the credentials (a public/private key pair) you can use to SSH in with third-party software, like (if you’re on Windows) PuTTY, or like the Mac terminal app.

l33t hack: If you’re using this, you’re pretty l33t already. Bonus points if you call me up and explain how to set up a new SSH connection in SiteGround. I thought I’d do it as part of the research for this post and it’s completely failing to work; and their PuTTY walkthrough omits just enough crucial information to be unusable. Or if you’re really l33t, buy a Mac, and sell me your old one.

Database Tools

MySQL Databases and MySQL DB Wizard

What they’re for: As we explained last week, Every WordPress site stores much of its data—like post contents, permalinks, and post metadata—in a set of tables in a MySQL database.

These databases have to be created manually; there’s no WordPress script to do it. The easiest way in a cPanel environment is using the “MySQL DB Wizard.” This will guide you through creating a database with a particular name that you choose, and a single user of that database who should have full permissions to view and change its contents. See the WordPress Codex for a good thorough tutorial on this piece of setting up a WordPress install. Here’s a decent video tutorial as well.

Less commonly used is the “MySQL Databases” utility, which lets you manage databases in more detail: create or delete databases and users, edit user permissions to particular databases, or add and remove users from databases. You might want to use this utility if you wanted to scrap a WordPress database entirely—say, if you were taking a site permanently offline and its database contained sensitive information.

l33t hack: Again, don’t use manually generated passwords (or repeated passwords) for your databases. Auto-generate the DB password and paste the resulting garble directly into your WordPress install’s wp-config file, or into the step in the in-browser installation that asks for database details. You’ll most likely never use or look at that password again, and making it a random string that not even you can remotely remember is good for your site security. If you ever needed to look the password up, it’s always there in plaintext inside wp-config.

phpMyAdmin

What it’s for: Last, but absolutely not least, is phpMyAdmin, a third-party tool that offers an intuitive interface for viewing and editing databases. phpMyAdmin is your destination for the following jobs, among many others:

  1. Migrating a WordPress database “the old-fashioned way.”
  2. Examining the way WordPress data is structured, to be able to program against it. For example, where does WooCommerce put its product prices? The most foolproof way to find out is to physically locate the relevant database table and column in phpMyAdmin.
  3. Troubleshooting some kinds of database connection errors. For example, did you migrate a database, but the site is still showing the old data (like the “Hello World!” sample post)? The WordPress database is likely storing two sets of WordPress tables with two database prefixes (say, the default wp_ and the desired mysite_, and wp-config is talking to the wrong set of tables. phpMyAdmin is the place to go to find out.
  4. Selectively dropping tables. In the example above, once you reorient wp-config, you’ll most likely want to remove the default wp_ database contents, which are just cluttering up the database. phpMyAdmin’s “drop tables” graphical interface is the quickest and easiest way to do this.

There’s so much inside phpMyAdmin that it’s worth at least another full post—so stay tuned for that!

l33t hack: You can generally use your hosting account password to log into all databases associated with your hosting account.

And viola

And viola

So rather than trying to log into database mysites_first1 with the garble password from that site’s wp-config, just log into mysites_ with nothing after the underscore, and use the (probably human-memorable) password you use to log into your hosting account. And viola: you’ll be able to browse all your databases at once!

In conclusion…

cPanel is a great tool, and one that has contributed in a major way to my ability to confidently work in WordPress. I hope this introduction to what’s valuable in cPanel should give you a big head start toward being able to confidently use it yourself.

Did we miss anything? Any cPanel questions we could clear up? We’d love to hear from you in the comments below!

Image credit: Al Howat, Ctd 2005


4 Responses

Comments

  • The FTP stuff here is a bit hinky – although not reusing an existing password is solid advice, saving it in plain text in your FileZilla config is, I would argue, even less secure than writing it down somewhere. If you’re going to store passwords (any passwords), use a password safe.

    Typically, if I’m setting up WP on a 3rd party’s hosting account, I’ll have a set of passwords saved together in one place – cPanel root, wp database user and pass, any FTP accounts, MailChimp API keys, WordPress admin user logins etc. If you use backup /migration tools like BackupBuddy, then you want DB details to hand, outside of the wp-config.php file, because its contents will be overwritten anyway on install / migrate.

    Gmail caps the number of Send Mail as…. accounts at, I think, 10, so it’s not an infinitely scalable solution. Unless all these domains / sites you are setting up are throwaways, where a single catchall address is all that’s needed, it seems like an over-simplified solution.

    The technique works fine if you only work with these accounts from within gmail’s web interface. But any SMTP mail sent using Google is I think different, it gets its reply address rewritten to be the Google account. Only exception is the account marked as default in gmail.

    • Fred Meyer Fred Meyer says:

      Thanks for the thoughts, Hugh.

      On the FileZilla piece, I wonder what new vulnerability it exposes? If you’ve got access to someone’s computer, you can already FTP into all that person’s saved sites, and you can also export all passwords (in plaintext) as an XML file. Is the FileZilla config especially hackable remotely?

      Agreed that the Gmail solution isn’t infinitely scalable and may not work outside Gmail’s web interface. Neither of those are constraints I’ve run against; I like Gmail’s interface and only have a few email accounts.

      • Hugh Campbell says:

        WRT passwords, storing them in plain text on your computer is not much better than having them written down somewhere… if someone breaches the security of your machine, then you’ve given up access to all the sites stored in FileZilla, in one go. Getting a copy of your password safe database, on the other hand would give an attacker nothing, without the master password to decrypt it.

        A cPanel tool that I’ve just started using for site admin, when administration of a site is a shared responsibility, is to use the ‘mailing lists’ feature that is often baked in. Usually associated with old school discussion boards, it is useful as a single endpoint for all admin mail that WordPress generates- whether it be from user form submissions, general admin emails, or WooCommerce orders, multiple recipients can be kept informed, and people can be added or removed from an admin roster in a single place.

        Set up a private mailing list, add all members you need, and allow people outside the list to post (ie so that WordPress itself can post messages, even tho it’s not a ‘member’), and away you go. If the site generates emails requiring follow up, the admin team can simply reply to them (ie to the list) in order to discuss action required or delegate responsibility to other team members.

  • Clay says:

    Hey! Thanks for linking to my WordPress Htaccess redirect tutorial!