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

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.

A WordPress Developer Salary Should Be…?

Earlier this week, Ryan Sullivan - a twitter-friend of mine - sent out the following note:

An interesting observation, isn’t it? Especially for those who work on WordPress full time, work with WordPress full time, and/or those who have come to WordPress from other backgrounds. Specifically those in software development backgrounds.

Straight up, I’ll say that I don’t know why a WordPress developer salary is less than any other [insert whatever type of] developer salary is here, but I have my thoughts and speculations (as I’m sure you do, as well). And as I – and many others – have been talking more and more about trying to force a shift in the WordPress economy, this seemed like a timely thing to share.

Making the Shift to Premium WordPress Plugins

When it comes to various business models that surround WordPress plugins, there are normally three types:

  1. Completely free
  2. Freemium
  3. Premium

How a developer opts to publish their plugin is their prerogative, and there are a lot of opinions as to why any one model is better than any of the other models. As with anything, each has its own set of advantages, and each person’s opinion is not necessarily any better than any other person’s opinion.

That said, as someone who has tried all three business models, I have to say that the longer I work in this particular economy, the more I lean towards the third option.

Though I’m not saying I dislike the other two, and though I’m not interested in discussing the advantages and disadvantages of the first two (at least in this post), I am interested in sharing my thoughts on the premium model (or the pay-for-it model or whatever you want to call it.

Writing JavaScript Helpers for the WordPress Theme Customizer

I’ve talked before about how I think the addition of the WordPress Theme Customizer (well, soon to be called the Customizer) is one of the nicest additions to the core application in a long time. I’ve also talked about how I fear the direction that some developers will take it.

Regardless, if you’ve worked with the Customizer long enough – especially when it comes to the JavaScript aspect of it – then you’ve likely noticed that you can end up writing relatively repetitive code especially when you’re working with something such as a list of items or something similar.

When you end up reaching this particular point, having too much of the same code with the only variations being a few strings ends up being a bit of a code smell.

In order to prevent this, it’s often better to write helper functions that abstracts the repetitive functionality into a single, ahem, function that you can call with the strings that are unique to your use case.

Here’s what I mean.

Does WordPress Encourage Poor Programming?

If you hang around any group of programmers long enough, you’re bound to get into a discussion as to which language is currently the best language and why that’s the case.

Well. Then again. Maybe not.

I’d say this is true is some cases, but I’d venture to say that if you’re hanging around a group who has been at it for quite some time (read: at least a decade or so), you’re going to have discussions as to what features of what languages are nicer in contrast to features of other languages.

A more mature discussion, right? At least a little.

But then you take this one step further: You sit and chat with a group of people who have been working on the same platform or framework for a while and you may find yourself in a discussion about what features of a given framework has that are better than its alternatives..

Perhaps a better way of putting it is: You may end up discussing why one language, framework, or set of tools encourages better programming practices than any other given set of languages, frameworks or tools.

You know you’ve been there when you can quickly list off several reasons, say, Python programmers prefer white space, Rubyists prefer unit testing, Rails developers appreciate MVC, jQuery developers like method chaining, JavaScript programmers love the prototypal inheritance, and Smalltalk programmers love how few of them exist (I kid, I kid).

On a more serious note, there’s no shying away from the fact that people either love or hate PHP. Sure, there’s middle ground but there’s no fun in taking a stance there so you don’t read many articles on people simply saying “Yeah, I think PHP’s okay.” But when it’s used in the context of another framework like CakePHP or Laravel, then you’re likely to find something different.

So ultimately, I think it’s worth asking the question, does WordPress encourage strong or poor programming practices?

The Embarrassing Nature of Modern WordPress Products

As far as WordPress projects are concerned, I’m far more comfortable talking about projects that I’ve been working on myself regardless of if they are for fun or profit.

And yes, there are times where I’ll share code and other snippets that come from contract work, but I generally do not talk about those types of projects out of respect for the client and/or out of respect for the terms of our agreement.

Contracts, respect, professionalism, and all that fun stuff.

The Disenchanted Young Professional

The Disenchanted Young Professional

But there’s been a project that I’ve been a part of for a few months now, and I received an email last week that struck a chord with me. I asked the client if I could share the quote – keeping them anonymous of course – but use it to try to make a point.

They obliged.

I hate trying to support a theme that’s so dated and broken. I can hardly wait until I can offer support for a theme that I am proud of and is coded well and will be kept up-to-date.

And though it’s already been referenced through a number of different blogs, and the article is already over a week old (which is, you know, practically forever in Internet time), I couldn’t help but think: “We’re ruining WordPress.”

You may or may not think of it as hyperbole, but this is a very real problem.