WordPress – Frequently Asked Questions

This page contains frequently asked questions about the Web Services WordPress environment. If you can think of a common question and answer that isn’t on this list or would like to suggest any changes, please let us know.

Why Can’t I Log in From Off-Campus?

By default, new WordPress sites and those migrated to the newest WordPress environment do not allow users to log in unless they are connected to a Purdue network or VPN, which provides a huge improvement in site security. Purdue networks include all regional campuses, public Wi-Fi in Lafayette and West Lafayette, and all general-purpose campus VPNs, so should cover all Purdue users, and Production sites are of course still viewable from everywhere on the Internet.

However, we acknowledge that this login requirement won’t work for every site. If your site requires non-Purdue users to be able to log in, or your site needs to allow logins from locations where a VPN won’t work, you can request that this restriction be disabled for your site by contacting Web Services. We highly recommend that any site allowing off-campus access to its login page also switch to using multi-factor logins for its Purdue users to further safeguard their accounts.

Is there an official Purdue theme?

Yes! Purdue Marketing and Communications has developed an official WordPress theme that will enable sites to present the correct Purdue branding without requiring custom theme development. Purdue sites aren’t required to use this theme, but using this theme is one of the easiest ways to comply with the Purdue brand policies that all purdue.edu sites must follow.

See our how-to on switching your site to the official Purdue Branded Theme. If your site hasn’t been created by Web Services yet, let us know that you want to use the Purdue Branded Theme when requesting your site and we’ll set it up for you.

Why doesn’t my home page show its title in its browser tab?

If your site uses the official Purdue Branded Theme, you may notice that the title of the page set as your homepage doesn’t show up in its browser tab. Instead, you’ll just see your site’s URL instead. Here’s an example showing a URL instead of the page title:

Fixing this is easy:

1. Log into the site to get to your WordPress Dashboard.
2. Visit Settings > Reading and note what your homepage is set as.
3. Visit Appearance > Customize > Site Identity > Site Title and set your desired site title, which should match the title of the page you’ve set as your homepage. If that’s not the title you want, you can edit that page to change its title to match.
4. Visit Appearance > Customize > Homepage Settings and duplicate the settings you found under Settings > Reading.
5. At the top of the screen, click Publish. Now, when you visit your site, it should have the correct title on the homepage.

Note that you may be able to skip some of these steps if you’ve already done them. Just verify that each of those settings pages looks correct, then publishing your appearance customizations should set the title.

Why does my site show just a white screen?

When a WordPress site loads to a plain white screen (also known as the “White Screen of Death”), numerous things could be wrong and it can be difficult to pin down (and fix) the issue. Typically, however, the last change you (or another admin) made is the culprit, so if you know what that is, undoing that change (or asking Web Services to if you can no longer log in) should be the first thing you try. Here are some common causes:

• Out of memory: If you just activated a new plugin, enabled a new feature, or updated something, this is highly likely. Check your site’s error log for a PHP error like PHP Fatal error: Allowed memory size of 134217728 bytes exhausted.... The error line will indicate what component tried to allocate too much memory, which may also tell you what to try turning off if you aren’t sure what was activated last.
  • To Fix: Deactivate the plugin that’s wanting more memory than is available or change its options to use less memory. If you can’t log in, you’ll want to ask Web Services to deactivate the plugin or restore a backed up copy of your site from when it was working.
• PHP parse error: Look in your site’s error log for an error message similar to PHP Parse error:. This either indicates a coding error or that the faulting plugin or theme is wanting a newer version of PHP than is available and is crashing instead of displaying a helpful error. Seeing that PHP is confused about an array notation character like [ typically indicates that the component is wanting a newer version of PHP.
  • To Fix: Fix the coding error if possible. If not possible, disable the faulting plugin and contact the developer asking that they fix the error (or support the version of PHP installed on the server). If the fault is with your theme, contact Web Services for help.
• No Theme Selected: This one is very hard to troubleshoot but is likely if you’ve just deployed your site content and only the destination isn’t working or if the site stopped working when you modified your child theme. There usually aren’t any errors in the error logs. About the only tried-and-true way to tell is to use a command line tool via SSH. If you aren’t comfortable with the Linux command line, it’s best to ask Web Services to check this out if you suspect a theme issue.
  • To Verify and Fix:
    1. Log in to the Development web server via SSH.
    2. Change to your site directory under /var/www/html/root/. For example, this is usually /var/www/html/root/<Production-site-URL>/. If you aren’t sure, please ask.
    3. Determine the tier that is failing: Development (dev), QA (qa), or Production (prod), and set the variable TIER to the corresponding value in parentheses. For example, if your Production site is faulting, run TIER=prod.
    4. Run the following command: wp theme list.
    5. Note which theme is listed as “active”. If your theme is a child theme, it must also have a theme listed as “parent”. If there is no active theme or you have a child theme without a theme listed as parent, continue to step 6. If you have an active theme (and a parent if using a child theme) then this is not your issue.
    6. Activate a theme that’s known to work: wp theme activate purdue2014.
    7. Correct the underlying issue. If your child is missing its parent, make sure your child references the parent theme correctly and that the parent theme is installed. If the theme you need isn’t installed, install and deploy it (or ask Web Services to do so if you’re unable).
• Broken After Update: It’s possible, though unlikely, that something will break after being updated yet not show any error messages or other indicators of a problem. If you’ve gotten this far in these troubleshooting steps, though, it’s a possibility. However, it’s also unlikely you can get into your Dashboard to troubleshoot, so if you’re not comfortable with SSH and WP-CLI commands like those used above, please engage Web Services for help.
  1. You’ll need a copy of the email the WordPress server sent you about what was updated. If you don’t have a copy, Web Services can look up what was updated in their logs.
  2. If your theme was updated, try toggling to a different theme as shown above.
  3. If that doesn’t work, change back to your original theme and then try disabling each plugin that was updated, one at a time, testing your site each time. Use something like wp plugin deactivate <plugin-slug>.
  4. Once you find the culprit, re-enable everything else and test one more time. If your site still works, you definitely found the culprit. You can re-activate plugins with something like wp plugin activate <plugin-slug>.
  5. Check the release notes with the update and discussion threads for the plugin to see if it mentions a reason it may no longer be working such as requiring a newer PHP version than is available on the WordPress servers. You may need to contact the plugin or theme developers for a fix.
  6. Contact Web Services and let them know about the issue. They’ll need to prevent this plugin update from applying to Production (assuming this was caught in Dev or QA), and potentially may need to contact other affected site owners that haven’t noticed the issue.
  7. If possible, roll back the plugin or theme to the previous version. You can get the version history from the plugin or theme’s information page. You’ll need to roll the plugin or theme back manually via SFTP or SSH.

How do I troubleshoot issues with updates?

If, after automatic updates have run against your site, you notice something isn’t working that was a day or so ago (or your site is completely broken) then you may have just discovered a problem with an update that needs to be corrected. Hopefully you’ve discovered this on your Development or QA site so we have time to find and fix the issue! If not and this has only come to light after the updates were installed in Production, make sure the problem also exists in Development and/or QA then continue troubleshooting there.

If this issue has rendered your Production site unusable, please open a ticket with Web Services requesting a restore from backup! This will get you back up and running as quickly as possible. Don’t forget to call the Purdue IT Service Desk to have the Web Admin on-call paged if this occurs outside of business hours! If your Production site still works well enough, it may be faster to find a fix and then apply it, only rolling back as a last resort, but this is a judgement call you need to make as the site owner or developer.

Once you’re sure your Production site is working well enough and you can replicate the issue in either Development or QA, it’s time to troubleshoot. The most likely cause of any issue like this is an incompatibility between WordPress itself and one or more plugins, or an incompatibility between active plugins. It’s usually easy to determine what’s causing it.

Important: Do not deactivate the Authorizer plugin while troubleshooting! If you do, you will lock yourself out of your site. Web Services tests Authorizer when it updates.

• Start by logging into a site exhibiting the problem and looking at the Plugins dashboard. Do you see any plugins that still need updates? Try deactivating them, one by one, checking each time to see if the problem is gone. If it is, try updating the plugin manually, re-activating it, and checking if the issue is still fixed. If it is, you’ve fixed the issue! If not, you may need to contact the plugin vendor for a fix. Note that some plugins require a paid subscription for updates and/or support that is the responsibility of the site owner or developers to procure.
• If that doesn’t work, it may be that you’ve got an old plugin that’s no longer compatible with WordPress. Try deactivating each plugin you have active, one-by-one, checking each time to see if the problem goes away. Once you’ve identified the faulting plugin, it’s time to visit that plugin’s support page for help. If that plugin is no longer being maintained or was removed from WordPress.org, you’ll need to find a replacement plugin.
• If that fails, it may be a combination of plugins that’s causing the problem. Try disabling all plugins (except Authorizer and any that are required by your theme) then see if the problem goes away. If it does, try re-activating them one-by-one until the problem returns. You’ve now got one of the faulting plugins and can try different combinations as above until you find what it’s interacting with. Note that the Recently Active tab on the plugins dashboard is helpful for this type of testing.
• Finally, you may have a theme issue that isn’t resulting in a completely inaccessible site. This is especially possible if your theme requires plugins. Try changing themes altogether (in Development or QA of course!), deactivating any related plugins at the same time, then test for the issue. If that fixes the issue, you may need to contact your theme vendor for support.

If all else fails or you get stuck, don’t hesitate to contact Web Services for help. We can help you through each possible avenue of troubleshooting to find the culprit and hopefully fix it. If an issue is found during Development and QA testing and yet a fix can’t be found in time for Production updates, we can also pause your site’s updates so your Production site won’t be affected.

Can I install plugins and themes?

• If you are a site Developer (with SFTP access and administrative access within WordPress), yes! See this how-to for more information.
• If you just don’t have SFTP access and need it, request it.
• Otherwise, ask someone who is a Developer for your site.

How do I install large plugins? WordPress keeps timing out when I try.

The built-in WordPress SFTP support can be very slow or even fail when dealing with large plugins, especially those with lots of files. There are two known workarounds for this problem:

• Install a small plugin called “ssh-sftp-updater-support” and activate it. This will replace the built-in SFTP support with its own, which seems to be much more reliable. With that in place, try installing the large plugin again and it should work fine. If not, the second workaround will always work.
• Install the plugin manually using an SFTP client. Most plugins will include manual installation instructions on their “Installation” tab on wordpress.org. You’ll find SFTP settings for WordPress here.

Can I increase the maximum file upload size limit?

PHP’s maximum file upload size limit is set server-wide, and cannot be increased for individual sites. Fortunately, it’s set high enough (32 MB per file) to allow for the upload of most media files useful on a WordPress site. If you do happen to bump into that limit, there are a number of solutions depending on what you’re trying to do:

• Videos, which are typically too large for this limit, should not be hosted on your website anyway. Web servers cannot stream video, and hosting video on web servers will result in an objectively worse experience for your visitors. Host your videos on a streaming service instead, then embed the resulting players on your pages. Note that very small videos and animations, as well as animated GIFs should easily fit within the limit and will work fine hosted directly from your site.
• Large presentations and other types of office documents are typically better hosted in OneDrive or SharePoint so collaborators can make comments and edits while visitors have access to the online version of PowerPoint. Some WordPress plugins even let you embed these in a viewer on your pages.
• Other large files that have no better home than your site will likely benefit from the installation of a media management plugin. Such plugins work around the PHP upload limit by uploading the file in pieces, then reconstructing it on the server. This is also more reliable, since it prevents your browser from timing out during the upload.

How do I fix an “HTTP 503” or other timeout error when installing or updating plugins or themes?

If one of the processes involved in downloading, unpacking, installing, or configuring your add-on update takes too long to complete, either the web server or PHP will stop the process and issue a timeout error. This typically only happens for very large (greater than 20 MB) plugins or themes and is the result of instability in the version of libssh2 included with newer versions of PHP. Here are a few workarounds while we await a fix from the package maintainers:

• The easiest workaround is to install and activate a plugin called SSH SFTP Updater Support. This plugin can be installed normally through the dashboard and will enable all future SFTP transfers to happen via that plugin instead of the built-in SFTP support. The plugin is slightly slower but always works. You’ll know the plugin is working because the screen that prompts for your SFTP credentials will look slightly different.
• A relatively easy workaround that always works (and may be needed regardless depending on the plugin or theme you’re installing) is to follow the manual (S)FTP install instructions that come with your plugin or theme. You’ll find SFTP settings for the Shared WordPress environment here.

Why do I get a JSON error when I try to publish posts or pages while off-campus?

You should no longer get this error from on or off campus after May 14, 2024. If you still get this error after May 14, 2024, please contact us with details so we can correct the issue.

Prior to May 14, 2024, you may see the following error when attempting to publish changes while off-campus and not using the Purdue VPN:

Updating failed. The response is not a valid JSON response.

There are two available workarounds that won’t be needed after May 14, 2024:

• (Recommended) Connect to a campus VPN prior to editing posts or pages. The VPN will put you on campus virtually allowing you access to the REST API. It’s also needed while off-campus for SFTP access to Development and access to the Deploy Tool, so you’ll likely need to be on the VPN anyway most of the time when working on your site. This workaround comes with no functionality trade-off.
• Install and activate the Classic Editor plugin. This will switch you back to the older WordPress page and post editor which doesn’t use the API and so will work normally while off-campus. This workaround comes with some loss in functionality since the older editor doesn’t have as many features, but many prefer the older editor. Note that this option isn’t available for the official Purdue Theme.

Why are some of my edits not appearing on my site?

Sometimes, when you make a change to your site, you may not immediately (or ever) see the results of that change. There are several things to check:

• The most common issue that causes changes to not appear is the WordPress cache not detecting the changes you’ve made. Clear your cache to force WordPress to show the latest changes right away.
• If you are editing pages while off-campus, be sure that you’re connected to the Purdue VPN or using the Classic Editor. Otherwise, your updates are not being saved.
• Be sure you are making content changes (updates to pages or posts) directly in Production whenever possible. If you edit the contents of your Development or QA sites, those changes only appear on those sites and will need to be made again to your Production site. Deployment of content changes is possible in certain situations but is usually not the best choice.
• If you’ve made changes via SFTP in Development (which includes modifying plugins and themes within WordPress), don’t forget that you need to test and deploy those changes to QA and Production before those files will be available there. You may also likely need to clear your cache after doing so.

What do I do if I can’t log in to my site?

There are several reasons you may not be able to log into your site. The fix depends on the reason.

• No Log In Link: Sometimes a theme settings change will make the Log In link or whole “Meta” area disappear from your home page or menu. Not to worry! You can always get to the login page by visiting one of the following URLs (substitute your site URL for <SiteURL>):
  • https://<SiteURL>/wp-login.php
  • https://<SiteURL>/wp-admin/
• Your Account is Locked Out of WordPress: If you see a warning message on the login screen that your account is locked out, it means that you (or an attacker) has tried logging in too many times with an incorrect username or password and you need to wait the specified amount of time before trying again. Contact Web Services if you need to get in before the timeout expires.
• Login Prompt Shakes/Bad Username or Password Error: The username you’re trying may not be authorized to log in.
  • It’s possible another admin removed your access (possibly by mistake) or, with a multisite network, that you haven’t been granted access to this sub-site. You’ll need to ask a site admin or super-admin to grant you access.
  • If you just changed your Purdue password, your account may have originally been set up incorrectly and isn’t synchronized with your Purdue account. Try your old password and contact Web Services to fix your account.
  • It’s possible your Purdue account is locked out in general to prevent a brute force password attack (see next bullet point).
• Your Purdue Account is Locked Out: If you (or an attacker) has attempted (and failed) to log into your Purdue account on any campus system too many times, your account could lock to prevent a brute force attack against your password. You’ll know if this is the case if you also can’t log in to other Purdue services. Typically you’ll need to wait 15-30 minutes before your account will unlock and you can try again. If you still can’t get in after 30 minutes, please contact the Purdue IT Service Desk.
• Login Page Doesn’t Work At All: If your login page doesn’t work at all (won’t load, shows errors that aren’t mentioned here, etc.), you may have a broken or incorrectly configured authentication plugin. If you recently changed any settings related to Authorizer, wpDirAuth, or CAS Authentication, you may have inadvertently locked all users out of your site. Please contact Web Services for help in this case.
• Login Page Just Reloads: If your site is using a plugin called “Theme My Login”, you might see the login page reload after supplying your username and password. No error message is given, you just get a blank login form again. This will only happen if you’re visiting the 2^nd login link above or click on the Log In button for your site (if present). To fix this, an administrator for your site needs to log in using https://<SiteURL>/wp-login.php. After they do that, the login system will fix itself and everyone else will be able to log in normally. You should consider uninstalling Theme My Login once you are able to log in again, however, since login screen branding is better handled by either the Purdue Login Theme Must-Use plugin or the Purdue Branded Theme, whichever is active for your site.

Why can’t a user with a short username log into a multisite network?

A very old “feature” in WordPress multisite requires that new users have usernames of 4 characters or more. Purdue allows usernames as short as 2 or 3 characters, however, so such users will have issues trying to register on multisite networks.

As a workaround, a super-admin can pre-authorize the user via Authorizer. Then, when the user with a short username next logs in, Authorizer will force WordPress to accept the short username.

Why can’t I get to my Development or QA site from off campus?

As per our three tier environment standard, non-Production sites are not accessible from off campus. This protects in-development code from the wider world and also prevents non-Production sites from being indexed by search engines. Some older sites are still exempt from this standard but will be brought into compliance as quickly as possible.

If you need to access a Development or QA site from off campus, please connect to the campus VPN service. This will virtually put your computer on the Purdue network and grant you access to campus-only resources. You can connect to and disconnect from the VPN as needed.

If you are in a situation where a QA site needs to be temporarily viewable from off-campus so it can be reviewed by a party without VPN access, contact Web Services to request a temporary exception.

How do I use my Development, QA, and Production sites?

Follow these links to learn more about the WordPress service’s tiers or about how Web Services uses service tiers in general.

How do I fix PHP “memory exhausted” errors?

Web Services has set PHP’s memory limit to 128 MB per PHP process on the WordPress servers as that is the largest size that has been shown to maintain system stability under load for the system configurations we have available. Based on WordPress’ own recommendations, 128 MB should be sufficient for up to and including complex multisite networks with large images. You can check how much memory WordPress is using at any given moment (while logged in) by using a plugin like “Server IP & Memory Usage Display“.

There are still some reasons your site may be running into the memory limit, however:

• Very Large Images: If you are using very large images (especially if they were transferred directly from the camera without post-processing), you will quickly use all available memory as WordPress loads and automatically scales them for display.
  • To avoid this, be sure to scale down your images to normal web resolutions. An easy way to do this is to use a plugin like Imsanity, which is pre-installed on all sites.
  • Don’t take pictures at a lower resolution to work around this! You’ll get poor results. Instead, take the image at the camera’s full resolution and scale it down later using either image editing software or a WordPress plugin.
• Too Many Plugins: Each and every plugin you activate uses a bit of memory to run (when they do run). Some of them individually will use quite a bit of memory, while others will use hardly any at all. The base configuration installed by Web Services uses less than 30 MB to render most pages.
  • If your errors started shortly after activating a plugin, try deactivating it.
  • If you can’t get into your Dashboard to deactivate the plugin, contact Web Services for help.
• Complex Theme: Extremely complex themes, when coupled with some of the other issues mentioned here, can push your site over the memory limit. This is especially true if you use a page builder theme/plugin combo as they tend to be very heavyweight.
  • Try a different theme to see if your problem goes away. If you can’t get into your Dashboard to activate a different theme, please contact Web Services for help.
  • If you use a page builder, be sure to turn off unneeded features prior to deploying your site to production. If you find that you need to use a page builder to get the features you want, it’s possible that Cascade would better suit your more advanced needs.
• Very Large Datasets: If your site uses a plugin to load large amounts of data from a database or external source, you could hit the memory limit.
  • If you can, process large external datasets in chunks of 30 MB or less. Plugins can always cache data in PHP’s temporary folder or even more permanently in the site’s uploads directory.
  • Fixing this usually means going back to the plugin developer for help.

Do I need to install updates?

Web Services automatically installs updates for all WordPress sites we host on a monthly basis, starting with non-Production and finishing with Production later in the month so site owners have time to test.

That means that you don’t usually need to install updates manually, but if you have any purchased plugins or themes that don’t properly hook in to the WordPress update mechanism (or that you’ve requested we don’t automatically update for you), you will need to install and deploy those updates manually.

Why are some theme customization options unavailable?

Some theme editor options are disabled due to security settings on the WordPress servers. Any feature that would let you do one of the following activities won’t work, so is automatically disabled:

• Editing theme files via the Dashboard code editor.
  • Edit these directly via SFTP, but be sure you’re editing your child theme, not the theme itself!
• Editing site-wide CSS via the theme customization options editor.
  • Edit your child theme’s style.css file using SFTP instead to make site-wide CSS changes. This is both safer and easier to deploy to Production.

Why can’t I see all installed themes in my sub-site?

Most likely the installed themes haven’t been network enabled in the parent multisite network. Make sure you (or network super-admins) have network enabled all themes you want to use on the network.

Why am I not getting administrative notifications from WordPress?

WordPress (and all of Web Services’ automated utilities) will email the administrative contact address set on the General Settings page of your site’s Dashboard, so make sure this is correct on all three tiers. It does not pay attention to the owners and developers set in Deploy’s Service Reports. If you’d like more than one person notified of administrative WordPress issues, use a mailing list address that all required administrators are part of.

How do I request a WordPress site?

You can learn more about requesting WordPress sites here.

What are the system specifications for the WordPress servers?

You will find the system specs of Web Services’ WordPress servers here.

Why am I automatically redirected to a similar looking page when I mistype a URL?

WordPress has a built-in custom 404 (page not found) handler that will look at the URL you entered, see if a page title looks right, and automatically redirect you there. This doesn’t always work how you’d expect, so you might want to disable it. You’ll need a custom theme or child theme to do this. Once you have that, add the following line to your (child) theme’s functions.php file:

remove_filter('template_redirect', 'redirect_canonical');

You can also install plugins that affect how WordPress handles 404 errors, so check your plugins and their settings as well if you’re seeing unexpected behavior.

Why is my site not showing up in some or all search engines?

If you’re not finding your site when searching for it with your favorite search engine or your visitors are reporting issues finding your site with their favorite, several things could be happening:

• If you have a very new site, you may just need to wait. Indexing happens slowly and one or all search engines may not have noticed that your site exists.
  • You may need to give it several weeks.
  • Some search engines allow you to request that your site be indexed when you have a special account with that company. For example, Google Analytics customers can request that Google index their sites.
• Most search engines will behave according to your site’s robots.txt file (if it exists) taking those preferences into account when indexing (or passing over) your site. WordPress doesn’t use a physical robots.txt file. Instead, it’s just a checkbox in the Dashboard under Settings → Reading called “Search Engine Visibility”. Check the box to discourage search engines from indexing your site (they don’t have to listen). Un-check the box (the default setting) to allow search engines to index your site.
  • All non-Production sites are rendered invisible to search engines since they are inaccessible from off-campus. This setting doesn’t matter there and can be left un-checked.
  • If you don’t want your Production site to be indexed, consider actually making your site private or by asking Web Services to prevent off-campus access to your Production site.
  • Remember that the Search Engine Visibility setting will follow your content when you deploy, so double-check that this setting is still correct for the destination tier after a deploy or you may miss getting indexed (or get indexed when you didn’t intend to).
• You may simply not be the top hit for that search query and may need to scroll through the list to find your site. Search engine rank depends heavily on search engine optimization (SEO), which is more of an art than a science. Several WordPress plugins claim to help with this and can be used if you need help. Some other suggestions:
  • Contact Purdue Marketing and Communications who can often advise on SEO.
  • Make sure your site theme is accessible (works for people with varying abilities) and responsive (works for devices with varying screen sizes). Many search engines base ranking on this.
  • Search engine ranking depends heavily on what other sites link to you and how those sites are ranked and categorized. Make sure your department site updates to include your new site in its structure and ask owners of other relates sites to link to yours where appropriate.
  • Make sure your site layout makes sense with related pages categorized and linked appropriately. If you draw your site as a flowchart, you should be able to find what you’re looking for without searching much like navigating a menu. In fact, some plugins let you create and publish sitemaps, which can help search engines navigate your site and improve SEO.