Include Bugs in Screencasting

For a number of years, I’ve been doing screencasts that help to teach others how to use WordPress – the majority of my work has been done for Envato, but I’ve also done some one-on-one screencasting as well as some screencasting for smaller teams.

Personally, I think it’s a really invaluable way to show people how to get started with using a given project without having to have them trudge through the documentation that often ships with software or with the manual that walks users through how to do a certain task.

Don’t get me wrong: I’m all for documentation, but I also know that when you’re sitting in your chair amidst all of this frustration and you have no idea where to turn, flipping through pages and pages of content hoping to find a solution isn’t always the best feeling in the world.

Anyway, the neat thing about screencasting is that aside from being able to show people how to use a project, it can always be a means by which we use to teach other people how to learn a new skill.

To me, that’s a really cool thing.

But up until this year – in fact, up until my latest round of screencasting – I always worked hard to make sure each video was as pristine as possible.

I don’t know if that’s always such a good idea, though.

Avoid Loops With save_post in WordPress

When working on WordPress projects, there may be times during which you have to do some sort of processing on the content or attributes of the post before saving it to the database.

There are a number of ways to do this, but one of the most straightforward ways to go about it is to setup a custom function hooked to the save_post action and then handle the attributes of the post in that function.

If you opt to go this route, there are a few considerations that you need to make (mainly that help you avoid some type of infinite loop) in order to properly adjust the content to your liking.

Debugging with Query String Parameters

There are a number of ways that we debug our WordPress-based projects.

  • Some people end up going through the code and setting up print_r statements or var_dump statements
  • Some end up working through the code and changing variables or function names until they find where something breaks (or changes)
  • Some use debugging software (or the debugging features in their IDE)
  • Some use a combination of plugins and other techniques
  • And some likely use some strategy that isn’t listed here

Personally, I’m partial to using some of the developer tools that are provided by WordPress through the use of setting constants and using plugins that are available to us, but I’m also a fan of using Codebug App (which is the content for another point).

Codebug App

But, for the purposes of this post, that’s beside the point.

Confessions of a WordPress Developer

For the last five or so years of my self-employment, a lot has changed. And I’m not talking about the technical landscape. I mean, that’s always changing, right?

But I’m talking about the way that I manage my time and the way that I get work done.

Unfortunately, the Internet has adopted this culture that allows everyone to share how they manage their time and then try to distill it into some type of step-by-step process that can be used by everyone.

That’s not the point of this post. I don’t operate that. I rarely subscribe to that advice, and I’m not going to be that guy.

Furthermore, I tend to ignore (and even reject) posts like that. We have many different personalities and so many variables that contribute to what we’re able to do, when we’re able to do it, and how we’re able to work that I don’t think it’s possible to actually distill something into a formulaic process.

Instead, I think it’s worth simply sharing ideas on what’s worked for ourselves and leaving it at that. This doesn’t mean that there aren’t some things we can borrow from others – because there is overlap in our personalities – but it also means that some of these posts are nothing more than informational pieces. And that’s fine.

So with that lengthy disclaimer out of the way, I thought I’d share some of the things that I currently do in order to manage by day-to-day tasks to get things done.

Anyway, here’s my first set of what’s to likely be more in posts that deal with confessions of a WordPress developer.

The Basics of How WordPress Works

If you’re getting started in WordPress development, odds are it won’t be long until you bump up against the concept of hooks. That is, points during the WordPress life cycle that allow us to add our own functionality to customize how WordPress behaves.

Of course, this is how both themes and plugins are made to do some of the neat (or not so neat, depending on the project) things that they do. And though I obviously recommend reading up on them in the Codex, I think it’s also important to understand how the WordPress application loads itself.

More specifically, I think it’s important to understand how WordPress works. There are a lot of resources out there available to read and review; however, John Blackbourn has been working on a no-frills version of this very idea that I believe to be worth starring and referencing.

On WordPress Theme-Specific Plugins and Theme Lock-In

When it comes to working with WordPress themes and plugins, there’s a general rule of thumb that most experienced designers and developers follow:

Themes are for presentation, plugins are for functionality.

Sure, there’s a little bit of blurring of lines, but this is the goal for which we strive when working through our code. And yes, there’s a lot that can be said (and has been said) about themes that include a ton of features, options, bundled plugins, and so on, but that’s not where this is going.

Instead, I’ve been thinking about how this relates to general theme development, niche theme development, and using WordPress as a platform for application development.

The Challenge of Over Solving a Problem

When building solutions for others, there are certain problems that we face that – although they’ve been solved – can still be a challenge for us to deal with.

For example, you’ll often hear programmers complaining about regular expressions or maybe you’ll hear someone complaining about working with timezones.

Moment.js

I’ve been heads down on the latter for sometime now in a project and even with solutions like Moment.js, there are subtle nuances that must be taken into account when dealing with dates and times.

There are plenty of other examples, but the point that I’m really working towards is this:

When we’re focused on problems that have a number of subtle nuances, I think that we often tend to overlook some of the simpler things that can be done to address the issue.

In my case, I’ve been in the trenches with timezones, offsets, and other subtleties that come with working with dates and times that I’ve tried to over-solve a problem.

Code Quality Is Not a Feature

One of the things that I think is easy to forget about working within the WordPress space is that we’re often talking to a circle of [many of] the same people. By that, I mean that developers are largely talking to other developers (and likely some designers), designers are talking to other designers (and likely some other developers), and so on.

I mean, I have no expectations that anyone who reads this blog is outside the scope of someone who writes or wants to write WordPress code.

And though there’s nothing inherently wrong with this – I mean we’re naturally all about creating groups and communities – I think that it can negatively influence how we may be marketing our products or even discussing our work with other people.

In fact, I’d argue that one of the biggest problems that we have as it relates to marketing our WordPress projects is the fact that we use phrases “clean code” or something similar when trying to sell others on our work.

What Are WordPress Theme Extensions?

Most experienced WordPress developers will likely make the case that themes are for presentation and plugins are functionality. I agree with this and it’s something that I try to take into account with each project that I work on.

That is, whenever I have a project that consists of some unique functionality, then I’ll build out said functionality into a plugin and then either advise the customer or the user of the theme to download the plugin (for which there are some great tools available for this) or I’ll include it in such a way that the theme will include it and activate it.

Honestly, I’m not a big fan of the latter – it assumes the user doesn’t already have a version of the plugin installed, it creates a dependency that’s harder to manage, and it’s activating something that the user may not want activated even though we may see it as something that’s crucial for the site to function properly.

This is something that could probably be argued ad nauseam and though that’d make for a lot of fun in writing up a blog post and chatting in the comments, that’s not the purpose of this post so I digress.

Instead, it’s to offer up the idea that perhaps there are shades of gray as it relates to building specific functionality for highly niche themes.

WP Sessions: Using The WordPress Plugin Boilerplate

Prior to handing off development and maintenance of the WordPress Plugin Boilerplate to Devin Vinson, I had the opportunity to work with Brian Richards of WP Sessions to put together a short course on how to use the WordPress Plugin Boilerplate.

Using the WordPress Plugin Boilerplate

The purpose of the course was to provide the initial set of documentation for the project that would give users and developers a complete walkthrough of the source code, understanding its organization, and a tutorial for how to build a plugin with the project.