WordPress

Articles, tips, and resources for WordPress-based development.

Stop Including Custom CSS in WordPress

One of the things that I think many, many young (that is: inexperienced) theme developers do is ship a custom.css file in WordPress. Years ago, I made the mistake so I’m just as guilty as the next person.

Unfortunately, this is something that’s still happening today - we need to stop including custom CSS in WordPress and use the native facilities to take advantage of the same functionality we’re trying to achieve with this particular file.

Here’s the thing: Normally I wouldn’t bother talking about something like this because the Codex does such a good job of outlining the proper way to introduce customizations into themes, but I recently received a comment (that I’ll paraphrase) in which I was told that:

In the real world not everyone uses child themes.

Odds are, many of us have heard the old cliché that:

The difference between theory and practice is that in theory there is no difference.

And when you’re talking about something like a complex algorithm for traversing, say, the shortest path across a graph over a large network, or when we’re talking about something like properly handling memory in embedded systems, talking about theory and the real world makes sense.

That is, all of those cases are important and are worthy of optimization, but we’re talking about a single CSS file.

We’re not talking about a complex system.

And it concerns me that those who are contributing to the WordPress economy through products aren’t taking the built-in features of the application seriously. It’s seen as some bit of impracticality that they don’t want to pursue.

But this introduces it’s own set of challenges that negatively affect theme development from both a developer and a customer standpoint.

How to Check if a WordPress Posts Exists by Its ID

I was recently having a conversation with a friend and fellow WordPress developer about the best ways to go about checking if a post exists given nothing but an ID.

For those who are experienced with the WordPress API, there are a number of ways to go about doing this. Functions and classes that exists for things like this are:

  • get_post
  • WP_Query
  • Running a direct query with $wpdb
  • …and so on

Each of these has its advantages and disadvantages, but of everything listed above, there are always two things I try to make sure that I do when working with simple functions (like checking on the existence of a post).

I try to make sure the function:

  1. Is as lightweight as possible
  2. Is as easy as possible to read within the context of the existing code

After all, months from now, you never know if you’ll recall why you wrote code a certain way nor will your team or your peers necessarily know why the code you selected is set in a certain way.

The Negative Effects of Changing WordPress Theme Design

For as much as I’m a fan of approaching WordPress theme and plugin development as one would any other type of software project, there’s one thing about releasing major updates to themes that I don’t think should be treated as some people treat software projects.

That is, when it comes time to do a major release of a theme – regardless of what the version number is (because that’s a discussion for an entirely different post) – I think that the presentation layer or the way the theme looks or its general styles shouldn’t deviate very much from the initial design.

Think about a number of the major applications that you use on a day-to-day basis. This can be desktop software, this can be mobile applications, this can be an operating system, this can be web applications, and this can even be other WordPress themes.

A tubular update to the UI of a dog collar.

A tubular update to the UI of a dog collar.

Then, think about how often their interface changes. When it comes to major updates, there’s often times a major change in the interface or the introduction of a different way of doing something within the application. The change can be significant.

Although this introduces a learning curve which often leads to frustration on the user’s behalf, and although this is something that’s normal because of the advances in technology, I don’t think it necessarily applies to the look and feel of WordPress themes.

Turning Off WordPress Pingbacks

One of the features of WordPress that used to be significantly more popular is that of trackbacks and pings (or more commonly referred to as pingbacks). In short, it’s a way for those who run a blog to know when someone else has linked to one of their articles.

It’s kind of a flattering thing, isn’t it? I mean, someone is writing a post and then linking their content to yours? Then again, sometimes they could just be responding to something you’ve said in a negative way. That’s not always the most flattering thing, I guess, but it fosters conversation nonetheless.

Pingbacks are the ping pong of blogging. Or something like thing.

Pingbacks are the ping pong of blogging. Or something like thing.

Regardless, I’ve seen some people question the purpose of pingbacks, question whether or not they should be enabled or disabled, and question whether or not they actually help readers when skimming through the content.

Though I personally don’t have any kind of evidence from any kind of study to back up any of those points above, I have decided to turn pingbacks off on the public-facing aspect of my site in the coming days.

Disrespecting the WordPress Customer, Damaging the WordPress Customizer

It’s no secret that one of the things that I love most about the most recent versions of WordPress is the Theme Customizer (which is soon to be called the Customizer). I’ve talked about it in a number of different articles, some of which include:

Further, I’ve been clear in stating that I think that as much as I like the Customizer, we’re beginning to see the same problems, but in a different place.

Simply put, I think that we’re disrespecting our customers and damaging the WordPress customizer.

And over the past few weeks, I’ve seen this manifesting itself more and more through various themes I’ve seen, various screenshots I’ve seen, and various other discussions I’ve seen.

Granted, I’m not really one in a position to say what a person opts to do with their own projects, and I’m not particularly interested in getting up on a soapbox (but this is probably going to read like that, so there’s that, I guess) and telling everyone how or why to do something, but I do have strong opinions on the WordPress philosophy and how it directly contributes to developing themes.

As it stands now right now, I think that we’re doing a terrible job of respecting the WordPress philosophy, putting it to work for us, creating happy customers, and leveraging the WordPress customizer for the betterment of the WordPress economy.

An Attempt to Improve JavaScript in WordPress

One of the things that’s always been somewhat of a point of pain in both theme and plugin development is how to handle JavaScript in WordPress.

By this, I’m not talking about third-party dependencies such as jQuery, FitVids, or whatever libraries Bootstrap, Foundation, or what’s contained within the frontend framework you opt to use when building your theme – instead, I’m talking specifically about code that we write in order to get things done within the context of our work.

When it comes to procedural programming in WordPress – think working in functions.php – it’s expected that we’re going to be naming our functions with a unique prefix in order to prevent conflicts with other functions that may exist within plugins, third-party libraries, or even in WordPress itself.

For anyone who is just getting started in working in WordPress, this can be a hard lesson learned depending on if you’re one of the “read-the-documentation-first” type of people or not, but the thing is that the global nature of PHP mixed with the wide array of functions included in WordPress, PHP, and third-party code can lead to naming collisions that will either break the overall application or cause erratic behavior.

Most likely the former, but whatever.

But look at that: I spent the entire first part of this article talking specifically about naming PHP functions – but this is exactly the point I’m trying to make: We spend a lot of time talking about doing this in PHP, but not a lot of time talking about doing it in JavaScript.

WordPress Developers: The Programmer and the Implementer

Throughout the last few posts, I’ve been talking a little bit about WordPress Developer Salaries, but have also done so by taking a look at exactly what it means to be a WordPress developer.

If you’re just catching up, the previous posts are:

  1. A WordPress Developer Salary Should Be…?
  2. WordPress Developer Salary: Manage That Content
  3. Of Salaries and Software Development with WordPress
  4. The Roles of WordPress Development

There have been a lot of awesome comments and I’ve enjoyed hearing the different perspectives and opinions that everyone has brought to each post. There’s one more aspect of WordPress development that I want to look at before ending the series.

I’ve already mentioned this throughout several of the previous articles (and it’s been bought up in the comments, as well), but I thought it’d be worth outlining it here not only to share my concrete opinions on the matter but hopefully as an attempt to provide a reference or even maybe some food for thought for those who are looking for WordPress-related jobs, and those who are looking to staff WordPress-related jobs.

Specifically, it’s about looking at the term “WordPress Developers” and trying to give an explanation as what that really means.

After all, we’ve already said that the term developer is overused to the point of having no meaning, right?

The Roles of WordPress Development

In the last three posts, I’ve spoken a bit about the salaries of WordPress developers, why they may be lower than traditional software developers, and some of the expectations that come with what a WordPress developer may be (depending on their role).

I’ve shared:

  1. A WordPress Developer Salary Should Be…?
  2. WordPress Developer Salary: Manage That Content
  3. Of Salaries and Software Development with WordPress

In the last post, I talked a bit about the responsibilities and expectations of a traditional software developer and how that may relate to WordPress. And earlier, I briefly talked about the terms a “developer” and an “implementer” both of which I think are applicable in the WordPress space.

But first, it’s worth noting that many WordPress developers are people who are building themes and/or plugins. At this point in WordPress’ history, people still aren’t seeing it as something that can be used to build web applications (let alone mobile applications) so it’s seen more as something that bloggers, frontend developers, and maybe some middle-ware developers are used to doing.

And all of that is correct – but there is more to it than what’s listed above.

Of Salaries and Software Development With WordPress

Over the last couple of posts, I’ve been talking about the various things that contribute to WordPress developers having lower salaries than other traditional software developers. Specifically, I’ve talked about:

To be clear (and as pointed out in the comments), this isn’t the case everywhere, but it’s apparently a common enough trend such that peers in the industry are noticing it, and it’s struck a chord with others to, ahem, write about it, and to continue a talking about it a little more in-depth.

Anyway, one of the things that’s undeniable is that WordPress can’t be compared directly to frameworks like Rails and .NET, libraries like jQuery, or straight up languages because it’s none of those things. In and of itself, WordPress is an application that can be installed on a web server and can be used for digital publishing.

It just so happens that it has a powerful API that allows it not only to be extended, but for other applications to be built upon it.

WordPress Developer Salary: Manage That Content!

In the previous post, I shared a few thoughts on the challenges of setting a WordPress developer salary. When I began writing out my opinion, I ended up writing a lot more than I had intended, so in order to keep posts at a shorter length (thus saving all of us time :) and sounding less monotonous, I’ve broken everything up into a handful of posts that I’m basically running as a series.

Yesterday, I laid it all out in that I shared three reasons as to why I think WordPress developer salaries are lower than that of the average software developer. There were some really good, thoughtful comments on the post, too.

And the whole point of doing that was to lay out a high-level view of my opinions before looking at the topic in more detail.

As much as I want to talk about more technical matters of WordPress, I think it’s worth noting that one reason that a WordPress developer salary is hard to set is that many still see WordPress as a content management system, if not just another blogging platform.