WordPress

Web Services is pleased to announce the release of the Shared WordPress Cluster. This is a service upgrade and lifecycle replacement for the previous generation of the Shared WordPress service and offers improved features, capabilities, and performance. Please visit the announcement page for a description of the differences. Existing WordPress site owners will be contacted to schedule site migrations to the new system.

ITaP Web Services hosts a shared WordPress environment available to Purdue users for academic or University business purposes. WordPress offers site developers a streamlined way to create and easily maintain certain types of web sites, such as blogs and information portals. ITaP 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

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.
  • Your desired URL for the site.
    • Please read this article about how to pick a URL and what the approval process looks like for certain types of URLs.
    • You may need to provide two or three options if your first choice isn’t available.
  • The owner(s) (or primary contacts) for the site.
  • The developers for the site, who 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.
    • 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.
    • 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 us 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)


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)


Development, QA, and Production

When you get a WordPress site from ITaP Web Services, you’re actually getting three sites (or two on the older environment). One site is your Production site and has the URL you requested. The others are non-Production sites. WordPress doesn’t deploy quite like a normal web application, however, so how you use those three tiers is slightly different than normal.

Development

  • 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.

QA

  • 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.

Production

  • This is your live, Production site.
  • Once your site has been deployed to Production, make your day-to-day content updates here directly. You can always use Development or QA for riskier updates like theme changes and site redesigns.
  • Accessible to the world unless you request otherwise.

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)


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 at least a Development version and a Production version, and sites on the cluster also have a QA/Test version. ITaP 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, on the Shared WordPress Cluster, correctly configured themes and plugins from other sources will 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 Wednesday of each month at 7:30 AM Eastern. All components will be updated to the same versions that Development and QA were previously.

Some purchased themes and plugins must be updated manually. This is true for all purchased themes and plugins in the legacy WordPress environment, as well as for any themes and plugins that do not use the official WordPress update mechanism. 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:

Hourly
  • File permissions are checked and corrected to ensure both WordPress and Deploy can operate securely and as expected. A similar check is also performed in the legacy environment.
  • Site disk quotas are checked, with quota issues automatically reported to Web Services. This check is also performed in the legacy environment.
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 core integrity is checked against sources provided by WordPress.org. Issues 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: ldvwebwp02.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: 5.4.16 (latest provided by Red Hat)
  • 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: 5.4.16 (latest provided by Red Hat)
  • 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 8 GB of RAM each
  • Clustering: Round-robin load balancing via F5, shared filesystem for /var/www, shared memcached object cache for sessions and PHP objects
  • Operating System: Red Hat Enterprise Linux 7
  • Apache HTTPD: 2.4.6 (latest provided by Red Hat)
  • PHP: 5.4.16 (latest provided by Red Hat)
  • 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)

Legacy WordPress Environment Specs

Development Server
  • SFTP Hostname: ldvwebwp01.www.purdue.edu
  • Server Hardware: VMWare ESX virtual machine with 1 CPU and 4 GB of RAM
  • Operating System: Red Hat Enterprise Linux 6
  • Apache HTTPD: 2.2.15 (latest provided by Red Hat)
  • PHP: 5.3.3 (latest provided by Red Hat)
  • WordPress: Latest (as of the update window)
  • PHP Settings: Memory limit of 128 MB, maximum upload size of 20 MB
Production Server
  • Server Hardware: VMWare ESX virtual machine with 4 CPUs and 8 GB of RAM
  • Operating System: Red Hat Enterprise Linux 6
  • Apache HTTPD: 2.2.15 (latest provided by Red Hat)
  • PHP: 5.3.3 (latest provided by Red Hat)
  • WordPress: Latest (as of the update window)
  • PHP Settings: Memory limit of 128 MB, maximum upload size of 20 MB

(back to top|table of contents)