ITaP Web Services hosts a shared WordPress environment available to Purdue users for academic or University business purposes (those wanting a personal site should look at web.ics.purdue.edu instead). WordPress offers site developers a streamlined way to create and easily maintain certain types of web sites, such as blogs and information portals. Web Services keeps your site up to date and provides you with the tools you need to make and deploy customizations, test updates, and recover from issues.

Table of Contents

Requesting a WordPress Site

Before requesting a WordPress site, please read and understand the following information:

Web Services wants to ensure that WordPress is the correct environment to use when someone requests a WordPress site. Many of our customers choose WordPress because they have been told, “It’s easy!”, or because someone has recommended it to them, but they don’t know all that is involved.

WordPress is offered as-is, and any site customization beyond the default configuration is expected to be supported by the site developer(s). Web Services will provide a reasonably secure and stable hosting environment and an initial WordPress configuration that is known to work. Web Services will ensure that environment remains compatible with the WordPress software in general, so long as the support provided by our operating system vendor allows for that.

If you require a fully supported Content Management System (CMS), training for end users, or otherwise don’t have available the development resources you need to support a WordPress site, Web Services encourages you to request a Cascade-based site instead. If you require design services, Web Services encourages the use of Purdue Digital Marketing’s digital design service.

If you agree to the above, please continue.

To request a new WordPress site, send us an email to get started. We’ll need you to provide us with the following information:

  • The site’s title.
    • You can change this later if desired.
    • It should briefly describe the purpose of your site.
  • Your desired URL for the site.
    • All URL requests are subject to approval by the owner of the parent site.
    • A site URL should be descriptive of the site’s purpose and show how it relates to the overall site structure to which it belongs.
    • Most public-facing Purdue websites should appear under www.purdue.edu, followed by their department or academic area, and should then follow any naming standards used by that parent site. Top-level subdirectory sites may be approved at Purdue Marketing and Media’s discretion. Other top-level Purdue subdomains may have different rules regarding sub-sites and URL selection set by their owners.
    • Top-level subdomain sites, which may be used when the site does not relate to Purdue’s public web presence, must conform to the hostname standard.
    • For accessibility reasons, a site URL should not contain spaces or underscores. Separate words with dashes instead. Additionally, URLs should not rely on case changes to convey meaning, as this information is typically lost for those using screen readers or other similar technologies. Keep this guideline in mind when choosing page names too!
    • You may need to provide two or three options if your first choice isn’t available.
    • Web Services advises against using a URL in printed material until it has been approved.
  • The Owner(s) (or primary decision-making contacts) for the site.
    • Owners can be added or removed upon request from an existing Owner.
    • By default no site access is granted to Owners unless they are also Developers.
    • Owners are responsible for ensuring a site has at least one Developer (the Primary Technical Contact) capable of meeting the responsibilities laid out below.
    • Owners are responsible for keeping Web Services updated regarding who should have Owner and/or Developer access to their site.
    • Owners are also responsible for working with Developers to ensure the site meets any University policies or guidelines that may apply, including accessibility, copyright, branding, etc.
  • The Primary Technical Contact for the site.
    • The Primary Technical Contact will get the same access as a Developer (see below).
    • They will be listed as the technical contact for the MySQL database request, so will receive and need to respond when needed to technical communication regarding the site’s databases.
    • They will receive all administrative email for the site unless you select a different admin email address (such as a group mailing list, see below).
    • In addition to standard Developer responsibilities, they are expected to be responsible for the following WordPress-specific duties:
      • Acting as a technical support contact between Web Services and other site users.
      • Testing automatically installed updates each month, and reporting issues found that they cannot resolve to Web Services prior to Production patching.
      • Installing new plugins and themes when needed.
      • Managing user registration and maintenance within WordPress beyond the initial set of users set up by Web Services upon site creation.
      • Making modifications to site templates, child theme settings, etc. as needed, and troubleshooting issues those modifications may cause.
      • Installing updates to purchased plugins and themes (if used) for those add-ons that do not or cannot automatically update.
      • Troubleshooting WordPress issues related to customer-installed add-ons or configuration before contacting Web Services.
  • Additional Developers for the site.
    • Developers will get administrative access in WordPress, SFTP access to the Development server, and access in the Deploy Tool to deploy the site files and content.
    • All site Developers have certain responsibilities as defined in this standard.
    • You may also want some or all owners to have developer access.
    • Developers can be added or removed upon request, subject to owner approval, and are automatically made WordPress Administrators.
    • Subscribers, Authors, Editors, and regular Administrators can be added within WordPress at any time by an existing Administrator. Only Developers get SFTP and Deploy access, however.
  • Your desired administrative notification email address that WordPress and all other automated processes will use to notify you of changes and other important messages.
    • This defaults to the email address of the Primary Technical Contact.
    • A group email is suggested, but not required.
    • You can change this later if desired.
  • If this needs to be a multi-site network, or is a pre-created site that needs to be imported, please let Web Services know before your site is created if possible.

Important: Between Owners and Developers, each site must have at least two points of contact to meet Internal Audit guidelines.

(back to top|table of contents)

Environment Overview and Getting Started

When you get a WordPress site from Web Services, you’re actually getting three sites. One site is your Production site and has the URL you requested. The others are non-Production sites: Development and QA (Quality Assurance).

At first, only your Development site will work. You’ll get started by logging in there. Once you get it set up, configured, and designed the way you want, you’ll want to deploy it to QA for testing and then to Production once it’s ready to go live. WordPress doesn’t deploy quite like a normal web application, however, so how you use those three tiers is slightly different than normal.

What follows is how ITaP Web Services recommends you use each tier, how to determine the URL, and any special notes about accessing it.


  • The URL is usually your Production URL with “dev.” added to the beginning. For example, dev.www.purdue.edu is the Development version of www.purdue.edu.
  • Use for initial site development.
  • Once your site is in Production, use Development to make changes to your child theme, install new plugins, and install any manual updates that are required.
  • Only accessible on campus or via the campus VPN.


  • The URL is usually your Production URL with “qa.” added to the beginning. For example, dev.www.purdue.edu is the QA version of www.purdue.edu.
  • Use to test your newly created site before going live and potentially to showcase the site to clients prior to final approval.
  • Once your site is in Production, use QA to test monthly updates against a recent copy of your Production site, and as a testing destination for plugin, theme, and child theme changes before deploying them to Production.
  • Only accessible on campus or via the campus VPN. Temporary exceptions can be made upon request for testing purposes.


Note: The naming convention for non-Production sites specified above is not absolute. For example, dev.itap.purdue.edu is the Development version of www.itap.purdue.edu, rather than dev.www.itap.purdue.edu. If you aren’t sure what your non-Production URLs are, please ask.

(back to top|table of contents)

Learning How to Use WordPress

Once you have your WordPress site, you’ll want to learn how to use it as well as how to use the various management tools that we provide. Use the links below to find the documentation you need.

(back to top|table of contents)

Getting Help with WordPress

When you run into trouble with your WordPress site or our services in general, the following links should let you find the help you need and maybe even fix the problem yourself.

(back to top|table of contents)

Detailed Environment Description

This shared WordPress environment is Linux-based and runs Apache HTTPD with PHP. It is separate from the PPWC. Each WordPress site in the environment has Development, Quality Assurance (QA), and Production versions. Web Services installs WordPress for all new sites, which includes requesting the required MySQL databases and setting up integration with Purdue Career Account authentication. Updates are automated wherever possible and performed on a monthly basis.

Update Schedule

Each month, updates are automatically installed for all WordPress sites. WordPress core as well as plugins and themes from WordPress.org will always be updated when updates are available. Additionally, correctly configured themes and plugins from other sources will try to automatically update as well (refer to the documentation included with the theme or plugin for more details). Reminders are sent to site owners after each update round asking that sites be tested and issues reported to Web Services as soon as possible.

  • Updates are installed in Development on the first Tuesday of each month at 7:30 AM Eastern. The latest available version of each component is always chosen.
  • Updates are installed in QA on the first Wednesday of each month at 7:30 AM Eastern. These will be the exact same updates installed in Development the previous morning.
  • Updates are installed in Production on the third Tuesday of each month at 7:30 AM Eastern. All components will be updated to the same versions that Development and QA were previously.

Important: Some purchased themes and plugins must be updated manually. This is true for any themes and plugins that do not use the official WordPress update mechanism as well as any that are not licensed on all three tiers or require manual steps as part of the update process. A reminder about this is included in each update notice.

(back to top|table of contents)

Audit Schedule

On the Shared WordPress Cluster, an automated utility audits all sites on a periodic basis. Currently, the following audits are performed:

  • Site disk quotas are checked, with quota issues automatically reported to Web Services.
Periodically Through the Day and During Database Deployment
  • File permissions are checked and corrected to ensure both WordPress and Deploy can operate securely and as expected.
Twice Daily
  • New plugins that have yet to be evaluated automatically generate tickets to Web Services requesting an evaluation.
  • Plugins that are known to cause issues or otherwise cannot be allowed on a shared environment generate notices to site admin contacts for removal.
  • WordPress is checked for security and standards compliance. Issues that can’t be fixed safely and automatically are reported to Web Services and a snapshot of any affected site is automatically taken for later analysis.

(back to top|table of contents)

Shared WordPress Cluster Specs

Development Tier
  • SFTP Hostname: sftp.wp.www.purdue.edu
  • Server Hardware: VMWare ESX virtual machine with 2 CPUs and 4 GB of RAM
  • Operating System: Red Hat Enterprise Linux 7
  • Apache HTTPD: 2.4.6 (latest provided by Red Hat)
  • PHP: 7.3.11 via PHP FPM
  • WordPress: Latest (as of the update window)
  • PHP Settings: Memory limit of 128 MB, maximum upload size of 32 MB, session and object cache in local memcached
QA Tier
  • Server Hardware: VMWare ESX virtual machine with 2 CPUs and 4 GB of RAM
  • Operating System: Red Hat Enterprise Linux 7
  • Apache HTTPD: 2.4.6 (latest provided by Red Hat)
  • PHP: 7.3.11 via PHP FPM
  • WordPress: Latest (as of the update window)
  • PHP Settings: Memory limit of 128 MB, maximum upload size of 32 MB, session and object cache in local memcached
Production Tier
  • Server Hardware: Two VMWare ESX virtual machines with 4 CPUs and 16 GB of RAM each
  • Clustering: Dynamic load balancing via F5, shared filesystem for /var/www, shared memcached object cache for sessions
  • Operating System: Red Hat Enterprise Linux 7
  • Apache HTTPD: 2.4.6 (latest provided by Red Hat)
  • PHP: 7.3.11 via PHP FPM
  • WordPress: Latest (as of the update window)
  • PHP Settings: Memory limit of 128 MB, maximum upload size of 32 MB, session and object cache in shared memcached

(back to top|table of contents)