Not that long ago, I made an attempt to fix what I saw as one of the biggest issues facing session management in WordPress. Many larger sites use multiple servers for presenting content, but the lack of sticky sessions on the load balancer[ref]This one change, making sessions sticky, can often correct the issue on its own. That said, some hosting environments don’t allow enough control over the stack to make such a change in the first place.[/ref] means that standard PHP sessions, which live in the filesystem, tend to fail quite quickly.
My first attempt, WP_Session, was a great prototype and helped prove the need for a solid solution. Unfortunately, it was prone to many issues on its own.
The Issues
As I was trying to prove a WordPress solution, I used WordPress as a platform itself. This isn’t an issue, per se, but it meant my experiment was limited to only WordPress sites and feedback. The limited scope of the project was an issue.
I also used the WordPress database for session storage. Again, not an issue on its own, but my aim at not changing the database schema did become an issue. WP Session Manager stores data in the options table by default – for smaller sites, this is OK. For larger sites, this can slow the server to a crawl as that table isn’t indexed for the kind of data we were throwing at it.
Finally, the system I had built was a reinvention of a wheel that already worked quite well. Instead of using PHP’s native sessions, I built an entirely new system from scratch that required developers to learn a new interface and made their code completely reliable on my very specific implementation. Understanding how cookies were created and curated alone was problematic, and that was the smallest component of the system.
The New Player
Over the past year, I’ve been able to step away from WordPress a bit and have learned how other platforms (and languages) are choosing to solve similar problems. I’ve been blown away by how fluent and efficient systems for request middleware have become, and I started to think about how that might affect session management as well.
Enter my new experiment: Sessionz.
Sessionz is a middleware-inspired session management stack that works for any PHP application running on PHP 5.6 or better.[ref]Yes, I could run this on older PHP, too … but older PHP is no longer supported. If you’re running anything less than PHP 5.6 in production, you’re just asking for someone to hack your site. Quit it.[/ref] Like a request middleware stack, you can add in additional handlers to take care of different abstractions for your session.
Right now, Sessionz has implementations for:
- The default PHP session store
- Storing session data in-memory for persistent PHP applications
- Encrypting data before it’s written out (and decryption before it’s loaded back in)
The project itself uses PHP’s native session implementation, so there’s no additional library to learn. Just add the project with Composer, initialize and set up your stack, then use $_SESSION everywhere else like you normally would. Sessionz works transparently in the background to make your life easier.
What’s Next
I’m working on a new version of WP Session Manager that will leverage Sessionz under the hood. The old interfaces will still work, but will trigger a deprecation warning. Like the older implementation, I’ll still use the WordPress database for persistence, but will set up a hidden post type so we don’t fill up the options table.[ref]Using a CPT will also allow us to query for and purge expired sessions using an actual date field in the database. There is no understating how much this will improve the plugin’s performance.[/ref]
I’m always open to feedback and suggestions! Take a look and let me know what you think.
