[WPMU DEV Dashboard] WPMUDEV Updates Breaking Cache With session_start() at Page.ly hosting

Page.ly hosting has notified us that WPMUDEV is contributing to excessive resource use because it employs session_start() which break their cache and causes all pages to be rebuilt rather than served from cache.

Can this be addressed?

plugins/wpmudev-updates/lib/PHPSecLib/Crypt/Random.php: session_start();
plugins/wpmudev-updates/lib/PHPSecLib/Crypt/Random.php: session_start();

The article below by WPEngine suggests that there may be alternate ways to accomplish what session_start() does but without breaking cache by writing values to the database. ????


The biggest conflict when using PHP Sessions has to do with the unique session identifiers. Because every user’s identification string is unique, this “busts cache” with every new user to visit your site. This kind of a system will not scale with many concurrent site users! With that in mind, our system specifically ignores headers defining a PHPSESSID cookie.

Beyond the performance and scaling implications, PHP Sessions present other problems. By default, PHP Sessions store data to the filesystem as their own unique file. Writing data to a file is an I/O process, and these kinds of processes are known to back up and cause high server load if your site gets too many concurrent users. Not to mention, this kind of session storage simply doesn’t work if your site is on a clustered solution spanning multiple web servers.

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

Before you panic, don’t worry just yet. Firstly, WordPress itself specifically does not use PHP Sessions, and instead relies heavily on other cookies. These days, most plugin and theme authors have opened their eyes to the problematic nature and insecurity of using PHP Sessions. The reality is, there’s a better way to store user session data! The correct method is to use the database to store session data. WooCommerce and other eCommerce solutions have already converted to using this method over traditional PHP Sessions, and also use their own cookie naming conventions.

If you look through your site’s code and see a plugin or theme file that uses session_start, your first step should be to check if an update is available. Be sure to update to the latest version and check again. If your plugin or theme does not have an update available, we recommend reaching out to the developer to ask why, and inquire about a more secure method.