One of the features people tend to love or hate (or simply accept) about writing PHP scripts is how you can mix general constructs of the language – such as conditions – with functions outside of any type of class, namespace, or container.
That is, you can write conditional logic that exists within the global namespace right alongside functions that aren’t part of anything other than the global namespace, as well. This can make for difficult code to maintain.
But the point of this post isn’t to complain – for what it’s worth, I see it as the nature of the language, accept it for what it is, try to avoid it, and work with it whenever something comes across my desk. I’m far less dogmatic about that kind of stuff than I used to be when I first started working as a developer, but I digress.
Anyway, this post is tagged as “WordPress” which doesn’t make a lot of sense, however the purpose of doing so is because I was recently working on an older WordPress-based site that was using Ajax, it wasn’t doing so using the built-in API, and it was basically using Ajax to call a vanilla PHP script.
As such, I thought I’d write a bit about as how it’s still possible to refactor code like this so it’s a little more maintainable even if it’s using a style of coding with which we don’t necessarily like to use.
WordPress, Ajax, and PHP Scripts
I wrote about Ajax in WordPress a few posts ago (and I’ve some other articles about it scheduled for the future) so this seemed like a good time to talk about the nature of working with Ajax in the context of a legacy application.
For the purposes of this example (and the examples in the rest of the post), I’m going to leave out some of the details of the script itself because it doesn’t add anything of value to what I’m trying to show in this post.
Instead, take a look at the constructs that are provided and read the comments and you’ll have all you need to know in order to see how the script was initially structured.
The point of the script was as follows:
- Take input from a form from the user
- Send it to the server-side script
- Have the server-side send the information (serialized as JSON) to another API
- Grab the response
- Send the response back to the browser
It’s a pretty common setup for an Ajax request and a third-party service, right? Remember, though, this wasn’t setup using WordPress’ Ajax API. This means the script looked something like this:
This should be easy enough to follow given the comments, but the main takeaway from this particular script is there’s no real use of hooks, functions, or other code like you may be use to seeing in the work you do or have done over the past few years.
Instead, you see a basic PHP script that runs from begin to end and the calls
die; at the end after sending a statement back to the caller.
It works, but it can also be refactored for a bit of readability.
Refactoring The Code
I’ll talk a little bit more about the nature of why I only go so far when refactoring this kind of code later in the post, but in handling the code above, I took some of the conditional logic, wrapped it in a few functions, and then updated the conditional so it was a little easier to read:
Is this the type of code I’m the most proud of writing? Not really, but the next time I revisit it, it will be easier to read and to manage and it will begin to get in better shape over time as small things like this begin to add up.
There’s Always More To Do
Like I said, the refactoring you see above isn’t great, but when you’re working on a legacy application and you have a deadline you’re working against, you have to be pragmatic about the decisions you make.
Sure, it’s completely possible to re-write the entire Ajax process so it properly uses the WordPress API, but if there’s not time to do it, then you have to do the next best thing: Make whatever improvements you can given the time you have, and move on to the next task.
For some, this is really easy to do; for others, it’s tough, but it is the nature of the business. Years ago, I read a quote by Martin Fowler I really liked:
You want to leave the code better than you found it, but it can also wait for another visit to make it the way you’d really like to see it.
And it’s served as my rule of thumb when dealing with situations exactly like this.