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.

Why You Should Write Meaningful WordPress Meta Keys

If you’re someone who’s building solutions with WordPress regardless of if they are themes, plugins, or applications, then odds are you’ve had to deal with saving some type of information to the database.

Granted, anytime you create a post, a page, or anything that stores data, you’re entering information into the database.

But that’s not what I’m talking about.

Instead, I’m talking about times when you’re having to work with the Options API, the Theme Customizer API, or one of the meta APIs (like the Post Meta API). In this case, you’re working with the core application to save and retrieve information from the database.

When doing this – especially in development and possibly in staging – it’s likely that you’re having to write the code, run a test (automated or not), and then take a look at the way the record is stored in the database to make sure it saved as expected.

In my experience, there are a handful of things that can be done to make this process a little bit easier and make your code a little bit cleaner and one of these has to do with writing meaningful WordPress Meta Keys

Aim for a Single Way to Achieve a Single Task

When it comes to user interface design and user experience, I’m no expert (nor have I ever claimed to be). I’m barely an intermediate. if even that. I’m fortunate enough people to have peers who are willing to review certain projects in order to help tighten up certain aspects of my work.

I don’t think we should ever be afraid or ashamed to ask people who are more skilled than us in a certain area to help us out (or to pay them, even!). After all, we have nothing but to benefit from it.

This doesn’t mean that a couple of ideas, rules, and general practices haven’t come up over the years.

For example, one of the rules of thumb that I have whenever I am working on a user interface is to try to make sure the user only has one way of achieving something.

In other words, I don’t like it when there are multiple ways to do the same thing. I think that it confuses the user, it complicates the code, and it makes it more difficult to maintain over time. The code aspect of this is enough content for another post.

For now, it’s just about finding a single way to achieve one task.

Adding More Fields to the WordPress Media Uploader

Last week, I shared a short post on how to include your own instance of the WordPress Media Uploader in your theme or your plugin.

Though it walks you through everything that you need, on aspect of using the instance that I described is that it’s limited. This is fine for certain situations, but there are other times where you may want to grab more information from the user.

Case in point, the post received the following comment:

Now, how do you activate (turn on) the Insert Image via URL feature of the Media Uploader?

Which I thought was a good question especially given that most of us are used to seeing more options in the media uploader than what the previous post described.

Thoughts on Design Patterns in WordPress

Whenever the topic of talking about using WordPress as a foundation for web applications comes up, I always get mixed reactions. That is, I’ll hear anything from how that’s a silly idea to how a person wants to know more (as well as everything in between).

One of the more common things that I hear developers often try to do is to retrofit the MVC pattern around WordPress in order to try to make sense of how existing themes, plugins, and applications work, as well as how they can take advantage of MVC to produce their application.

Don’t do that!

WordPress doesn’t use MVC. It uses the event-driven design pattern. But for whatever reason, this doesn’t stop us from trying to wrap MVC around WordPress. When it comes to design patterns in WordPress, there are other approaches.

There are reasons for why I think this is a relatively common trend, but there are alternative ways to approach development on WordPress, as well.

Tagging Untagged Posts in WordPress

This weekend, I shared how to setup a query to find all untagged posts in WordPress that aren’t tagged with a specific tag. In my example, I opted to use IDs (for no particular reason), but Ross also showed how you can use slugs, as well.

Anyway, there are a number of things that you can do with untagged posts – perhaps you want to remove them, perhaps you want to categorize them, or perhaps you want to apply a tag to them so that they’re stamped with a tag (like one that was not

Find Untagged Posts in WordPress

It’s common for people to categorize or tag their posts when using WordPress. This is true for the average blogger and for those who are using WordPress for its content management features.

For example, let’s say that you’re responsible for working on a site that has an RSVP custom post type and the post types can be tagged for certain types of events.

Tags may include:

  • Formal
  • Informal
  • Wedding
  • Birthday
  • Family
  • Friends
  • …and so on

Overtime, the database is going to increase in size and if RSVPs aren’t manually entered (that is, they are imported or maybe the database is even inherited and mismanaged), there’s a chance that some of the posts will not be tagged.

If you’re a developer, the odds are strong that you’re going to need to at least locate the untagged posts (and perhaps update them, as well).