Software, Development, and WordPress

On Immutable Values in WordPress Plugins

If you’ve done any work – or even any reading – on object-oriented programming, then you’ve likely come across the idea of immutability. That is the idea of something being unchanging.

Sometimes you can have immutable values, and sometimes you can have immutable objects (at least after they are instantiated).

Immutable Values in WordPress Plugins

The opposite of immutable (but he was my favorite ninja turtle, anyway).

The thing is, the more I work with object-oriented code, the less I tend to work with immutable variables. Sure, I’ll use constants as defined in a configuration file, but you’re not likely to find me storing values within a class as a const.

That probably implies something about me and my abilities, but it’s true. Thankfully, code reviews are great at helping you see opportunities on where to leverage strategies you normally wouldn’t. And such is the case with immutable values in WordPress plugins.

Of course, this is one of those things that was brought to my attention by a friend when reviewing my code.

Immutable Values in WordPress Plugins

When working with WordPress, many of us are likely familiar with functions.php and wp-config.php and the role they play in the core WordPress application.

Yes, there are times in which things belong in wp-config.php, and yes, there are times where things belong in functions.php, but sometimes I think that particular file is abused with far too many functions, values, and so on.

But what about plugins? Specifically, what about object-oriented plugins? Case in point, say you’re working with an API that requires an API key, so you don’t hit up against a particular rate limit with a free version of the application.

Usually, you might find me storing the value in the main plugin class as an instance variable that can be passed around, or maybe it’s in a container class to which I can refer and use its get method.

But what about using a const property in a class and then passing it around via setter injection?

For example, let’s say there is a plugin class that relies on a helper class to render something on the screen. The API key can be defined in this class and then passed into the helper when needed:

Next, the helper class can make a call to the arbitrary API (I’m calling it Canvas since we’ll be hypothetically something) using its URL and passes the API key as part of the query string.

This way:

  • there’s a single place in which the value is kept,
  • there’s a descriptive name indicating what it stores,
  • it can be passed to other classes with minimal dependency,
  • the other classes can refer to them as local variables or as instance variables (depending on how they are passed around).

Sure, there are other ways in which these values can be kept (again with using functions.php or something similar).

But if you’re working with object-oriented programming and you want to work with immutable values in a WordPress plugin, wouldn’t make sense to keep it in the context of the classes that make up the plugin?


  1. aveeshkumar

    Hello Tom,

    I have a lot of respect for you – not just as a developer but as someone who cares enough to be open to constructive criticisms…

    On the specific issue of an API key required by a helper class – and if the main plugin has a config app class – by all means – what you say should be done..

    But in my 20 years of programming, I have held off applying object oriented approach to design blindly – right from using arrays in VB/VBA or acting on an entire range of excel cells via a function Vs using a class and looping thru cells…

    Perhaps it was becoz that I was always either the sole or lead developer with a small team…

    Even today, wordpress and PHP programming, I find enough good reasons not to use classes / objects but functions n libraries of functions…

    Just thought I will chime in for a few others who always get verbally chided for not adopting an object’s style approach first…

    What you do and espouse is right for right now…just wanted to say that non object style programming if done well/clearly/documented has some benefits too…sometimes at least


    • Tom

      Thanks for sharing your take on OOP and procedural code :).

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑