When it comes to programming, the idea of temporary values or temporary variables or any way of storing data temporarily in memory isn’t anything new.

But when working with WordPress – which is stateless – we don’t always have that luxury. That is, it’s not simply a matter of, say, throwing something into the current session, reading it, and then removing it when we’re done with it.

And that’s when I’ve been giving more and more thought to the idea of temporary options, for lack of a better term of course. That is, whenever I need to store a value from a single page load, or request, to read in another page load, or another request, I’ll temporarily throw the value into the options table.

Temporary Options: An Exercise and Representation via Rudimentary Sketching

Temporary Options: An Exercise and Representation via Rudimentary Sketching

Is that sloppy? Maybe. Do we have a lot of other choices? It depends on how much of modern browser technology we want to use. That’s not the point of this post, though.

The point is that because of the way WordPress works, I wonder if our current, best strategy for maintaining temporary values that is most widely supported across installations is to temporarily add a value into the options table, read it, and then delete it once it’s been retrieved?

Our Options for Temporary Options

Personally, I don’t have a strong opinion on if this is a bad thing or not. If it’s the nature of how the foundation on which I’m working on a solution works, then I’ll go with it.

So, first, this is how I’ve typically done this within WordPress:

1. Creating a Temporary Option

First, I set up a function that’s hooked to update_option. This allows for looking at the option that’s being updated, its old value, and its new value.

In the function, I can look and see if a specific option is being saved. If not, then I can just ignore it; otherwise, I can take a look at it and begin working with a temporary option.

But what would the temporary option hold?

2. An Option For Temporary Options

Say you have an option in a plugin that is toggled. Perhaps it requires the user to input some information before moving throughout the rest of a process.

Case in point: Say you’re working on a checkout experience and you want to force users to create an account, but there’s an option that allows for customers to checkout without a creating an account.

One implementation we could use is this:

  1. Before the checkout page is loaded, look to see if the user can checkout as a guest.
  2. If so, store the original value of the option in a temporary option.
  3. Change the original value so that it requires they create an account.
  4. Once the checkout process is done, then copy the value fro the temporary option to the original option.
  5. Delete the temporary option.

It’s similar to the whole exercise in C when you need a pointer to swap two numbers (for whoever remembers or whoever has done that).

Our Best Option?

The process outlined above is but an example and isn’t meant to be the definitive way to maintain temporary values. Secondly, the checkout example isn’t meant to associate this post with eCommerce.

Instead, it’s meant to provide a concrete use case for when storing temporary options is useful and how we may want to do it.

So the original question remains: Given the way WordPress works, the lack of sessions, and without being guaranteed certain browser features like localStorage, are temporary options in the options table our best way to go?

Share:

Leave a Reply