Category: Articles (Page 117 of 258)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Understanding WordPress Hooks

August 24, 2016 / Tom

WordPress hooks are arguably the foundational topic that developers need to learn and understand when it comes to building more advanced functionality for WordPress.

WordPress Hooks

Yes, you can build an entire theme primarily with markup, styles, and JavaScript. Though you may need a few server-side functions in PHP, it’s easy to find things like this in the WordPress Codex or in Underscores.me.

But if you’re someone who’s new to WordPress or who is ready to take the next step regarding extending the platform or writing a plugin, then it’s important to understand to know what WordPress hooks are, how they work, and what they’re designed to do.

And that’s what I’ve covered in my latest series on Envato.

Your Source Code (“This Could Be Better”)

August 23, 2016 / Tom / 0 Comments

I’d like to think that one of the struggles many developers feel when shipping code is a sense of “this could be better” before they push whatever button to send their code out into the world.

Yeah, okay, code review this.

It doesn’t necessarily matter if this is a hobby project, if this is a project for a corporate job, a freelance job, or if this is something that’s for an open source project. I say that because I think this is something that many of us feel with whatever it is that we release.

It’s a feeling of something is “not quite done” or “if I could just refine this a little bit more.” I know: This isn’t the first time I’ve talked about this before, and it’s likely not going to be the last.

And the feeling is not without merit. Other developers can make us feel like we’re doing something wrong (sometimes we are, sometimes we aren’t). But in our industry, I think there’s more of a spectrum of optimal-to-suboptimal. Though some may not agree, a friend of mine recently said it best:

The software industry is too vast and too fast to keep up with it all. But because it’s now that way, people find their niches and think that it’s the “best” or “only” way to get something done.

The further I get into my career, the more I feel this sense of obligation to make things as pristine as possible before sending it to a client, user, or just out for the world to use.

And though I think this is important, it’s important to make sure that I (and we) are doing this for the right reasons.

An example of a wrong reason might go something like this:

It’s not because it doesn’t meet requirements and it’s not because it doesn’t fulfill what was requested by the client. It’s because how others might perceive the work when they do not have the proper context.

So of course, I don’t think there’s anything wrong with wanting to make your code base or your architecture as robust as possible. We should all strive for that. But I believe that it’s important to contextualize appropriately and adequately scope your sprints, milestones, work or however you group your tasks together.

Finding Optimal Development Tools

August 22, 2016 / Tom

I have a tendency to talk about the importance of finding optimal development tools that work best for you, that fit your workflow, and that improve your productivity.

Cornerstone is the Subversion client that I prefer to use.

And I stand by those statements.

But sometimes I wonder if the things that I’ve said don’t come across as mutually exclusive (or even sometimes partially exclusive, if that’s a thing). This is true especially when I talk about things like why I switched from an IDE to a text editor to handle my development tasks.

Anything other than that is never my intent (though I can completely see how someone may interpret my perspective that way).

What I mean is this:

Whenever I share information about what I opt to use, I do so in a way where I mean to give information as to why it works for me.

Admittedly, sometimes I’m better at doing that than others.

How (And Why) to Create a Repository Archive

August 18, 2016 / Tom / 0 Comments

If you’re someone who regularly develops software, sites, or anything with any code, you’re going to start using source code control at some point.

And when a project ends, you’ve got options when it comes to maintaining the source code:

Perhaps you’ll hand the code over to the client, and you will retire it,
Or maybe you’ll continue to maintain it for the client as part of an ongoing relationship,
Or there’s a chance you’ll be done with the project but still want to hang on to the source code.

For me, I’m partial to the latter option primarily because I like to have an archive of the things I’ve worked on throughout my career (no matter how trivial they may be) and because I’m a bit of a packrat when it comes to things like this.

Because if a client ever comes back for future work on a project, then I want to be able to spin up a copy of the development environment so I can get back to work. This assumes that I have an archive of the source, though.

But this assumes I have a repository archive.

Late Escape WordPress Data

August 17, 2016 / Tom / 0 Comments

When working with themes and plugins, it’s a common practice to escape WordPress data. Honestly, this is a standard practice in all web development:

Whenever you’re retrieving information from the database to display to the user, it should be validated and escaped so that nothing but clean, readable text is rendered to the user.

In WordPress, you’re likely to see this in one of two ways (or maybe both ways depending on your setup):

You’re retrieving information from the database via get_option and then displaying it to the user.
You’re retrieving information from the cache and displaying it to the user.

There may be other ways that you’re grabbing the information, but the specifics beyond what’s above are outside the purpose and scope of this post.

Instead, the point I’m working towards is that we should escape WordPress data in the context of a template file or a view rather than in the context of a function.