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.

Continue reading

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?

Continue reading

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.

Continue reading

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:

• Three reasons I think salaries are lower,
• And how the industry, applicant pool, and skill set play a role

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.

Continue reading