For the Copy and Paste Programmers

One of the things that has been absolutely fantastic about the web is how much information we can publish and how much we can access it at any given time. I don’t know many who would disagree with that.

Even more so, for those who are interested in learning how to write software, there are various articles, podcasts, videos, tutorials, and so on all of which aim to teach a person the skills they need in order to actually get from not knowing how to write code, but knowing how to do so in a productive manner.

One of the downsides of this – and even more generally, open source – is that breeds this copy-and-paste mentality that completely undermines the very thing that it’s trying to teach: that is, how to write code.

Custom Meta Box Tabs in WordPress

One of the things that has become relatively common within themes that offer a lot of options is the use of tabbed navigation. That is, options that are related are logically grouped into tabs and then the user can navigate through each tab in order to select the options.

Whether or not this is a good thing for themes is outside the scope of this particular post; however, another place in which tabs may also be used is within the context of custom meta boxes.

That is, a custom meta box sits below the post editor and it offers several options or additions to the post meta data each of which is group together in their own tab.

Though I personally find this a bit more effective than using tabs of pages for screen options, that discussion is outside the scope of this post.

Regardless, there are ways to improve the ways in which custom meta box tabs are created such that they are organized in a more maintainable way, and each tab has its own view, partial, or template so that it’s easier to work with over time.

WordPress Theme Updates Are New Themes

I know that there are different ways that people approach building WordPress themes and I’m not one to argue that there’s a single right way to do it. Sure, some ways are better than others, but that’s true of a lot of things.

Personally, I approach building themes, plugins, and so on as I would as if I was building some type of software. That has to do with my background. Similarly, someone who has a background in design and in front-end development will conceptualize what they are building in a different way.

Like I said, all of that’s fine (in fact, I think it’d be interested to see how different people view building themes, but I digress), but I do know that one common thing we always have to think about as it relates to updated our WordPress themes is the actual front-end design.

Specifically, does it make sense to completely change the design of a theme for a different version of the theme?

How Do You Blog? (Wanna Have an Event?)

For those of you who blog regularly, you likely get a fair share of feedback and it probably comes in many forms.

  • Praises
  • Critique
  • Donations
  • Profanity
  • Love
  • Hate
  • …and anything and everything in between

You name, it’s been said either in comments, emails, and tweets. But yet, we still write and a bunch of people – perhaps more than ever – are interested in digital publishing in some capacity.


This may be writing a personal blog, this may be writing a business blog, this may be writing a technical blog, or this may be writing a blog about anything and everything. Whatever the case, there are a lot of resources out there that tell you how to be successful at what you do.

That is, they offer prescriptive solutions on what you should do in order to be successful in blogging, but I’d venture to say that if you asked 10 people what it means to be successful in blogging, you’d get 5, 8, maybe even 10 answers.

So where does that leave us, and where does that leave the people espousing all of the information on how to be successful doing it?

Single Page Tabbed Navigation in WordPress

In a couple of recent projects, I’ve been tasked with adding tabbed navigation to various WordPress templates. The thing is, these tabs work in such a way that all of the information is loaded on the page so when the user clicks on the tab, the contents of the page appear without having to do a page refresh.

Tabbed Navigation


In some cases, it may be best to load pages via Ajax, in some cases, it’s better to load things up all in the first page load. This particular post is about the best strategies for that (that’s a debate for another post).

Design Patterns for Refactoring: The Facade Pattern

For some time now, one of the things that I’ve been considering writing about is the idea of refactoring.

Not necessarily in an incredibly specific sense – because each project is different – but in the sense of using some strategies that can help to take an existing project that’s running in a production server and slowly begin to refactor it so that its architecture changes but the functionality remains the same.

Anyone who’s worked in the software world knows just how nasty a codebase can get, and WordPress is no different. And I’m not talking about WordPress core – I’m talking about plugins, themes, apps, or whatever else it is that you may be building on top of WordPress.

For the most part, we start our projects with the idea that it’s going to have a great architecture, a pristine design, and that it’s going to basically be the best thing that we’ve ever worked with.

At some point, usually due to external factors, the thing devolves into a pile that we no longer want to touch, and we hope that it holds together to continue solving the problem at hand.

But it doesn’t have to be that way and even if the code you end up working with – be it your own, or someone else’s – has devolved into a big ball of mud, there’s still a strategy (probably multiple strategies) that you can use in order to refactor it into something far more elegant.

Everything Is Bloated, Nothing Is Good

One of the things that’s becoming more and more common place regarding front end frameworks, utilities, or applications is the use of the phrase “it’s bloated” followed by an argument as to why we should dismiss it.

No, this isn’t something that’s new, but it’s something that’s becoming appears to be becoming more mainstream – at least as far as I can tell – in how people describe the tools, apps, frameworks, libraries, and other tools that they work with today, or have worked with at some point in the past.

Obviously, this isn’t to say that nothing is bloated – I mean, I’ve written enough articles on the idea on “decisions, not options” and on how things should be more focused on a single niche – but sometimes I think that we often write off certain utilities as being “bloated” when that’s not exactly the case.

Just because something has a number of features that you don’t use doesn’t make it bloated.

WordPress Plugin Boilerplate: Testing 1, 2, 3

In 2011, I released the first version of the WordPress Plugin Boilerplate and have been maintaining it (along with contributions from other programmers) ever since.

Over the last couple of years, the Boilerplate became quite active – as far as very small projects are concerned – with issues, pull requests, and so on. It’s been a lot of fun to maintain, and it’s been really neat to receive so much feedback from other developers in terms of making the Boilerplate more resilient and from those who were just getting started with plugin development.

Earlier this year, I shared that I – along with a small group of other people – began working on the next iteration of the WordPress Plugin Boilerplate. That is, we were initiating a complete rewrite of the project.

As of today, I’m officially launching a beta of sorts of 3.0.0 of the Boilerplate. This is a major rewrite and refactoring of the Boilerplate in the state that its had for the past few years, and there’s a lot of change coming not only to the Boilerplate itself, but to new site, documentation, forks, and so on.

JavaScript and WordPress Page Performance

Last week, I was having a conversation with a fellow WordPress developer about improving page performance as it relates to JavaScript. Specifically, we were talking about if it makes sense to load JavaScript sources at the bottom of the page.

If you’ve done any client-side development for a moderate length of time, odds are strong that you’re well-aware that it’s considered a best practice to include JavaScript sources before the closing body tag rather than in the head element.

This is because it allows the browser to render the page more quickly without waiting for larger files to download (and JavaScript files are normally heavier than HTML documents because of their file size and the processing they do on the DOM).

There’s a lot that could be said with respect to this in terms of general web development, but in terms of WordPress, opting to enqueue your scripts at the bottom of the page versus the top of the page may require a bit more consideration.

The Beginner’s Guide to Type Coercion

This week, I started a new series on Tuts+ Code that walks readers through understanding type coercion.

Type Coercion

Type Coercion

Generally speaking, the series of articles starts at the most basic level by discussing strongly typed and weakly typed languages, data types and how they work in different environments, and then begins to branch out more into how data types work within dynamically typed languages.

The main motivation for this is because people who are coming from a strongly-typed background, or those who are just getting into programming may end up finding themselves making a few mistakes especially as it relates to comparisons, conditionals, and other similar evaluations.

This series aims to mitigate that.