WHM & WordPress Tips & Tricks

In my day job, I work a lot with WordPress and lately we’ve been utilizing a VPS or Dedicated server for more labor-intensive needs when shared hosting won’t cut it. Further, this site you’re reading now, along with about 8 others I own, are currently hosted on a VPS I’ve had for about 6 months now.

During this time, I’ve learned a lot about server management from the Linux command line, WHM (Web Host Manager, for the uninitiated), and cPanel. Below are just a few of the more helpful things I’ve learned along the way.

WHM vs. cPanel

If cPanel is the user interface for managing you hosting account, think of WHM as the user interface for managing all of your cPanels. Most people won’t ever see/use WHM because with most shared hosting accounts, you don’t get WHM access. However, as soon as you purchase a VPS or Dedicated server, you’ll be provided WHM as a way to manager all of your sites on the server. Resellers are very used to WHM as they use it to manage their clients.

WHM doesn’t allow you to do anything you can’t do from the command line & an FTP client but it sure does make it easier and faster. The WHM interface is very cPanel-esque and once you learn where the main things are, it’s pretty simple.

~tilde access for temporary site access

One of the great things about setting up a shared hosting account and registering a new domain name is the fact that most hosts give you immediate access via the IP address followed by “/~account_name”. When I first began using my VPS, I noticed that this helpful option is turned off by default.

Turning it on is a really simple procedure. Basically the Apache module mod_userdir needs to be enabled. To do so, log into WHM, open the ‘Security Center’ tab in the sidebar, and click the first option, ‘Apache mod_userdir Tweak.’ Once there, uncheck the ‘Enable mod_userdir Protection’ box and viola! your /~username conventions will now work.

A note from the cPanel user manual: “Disabling this is desirable, as the bandwidth used when the site is accessed using this method is attributed to the web host’s main domain, skipping bandwidth monitoring systems.”

Whitelist IP addresses

When setting up a new site, or constructing one for a client, it’s not unusual to hit (that is, access) a site several hundred times an hour (esp. if you’re awful at CSS like me and need to refresh a lot.) Default firewalls are typically set to quickly lock users out for what looks like ‘spam’ OR if you happen to forget a password and attempt to login with the wrong credentials more than a few times.

To prevent this, it’s a good idea to quickly whitelist your IP address (at home and work) as well as any potentials clients who will be accessing the site a lot. To do do, go to the very bottom of the WHM sidebar and open the Plugins option, then ‘ConfigServer Security & Firewall’. Once there, look for the Green box that reads ‘Quick Allow’. Simple enter your IP addresses here, one by one, and click Quick Allow. You can also use wildcards here.

Set recursive php.ini location

Over and over, WordPress plugins require more that 8, 16, and even 32MB of PHP memory to run. Many hosts limit the ceiling of PHP memory allowed to 32 or 64MB (Midphase upped one of my accounts to 96MB upon request, but it took getting in touch with a System Admin. for the concession and I got a strong warning that if more than 7 processes used 96MB simultaneously, my account would be subject to suspension.)

Anywho, without getting into the details of the PHP.ini file and why it needs to be modified (that’s another post), in order to be truly useful, the newly created .ini file needs to be placed in EVERY directory on the server. That can be really tedious for many reasons. (1) It’s a pain to place it in every directory and (2) to make a change, one has to replaced it every directory. Fortunately there’s a solution that makes use of your .htaccess file.

Most WordPress users will only be familiar with their .htaccess file as it relates to their permalink structure as this is the file WordPress writes to for mod_rewrite rules. The .htaccess, among other things, is useful to creating permanant 301 redirects, custom rewrite rules, and setting the location of a ‘global’ .ini file.

I use the term ‘Global’ loosely as the VPS or Dedicated server’s PHP.ini file has the ‘ultimate’ ceiling defined but a local .ini file can up your limits to the max of what is allowed. So ‘global’ is the local sense. Confusing, I know.

Back to the helpful part: Rather than placing this file in every directory, simply place your PHP.ini file in a central locale and then add the following line to your .htaccess file:

SetEnv PHPRC /location/todir/containing/phpinifile

Notice that the command does NOT link to the actual .ini file but rather the directory in which the .ini file resides. Setting this value makes it easy to change, keeps you from having to place the .ini file in every directory, and finally, some areas in WordPress work much better with this line defined (For example, the Media Upload tool often doesn’t recognize an upload limit that has been raised from the 8MB initial limit to a newly defined 32MB.)

Closing remarks

These are just a few tips I’ve picked up in the last few months. When I have time, I’ll try to write a follow up article dedicated solely to the best practices for .htaccess files & PHP.ini files.

Easy WordPress Client Management via Command Line

I’ve had a WiredTree VPS for about 3 months now. In addition to hosting about 5 of my personal sites on it, I also host a few family members blogs and some pro-bono stuff I’ve done for past clients.

Anytime I get ready to create a new account on the VPS (which, in turn, creates its own cPanel account just as if one had purchased a shared hosting account) I always dread the next step of downloading the latest version of WordPress, grabbing the latest copies of what I consider ‘base-install plugins’ (that is, plugins that I always include in a WordPress installation. These include Absolute Privacy, Google Analyticator, All-in-One SEO Pack, Next-Gen Photo Gallery, WP-Optimize, WP Super Cache, Google XML Sitemap Generator, Contact Form 7, and Akismet.) [Note: I don’t always activate all of these in each build, but I do like to have them handy if I need them. In today’s ‘Unlimited Storage Space’ environment, these small plugins don’t get in the way.]

After going through this download, unzip, upload, and activate process about a hundred times, I figured there had to be an easier way. Yes, I know you can auto-install plugins (and even WordPress, via Fantastico or Softaculous) but I don’t pay for either of those two auto-installers on my VPS because, well, I don’t need them. Plus, I run my PHP as DSO on my VPS rather than suPHP, so there can easily be permissions issues since I run all processes as the ‘nobody’ user.

So, I began thinking…couldn’t I download the latest WordPress build, download the lastest plugin versions I want, put the plugins, extracted, in the wp-content/plugins folder and even toss in a few ‘Coming Soon’ or ‘Maintenance Mode’ themes in the wp-content/themes/ folder. Then, when I create a new account, I could just explode the zip file into the newly created public_html directory and the only manual process I would have to go through would be setting up the MySQL database and editing the wp-config. file–a process which I can now due in under 5min.

Well, that’s exactly what I did. I created the folder I wanted and zipped it up. Then I dropped it on my VPS in a high level folder and tried exploding it into a directory. What I noticed was that, since I had zipped things on my Mac and then uploaded to a Linux box, I had the nasty _MACOSX folders in each directory…making the zip file larger than it needed to be AND making things convoluted.

I did a bit of Google research and found that I just needed an archive utility that would zip ‘Windows Friendly’ files which simply excludes those Mac folders. There were several programs out there, but I settled on one called YemuZip for it’s simplicity and cost (free!). It has a simple drag-and-drop interface that worked perfectly.

I deleted the ugly directory I created the first time using the fantastic “$ rm -rf /ugly-directory” command, uploaded the newest zip and exploded it. This time, it worked like a charm. I quickly tied it to a database I had standing by and was able to log in, with themes & plugins intact, in a matter of seconds.

This process certainly beats the heck out of downloading WordPress each time and and then subsequently downloading plugins. Below, I’ll share the Linux commands for accomplishing this.

How to do it

Once you’ve created your zip (using a program like YemuZip if you’re on a Mac!), upload your wordpress.zip file to a neutral folder on your server. (By neutral, I simply mean a higher level folder that isn’t likely to be deleted…something like /home/.)

Then, you’ll want to ‘explode’ (uncompress) the zip file to a directory on your server.

You’ll need to have navigated to the directory where your recently uploaded wordpress.zip lives.For me, that means logging into my VPS via Terminal (SSH) and the using the bash command:

cd /home/

…which simply tells the server to ‘change directory’ (cd) to the /home/ folder. Then, you have two options for inflating: (1) you can pre-create the destination folder or (2) you can tell the command line to create it for you. I typically follow the latter, so my code looks like this:

unzip wordpress.zip -d /home/USER/public_html/destination

That “-d” tells Linux to create the referenced directory, “destination”, even though it doesn’t exist. If you’re inflating to a folder that already exists, you’ll simple leave off the -d.

The server-side explode takes about 2 seconds and then everything is ready for you to start configuring. In my opinion, this is the fastest way of quickly installing WordPress, fully configured, on a new server. (There are also config files you can include in your install to further personalize things, but I avoid those in most cases unless I’m setting up 5+ sites for the same client. You can Google that topic for more info.)

If you’re interested, I’ve included my latest ‘wordpress.zip’ here for you to download. All the plugins & core files are up-to-date as of the date of this post and it includes WP v. 3.0. I hope you find it useful. FYI: The unzipped folder is 18.6 MB. The zipped file is 6.0MB…another pro of uploading the zip to the server and inflating it there rather than the other way around.

Download pre-built WordPress.zip.

Do you have any tips or tricks for making things easier that I haven’t thought of? Please share you tips with us! Oh, and for what it’s worth, I also delete the “Hello Dolly” plugin…you would think Matt and the team would have gotten rid of this by now…