Many WordPress sites use a cache to improve the loading speed of their website as well as to save bandwidth and server resources. Caching is a powerful tool when used correctly.

However, caching can also cause some very strange issues when used incorrectly. You might have a caching issue if:

  • Your website is showing the wrong information after you saved an update.
  • Your website won’t save changes.
  • You see different content when viewing your website from another computer.
  • The site is showing old information.

This article describes the various types of caching and explains how to resolve problems that sometimes crop up with your donations when caching is involved. Perhaps your donors are seeing a donation receipt that has someone else’s name on it. Maybe your forms are not showing new information you edited on them. Each of these can be related to caching, so this article is designed to help you understand why that is and what to do about it.

What is a Cache?

In short, the word “cache” essentially means “store” or “save.” Cached assets are assets saved, or stored, for later use.

Web browsers render websites using HTML, CSS, and JavaScript. The files that contain this code are stored separately and the browser needs to generate the code from each one individually. However, the fastest way to deliver those files so that the browser can display the output is to pre-assemble them, otherwise known as creating a “static” site.

WordPress is a content management system (CMS) built in (primarily) PHP. The PHP does the “heavy lifting” of generating the HTML/CSS/JavaScript and delivering it to the browser. It does that by communicating with your database (in MySQL or similar database language). Depending on the complexity of the site, there can be dozens or more calls to the database for each page that loads on the site.

Caching limits those calls to the database by saving a static version of the site from a single visit and delivering that to the browser of subsequent visitors. This can dramatically increase the speed of the site as well as the site’s ability to handle multiple users at once without a noticeable dip in performance.

Many hosts and plugins in the WordPress ecosystem use caching to save server resources and speed up sites at minimal cost to the user.

Types of Caching

Browser Caching

Browser caching saves things like HTML, JavaScript, and images in a cache directly in the visitor’s browser. This allows the browser to skip downloading those assets again the next time a visitor is on the site.

A good analogy for the browser cache is when you take a screenshot of your airline ticket on your phone. You don’t want to have to open your email and search for the ticket. Instead, you take a static image that you can have ready and quickly available.

Most browsers support clearing this cache within their browser settings, but it depends on each individual browser. There are also ways the server can force the browser to grab updated assets, bypassing the local browser cache.

Page Caching

Page Caching is most often handled inside your WordPress installation by plugins like WP Rocket and others. It stores (caches) the individual pages on your site as static files that are delivered to the next users to visit the site. The cache is stored to a specific spot in the memory on your server and delivered from there.

Object Caching

Object caching is different from page caching. Instead of saving a snapshot of the whole page, object caching saves the way the page was requested from the server. This allows the cache to skip creating the query-building and instead serves the query results directly on subsequent page loads.

An example of a GiveWP-specific WordPress query in plain language is “show me all the donations from Ben Meredith in the month of June.” If the value for that query is stored the first time your server has to go look it up, then the next time that query comes up, you don’t need to access the database again to see the results.

Troubleshooting Common Caching Issues

In order to resolve caching-related issues with your website, first isolate caching as the cause of the problem. To do that, temporarily disable caching on the site and see if the problem is resolved.

If you have a caching plugin installed, go to the Plugins page and disable it. If your server is controlling caching, ask your host to temporarily disable it for you.

Within GiveWP, the most common place caching causes issues is on the “Donation Confirmation” page. After successfully submitting a donation, the confirmation page shows “Please enter the email address you used for your donation” instead of the donation receipt.” This is almost always related to page caching. Other places you’ll see similar problems are the “Donation History” page as well as the Subscriptions page if you are using Recurring Donations.

Once you’ve isolated that caching is the problem, you’ll want to stop caching the important donation pages on your site. These are the pages that should be excluded:

  • (only relevant if using the Recurring Donations add-on)

The exact URLs might be different for your site—they can be changed in your GiveWP settings at Donations > Settings > General—but these are the defaults that GiveWP creates.

Where is my Cache Stored and How Can I Clear It?

Caches are stored in different places depending on the type of cache you’re dealing with. Page caching and object caching are both stored on the server. Server caches can be further optimized by using things like a Content Delivery Network (or CDN).

A CDN stores the assets on multiple servers, and then delivers them based on geography. Using this tool, a visitor from Japan gets the resources from a different server than a visitor in Portugal. The goal is to give the information the shortest route to travel from server to visitor, making the site load faster.

How Caching Can Create Trouble for Your Donations

On a site with GiveWP powering donations, you need to exclude certain pages from caching. This prevents donor-specific data from being cached and then served to the wrong visitor. An example is any page that displays Donation History or Donation Receipts.

In addition to caching serving the wrong data to donors, it can also disrupt the PHP session of them. PHP disruptions result in confusing messages to the donor or in missed donations.

Visit our documentation on PHP sessions to learn more about them and why they affect your donor experience.

Is There Caching in the Admin Dashboard?

In WordPress, generally caching plugins only save things for visitors (and in some cases, only logged-out visitors). But the back end administration screens can have caching as well. It’s usually applied at the server level by the web hosting company.

Some WordPress plugins utilize caching to store commonly-queried information, saving server resources. For example, GiveWP uses caching to store donation counts and income amounts. That way, each time the Donations page in the Dashboard is loaded, GiveWP doesn’t have to search the database for those amounts.

Another example of caching that WordPress employs on the admin side is something called “transients.” Transients are a method of storing data on your server (limited to admin/dashboard use only). They limit calls to the server in order to improve both internal WordPress functionality and external sources that your site might interact with, like social media sites or payment gateways.

While not technically caching, issues related to transients can often show the same symptoms as a caching problem. To help troubleshoot, use a plugin like Transients Manager to see all transients on the site and optionally delete transients that might be problematic.

In addition to caching, WordPress (and GiveWP) use a concept called a “Number used ONCE” to access sensitive data. (Usually “Number used ONCE” is abbreviated and in all capital letters, but due to cultural differences, the abbreviated term is derogatory in some regions.) This “number” (a string of letters and numbers) is added to requests to tell the server that the person requesting the data is allowed to see it.

This also goes hand in hand with the concept of PHP sessions.

Use the Cache Correctly for a Better Donor Experience

When used correctly, caching greatly increases the amount of traffic your site can handle. It also helps you save on unnecessary expenses maintaining your website. Understanding more deeply how caching changes things on the site brings you more visitors and more conversions.

What are Cookies

Similar to caching, cookies are a method of storing data for reuse. As opposed to storing session data, cookies are used to store user data in the user’s browser. Cookies are often employed to store information related to the user, so the website can track different characteristics related to it.

As an example, cookies can store information like the logged-in state so the user doesn’t need to log in every time they navigate to a different page on the website. On an ecommerce site, cookies save the items in a shopping cart, so the user can add multiple items to the cart, leave the site, and when the user is back, the items are still there.

Types of Cookies

There are two types of cookies available: persistent cookies and session cookies.

Session cookies are temporary cookies stored on the user machine that is erased when the browser is closed. It means that the next time the user visits the website, it will not recognize the visitor and it will be treated as a completely new user, because there is nothing on the browser that indicates that this user has been there before.

Persistent cookies, on the other hand, are stored on the user’s machine for a specific or unlimited time, depending on how the developers implemented them.

Excluding GiveWP Cookies from the Cache

It’s important that, when whitelisting GiveWP from caching systems, the cookies used by it are also whitelisted. The cookie used by GiveWP is a mix of a hard-coded string plus a hash, which is a sequence of characters to differentiate between one cookie and another.

When whitelisting GiveWP’s cookie name, you need to make sure that you whitelist it for any hash generated. It usually means that you need to add an asterisk instead of the hash. See the example below:

Cookie name: wp-give_session_*

Adding an asterisk in the end tells the caching system to ignore anything that comes after the wp-give_session_.