Autoloaders and Backwards Compatibility

The Power of Autoloaders

Rubix Cube with WordPress LogoAs you may be aware, WordPress does not have a class autoloader. Class autoloaders are very useful, and backwards compatibility is one example of why.

Sometimes, the PHP developers decide to deprecate a function. What if a plugin you use uses one of those functions but the developer does not update it?

Well, autoloaders make things easier.

The class files I am maintaining for use in WordPress contains a class of static methods called \AWonderPHP\Compat that exists to provide compatible functions to functions that PHP has deprecated.

I will not provide compatible functions to everything PHP (or WordPress) deprecates, but I will provide compatible methods to some.

For example, the PHP functions png2wbmp and jpeg2wbmp have been deprecated. In PHP 8 they will be gone. So what do you do if a plugin calls them? You could port the plugin to do the conversion a different way, or…

if (! function_exists('png2wbmp')) :
  function png2wbmp(string $source, string $dest, int $height, int $width, int $threshhold)
    return \AWonderPHP\Compat::bitmap2wbmp($source, $dest, $height, $width, $threshold);
  function jpeg2wbmp(string $source, string $dest, int $height, int $width, int $threshhold)
    return \AWonderPHP\Compat::bitmap2wbmp($source, $dest, $height, $width, $threshold);

Put that in a plugin file your mu-plugins directory, and plugins that need those two functions will continue to work.

If you look at the source to my Compat.php class, you can see using the functions PHP recommends to replace those two functions isn’t just a simple swap. Hopefully a plugin developer that uses those functions will update their so they only use supported functions, but remember, most people do not donate to plugin developers. As a result, when they update a plugin, they are giving away free time and often to businesses profiting from their code that do not give back. As a result, a lot of plugins end up abandoned.

When you need a plugin that is abandoned, you either have to pay the original maintainer to maintain it if you can find them, update the code yourself or pay someone else to update the code, switch to a different plugin that does a similar thing and hope it doesn’t break old pages, or provide a compatibility layer.

Autoloaders make the compatibility layer option a lot easier.

Most people deploying WordPress do not have the skill to update a plugin themselves or create compatibility functions, but with an autoloader, classes that provide backwards compatibility to make it a lot easier can easily be installed where the autoloader can find them. Then providing backwards compatibility is as simple as defining the deprecated function as a wrapper to the class if the function does not exist.

A compatibility class also allows giving options that do not exist. With the above example, the same compatibility function that supports png2wbmp and jpeg2wbmp can also convert WebP to wbmp and can easily be adapted for other bitmap image types if needed. It also is not as rigid as the functions it provides compatibility for, you do not have to specify width and height if you want the dimensions to be the same and if you want it scaled, you only have to define the new width or the new height and it will proportionally scale it automatically. That is not very useful if you are creating a compatibility layer, but it is potentially extremely useful to plugin developers updating their plugins who just want to call my class.

Compatibility functions do not only need to exist for deprecated functions. The PHP function uniqid for ecample, even though it is not deprecated I suspect it soon will be because it does things horribly wrong. The concept of what it is suppose to do is actually really nice though. It is suppose to create a unique string that contains a machine parseable timestamp in it. Unfortunately the strings it produces are not very unique and collision rates are high and will become higher as processors continue to gain speed.

For that function, I actually provided two different compatibility functions. The first, the parameters have the exact same meaning as the PHP function and the output has the exact same format. It is still vulnerable to collisions, but I suspect the odds of collisions (when the second argument is set to true) are greatly reduced. Providing a compatible function with identical output is important for cases where the length of the output is expected to be a precise character length.

However the second function I provided does things the right way. The odds of a collision happening are extremely remote.

If you need to generate a unique id that includes the timestamp without the possibility of collision, use the second function if you can. In most cases, it can be used as a drop in replacement for the standard PHP function it is meant to be a replacement for.

Anyway, the point of all this is, autoloaders make it easy for classes that are generic in nature and not tied to a specific plugin or theme to be usable by any plugin or theme, or to be used to provide a compatibility later for plugins and themes that use deprecated functions.

This is part of why I am such a huge fan of namespaced classes and autoloaders.

Leave a Reply

Your email address will not be published. Required fields are marked *

Anonymity protected with AWM Pluggable Unplugged