Cookies and PHP Sessions

We will be going over how Cookies and PHP Sessions are handled on Flywheel. It is important to understand this especially if you’re migrating a site over to Flywheel. We will explain what cookies and PHP Sessions are and how they interact with FlyCache along with the performance implications of using them.

Cookies

A “cookie” stores certain bits of data to your web browser. A cookie can be used to display different information on a website for different users, such as a popup. It can also be used to gather data about their browser activity.

Cookies are assigned to individual users. They aren’t intended to span out across multiple user sessions. The data stored in the cookie should have the ability to return a unique value and apply a unique set of rules. For example, you could set the popup to show for users who aren’t subscribers to your newsletter and not for subscribers that are. A cookie can help with this.

Issues with Cookies

When a cookie is present, they work with PHP (as the page is loaded) in order to perform a certain action. If a page is served from the server cache, the cookie has already been generated previously by the server. If the page is cached, the cookie cannot be generated and perform it’s certain action when the page is loaded as expected.

A cookie may work as expected when you’re logged into the WordPress Admin Dashboard. This is because logged-in user sessions bypass the page cache layer an will be processed by PHP every time.

This is why we recommend populating all the options available for the action you would like to take with HTML or PHP. You can then use JavaScript to select which option to load (based on the presence of the cookie). This way, the page can be served by cache and will still fit all scenarios, since browser-side JavaScript will determine which options to show to the user.

Below is an example of some very simple conditional HTML. This code says to show one sidebar image when a preferred user visits, and another for those who need to sign up. Then, JavaScript reads the $_COOKIE header to determine which sidebar image to show.

Cookie Alternatives

If you try to use PHP to read cookies, it will likely only display an empty cookie array. And while it’s not ideal, we understand that sometimes this might be a necessity for sites. Page caching does not automatically mean that you can’t use PHP to read cookies. There are two alternatives:

Issues with Sessions

The biggest problem this presents is due to the unique session IDs. Unique IDs effectively bust cache and causes every session to become uncached. This will cause serious performance issues for your site. With that in mind, our system specifically ignores headers that define a PHPSESSID cookie.

PHP Sessions also store data to the filesystem as their own unique file. Writing data to a file is an I/O process which are known to back up and cause high server load. This kind of session storage also simply doesn’t work if your site is on an AWS clustered solution spanning multiple web servers.

Finally, there are multiple security vulnerabilities centering around PHP Sessions. Vulnerabilities include Session data being exposed, Session fixation, and Session hijacking.

Session Alternative

WordPress itself specifically doesn’t use PHP sessions. The correct method to store session data is to use the database. WooCommerce and many other eCommerce solutions have previously converted to using this method.

If checking through your site’s code you find a plugin or theme file that uses session_start, check if there’s an update available. After updating, check the code again to verify it’s been corrected. If your plugin or theme doesn’t have an update or it continues using sessions after the update, we highly recommend reaching out to the developer or finding a more secure alternative.

Need help?

If you have any questions our Happiness Engineers are here to help!