WordPress

Service Description

The Shared WordPress environment is a Linux-based system running Apache HTTPD 2.4 with PHP 7.3. It exists to supplement the Cascade CMS in situations where Cascade isn’t the best solution. The Production environment is clustered to allow more simultaneous visitors.

The Shared WordPress environment is the best choice when WordPress is specifically required, when a small team needs to produce and maintain a site quickly, and when a knowledgeable developer wishes to be able to deliver small sub-sites to contributors without requiring much training. On the other hand, this environment is not recommended for high traffic sites, sites with uptime requirements that can’t afford downtime for patching, and sites that have complex structures.

The Shared WordPress environment supports any URL that can be hosted by Web Services unless that URL occurs within another WordPress site in the same environment. WordPress sites come with a set of fully supported MySQL databases and by default authenticate users against Purdue Career Accounts via the Purdue IT OpenLDAP service. BoilerKey and local accounts are also available and supported with some setup on the developer’s part. Other account types, such as OAuth2, are also available.

Developers have access to the Development server via ssh or SFTP and use a web-based Deploy Tool to copy code and site-wide content changes to the QA and Production systems. Developers and all registered site users also have front-end access to the WordPress dashboard in Development, QA, and Production.

Getting Started

Web Services offers WordPress any college, department, or business unit of Purdue University for the support of the business of the University. 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 simple 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.

At the present time, there is no charge for a WordPress site on the Shared WordPress environment.

Support Notice for WordPress Sites

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 developers. 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, capabilities WordPress doesn’t support, 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 Marketing and Communication’s digital design service.

If you agree to the above, please continue.

Requesting a WordPress Site

To request a new WordPress site, please contact Web Services to open a ticket. We’ll need you to provide us with the following information:

  • Owner – This is the person(s) ultimately responsible for management decisions related to the site, including who may have developer access, if the site is still needed, etc. They may or may not also be a developer and may or may not have access to the WordPress dashboard.
  • Developers – These are the people who should have access to the Development server and the Deploy Tool to copy the site between Development, QA, and Production. Developers are also given Administrator access within WordPress and super-admin rights if the site is a multisite network.
  • Primary Technical Contact – This is the person who should receive administrative notices from WordPress and other automated processes. They must be a developer and be comfortable administering WordPress. If you wish to have multiple people in this role, a mailing list (which must be requested separately if you don’t already have one) can be used in place of an individual.
  • Site Title – This should briefly describe the purpose of the site and can be changed later if desired. This almost always appears on your site or in page headers, depending on how WordPress is configured and which theme is used.
  • URL Options – These should be the desired URLs, in order of preference, for your new site. Any requested URL is subject to various levels of approval unless you already own it. Providing alternatives helps avoid a certain amount of back-and-forth discussion.

If this needs to be a multisite network, is a pre-created site that needs to be imported, or you have any other special requirements, please let Web Services know before your site is created.

Once your site has been created, please see our Getting Started Guide for WordPress for detailed information about how to log into your site, make changes, deploy it, etc.

Important: Between Owners and Developers, each site must have at least two different points of contact who can make management decisions about the site to meet Internal Audit guidelines.

About Service Tiers

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 and are used to make and test certain types of changes to your site. 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.
  • At first, this is where you design and build your site before deploying to QA and Production.
  • 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, qa.www.purdue.edu is the QA version of www.purdue.edu.
  • At first, this is used 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.admissions.purdue.edu is the Development version of www.admissions.purdue.edu, rather than dev.www.admissions.purdue.edu. If you aren’t sure what your non-Production URLs are, please contact Web Services.

Developer Resources

Local Resources

Remote Resources

Getting Help

The Shared WordPress Service is intended for customers familiar with WordPress administration and optionally PHP development. Because WordPress is so customizable and because we do not have developers on staff, our ability to offer support is limited to the server environment and its interaction with WordPress. For example, we do offer support for the following:

  • Providing copies of logs that are not accessible to site developers
  • Answering questions about the environment and our modifications to WordPress
  • Restoring files and databases from backups
  • Restoring WordPress Dashboard access in the event that can’t be done by a developer
  • Basic troubleshooting to rule out server or service configuration issues
  • Basic support and access to vendor support for core required plugins

Support Requests

Please submit all requests for support by contacting Web Services to open a ticket. If the issue involves a production service outage, please follow the instructions in the automated response to escalate the priority of the ticket.

When opening a support ticket, please provide the following (at a minimum):

  • What exactly are you needing?
  • What is the URL of the site?
  • Is this about Production, QA, Development, or multiple tiers?
  • If there is an error or malfunction:
    • What is the error?
    • How can we reproduce the error?
    • What is the expected result?
    • A screen capture that includes the URL in the browser can also help.
  • If you are requesting a site to be restored from backups, please be sure to provide:
    • The date and time the site was last in a good state
    • The tier to be restored
    • Whether you would like us to overwrite the site in place or deliver a copy of the backup to you to go through

Service Specifications

Software Versions

The Shared WordPress service is provided on an Oracle Enterprise Linux v7 platform with:

  • Apache HTTPD 2.4.6 (latest provided by Oracle)
  • PHP 7.3.33 (latest provided by Oracle Software Collections)
    • PHP is executed via PHP-FPM
    • Per-process memory limit: 128 MB
    • Maximum file upload size: 32 MB (upload manager plugins can exceed this)
    • Memcached used for session data
  • WordPress tracks the latest release as of the first Tuesday of the current month

Database Support

The only supported and available databases to WordPress sites in the Shared WordPress environment are the MySQL databases provided with each site. A separate database is provided for each tier, and the Deploy Tool is able to clone content back and forth between tiers as needed. The MySQL version provided for all new sites is 5.7 with some older sites on MySQL 5.5.

Server Specifications

  • Development: 2 CPUs, 4 GB RAM
  • QA: 2 CPUs, 4 GB RAM
  • Production:
    • Node A: 8 CPUs, 32 GB RAM (shared storage host)
    • Node B: 4 CPUs, 32 GB RAM (shared storage client)

Memory, processor, and storage usage is monitored and will be increased as needed within reason. Additional production nodes can be added if needed.

Patching and Backups

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, themes and plugins from other sources that are properly registered and support the built-in WordPress update mechanism will automatically update as well (refer to the documentation included with the theme or plugin for more details).

  • 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 (following the first Tuesday) 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.

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. This notification will also contain details of what was updated along with any issues encountered during updates. Failed updates will not be carried forward to the next tier in most, but not all situations, so site admins need to act on reported issues promptly!

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. A reminder about this is included in each update notice.

Audit Schedule

On the Shared WordPress environment, 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.
  • Site disk quotas are checked, with quota issues automatically reported to Web Services.

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.

Accessing Services Behind Firewalls

In the unlikely event a WordPress plugin needs to access a service protected by a firewall, you will need to provide the following IP ranges to the administrator of that firewall so they can allow access. Usually this will be the Public address, but the internal Zoned Network addresses are provided in case a custom in-house plugin needs to access an Purdue-IT-hosted system.

Public and Zoned IP addresses of Shared WordPress Systems
Server Tier Server Name Public Address Zoned Address
Development ldvwebwp02.www.purdue.edu 128.210.23.92 172.30.196.92
Quality Assurance lqvwebwp02.www.purdue.edu 128.210.7.98 172.30.140.98
Production lpvwebwp02a.www.purdue.edu
lpvwebwp02b.www.purdue.edu		 128.210.7.93
128.210.7.94		 172.30.140.93
172.30.140.94