Working with WordPress Transients and Authentication

In continuing with the content of the previous post, it’s important also to consider the use of transients and authentication.

Because there are scenarios where users are authenticated on a site (think of a members-only area of a site) and or aren’t authenticated on the site (such as site visitors).

These types of situations are present both on blogs and other sites and web applications across the board.

WordPress Transients and Authentication

How might we store user information for those users? Luckily, PHP provides us with some functionality that gives us the ability to do so without needing WordPress APIs.

Ultimately, the goal that we’re aiming to achieve is serializing transient data using a key that uses the ID of an authenticated user or a non-authenticated user.

And here’s how to do each of those.

The WordPress API

Assuming that a user is authenticated with WordPress, then we can use the get_current_user_id function.  It’s simple, too.

From the Code Reference:

Get the current user’s ID

We can then use that function in the constructor to set a property that stores the user’s ID. And I’ll show the code for that momentarily, but what about the situation when a user is not logged into?

The PHP API

When it comes to storing information for users who aren’t authenticated, we still need a way to identify them. This can be done in a variety of ways using various values maintained by PHP to append to the transient key.

Remember, the key has to be unique, and as long as it’s unique to the user on the site then it should be good.

Two functions that PHP offers are:

As far as the second one is concerned, it won’t work using IIS or any Windows-based servers. But I’m mentioning it here as another alternative for hosts that are *nix-based (since so many are, especially with regard to WordPress).

The get_current_user function is clear enough:

Gets the name of the owner of the current PHP script

There’s something else to notice in the manual, too. It explicitly states this “ the name of the owner of the current PHP script.” And I’ll address this before the end of the post.

Furthermore, get_current_user may also not be what you’re looking for depending on how the server is configured and which user is the ‘owner’ of the PHP script that’s running on the server.

But suffice it to say for this example it works. And here’s why: The point I’m trying to demonstrate is how to use values that are unique to a visitor who is not authenticated on a site to generate a key from which we can pull information.

How the key is generated is secondary to the actual code.

Combining It All Together

So what does the code look like if we’re to leverage the above functions? That is if we maintain a property that holds the user’s ID and then does so for both authenticated and non-authenticated users?

Perhaps this:

And that will give you the functionality necessary for creating a unique user ID for both authenticated users and non-authenticated users.

What About Transient Keys?

Yes – part of the point of what we’re discussing is creating unique transient keys, as well.

To do this, I’ve found it easy enough to concatenate the user’s ID that we’ve generated above and append it to the key that’s used when serializing a transient.

For example:

Then, with the value this function returns, we can use it to save the data as a transient using unique keys.

Still Other Options

As mentioned, simply using features built-in to PHP  may not be the proper route to go. But that doesn’t mean there aren’t other values that provide a unique value to what you need.

In cases like that, it’s important to identify how you want to identify your user, what operating system their using, and what user account owns the application.

If that doesn’t provide a unique enough setting (and it’s very likely that won’t under certain conditions), then the principle still applies – you’ll just need to swap out the get_current_user() functional call into something that works best for you.