WordPress – How To’s

This page is dedicated to providing or linking to step-by-step how-to documentation that will help WordPress administrators get the most out of Web Services’ Shared WordPress environment. If you have issues with or suggestions for a how-to, please let us know.

WordPress 101

All WordPress sites have access to the WordPress 101 video tutorial plugin. This plugin gives WordPress site creators direct access to helpful video tutorials covering non-Purdue-specific aspects of using WordPress all within your site’s dashboard. That plugin is automatically activated for new sites, can be activated on any site, and has been made available to everyone by Purdue Marketing and Communications. You’ll find the tutorials near the bottom of your left-hand dashboard menu under “Video Tutorials”. Feel free to de-activate it once you no longer need it as it can be re-activated at any time.

This guide, on the other hand, focuses on Purdue-specific information and addenda to the general-purpose tutorials WordPress 101 provides.

How to Log In to WordPress

Visit the WordPress Getting Started page for help on how to log in to your WordPress sites. Remember that at first you’ll only have a Development site.

How to Access the Network Admin Dashboard

On WordPress multisite networks, there is a Network Admin Dashboard. This is where network super-admins can configure multisite-wide settings. To access this Dashboard, a super-admin should:

  1. Log in to the base site or any of its sub-sites.
  2. In the top bar of the Dashboard, mouse over the site name to reveal the site menu. It’s just to the right of “Log Out” and has a house icon.
  3. Choose Network Admin from the menu. If you don’t see Network Admin, you aren’t a super-admin or this isn’t a multisite network. Note that Network Admin also has a sub-menu so you can quickly navigate to some of the most important sections of the Network Admin dashboard.

How to Update the Admin Contact Email

The WordPress administrative contact email is extremely important to have set correctly in Development, QA, and Production since not only is this how WordPress tells you that action is needed on your site, it’s also how all of Web Services’ back-end maintenance automation is able to alert you to issues. When Web Services first sets up your site, this is set to either the email address of your primary technical contact or to another address you specified at that time. You can change it at any time, however:

  1. You must be a site administrator to change this value. If you aren’t an administrator, please contact an administrator for your site.
  2. Log in to each tier of your site starting with Development.
  3. In the WordPress Dashboard, visit Settings, then General in the left column.
  4. Find the field labeled Administration Email Address and change it to what is desired. Some important considerations:
    • This must be a single email address. If you want more than one person to get these emails, use a group address or mailing list. You can request one by contacting the Purdue IT Service Desk. Microsoft Teams group addresses work here too.
    • These emails will often be highly technical in nature. They should go to one or more experienced WordPress administrators.
  5. Click “Save Changes” at the bottom
  6. Repeat this on your QA and Production sites if they exist.

How to Manage Users

This section deals with how to add, remove, and change the roles of WordPress site owners, developers, and WordPress users. Web Services manages owner and developer access for you, while the site administrators (or super-admins in the case of a multisite network) manage WordPress users.

Important: Only developers have access to SFTP and Deploy and only WordPress Administrators (or super-admins) can modify WordPress user access.

Adding and Removing Site Developers (or Owners)

To change who is listed as a site owner and who has developer access to your site or request developer access for yourself, please contact Web Services. Please make sure your request contains the following information:

  • The site URL(s) (any tier)
  • The Purdue Career Account usernames (not email addresses) of the people you’re requesting a change be made for. If they don’t have a Purdue username, you’ll need to work with your business office to set that up first through the Request for Privileges process.
  • The permission changes requested

If anything else is needed, such as an Account Request Form, we’ll let you know.

Adding a Purdue WordPress User

There are two primary ways (and many, many others) to add a new Purdue user to a WordPress site, assuming they don’t need developer access (see above). Non-Purdue users aren’t covered by this guide, since they can be managed using the regular WordPress Users Dashboard page.

Important: For the most part you’ll only be managing WordPress users on your Production website since the only people using your Development and QA websites are typically developers who get access via the procedure above. The exception is removing users when they should no longer have access to your site: you’ll likely need to do this on all three tiers. That said, you can add users on multiple tiers using the same instructions presented by following them on your Development or QA site instead.

Option 1: User Initiated

This is the easiest option for new Purdue WordPress users themselves since they initiate the process when they’re ready.

  1. Ask the new user to log in to your Production website. If you have a multisite network, they should log in to a sub-site where they need access (others can be added later). It is very important that Purdue users log in with their Purdue Career Account username, NOT their email address, since the two can differ.
  2. Depending on your settings, this will either give them read-only Subscriber access or prompt a site administrator to approve the new user. Wait for the person to tell you they’ve tried to log in before continuing.
  3. Log in yourself. If you have left the Authorizer Settings widget on your main dashboard, you can approve new users and/or change their roles right there. Otherwise, visit Settings, then Authorizer and select the Access Lists tab to do this. Some notes:
    • If you require new users to be approved, they’ll be in the Pending Users section.
    • Next to each email address you’ll find a drop-down letting you choose a role for the user. Changing this applies the change immediately.
    • On WordPress multisite networks, these permissions exist both per-sub-site and also at the network level under Network Admin’s Authorizer Settings. You can grant someone access multisite-wide from the Network Admin version of this panel.
  4. Have the new user refresh the page or log back in.

Option 2: Pre-Authorization

This is the easiest method for site administrators since they can take care of the whole process before the user logs in.

  1. Log in to your Production website. If you have left the Authorizer Settings widget on your main dashboard, you can add new users and/or change their roles right there. Otherwise, visit Settings, then Authorizer and select the Access Lists tab to do this. If you have a multisite network, you’ll want to do this in your Network Admin dashboard instead.
  2. At the bottom of the Approved Users section, you’ll see a field labeled “email address”. Here you’ll enter the person’s Purdue Career Account username followed by @purdue.edu whether or not that’s their preferred email address.
  3. Choose the appropriate user role for this new user from the drop-down to the right of the address you just entered, then click Approve.
  4. Ask the user to log in themselves.

Bulk User Creation

If you need to create users in bulk, please contact Web Services. There is currently no built-in or automated process for doing this, so if you need to bulk-add (or remove) users regularly, WordPress is likely not the best tool to be using.

Adding Existing Users to Sub-Sites (Multisite)

Once a user exists somewhere in a multisite network, they can be granted the same or different roles on the other sub-sites in the network. The easiest way to do this is to use Option 2 above as written. There are also two other options if that won’t work for you:

  • “Add Existing User”, which appears in the Users dashboard page on sub-sites
  • The Users tab seen when editing a sub-site in the Network Admin dashboard

Changing a WordPress User’s Role

Important: In order to change a user role, you yourself must be a site administrator. In order to change super-admin status on a multisite network, you must yourself be a super-admin of that network. You can learn about the capabilities of each role under WordPress Roles and Capabilities.

The easiest way to change user roles is via Authorizer:

  1. Log in to your Production website. If you have left the Authorizer Settings widget on your main dashboard, you can change user roles right there. Otherwise, visit Settings, then Authorizer and select the Access Lists tab to do this. If you have a multisite network, you’ll want to do this in your Network Admin dashboard instead.
  2. Find the user whose role you wish to change in the Approved list and select a new role using the drop-down to the right of their email address. The change is immediate.

For multisite networks only, a user can have a different role on each sub-site (changed as above), and can also be given super-admin access to the whole multisite network. To change someone’s super-admin status:

  1. Log in to your Production website and visit the Network Admin dashboard’s Users section.
  2. While mousing over the user who’s super-admin access you’d like to change, click Edit.
  3. Check the box for Super Admin to grant super-admin access, or clear the box to revoke super-admin access.
  4. Click Update User at the bottom

Removing a WordPress User

Important: You must be a site administrator to remove a user from a site or sub-site, and a super-admin to remove a user from a multisite network.

  1. Log in to the website where the user needs removed. If they need removed from multiple sites (or tiers of the same site), you’ll need to repeat this process on each.
  2. Either using the Authorizer widget on the main dashboard or the Authorizer page under Settings, click the “X” button to the far right of the user(s) you wish to remove.
    • If the user owns any content, you’ll be asked to which account WordPress should now attribute that content. If you skip this step, you could lose site content!
    • If this is a multisite network, perform this step at the sub-site level, not at the network level, unless you want to remove the user from the entire network.
    • If this is a multisite network, the user is a super-admin, and you want to remove them from the network completely, you’ll need to revoke super-admin access first (see above). Note that super-admins have administrative access to all sub-sites whether they specifically have a role on that sub-site or not.
  3. If the person who was removed had developer access and you’re completely removing them, you’ll also need to contact Web Services to have that removed as well.
  4. If the person who was removed was also a site owner and they should not retain that role, please contact Web Services to have that removed as well.

How to Manage Site Access

This section covers how to change the ways in which your site and its contents can be accessed and by whom. You may also want to review the limitations WordPress has regarding access restrictions here.

Enabling Two-Factor Logins on Your Site

Two-factor (Duo push) logins are not enabled automatically for sites because it requires the site owner to first sign an SLA (Service Level Agreement) regarding its use. Once that’s signed and access enabled, it just takes a few clicks to switch your site over to use two-factor logins for Purdue users.

Signing the CAS SLA

  1. Request that your site be granted access to CAS (Central Authentication Service) by filling out and submitting the Single Sign-On Request form found on IAMO’s CAS Information site.
    • Only managers or directors may fill out this form, so you may need to work with your supervisor to complete it.
    • If you have questions about how to fill out the form, contact your supervisor, your business office, or the Accounts team for assistance.
    • Only request CAS access (skip other types like LDAP/LDAPS, etc.).
    • It’s important to enter all URLs your site may use, including the Development and QA tiers, along with their public IP addresses. If you aren’t sure what to put here, please contact Web Services.
  2. Wait for your request to be approved. Once you receive notice that CAS access has been granted to your site, you may proceed.

Enabling and Testing Two-Factor Logins

Once you hear back from Accounts that CAS is enabled for your site, it’s time to turn it on. You’ll need to repeat these steps on every tier where your site is deployed already, and you should start in Development.

  1. Log into your Development site. You’ll need to be an administrator in WordPress (or a super-admin for a multisite network) to follow these steps.
  2. For standard sites, visit Settings → Authorizer in the Dashboard. For multisite networks, visit My Sites (at the top) → Network Admin → Settings, then click on Authorizer (near the bottom on the left).
  3. Select the External Service tab.
  4. Check the box to Enable CAS Logins, which will cause more settings to appear. Set those options as follows:
    • CAS custom label: CAS or Duo Push (your choice)
    • CAS service hostname: www.purdue.edu
    • CAS service port: 443
    • CAS server path/context: /apps/account/cas
    • CAS server protocol: SAML 1.1
    • CAS attribute containing email address: mail
    • CAS attribute containing first name: givenName
    • CAS attribute containing last name: sn
    • CAS attribute update: Update first and last name fields on login
    • CAS automatic login: Leave this off for now
    • CAS users linked by username: Leave this off for now
  5. Changing nothing else, scroll down to the bottom of the page and click Save Changes.
  6. In a different browser or a new private browsing window (not just a regular new window or tab), visit your Development site and go to log in. Notice the new “Log in with CAS” or “Log in with Duo Push” button at the top of the login page (depending on what you picked for step 5A). Click that button, log in with your Purdue username and password, then respond to the Duo push to finish logging in.
  7. Assuming that worked, you’ve successfully enabled two-factor logins!
    • If you’ve already deployed to QA and/or Production, be sure to repeat these steps there.
    • If you would like to use two-factor logins exclusively (that is, automatically sending all logins to the CAS login page), move on to the next section.
    • If, on the other hand, something went wrong, un-check “Enable CAS Logins” in the browser window you left open to the External Service settings page, click Save Changes, and contact Web Services.

Using Two-Factor Exclusively

If you don’t have any non-Purdue site users, it’s recommended to use two-factor logins exclusively. Simply do the following once you’ve finished the above instructions:

  1. If you’ve not already enabled and tested two-factor logins as shown above, do that first.
  2. Log into your Development site. You’ll need to be an administrator in WordPress (or a super-admin for a multisite network) to follow these steps.
  3. For standard sites, visit Settings → Authorizer in the Dashboard. For multisite networks, visit My Sites (at the top) → Network Admin → Settings, then click on Authorizer (near the bottom on the left).
  4. On the External Service tab, check the box for CAS automatic login and then click Save Changes.
  5. On the Advanced tab, check the box for Hide WordPress Logins, write down the bypass URL listed in that option and save that just in case (you shouldn’t ever need it, but it’s good to have), and click Save Changes.
  6. In a different browser or a new private browsing window (not just a regular new window or tab), visit your Development site and go to log in. You should be automatically redirected to the CAS login page, and you should be able to log in with your Purdue username and password, followed by a Duo push response.
  7. Assuming that worked, you’ve successfully enforced two-factor logins!
    • If you’ve already deployed to QA and/or Production, be sure to repeat these steps there.
    • If that didn’t work, go back to your other browser window and undo the two check-boxes (Hide WordPress Logins on the Advanced tab and CAS Automatic Login on the External Service tab) saving changes each time. Contact Web Services for help troubleshooting the issue.

WordPress Roles and Capabilities

WordPress uses roles to determine what each user can do within a site or sub-site, and each role is a set of capabilities. You can learn more about user roles and capabilities in the WordPress Codex.

Limiting Who Can Log In to Your Site

By default, WordPress sites allow all Purdue users subscriber-level access to your site. This allows them to have an account, leave comments where comments are enabled, and follow updates to your site or blog. If you wish to only allow pre-approved users to have accounts on your site and require all new users to be approved by an administrator, follow these steps:

  1. Log in to your site and visit the Dashboard if you aren’t taken there automatically.
  2. Visit Settings → Authorizer and view the Login Access tab.
  3. Change “All authenticated users”, the default setting, to “Only approved users”.
  4. Click Save Changes when done

Important: This affects how adding users to your site works. Purdue users will no longer be able to self-register and must either be approved after a successful login attempt or be pre-approved by an administrator (see above).

Limiting Who Can View Your Site

By default, WordPress sites are public allowing anonymous visitors to view any page that isn’t otherwise made private. You can make your entire site private requiring all visitors to have accounts on your site to view it (Subscriber or higher) by following these steps:

  1. Log in to your site and visit the Dashboard if you aren’t taken there automatically.
  2. Visit Settings → Authorizer and view the Public Access tab.
  3. To make your whole site private, change the option from the default “Everyone can see the site” to “Only logged in users can see the site”. Note that for multisite networks, this setting is on a per-sub-site basis unless set at the network level.
  4. Click Save Changes when done.

Important: Private sites can’t have public pages. If you want to have some of your site public and the rest private, consider the next item below, but note that you must be an Administrator or Editor to view individual pages marked Private. Predominantly private multisite networks can have public sub-sites, however, depending on which sub-sites you configure as public or private.

Limiting Who Can View a Single Page or Post

Note: This section is no different on a Purdue site vs. WordPress in general and is provided for completeness of the topic.

By default, all newly published pages and posts are public if the rest of the site is public. You can change this on a per-page/post basis both before and after you initially publish it. Do this by changing the page’s or post’s Visibility setting to something other than Public, then publish or update the page:

  • Choose Private to limit this page to be viewed by Administrators and Editors only. It’s not possible to allow roles less than Editor to view Private pages without using additional plugins or manipulating roles.
  • Choose Password Protected to set a password that enables visitors who know it to see the page. You’ll then set a password that will need to be shared with everyone that needs access to the page. This password should not be used anywhere else!

Changing the Default Role for New Users

By default, all user accounts that are automatically created by Authorizer when a new user logs in (and is approved, if new user approval is enabled) get Subscriber access. You can change that default to no role at all by doing the following:

  1. Log in to your site on the tier where you want to make the change.
  2. Settings → Authorizer and select the External Service tab. If you have a multisite network and want to make this change for all sites instead of just one sub-site, use the Network Admin version of Authorizer settings instead.
  3. Select the “None” role for new users from the “Default role for new users” drop-down. This will give new Purdue (and other directory service, if configured) users no rights beyond updating their profile.
  4. Scroll to the bottom of the page and click Save Changes.

Note: Other roles can be selected as default, but selecting any role other than “None” or “Subscriber” is EXTREMELY DANGEROUS and should never be used.

Making Changes to WordPress Core or wp-config.php

WordPress sites hosted by Web Services do not allow modification of WordPress core files or wp-config.php even by site developers. This is to prevent a site developer from knowingly or unknowingly making a change that impacts other sites on the server or compromises system security. Exceptions can be made, however:

  • If you wish to update WordPress Core before the next automatic update cycle, contact Web Services to be allowed temporary access to update core files. You can then update WordPress via the dashboard in Dev and deploy those updates to QA and Prod after testing them.
  • If you wish to make changes to your site’s wp-config.php file, contact Web Services and detail the changes you wish to make. We’ll make them for you if they can be supported by this environment.

How to Manage Plugins

Plugins extend the capabilities of WordPress in small or large ways. How to manage and use them in Web Services’ WordPress environment is almost exactly the same as you would in any other WordPress environment with the following important differences:

  • You must have Developer access to install, update, or remove plugins. Non-Developers with Administrator access can activate and deactivate plugins but cannot install, update, or remove them.
  • It’s only possible to install, update, and remove plugins in Development. To make those same changes in QA and Production, you’ll use the Deploy Tool. Don’t forget to activate new plugins you’ve deployed to QA and Production on those sites’ dashboards!
  • Web Services must review new plugins before they can be deployed to QA and Production. See the section below on Plugin Review for more info.
  • When you attempt to install, update, or remove a plugin you’ll be prompted for SFTP settings. You’ll find these on the WordPress getting started page.
  • Very large plugins may time-out during installation. You’ll need to install these with an SFTP client instead.
  • Plugins (and themes) that require helper plugins won’t be able to install them automatically. Instead, follow the plugin vendor’s instructions to install each helper plugin you need individually as if it were a regular plugin. If you have questions about how to do this, contact Web Services.
  • Some plugins, particularly WP Super Cache (and other caching plugins, if approved), cannot be (re-)activated from the GUI due to the permissions they require during setup. Contact Web Services for help activating these.
  • Some plugins are globally installed. These are pre-installed on your site and cannot be deleted or manually updated, though they may be deactivated if you must. The one exception is Authorizer, which must remain active in order for you to log into your site.

Tip: When activating a plugin, there may be post-activation steps you need to follow. These will appear immediately, either at the top of the screen or by taking over the screen, after activating a plugin. For example, you might have to provide an API key, walk through a setup wizard, or even just click OK to a message. Keep an eye out!

Plugin Review

Web Services must review all new plugins before site Developers will be able to deploy them to QA and Production. Plugin review is triggered automatically when a new plugin is installed that the system doesn’t recognize, a process that usually takes 24-48 hours. If you are on a tight timetable, you should contact Web Services about reviewing a plugin before it’s installed.

Plugins are assessed to ensure they don’t present a security, stability, performance, or legal concern to the environment. After they are reviewed, they are added to one of the following lists:

  • List of Allowed Plugins (Purdue login and campus IP address or VPN required to view)
    • May be installed and deployed by any site in most circumstances.
    • Some allowed plugins still require a per-site assessment because they potentially present regulatory issues. Web Services will contact you about such plugins when we detect their installation. For example, “storefront” and “learning management system” plugins fall into this category.
  • List of Banned Plugins (Purdue login and campus IP address or VPN required to view)
    • These were assessed to present a security, stability, performance, or legal concern to the environment and cannot be deployed to QA or Production.
    • The site administrative contact will be emailed automatically within 24 hours of a site Administrator installing such a plugin letting them know it’s not allowed.
    • A site owner may request that banned plugins be reviewed again. For example, if the vendor has addressed the security issue, new installations could be allowed.

Here are some tips when choosing a new plugin:

  • For the best possible support lifetime and to benefit from WordPress.org’s own security assessment process, choose plugins from WordPress.org whenever possible.
  • Do not choose a plugin that shows a warning on its WordPress.org page regarding its update frequency, testing frequency, compatibility, or other issues.
  • Avoid plugins that require capabilities beyond what environment security allows, such as the ability to directly edit files, change PHP settings, modify plugin files, or directly edit and run PHP code.
  • Avoid plugins that duplicate functionality provided by Web Services, since the plugin will always be the least efficient way to do that. Web Services already audits site code, protects sites from brute force login attacks, and backs up sites on a daily basis.
  • Avoid plugins that have not been updated for an extended period of time, are not listed as being supported by a recent version of WordPress, or require very old or the absolute newest versions of PHP without contacting Web Services for advice.
  • Contact Web Services before purchasing a commercial plugin. Provide information that we can use to learn about the plugin, its requirements, its functionality, etc. We’ll do our best to assess the likelihood that it will be acceptable in our environment. If a “lite” version exists, consider trying that out first, since that will give both us and you a better idea of how the “pro” version will work.

Installing Plugins

Remember that only Developers may install plugins, plugins may only be installed in Development, plugins must be deployed to QA and Production before they can be used there, and that all never-before-seen plugins are subject to plugin review before they can be deployed to QA and Production.

  1. Make sure you are on a Purdue campus network, which includes a Purdue campus VPN.
  2. Log into your Development site.
  3. Visit the Plugins section of your site’s Dashboard. Remember that for multisite networks, you’ll need to do this from the Plugins section of the Network Dashboard.
  4. Click the Add New button at the top. From here you can either browse the gallery or upload a zip file that contains the plugin you want to install.
  5. When prompted, provide your SFTP credentials.
  6. The plugin will install. You’ll then be able to activate it and verify it works.
  7. If your plugin has not already been approved, either wait for that to happen automatically or contact Web Services to kick off the process early. If or once it has been approved, proceed.
  8. Deploy the plugin to your QA site, then log into your QA site to activate and configure it.
  9. Test that the plugin functions on your QA site. You may need to reverse-deploy your Production content to have a good test. Note that if you reverse-deploy after you’ve activated the plugin, you’ll need to re-activate the plugin.
  10. Deploy the plugin to your Production site, then log into your Production site to activate and configure it.

Manually Updating Plugins

Most plugins will be automatically updated for you every month. There are cases when you’ll need to manually update, though:

  • The plugin is a commercial plugin and you haven’t registered its license on all three tiers of your site.
  • The plugin is a commercial plugin that requires you to download updates directly from the vendor or from within the plugin’s settings page.
  • You wish to update the plugin early.

Try these steps to manually update a plugin:

  1. Make sure you are on a Purdue campus network, which includes a Purdue campus VPN.
  2. Log into your Development site.
  3. Visit the Plugins section of your site’s Dashboard. Remember that for multisite networks, you’ll need to do this from the Plugins section of the Network Dashboard.
  4. Find the plugin you want to update in the list and see if there’s an “Update” link or button.
    • If there is, click it, then proceed!
    • If there isn’t, stop, you can’t follow these instructions. Download the plugin update from your account with the plugin vendor, then follow the above instructions for installing a new plugin again, using the zip file option.
  5. When prompted, provide your SFTP credentials.
  6. The plugin will update. You’ll then be able to verify it works.
  7. Deploy the updated plugin to your QA site, then log into your QA site.
  8. Test that the plugin functions on your QA site. You may need to reverse-deploy your Production content to have a good test.
  9. Deploy the plugin to your Production site, then log into your Production site to verify it works there too.

Uninstalling Plugins

When you no longer need a plugin that you installed (as opposed to a plugin Web Services installed for you, which cannot be uninstalled), it’s best practice to uninstall that plugin.

  1. Make sure you are on a Purdue campus network, which includes a Purdue campus VPN.
  2. Log into your Development site.
  3. Visit the Plugins section of your site’s Dashboard. Remember that for multisite networks, you’ll need to do this from the Plugins section of the Network Dashboard.
  4. Find the plugin you want to uninstall. If it’s active, click Deactivate to deactivate it first. Then click Delete.
  5. When prompted, provide your SFTP credentials.
  6. The plugin will be uninstalled.
  7. Log into your QA site and deactivate the plugin there if you haven’t already (you won’t see a Delete option appear).
  8. Deploy your entire plugins folder (or all WP-FILES) to your QA site, then test that your QA site still works!
  9. Log into your Production site and deactivate the plugin there if you haven’t already. As above, you won’t get the option to Delete.
  10. Deploy your entire plugins folder (or all WP-FILES) to your Production site, then test that your Production site still works!

How to Manage Themes and Child Themes

Themes are what give your site its look and feel causing WordPress to present your content in a specific way that’s unique to each theme. Each site can have a single theme active at a time. Multisite networks can have a different theme per-sub-site, and super-admins set which themes are available to sub-site administrators.

Important Theme Considerations

  • All sites on a purdue.edu domain must adhere to Purdue brand standards. The easiest way to do that is to use the official Purdue Branded Theme, but it’s not the only way. Sites on external domains, like .org and .com sites, do not need to adhere to Purdue brand standards but may choose to do so.
  • All sites hosted by Purdue, regardless of domain, must adhere to accessibility standards. Purdue Marketing and Communication provides the SiteImprove service to help evaluate accessibility standards compliance, and Web Services provides the WP Accessibility plugin to assist in this goal as well.
  • To improve page rank in search engines and also just for a better visitor experience, it’s recommended to choose a theme that works equally well on desktop computers and smartphones otherwise known as a responsive theme. You should also test your site on a variety of devices and screen sizes (and browser window widths) to make sure your site will look great for everyone. Look for a “Responsive Design Mode” in your browser’s Developer menu to help you do this.
  • Themes are tough to change once you’ve launched your site, but it is possible. This warning is doubly true for multisite networks. It is highly recommended to fully evaluate your site and theme in Development and QA before launching your site into Production.

Enabling the Official Purdue Branded Theme

The easiest way to enable the official Purdue Branded Theme is to contact Web Services and request that we enable it for you. It’s a multi-step process and we have a script that will automate this without error. Even better, ask that we enable it when we initially create your site, and it’ll be ready to go for you.

If you want to enable it yourself, follow the instructions below.

  1. If your site is already in Production, you’ll want to follow the advice on changing themes below first.
  2. You will need to use the Gutenberg block editor when using the official Purdue branded theme to get the most out of it. If you’ve created pages using the Classic Editor, you can migrate them on a page-by-page basis by clicking “Switch to block editor” in the right-hand column while editing a page or post, but you only need to do this on pages where you want to take advantage of the Purdue theme’s blocks. Note that the Gutenberg editor requires a VPN connection to be used from off-campus.
  3. Use an SFTP client to make the following changes to your Development site. If you aren’t comfortable editing your site via SFTP, contact Web Services requesting that we make these changes for you instead.
    • Connect to the Development WordPress server using your SFTP client.
    • Copy the contents of /var/www/share/marcom-mu-plugins/ into your site’s mu-plugins folder using your SFTP client. You’ll find your site’s mu-plugins folder at /var/www/html/root/<your Prod site URL>/wp-content/mu-plugins/.
    • Delete the pu-login.php and pu-images symbolic links from your site’s mu-plugins folder using your SFTP client.
  4. Install and activate the free Advanced Custom Fields plugin if it’s not already installed and/or activated. If you have Advanced Custom Fields Pro you can use that instead.
  5. Activate the “Bulma Blocks” and optionally the “Purdue Blocks” plugins that should already be installed.
  6. Activate “Purdue Branded Theme” in Appearance → Themes.
  7. After making the above changes, the Purdue branded theme will be active on your Development site. Once you are ready to carry these changes forward to your QA and Production sites, you can follow the steps for deploying a redesigned site. After you’ve done that, you can resume using your Production site normally.

Like any new theme, if you’ve already developed your site, you will probably need to do a bit of manual work to reconfigure your site content to use the new theme. Questions and issues with the theme can be directed to Purdue Marketing and Communications.

Customizing Themes and Using a Child Theme

All themes have a certain amount of customization that can be done within the WordPress dashboard using the Appearance menu. The amount of customization available here depends on how much the theme developer added. Some site developers may find this too limiting, however, and will want to modify theme files directly. Put simply: do not modify a theme or its templates directly. If you do, the next time that theme updates, all of your changes will be lost. Instead, use a child theme!

Child themes selectively override parent theme styles, functions, and templates. All sites come with a child theme pre-created and available for use, though you’ll probably want to re-parent it if you don’t use the default base theme (see below). You can learn more about child themes in the WordPress Codex.

Re-Parenting a Child Theme

On our shared WordPress environment, all new sites start off with a child theme of the theme your site started out using. You may want a child theme with a different parent, however, if you want to change from your initial theme. The easiest thing to do is re-parent your existing child theme:

  1. If you are currently using your child theme, begin by logging in to your Development WordPress site and activating a different theme. Any theme will do, but the two that make the most sense are the child’s current parent or the new parent to which you want to switch the child.
  2. Connect to the Development WordPress server using an SFTP client (logging in with your Purdue Career Account) and navigate to your site’s themes directory in /var/www/html/root/<Production-site-URL>/wp-content/themes/.
  3. Identify your child theme’s directory. It’s probably named either child_theme or <theme-name>_child, but it could be anything if it wasn’t created by Web Services.
  4. If you’ve not already customized your child theme, skip to step 5. Otherwise, you’ll want to back it up first by copying the child theme’s folder to your home directory. Then, remove everything from inside the child theme’s directory except style.css and functions.php.
  5. Navigate into the child theme’s folder and edit both style.css and functions.php. You’ll want to change all references of your current parent theme’s name to the name of your new selected theme. You may also want to update the theme name and description in style.css to be more informative.
    • The main thing to change in style.css is the Template, but Name and Description should be updated as well to make it easy to find in your site’s Appearance preferences.
    • In the default functions.php you’ll find 4 references to your current parent theme’s name that need changed.
    • If your new parent theme’s name contains one or more dashes, know that PHP function names can’t contain dashes. That means for the add_action(... line and the function...{ line, you’ll need to substitute underscores for dashes. In the other two places where the parent theme’s name must appear, you should spell it exactly as the parent theme does normally.
    • See below for examples.
  6. Save those files and re-upload them to the web server if your SFTP client didn’t do that for you automatically, replacing what’s there.
  7. Log in to your Dev site again and activate your child theme. Note that it should have the new name and description you entered in step 4.
  8. Make any additional customizations you know you want right away to either style.css, functions.php, or by copying over other template files from the parent and modifying them to suit your needs. You’ll see changes immediately in your Development site.
  9. When you’re ready to move these changes to QA and Production, log into your QA and Production sites and see if they are using your child theme. If either are, activate a different theme there. If you change Production’s theme, this will change how your Production site looks briefly, but it is necessary for WordPress to see the changes to the child theme.
  10. Deploy your site’s files to QA and then Production (not the content!).
  11. Back in your QA and/or Production sites, activate your child theme, which should after refreshing the page show the name and description you entered in step 4 just like it did in Development.

Notes:

  • Prior to step 8, if you used any images from your media library while setting up your updated child theme in Development, you’ll need to upload those same images to QA and Production if they aren’t already there.
  • You need to be a Developer to modify child themes.
  • Please review the official WordPress documentation on child themes prior to modifying your child theme.
  • Administrators of multisite networks may find it useful to have multiple child themes, one for each sub-site that’s using a different theme. To create additional child themes, copy one you already have giving each a unique name for the folder and within both its style.css and functions.php. It’s recommended to pick names related to the sub-site using the child theme so it’s easy to tell which is used by which sub-site.

Style.css Example

/*
Theme Name:     Child Theme for <NEW NAME GOES HERE>
Theme URI:
Description:    <NEW DESCRIPTION GOES HERE>
Author:         <YOUR NAME GOES HERE>
Author URI: 
Template:       <NEW-PARENT-THEME-NAME> 
Version:        0.1.0
*/

Replace everything in <ALL CAPS AND ANGLE BRACKETS>.

Functions.php Example

<?php

add_action( 'wp_enqueue_scripts', '<NEW_PARENT_THEME_NAME>_parent_theme_enqueue_styles' );

function <NEW_PARENT_THEME_NAME>_parent_theme_enqueue_styles() {
    wp_enqueue_style( '<NEW-PARENT-THEME-NAME>-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child_theme-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( '<NEW-PARENT-THEME-NAME>-style' )
    );

}

Replace everything in <ALL CAPS AND ANGLE BRACKETS>. Note underscores vs. dashes.

Changing Themes

Before you deploy your site to QA and Production, it’s easy to change themes. Just change the active theme (you can sometimes even do a live preview!) in your Appearance dashboard. Once you’ve launched your site, however, there is a recommended procedure to follow:

  1. If there is content in your Production site that isn’t in your Development site that you want preserved, reverse-deploy your Production site’s content to QA then reverse-deploy your QA site’s content to Development.
  2. Make sure all users with edit access to your Production site know not to make changes while you change themes. Any changes made will be lost.
  3. Change themes on your Development site
  4. Make any adjustments and customizations needed. It is very unlikely that a new theme will work perfectly without at least some tweaking. Each theme has settings that are incompatible with other themes, and these won’t be preserved. For example, you’ll very frequently have to redesign your site navigation from scratch.
  5. Deploy your Development site to QA and Production as a redesigned site.

A Note on Multisite Networks: You may notice that this is very complex to do in a multisite network. It is! You may be better off creating a new sub-site with the theme you want, migrating content from the old site, deleting or archiving the old site, then renaming the new site to take its place.

How to Deploy WordPress

WordPress doesn’t store your site in PHP, HTML, CSS, etc. files. Instead, the bulk of your site content is stored in a database. This is then run through your theme to produce the pages you see when you visit your site. Because of the database, using the Deploy Tool with WordPress works differently than with most other hosting services provided by Web Services.

This section is a supplement to the full Deploy Manual regarding the particulars of using Deploy with WordPress. You may want to review the Deploy Manual first so you’re familiar with the normal operation of the tool.

Deploying a New or Redesigned Site

Let’s say you’ve recently finished developing (or re-developing) your site in Development. You’re ready to test that site out in QA and then make it live in Production. Here’s how to do that:

Warning: This will completely overwrite your QA and Production sites with what is in Development. If your QA and/or Production sites aren’t empty, take a moment to consider what is going to be replaced and make sure you have everything important in Development. If you have a multisite network, all sub-sites are deployed at once! There is no way to selectively deploy individual sub-sites.

  1. Visit the Deploy Tool home page, click Get Started, and log in.
  2. Select the “WP-FILES” option for your site’s QA URL, click Deploy, and click Confirm. This deploys WordPress itself and all your plugins and themes to QA, so it will show quite a few files to deploy. Be sure to select “Entire Site” if you’re using Advanced mode in Deploy.
  3. Select the “WP-DB” option for your site’s QA URL in the Deploy Tool, click Deploy, and click Confirm. This gets all of your posts, pages, settings, media, etc. deployed to QA and can take several minutes, so please be patient.
  4. Visit your QA site, browse around, and log in to make sure it’s working properly.
    • If you’re building the site for someone who needs to review it, the QA site is a good one to show off for final approval. Contact Web Services if you need your QA site temporarily accessible from off-campus.
    • If changes are needed, make them in Development and then deploy either content, files, or both again depending on what you’ve changed.
    • Only continue once you’re happy with the way your QA site looks and works.
  5. Repeat step 2, but this time select the “WP-FILES” option for your site’s Production URL instead.
  6. Repeat step 3, but this time select the “WP-DB” option for your site’s Production URL instead.
  7. Visit your Production site, browse around, and log in to make sure it’s working properly. It should look and work just like QA, so if it doesn’t, you may need to contact Web Services for help in determining why.

Important: Once your site is live in Production, day-to-day changes, posts, page updates, etc. should all happen directly in Production when possible, using the Draft functionality in the page editor if you don’t want the world to see the changes before you’re ready. See the main WordPress service page for more information about how Web Services suggests using each tier.

How and When to Deploy WordPress Files

Sometimes only WordPress files need to be deployed. This type of deployment excludes the site’s media library and content database and is useful in situations such as:

  • After installing a new plugin, making it available in QA for testing and then in Production.
  • After installing a manual update (to a plugin or theme) in Development, applying that same update to QA for testing and then to Production.
  • After making changes to your child theme, testing those changes in QA and then taking them live in Production.
  • As the first step in a full site (re-)deployment.

To deploy just files:

  1. Visit the Deploy Tool home page, click Get Started, and log in.
  2. Select the “WP-FILES” option for your site’s QA URL.
    • Using Advanced mode is useful here. Click the Advanced Options button in the upper-left of Deploy to switch to Advanced mode giving you a file browser. In this way, you can deploy just the new/updated plugin instead of all outstanding updates to your site.
    • That said, since you’ll be testing what you deploy and are only deploying code, not content, it’s generally safe to just deploy your entire site.
  3. Log in to your QA site to activate, if needed, and test what you just deployed.
    • If you deployed a new plugin, you’ll need to activate it in QA. Similarly, if you had deactivated a faulty plugin and have patched it back to working, you will likely need to re-activate it in QA.
    • Some changes, especially child theme changes, won’t get noticed by WP Super Cache, so you’ll need to log into QA and click the “Delete Cache” button at the top to see your changes.
    • Only continue once you’re happy with how your QA site is working.
  4. Repeat step 2, but this time select the “WP-FILES” option for your site’s Production URL instead.
    • If you used Advanced mode in step 2, use it again here in the exact same way.
    • Alternatively, if you deployed all site files in step 2, do that again here.
  5. Log in to your Production site to finish up.
    • As above, new and fixed plugins will need to be (re-)activated after deployment.
    • Many changes deployed this way require you to log in and click “Delete Cache” to make the changes visible to anonymous visitors.

Important: If you perform a WP-FILES deployment in Standard mode or with “Entire Site” selected in Advanced mode, you will see that a VERY large number of files will be deployed. Most of these are just to synchronize file modification times, which get out of sync due to how WordPress is updated and are not harmful if updated or left alone. However, if you do this in the two weeks after Development and QA updates have been installed, but before Production updates have been installed, you will in effect be installing all those updates in Production early. This is fine, but only if you’ve tested your site and are ready for those updates to be applied!

How and When to Deploy WordPress Content

There are only two times that site content should be deployed forward to QA and Production:

  • As part of a full site (re-)deployment. In this case, see above for those instructions.
  • When instructed to do so by Web Services. In this case, Web Services will provide instructions.

How and When to Reverse-Deploy WordPress Content

Reverse-deploying content is something a lead site developer should be doing regularly:

  • Every month after you’re notified that QA updates have been installed, reverse-deploy Production to QA so you can accurately test updates there before they hit Production.
  • Any time you want to install a new plugin or test a new theme, you’ll want to reverse-deploy Production to QA, then QA to Development.
  • Roughly annually it’s best practice to perform a full reverse-deployment from Production to QA and then from QA to Development to refresh those tiers if you haven’t otherwise had an occasion to do that.

Reverse-deploying content from Production all the way back to Development is also an important part of changing themes or redesigning your site in general.

To reverse-deploy content:

  1. Visit the Deploy Tool home page, click Get Started, and log in.
  2. Select the “R-WP-DB” option for your site’s QA URL in the Deploy Tool, click Deploy, and click Confirm. This can take several minutes, so please be patient.
  3. Visit your QA site and log in. You can now test any updates made in or deployed to QA. If you’re not performing a full reverse-deployment because you’re just here to test updates, you’re done and can stop here.
  4. Repeat step 2, but this time select the “R-WP-DB” option for your site’s Development URL instead.
  5. Visit your Development site and log in. You can now install new plugins or do anything else you need to do in Development knowing you’ll be seeing the results with a copy of your Production content.

How to Test Monthly Updates

Updates to WordPress core and all plugins and themes that can be patched automatically are installed on a monthly basis. Each site’s administrative contact address is then contacted with a summary along with a reminder to update anything that can’t be automatically updated and to then test the site. But how do you test your site? And how do you report issues that you can’t fix in time so they don’t make their way to Production?

Important: If you are not receiving update notices, double-check that your administrative contact address is correct on all three tiers.

Testing Development Sites

  1. Visit your Development site after you receive notice that it’s been updated. Check for errors, broken pages, or other issues. If you haven’t refreshed in in a while, your Development site may look significantly different from your Production site but should have the same theme and plugins active, so you’re mostly looking for errors.
  2. Log in to WordPress in Development. See if there are any error or warning messages in the Dashboard. They should appear right at the top above all the Dashboard widgets.
  3. 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 this has fixed them.
  4. 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.
  5. Report any issues found to 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. After you receive notice that QA sites have been updated, 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. Check for errors, broken pages, or other issues. This is exactly how your Production site will look if it were upgraded today.
  4. Log in to WordPress in QA. 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 QA 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 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. Check for errors, broken pages, or other issues.
  3. Log in to WordPress in Production. 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. 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.
  5. Report any issues found to Web Services ASAP. If your Production site is down or otherwise unusable, please also report the outage.

How to Use 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 contact Web Services.

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 serving those pre-rendered copies whenever possible.

Manually Clearing the Cache

WP Super Cache is (usually) smart enough to re-cache pages that have changed and by default won’t serve cached content to logged in users. It will also periodically re-cache pages that have been in the cache for too long making sure your site is always displaying up-to-date versions of your pages.

Sometimes 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 WP Super Cache and won’t trigger the cached page(s) to be flushed and rebuilt. In such situations, your best bet is to clear your site’s cache. Doing this is super easy:

  1. Log in to your site. Specifically, log into the tier that’s not showing up-to-date information.
  2. Notice the “Delete Cache” button in the top bar that appears above your site when you’re logged in. Click that, and your cache will be cleared and automatically rebuilt.

Note: If clearing your cache takes a long time or gives you an error message, your cache may be too large for WordPress to clear by itself. Contact Web Services for help.

Tuning Your Caching Plugin

By default, WP Super Cache comes configured with common, safe defaults. To further improve your site performance, you’ll need to tune these 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 3600 seconds with the timer set to 600 seconds. This is a safe default but may not be right for your site.
  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.

Note: If you use a different approved caching plugin these settings will be different, but you can use the above as a guide. Regardless of what caching plugin you use, if you would like consultation from Web Services on any of these settings, please ask.

Cache Pre-Loading

Sometimes you know when your site is about 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 (Preload mode and Preload tags…) and click Save Settings again. Your site is now back to normal.

Note: If you use a different approved caching plugin that also has a pre-cache feature, these settings will be different, but you can use the above as a guide. Regardless of what caching plugin you use, if you would like consultation from Web Services on any of these settings, please ask.

Content Delivery Networks

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. With CDN support enabled in WP Super Cache, it will automatically rewrite requests for static files to your configured CDN.

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 any Purdue campus. In fact, it may reduce performance. If most of your visitors are accessing your site from a Purdue campus network, do not use a CDN.

For WP Super Cache, setting up a CDN is done on the CDN tab under Settings → WP Super Cache. Exactly what to use for each setting depends on your CDN, so follow the instructions for the service you’re using. Once you’re done, click the “Enable CDN Support” check box, test some static file URLs as suggested, then click Save Changes to turn on your CDN.

How to Embed Video

One type of media to avoid uploading to your WordPress site is video. WordPress does not natively support video streaming, so serving video files directly out of your media library will be slow and potentially exclude visitors with slower connections or older browsers. It’s much better to embed videos hosted by a streaming service, and fortunately WordPress supports this natively.

Videos in YouTube, Vimeo, and Other Popular Services

WordPress supports popular video streaming services out of the box. Simply paste the URL to a video into your page, and WordPress will turn that into a video player. Depending on the streaming service, you may be able to control various embedded player settings by adding query parameters to the URL you paste. In fact, most streaming services have an “embedded player wizard” that will let you set up the player and then copy a customized URL that you can paste into WordPress.

If you want even more control over the video player, you may find installing a service-specific plugin useful.

Videos in Kaltura

Unlike YouTube, Vimeo, and other popular online video services, Kaltura does not have native embedding support within WordPress. Instead, you’ll need to add a little code to your theme.

Important: This requires your site to be using a child theme. If you’re not, switching to a child theme is (usually) easy. If the example child theme for your site isn’t used, you can re-parent it to your site’s current theme then activate the child theme. If your site is a multisite and there are no “spare” child themes, you can create a new one based on your current theme.

To embed Kaltura videos, edit the “functions.php” file in your child theme and add the following lines at the end.

/*
 * Add oembed for Kaltura
 */
function custom_oembed_provider() {
    wp_oembed_add_provider('https://mediaspace.itap.purdue.edu/id/*', 
                           'https://mediaspace.itap.purdue.edu/oembed', 
                           false);
}

add_action( 'init', 'custom_oembed_provider' );

This enables WordPress to recognize the standard “oEmbed” links that Kaltura provides.

Then simply paste the oEmbed link provided by Kaltura into a page:

https://mediaspace/itap.purdue.edu/id/<video-id>

WordPress will recognize this and embed a player. You may optionally append some parameters to specify the width and height of your video player:

https://mediaspace/itap.purdue.edu/id/<video-id>?width=400&height=200