There are a lot of opinions on how return statements should work.
Some say that there should be a single point of return in a function,
Some day we should return as early as possible,
Some day multiple return statements are fine,
And some say that, when applicable, return as early as possible.
I’m sure I’m missing some, but all of these are ones I’m sure the majority of you have seen. And though I don’t hold either of these to be law, I think there’s a time and a place for each.
I’m a fan of the early return statement. In my mind, the sooner we can determine we don’t need to do the work of a function, the better we just leave.
For example, say we know if we’re not on a certain page, we can go ahead and leave the function:
In this case, it makes sense because:
You only want to perform work on the plugins.php page,
The amount of work to be done in the function is larger than what should ever fit within a conditional.
But there’s an alternative when the amount of work is less than what’s above.
Over the last year or so, the term “WordPress adjacent” has become more popular to use. And I get it. There are a lot of us who are still heavily involved with WordPress but who are building tools and/or solutions that may not only interact with WordPress or that start with WordPress and fan out from there.
So that phrase, as they say, has entered the chat. And it’s not a bad phrase, per se. But I think it’s imprecise and I think we can do better. This is important for those of us who write, podcast, speak, and any or all of the above.
First because I believe it’s important for us to be able to clearly define about what we’re talking and how it relates to WordPress. And secondly, so that our audience can follow it.
Imagine thinking you’re going to hear someone talk about building headless applications in WordPress and all that comes with that only to hear that a backend engineer is going to be talking about building a utility that incorporates Google Cloud Functions and custom endpoints to send data to a cloud-based database and to a WordPress database, too.
All of that falls under the umbrella of WordPress Adjacent. And that’s why it’s not good enough. It’s why we need to more more precise.
What Does It Mean to Be WordPress Adjacent?
Starting a more broadly, I would say, at it’s core, being WordPress adjacent refers to individuals or projects closely associated with WordPress, either through direct use or integration with technologies related to the core application.
It’s straightforward enough, but it’s a mouthful, isn’t it? Trying to throw this into a presentation or a podcast and you’re going to lose half your audience.
This person just checked out of your talk. Photo Credit.
Here’s why I say that: In their mind, people already have what it means to be WordPress adjacent. So when what you describe doesn’t map to what they think, it feels like someone is wrong or perhaps being misunderstood.
There’s no reason to feel that way but this is why I think we need a level of precision. Ultimately, there’s a myriad of ways one can be WordPress adjacent.
Lack of Precision is Frustrating (Why Wouldn’t It Be?)
The imprecision of the term WordPress adjacent is both a blessing and a curse. On one hand, it allows for flexibility, acknowledging the diverse roles and projects within the WordPress ecosystem.
On the other, this vagueness can lead to confusion. Imagine trying to explain your job to someone using this term – chances are, you’d end up providing a convoluted explanation that leaves the them more confused than not.
Okay, so How Do We Address It?
In my experience backend engineer, I’ve found myself involved in projects that are WordPress adjacent. And there’s certainly been an uptick in that in the last few years. Further, I’m grateful for it because it allows me to continue to grow as an engineer with learning other technologies, integrating them, and then having them still communicate with WordPress.
Case in point. Imagine, databases with a master and development branches all accessible via PHP or cloud functions.
From developing custom APIs that communicate seamlessly with WordPress installations to creating data systems all of which ultimately increase the functionality of WordPress websites.
Stuff like this orbits WordPress without directly living only within it.
And so that’s how what I do is WordPress adjacent. It may be how the work you do is too. But it’s not the same for all of us.
Clarifying Our Roles
So, how do we address this ambiguity? When we use the term “WordPress adjacent,” we provide a brief explanation of how exactly we are adjacent. Whether it’s through
developing plugins,
creating bespoke themes,
enhancing user experience,
building headless front-ends,
communicating with third-party APIs and integrating them back into the WordPress application (or vice versa),
and so on.
Specifying our roles helps in demystifying the term for others.
Ultimately, it fosters a deeper understanding of the diverse economy that revolves around WordPress.
Clearing Things Up
In technology, clarity is key. And given WordPress is technology, it isn’t exempt from that.
For those of us who work in this space, we have a responsibility to those who read our articles, listen to our podcasts, or attend our talks to clarify our roles. Don’t leave it to them to figure out in the moment.
If you’re going to be using the term in the future – which I personally hope to see more of – let’s at least explain how we’re adjacent.
But if you’re in a situation in which you’re working on code that’s, say, WordPress-adjacent where it both talks to third-party APIs and services but also sends data to WordPress (or reads data from WordPress), it may be helpful to have another way to determine if your code is running on a local machine.
Use Custom Functions
Case in Point
Perhaps you’re going to be registering a JavaScript file that requires a dependencies that is not available on your local machine. If this is the case, you have a few options:
Find all of the dependencies from the production application and add them to your local machine ignoring whatever side effects may happen,
Remove a call to the dependencies in your code and try to remember to add it back before committing to source code,
Or use a a drop-in function for checking if you’re running the code locally.
Though I know each option has its own tradeoffs, I find myself doing the third option more often than not. All it requires is evaluating the loopback interface and seeing where the script is running.
In the context of PHP, a loopback interface refers to the ability of a script or a server to send requests to itself. So if you check to see if it’s running on 127.0.0.1, which is an IPv4 variation of localhost or ::1 which is the IPv6 variation of localhost then you can determine how to move foward.
A Simple Example
Here’s my example function:
public function isLocalDevelopmentEnvironment()
{
return (
0 === strcasecmp('::1', $_SERVER['REMOTE_ADDR']) ||
0 === strcasecmp('127.0.0.1', $_SERVER['REMOTE_ADDR'])
);
}
Then if you want to use this when, say, enqueuing JavaScript sources in WordPress, you can set up a conditional for dependencies like this:
Sure, it’s a simple example but there’s much more that can be done with that single helper function regardless of if you’re working with WordPress, Google Cloud Functions, cloud databases, or more.
There are, of course, much more complicated ways in which custom functions can be written and used. The point isn’t about complexity, though. It’s about thinking through when utility functions like this are helpful and when they should be used.
A few days ago, Carl and I were talking about the impact that ChatGPT and related technologies have had on those of who spend – or spent – a lot of time writing long form articles showing how to achieve things within the context of software development.
Both he and I, among others – perhaps including some of you who are reading this post or regularly read this blog – have been around long enough to remember what it was like growing up online, learning how the machine works, how to write code, and perhaps even studying it in both high school and college, and maybe beyond that.
The 90s
For me, it was a combination of AOL, the the programming forums, VB3, and then onward and upward to other languages, operating systems, and platforms from there. True story: The first copy of Linux I ever received was Slackware that someone I met in IRC sent to me via USPS. The site doesn’t look enough different today.
So many afternoons, nights, and evenings were spent hopping between playing games like King’s Quest (Six is the best and I’ll fight you for it) and then signing online to see what certain people were building (such as a TCP/IP checkers game built fully in Visual Basic) to random proggies people were using to manipulate AOL, and from trying to wrap my head around C++, to trying to make sense of Dan Appleman’s Programmer’s Guide to the Win32 API.
The 00s
Fast far forward to the early two thousands and sites like Stack Overflow come online (from the minds of long-time bloggers Joel Spolsky and Jeff Atwood, no less) and begin having perhaps the largest scale and gamified way to get your programming-related questions answered quickly.
In fact, I remember listening to the podcast on my iPod Shuffle while running through the suburbs of the north Atlanta metro area. They’d talk about how they were discussing certain aspects of the site from an object-oriented programming standpoint, the technology stack they were using – which was .NET – and they were using Subversion as their version control system.
And I’m old enough to be one of the double-digit user accounts. And I remember them growing into what was originally called The Stack Overflow Trilogy. It was a really cool time to be a young software developer working in web application development.
Today
All of this is to say:
I don’t recall a single new set of sites and/or technologies being introduced that so quickly impacted what those of us who do what we do for a living.
On Blogging
Sure, certain technologies or libraries or languages or tools have come and gone, but when I think about major inflection points of utilities that have impacted software developers, Stack Overflow and ChatGPT (along with its related technologies such as Copilot) are the first thing to come to mind.
I’m shooting from the hip as I’m drafting this late at night and should be giving this more thought, but I digress.
Anyway, during the conversation with Carl, he made the following claim:
I think ChatGPT wrecked our type of content
I’ve been rolling it over in my mind for the past few days not so much because I disagree – I actually firmly agree – but I’ve been thinking about the following two points:
It’s paradoxical. Bloggers wrote the content that helped train a massive LLM that ultimately negate the need for that kind of content. Granted, we could continue to feed the machine, so to speak, but LLMs can learn from themselves given the right interaction.
The goal was never to provide a quick way to copy and paste a solution, but how to learn how to solve a problem when you weren’t sure how to approach it. (And this is something that I think serves anyone in the field of applied computer science well.)
When you’re someone who enjoys writing about technical concepts for yourself and others, the ultimate goal isn’t to show someone how to quickly do something. More so, it’s to show how to approach problem solving in the abstract and to understand the tradeoffs of various solutions.
On Social Media
Then I got to thinking about all of the people in WordPress I’ve met over the years, then I got to thinking about all of the people in adjacent groups I’ve met over the years. Those work work in:
backend languages,
front-end languages,
content creators,
podcasters,
and so on.
So I decided to hop back on to X/Twitter for a bit to see how those people have been using the platform since ownership changed hands earlier this year.
And what I found during my, what you may call, straw poll was that there’s a lot of people who haven’t abandoned the platform at all. Instead, they subscribe for access to the premium features of the platform, who are writing long form content, who are sharing longer form content than I think we’d more likely see on some blogs just five years ago.
So then I brought all of this back to what I’ve traditionally written about and in the field in which I work, and I’ve noticed that there are a lot of people spending a lot of time writing about development work as it relates to WordPress on X/Twitter rather than on their blog.
And here’s why that strikes me as strange:
Old school tweeting was one thing because it included short statements that felt more like parts of a conversation. A very loud, boisterous, crowded conversation, but a conversation of sorts nonetheless.
Now, though, people are writing essays on their premium accounts about content related to a platform that targets the democratization of publishing. An essay does not a conversation make.
Further, publishing content on a platform about the software on which you work that aims to give people the goal to publish content so they can maintain it seems incongruent.
I don’t think anyone should have to make this claim but I’m not someone who cares one way or the other who owns X/Twitter or what’s going on with it from a socio-political-or-economic perspective. The observations I’m making wouldn’t matter who owns it.
Bringing It All Together
So how do I bring the various and seemingly disparate thoughts on all of this together to try to make a cohesive article? I’ll do what I can.
Writing about software development and trying to provide quick solutions to common problems are not the same thing.
Writing long form articles about the concepts in software development and looking for an answer from ChatGPT or related services are not related.
So the first question seems to come to something like:
When people are given the choice to choose between the two, will they search the archives aggregated via RSS first or go to ChatGPT first?
Though the goals of this question are not mutually exclusive, I think getting an answer fast often outweighs the “I’m looking for an answer but it was neat to also read about someone else’s situation while searching for it.” And this is why ChatGPT has “wrecked” some of the content a bunch of us typically write.
It’s not because we don’t want to write it (and no one is stopping us), but it’s hard to know just how many people come for the content and stay for the answer versus come for the answer and stay for the content.
The answer, then, seems to lie somewhere in between either continuing to write as usual, which is a completely viable option, or do what content creator types do and bring the content to the table in a way that’s compelling enough to keep people coming back (or turning in, or watching, or smashing that subscribe button and remembering to hit the bell).
The second observation, though, is a bit less clear to me. Before X/Twitter changed hands, people were already involved in a number of different areas online such as Slack channels for Post Status or The WP Minute, Facebook groups, but they also tended to maintain their own site while sharing their shorter content on X/Twitter (for reasons that I’ve already covered).
Now, the whole thing is all over the place:
Some are spending a lot of time writing long form content on X/Twitter,
Some are participating in various Slack channels,
Some are participating in various Facebook Groups,
Some are blogging,
Some have pulled back from the social web,
Some are doing none, multiple, or all, of the above.
Having choice is fine and picking where to hang out is great – it’s the whole go where you feel most welcome kind of thing – but the degree and/or ways in which many of us have changed in 2023 alone is really something to observe.
Where We’re Headed Isn’t Clear
And, as I said at the outset, the solution to this isn’t clear. If I had to summarize my take it would be something like this:
Long form posts for those on X/Twitter has increased this year and the amount of content people are sharing on their own blogs and syndicating it to X/Twitter has decreased.
I have to leave it at that for now because I don’t know what to make it of it. Maybe it’s just the way it is.
Anyway, Carl also made the comment in our conversation:
I think there’s still space for teaching and writing about concepts
And I agree with this, too. The thing is, I don’t think the way we’ve historically done is it the way to do it moving forward. I won’t be the guy who’s writing his thoughts on X/Twitter (not as a protest or anything) because I don’t see the medium has particularly useful for that in the long term.
I still think blogging and ultimately publishing content on your own property and syndicating it out to social networks is ultimately better than inverting how it’s done (though that’s what’s happening right now).
People can read the content and then take the social aspect of to social media. Or they can drop an email in our inbox. Or they can consume it and move on.
Regardless, how the content is produced is presented is likely the next challenge for those of us who have historically done long form technical writing. And I don’t know what that looks like right now.
The property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.
In other words, in the context of REST APIs, the result of making a request shouldn’t change the state of the application more than once. That is, you make the same request multiple times, there should be no side effects such that the same result is sent each time.
Or, perhaps even more simply, if the same request is sent more than once, it’ll only be processed once.
Secondly, the crux of the article has a great breakdown of the various methods that should exist in a REST API:
GET Method: The GET method is used to retrieve a resource from the server. It is an idempotent method because retrieving the same resource multiple times will not change the resource itself or cause any side effects on the server.
PUT Method: The PUT method is used to update a resource on the server. It is idempotent because sending the same request multiple times will result in the same resource state as if the request had only been sent once. For example, if you send a PUT request to update a user’s email address with the same new email address multiple times, the user’s email address will only be updated once.
DELETE Method: The DELETE method is used to delete a resource from the server. It is idempotent because deleting a resource multiple times will have the same result as deleting it only once. If the resource has already been deleted, sending a DELETE request for the same resource will not result in any changes.
POST Method: The POST method is used to create a new resource on the server or to submit data to be processed. It is not idempotent because sending the same request multiple times will create multiple resources or submit the same data multiple times, resulting in different outcomes.
And keeping this in mind is very helpful when designing an API.
Ultimately, I share this because the article does a great job of breaking down the concepts of idempotency in REST API design and the supporting application. And it’s a good reminder to have on hand whenever I’m – or you, whoever you are ::s
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get startedwith a free migration today.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.
