WordPress – Getting Started

Welcome to Purdue IT’s Shared WordPress environment! Below you will find some basic information useful to all new WordPress developers.

Requesting a Site

Please see the Shared WordPress Service page for information about how to request a new WordPress site.

Accessing the Service

Important: At first you will only have a Development site until you deploy your finished site to QA and Production.

Web Access

Your WordPress site is accessible via the standard HTTPS protocol using any modern web browser. Your site’s URL varies by tier:

  • https://Development-URL (where you develop your initial site and install add-ons)
  • https://QA-URL (where you test monthly updates)
  • https://Production-URL (your live site that people visit)

In most cases, the Development URL will be the same as the Production URL with “dev.” added to the front, and the QA URL will be the same as the Production URL with “qa.” added to the front. If you’re not sure, contact Web Services for help.

Important: Access to Development and QA is restricted to Purdue network IP addresses. This protects your non-Production sites while they’re still being developed and tested, and also makes sure they don’t show up in web search results.

WordPress Dashboard Access

You (and other authorized users) can log in to your WordPress Dashboard by clicking the “Log-In” link on the site homepage (if your theme provides it… many don’t) or by adding /wp-admin/ to the end of the Development, QA, or Production URL (see above). Purdue users should log in with their Purdue Career Account username (not email address) and password or their Purdue Career Account username and BoilerKey, if BoilerKey access has been set up.

Note: Development and QA sites and their Dashboards are only accessible from the Purdue campus network and Purdue VPN services.

The Dashboard is where everything happens on a WordPress site beyond viewing content and, if enabled, making comments. Depending on each user’s role, they can create and edit posts and pages, upload media, install plugins, customize themes, manage site users, and otherwise configure and administer the site.

Important: If your site uses the default “block” (Gutenberg) editor, you must be on a Purdue campus network or connected to a Purdue VPN service to save changes to posts and pages. This is true for Development, QA, and Production.

SSH/SFTP Access to Development

All developers must have an account on the Development WordPress server and must have a Purdue Career Account to be granted this access. Purdue users can request accounts by filling out an account request form. If your site will have external developers, you’ll need to first contact your business office and use the Request for Privileges process to get Purdue Career Accounts set up for anyone that needs them.

For the most part, site developers will make the bulk of their changes through the WordPress Dashboard (see above). Certain changes, like plugin and theme installation, modification, and deletion require SFTP credentials be provided when prompted but no separate SFTP client is needed. Advanced users may still wish to use a full SFTP client for certain changes and troubleshooting, in which case any standard SFTP client is supported. The following SFTP settings should be used with WordPress:

  • SFTP Server: sftp.wp.www.purdue.edu
    • If your site is on the new WordPress cluster, use ldvwebwp03.www.purdue.edu here instead
  • Port: 22 (the default)
  • Protocol: SSH2 (in WordPress), SFTP (using an SFTP client), or SCP (on the command line)
  • Username: The Developer’s Purdue Career Account username
  • Password: The Developer’s Purdue Career Account password.
  • Site Directory: (not used within WordPress, only when using an SFTP/SCP/SSH client)
    • Full Path: /var/www/html/root/<your-production-site-url>
      • Example: /var/www/html/root/www.purdue.edu/example/site
    • Shortcut: ~/HTML/<your-production-site-url>
      • Example: ~/HTML/www.purdue.edu/example/site

Notes:

  • FTP and FTPS will not work.
  • The SSH key and passphrase fields should be left blank unless you have previously set up and wish to use public key authentication with your account.
  • You may be told to temporarily use a different SFTP Server name while sites are being migrated to a newer WordPress environment.

SSH access is also provided to all Developers, but is usually not needed for WordPress except in advanced “power user” scenarios. Any standard SSH client is supported and every major desktop operating system provides an SSH client via the included “Terminal” application (though this is an optional install in Windows 10). Simply issue the command ssh username@ssh.wp.www.purdue.edu (substituting your Purdue Career Account username for “username”) and enter your Purdue Career Account password when prompted to log in. As mentioned above, advanced users may set up public key authentication instead of using a password if desired.

Important: To use SSH or SFTP access, including via the WordPress Dashboard, you must either be on a Purdue campus network or connected to a Purdue VPN service. Only the Development server is accessible via SSH and SFTP.

Adding Users

Everyone that you requested be made a Developer of your site will already have Administrator access in WordPress, but you might still need to grant access to more people like Editors and Authors or even Administrators who don’t need full Developer access. Here’s how to do that.

Picking a Theme

Unless you requested that Web Services enable a specific theme during site creation, you’ll find that your site is using whatever default theme ships with WordPress currently. You probably want to change that! Keep in mind, any site with “purdue.edu” in its URL needs to conform to the branding standards laid out by Purdue Marketing and Communications. The easiest way to do that is to use their official Purdue branded theme, but so long as you follow those guidelines any theme can be used.

Note: Sites that don’t have “purdue.edu” in their URL don’t need to conform to Purdue brand standards but still need to conform to modern accessibility standards.

Adding Plugins

Every site comes with a set of base plugins installed and configured. Some of these are required for the site to function and others are just so generally helpful that we include them for all sites. You can add additional plugins of your own too!

Restricting Access

Restricting access to WordPress sites and content works a bit differently compared to standard Apache and IIS sites. By default, all WordPress sites are public and any Purdue user is allowed to log in and get Subscriber-level access. Additionally, only pre-approved users (Administrators, Editors, and Authors) have more access than that by default, such as the ability to edit pages or change settings. These behaviors can be changed in various ways:

  • You can change how people log in:
    • By default WordPress uses basic (Purdue Career Account username + password) authentication for Purdue users. This can (and should!) be upgraded to BoilerKey multi-factor authentication wherever possible.
    • OAuth2 and Google Accounts can be supported to allow non-Purdue users to use their compatible accounts with your site.
    • Administrators can also create local, self-managed accounts for users, though in general this isn’t recommended since such accounts are easier to compromise.
  • You can restrict access to your entire site:
  • You can restrict access to individual pages:
    • Individual posts and pages can be made private with only registered Administrators and Editors able to view them. There is no built-in way to restrict individual pages or posts to logged-in users in general.
    • Alternatively, individual posts and pages can be password protected using a simple password that must be pre-shared with authorized visitors. This allows a post or page to be hidden from the general public without requiring the visitor to have a high-level role in your site.

Limitations

  • It’s not possible to restrict access to files in a site’s media library, including uploaded PDFs, Word Documents, etc.
    • Files in a site’s media library will always be fully public to anyone who knows the URL.
    • To restrict access to such things, you’ll need to host them on another service that supports file access restrictions like SharePoint or Box, then include a link to the shared file on your WordPress site.
  • By default there are only four user roles on WordPress sites: Subscriber, Author, Editor, and Administrator. These roles and permissions are site-wide, or sub-site-wide in a multisite network, and can’t be set per-page or per-directory. Some plugins may allow Administrators to define additional roles. Anyone not logged in is a visitor and can only view public content.
  • Users need to be granted access to sites or sub-sites individually. WordPress cannot make use of Active Directory groups to control access. LDAP-based department codes can be used if absolutely needed, but this prevents the use of BoilerKey and is both complex to set up and fragile.
  • Private sites can only be viewed by a person with an account on your site and private pages and posts can only be viewed by Administrators and Editors. By default all Purdue users can log in and get Subscriber-level access after logging in the first time, but this creates an account rather than simply granting access to view the private content. All WordPress accounts, Purdue or otherwise, need to be managed by site Administrators and will not automatically be removed when the user leaves Purdue.

If these limitations are deal breakers you should pick a different hosting environment.

Deploying Files and Content

Unlike a traditional website, WordPress sites are typically only deployed once in full, after initial site design in Development is complete. After that, all content changes can be made in Production directly. There are some additional uses for the Deploy Tool with WordPress sites, however:

  • Content from Production can be reverse-deployed to QA and Development, refreshing those instances with your latest changes to allow for better testing of patches and new plugins. This can also be useful when beginning a site redesign.
  • New plugins, themes, and child theme changes can be deployed to QA and then to Production since such things can only be done directly in Development.
  • A redesigned site can be deployed fully to QA and Production just like a new site.

Accessing Logs

There are four types of logs recorded for WordPress sites:

  • Access logs record who visits your site, what they view or download, and what errors they encounter, if any. While they can be viewed directly as shown below, these are also analyzed by the Webmetrix service and is often more useful when viewed there. These analytics are in addition to any external analytics service you might set up yourself such as Google Analytics or SiteImprove.
  • PHP error logs record errors encountered by PHP when running WordPress. These are useful when troubleshooting errors you see when using or administering your site as well as fatal errors that cause WordPress to crash.
  • PHP slow logs record operations that take so long that PHP has to give up. These can be useful when troubleshooting WordPress issues that don’t show up in the regular error log.
  • Apache error logs record instances where the web server itself encounters an error when serving your site. These are rarely useful for WordPress sites.

All of these logs can be viewed in the Unified Log Viewer for all site tiers or directly in Development. For the Unified Log Viewer:

  1. Log in to the Unified Log Viewer with your Purdue Career Account username and password.
  2. Find and click on “Shared WordPress Cluster” within the Dev, QA, or Prod section, depending on the site tier where you’re interested or able to reproduce the problem.
  3. If you’re looking at PHP error or slow logs, click on php-logs (all sites share the same PHP logs). If you want to see Apache access or error logs, click on apache-logs, then click on your top-level site.
  4. Click on the log of interest to open it. The current log of each type won’t have a date, while all historical logs will show the date when they were saved.
  5. The Unified Log Viewer will show the log and offer controls to filter entries and page through results. The filter box is very important for PHP error and slow logs so you can narrow the results down to your site. Note that some logs may be too large to display.

Tip: Be sure to reproduce the issue just before you open the log in the Unified Log Viewer, or refresh the viewer page after you’ve reproduced the issue. This should show any messages related to the issue as the most recent messages.

Advanced Users: If you want to view logs in Development directly, you can do this via SSH (see above). The log locations are as follows:

  • PHP Logs:
    • Current PHP Errors: /var/log/php-fpm/www-error.log
    • Current PHP Slow Log: /var/log/php-fpm/www-slow.log
  • Apache Logs (substitute your site’s Production host name):
    • Current Access Log: /var/log/httpd/vhosts/production-host-name/access_log
    • Current Error Log: /var/log/httpd/vhosts/production-host-name/error_log

Historical logs are available in the same locations. These append -<save-date>.gz to each filename.