WordPress How-Tos

Below are the collected how-to articles for ITaP Web Services’ WordPress environments. These should provide a basic guide to using the service, along with links to other websites for further learning. If you have issues with or suggestions for a how-to, please let us know.


Table of Contents


Logging In

Unless you’ve imported a site built elsewhere, when you first visit your WordPress site, you’ll just see the default “Getting Started” message that sends you here. You’ve got an empty site now, and can build it as you see fit. The first step to constructing your site is to log into WordPress. If your theme has a Log-In link, click it, otherwise add /wp-admin/ or /wp-login.php to the end of the URL in the address bar and press enter/return. You can then log in with your Purdue credentials.

If you were the person who requested the site, or the person requesting the site asked for you to be added during site creation, you should already have full administrative access and can begin editing! You can also start adding more users.

(back to top|table of contents)


How to Manage Users

Most of the time, for most site configurations, the simplest way to add a new Purdue user to your site is to have them log in with their Purdue career account username (not their email address!) and password. This will add them as a Subscriber, and then any site admin can change their role as needed.

Some quick links:

Learn more about managing WordPress users.

(back to top|table of contents)


SFTP Configuration

Certain operations require site developers to directly manage files on the Development WordPress server using SFTP (or SCP). While some of these operations can be done through the WordPress Dashboard’s built-in SFTP support, many cannot. Therefore, if you are a WordPress developer, you will need an SFTP client. One option is VanDyke SecureFX, which is provided free to all faculty, staff, and students, and is available for Windows, macOS, and Linux. It can be installed upon request on ITaP-managed workstations.

Once you have your SFTP client, you will need to configure it as shown below.

  • Server: sftp.wp.www.purdue.edu
  • Protocol: SFTP (or SCP)
  • Port: 22 (the default)
  • Username: Your Purdue username (you must be a site developer)
  • Password: Your Purdue password
  • Site Directory:
    • Full Path: /var/www/html/root/<Production-site-URL>
    • Shortcut: ~/HTML/<Production-site-URL>

Notes

  • These settings will also connect you via SSH if you prefer or need a command line instead of file transfer, though you may also use ssh.wp.www.purdue.edu as the SSH server hostname if that’s easier to remember.
  • The server hostnames sftp.wp.www.purdue.edu and ssh.wp.www.purdue.edu will not change as these systems are upgraded in the future, and will always point to the current WordPress Development server.
  • You may use a public/private key pair for authentication instead of a password if desired, but support is not provided for that method.
  • After connecting, depending on how you configured the starting or site directory option you may need to navigate to your site directory.
  • Most newer SFTP clients will let you edit files remotely by double-clicking them or choosing an “Open With…” menu option.
  • Some clients may require you to manually transfer files to your desktop for editing, which you can then manually transfer back when done, overwriting the originals.
  • Most clients support transfer via drag-and-drop between the left (local) and right (remote) sides, as well as with other open file browser windows.
  • If you are using a Windows computer and want to upload the contents of a Zip archive, be sure to extract it first. Uploading from the Zip archive preview you get when double-clicking a Zip file in Windows Explorer won’t work.

How to Manage Plugins, Themes, and Child Themes

Plugins allow you to change how your WordPress site works, while themes allow you to change how your WordPress site looks. Child themes are a special kind of theme that allow you to override features and styles from the parent theme and therefore enable you to make safe modifications that will be preserved when updating the parent theme.

Some quick links:

Learn about managing WordPress add-ons.

(back to top|table of contents)


How to Test Monthly Updates

The first week of every month, new updates are automatically installed for all non-Production WordPress sites. After those updates are installed on each non-Production tier, the system will email each site owner that it’s time to test. At that point it’s time to test that those updates have applied successfully and haven’t broken anything. If they have broken something, you need to let ITaP Web Services know immediately so we can get that corrected before the Production updates install about two weeks later.

Testing Development Sites

  1. Visit your Development site. If you aren’t sure of your Development site’s URL, typically you can just add “dev.” to the front of your Production site’s URL. For example, the Development site for www.purdue.edu is dev.www.purdue.edu.
  2. Check for errors, broken pages, or other issues. Typically your Development site will look significantly different from your Production site, but should have the same theme and plugins active, so you’re mostly looking for errors.
  3. Log in to the site. See if there are any error or warning messages in the Dashboard. They should appear right at the top above all the Dashboard widgets.
  4. If you have purchased (or otherwise self-managed) themes or plugins, install all available updates using the instructions that came from the theme or plugin developer. If you saw any errors or issues before, see if they’ve gone away after these updates were installed.
  5. You may want to check your Development site’s error logs, especially if you’re seeing any issues that don’t have error messages displayed on screen.
  6. Report any issues found to ITaP Web Services ASAP.

Testing QA Sites

QA is where you can actually see what your Production site will look and work like after updates are applied. If your site hasn’t changed much since last month, you may optionally skip step 1.

  1. Perform a reverse content deployment to your QA site. This will overwrite your QA site with a copy of Production, so be sure there’s nothing there you want to keep.
  2. If you manually updated any themes or plugins in Development (like purchased themes or plugins), deploy those to QA now.
  3. Visit your QA site. If you aren’t sure what it is, just ask, but you can typically just add “qa.” to the front of your Production site’s URL. For example, the QA site for www.purdue.edu is qa.www.purdue.edu.
  4. Check for errors, broken pages, or other issues. This is exactly how your Production site will look if it were upgraded today.
  5. Log in to the site. See if there are any error or warning messages in the Dashboard. They should appear right at the top above all the Dashboard widgets.
  6. You may want to check your QA site’s error logs, especially if you’re seeing any issues that don’t have error messages displayed on screen.
  7. Report any issues found to ITaP Web Services ASAP.

Verifying Production Sites

Once Production updates are installed, site admins will receive a message asking them to verify their Production sites. When this happens, site admins should follow these steps:

  1. If you manually updated any themes or plugins in Development (like purchased themes or plugins), and deployed those to QA, deploy those to Production now.
  2. Visit your Production site.
  3. Check for errors, broken pages, or other issues.
  4. Log in to the site. See if there are any error or warning messages in the Dashboard. They should appear right at the top above all the Dashboard widgets.
  5. You may want to check your Production site’s error logs, especially if you’re seeing any issues that don’t have error messages displayed on screen.
  6. Report any issues found to ITaP Web Services ASAP. If your Production site is down or otherwise unusable, please also report the outage.

(back to top|table of contents)


How to Use Deploy With WordPress

Using the Deploy Tool with a WordPress site works quite a bit differently than using it with most other types of sites hosted by ITaP Web Services. This is because most of what comprises a WordPress site is stored in its database, with each web page being produced by WordPress running that content through your selected theme (and any active plugins).

When deploying your site, you can deploy either your site’s WordPress files, like your themes and plugins, or you can deploy your site’s content, which includes the full database. You can also reverse-deploy content from Production to QA and Development to freshen those tiers with your latest site content. However, be very careful when deploying content since it is easy to overwrite more than you expected.

Some quick links:

Learn more about using Deploy with WordPress.

(back to top|table of contents)


How to Work With Multisite Networks

A multisite network is a modification of a standard WordPress blog to allow for the creation and management of multiple, virtual sub-sites, all using the same WordPress installation and content database. Each sub-site is semi-independent and can have its own theme, active plugins, users, roles, etc. However, all sub-sites are governed by a number of Super Admins who manage the sub-sites, users, themes, and plugins used by the network. Super Admins can also specify which themes are available to sub-sites and can enable or disable plugins network-wide.

Some quick links:

Learn more about how to work with multisite networks.

(back to top|table of contents)


How to Set Up and Tune a Caching Plugin

By default, unless you’ve turned it off, your site will already have WP Super Cache enabled. If you turned that off and want it turned back on, just turn it back on in the Dashboard under Settings → WP Super Cache. If you deactivated or completely uninstalled it and want it back, or would like a completely different caching plugin, please follow the instructions below.

About Caching Plugins

Caching plugins can dramatically increase the performance of your site and reduce the load on the web server. They do this by creating static, pre-rendered copies of your site’s posts and pages on disk, then automatically serve those pre-rendered copies whenever possible. Caching plugins are smart enough to re-render pages that have changed (caching a new copy!), and typically won’t serve cached content to logged in users.

Important: Logged in users with content (even a posted comment) will not see any benefit from a caching plugin. If you want to test the performance of your site once the cache is built, remember that you need to log out. If the majority of your site visitors log in and leave comments, your site is unlikely to benefit from caching.

Conversely, you may notice that certain updates to your site don’t immediately appear for visitors who aren’t logged in, or even to you when browsing your site normally. This is because certain content updates, like theme changes, won’t be noticed by the caching plugin and won’t trigger the cached page(s) to be flushed and rebuilt. In such situations, your best bet is to tell your caching plugin to rebuild its cache manually.

Tuning Your Caching Plugin

By default, WP Super Cache comes pre-installed and set up very conservatively. While the default settings will help the web servers handle additional load, they may not do much to improve your site performance. To see the caching plugin improve your site performance, you’ll need to tune its settings to match how often you update your site and how many visitors you get in a day.

  1. First, think about how frequently you update your site. Is it hourly? Daily? Or less frequently, more like a traditional website than a blog?
  2. Second, think about how much visitor traffic your site gets. Do you see a few dozen visitors a day? Or maybe several hundred, or even several thousand? Web log analytics tools like Google Analytics and Angelfish can help you determine this. If you’re expecting a large influx of visitors due to a big announcement or special event, look at the cache pre-loading section below.
  3. Log into your WordPress site with an administrative account and visit Settings → WP Super Cache → Advanced.
  4. Make sure all the “Recommended” settings are selected in the Cache Delivery Method and Miscellaneous sections. Make sure nothing in the Advanced section is selected unless you’ve been instructed to select it. Scroll down and click Update Status if you’ve changed anything.
  5. Scroll down to the Expiry Time & Garbage Collection section. The settings are all very well described, so be sure to read that entire section. You’ll note that your cache timeout is probably set to 1800 seconds, with the timer set to 600 seconds. This is a safe default, but not usually very helpful.
  6. Read the four listed scenarios for the cache timeout and timer settings and choose one that best suits your site’s update frequency and expected visitor traffic. Enter the appropriate values in for cache timeout and timer (or choose a different timer style if needed) and click Change Expiration.

Using Cache Pre-Loading

Sometimes you know your site is going to draw an unusual amount of traffic, and you’d like to be prepared so your site doesn’t go down. For example, say you’re just about to start a social media blitz, put out a newsletter, put on a popular event, or get featured in a major publication that is likely to drive traffic to your website. It’s time to pre-load your cache!

  1. Make any changes to your site that you want live before pre-loading the cache.
  2. Before the period of increased traffic starts (if it’s already started, skip step 8), log into your WordPress site with an administrative account and visit Settings → WP Super Cache → Preload
  3. Consider how long you expect this high traffic period to last, or if you want to be able to make updates to your site while pre-loading is enabled. Set an appropriate number of minutes to have WordPress reload cache files and see changes.
    • If you don’t need to make changes, it’s OK to set this to 0
    • If you want to be able to make changes once a day, 600 or 720 minutes should work
    • If you want to be able to make changes frequently, 30 minutes will let you, but may reduce site performance
    • Pick something else if it makes more sense!
  4. Check the box for Preload mode. If you don’t, your pre-loaded cache will be erased when your garbage collection timeout expires (see the cache tuning section above). This may be desirable if you don’t want to have to remember to turn this off, your site has a very long cache timeout (like 86400 seconds), and you don’t expect the period of increased traffic to last longer than your cache timeout. Otherwise, check that box!
  5. If you use tags, categories, etc., be sure to also check the box to pre-load those. It’s safe to do this if you aren’t sure.
  6. Choose a progress notification option that suits you from the drop-down.
  7. Click Save Settings.
  8. Click Preload Cache Now. If you’re already seeing a spike in visitor traffic, you may not want to do this (it adds extra load) and just let the visitors naturally cause your site to become cached by visiting it.
  9. If you chose to receive progress notifications, watch for those. Otherwise, sit back and wait, maybe checking your site status occasionally to see how it’s doing. If you have live visitor stats enabled through something like Google Analytics, you can likely watch how your site is doing from that interface. Avoid logging in to your site.
  10. Once the period of increased traffic is over, log into your WordPress site with an administrative account and visit Settings → WP Super Cache → Preload. Uncheck both boxes and click Save Settings again. Your site is now back to normal.

About Content Delivery Networks, or CDNs

If you have access to a content delivery network (CDN), most caching plugins will let you use that to improve performance of your site for remote visitors. CDNs store and deliver static content for your site physically closer to your visitors, allowing faster page loads when your visitors aren’t near Purdue University.

Important Information:

  • Purdue does not currently provide access to a CDN, and they usually aren’t free. It is up to the site owner if they wish to purchase and use such a service.
  • Using a CDN will not improve performance of your site near or on the Purdue West Lafayette campus. In fact, it may reduce local performance. If most of your visitors are in the immediate area, do not use a CDN.

The exact steps to configure a CDN will vary depending on the CDN and your caching plugin. For example, WP Super Cache has a CDN tab for configuring this.

Installing a New Caching Plugin

If you’d rather use a caching plugin other than WP Super Cache or have uninstalled your caching plugin and want it back, follow these instructions.

  1. Choose a caching plugin. There are many to choose from, but ITaP Web Services installs, activates, and enables WP Super Cache by default. Note that some features of other plugins may not work, especially if they require an .htaccess file.
  2. Install the plugin in Development but DO NOT ACTIVATE IT. Neither you nor WordPress have sufficient permissions to activate a caching plugin successfully.
  3. Submit a request to ITaP Web Services requesting that your caching plugin be activated for your Development site with elevated permissions. Be sure to include:
    • The plugin slug or a link to the plugin download URL if it’s not WP Super Cache. If it is WP Super Cache, the slug is “wp-super-cache”.
    • Your Development site URL
    • If there are any special instructions that need followed beyond just activating (usually provided by the plugin developer).
  4. Once you hear back that it’s active (please allow at least 2 business days), log back in to your Development site and enable caching. Instructions for WP Super Cache follow (other plugins should come with their own instructions):
    1. Visit Settings → WP Super Cache
    2. On the Easy tab, choose the radio button to enable caching
    3. Save changes
    4. A testing section will appear. Click the test cache button. You should see green text that the timestamps match after a short delay.
  5. Deploy your site files to QA. Optionally, reverse-deploy your site content to QA if you want to see how Prod will behave with caching enabled.
  6. Log in to your QA site and enable your caching plugin with the same settings you did in Development. Test again the same way.
  7. When ready (and you can potentially stand some downtime if anything goes wrong), deploy your site files to Production.
  8. Log in to your Production site and enable your caching plugin with the same settings you did in Development and QA. Test again.

(back to top|table of contents)


How to Embed a Video from Kaltura

Unlike YouTube, Vimeo, and other popular online video services, Kaltura does not have native embedding support within WordPress. Not to worry, because it can embed itself!

Unfortunately, only one player skin is known to work properly with WordPress, so follow the below tips to ensure you get a working video player:

  • When choosing a player skin, choose the second skin up from the bottom (it looks like a YouTube player skin). You can choose any size you want.
  • Copy the generated embed code, starting with <iframe, and ending with </iframe>.
  • Use the WordPress editor like normal, creating your page and laying out text and other elements. When you’re ready to add your video, switch over to the “Text” view and paste the embed code where you want the player to appear in your page. This can be tricky if you’re not familiar with HTML code, but you can swap back and forth between the “Visual” and “Text” tabs to see where the video will appear, and move it around in the code as needed.
  • Once you’re happy with where the video is, click Update to publish your changes. The video will play when you click the play button when viewing the real page (not the editor).

(back to top|table of contents)