Author: Tom (Page 347 of 427)

A Look at The UI Design Process in WordPress Plugins

February 22, 2013 / Tom / 0 Comments

I’m no designer. I don’t aspire to be one, nor do I claim to be one that; however, I am interested in the topic and enjoy seeing the work that others do as well as following blogs, articles, books, etc. on the topic.

Though user interface design is a bit of a different field, it hits much closer to home for me than other types of design. After all, a user interface is basically the face of the code that we’re writing.

And if we’re not careful, then we’re going to continue perpetuating the stereotype that developers do not care about design.

I’ve spoken previously about sharing case studies on WordPress projects, and though I don’t have a full project to share right now, I thought it might be fun to look at some I’ve been working on and the evolution of a particular user interface that evolved from a first pass, to discussion, then from mockup, to implementation.

Object-Oriented WordPress Plugin Development

February 21, 2013 / Tom / 0 Comments

When it comes to writing plugins – specifically those that are object-oriented in nature – many of us do so because we’re obviously fans of writing object-oriented code.

Personally, I’m a fan of it because it helps to separate the responsibilities and concerns of a requirement into its own logical unit.

Sure, this can be done with several function files as well, but I come from an object-oriented background, so when I approach a problem, I automatically begin thinking in terms of classes and their relationship to one another.

And I know that other developers do the same.

The thing is, I think some of us – myself included – have gotten lazy or we only half-bake our object-oriented-based plugins. That is to say that we may be using classes in writing our plugins, but we don’t do such a good job of taking advantage of other object-oriented principles and features.

Properly Instantiating WordPress Plugins

February 20, 2013 / Tom / 0 Comments

One of the things that Pippin, Norcross, and I have been talking about during the course of building Comments Not Replied to is the best practices for instantiating WordPress Plugins.

Specifically, we’ve gone from simply creating an instance of the plugin, to storing it within the PHP $GLOBALS variable, as well and then debating whether or not to implement the plugin as a singleton.

There’s more to this that I’ll cover in a follow-up post, but the most significant thing worth sharing in this post is why we’re discussing how to instantiate our plugin.

Should I Do This in a WordPress Theme or Plugin?

February 19, 2013 / Tom / 0 Comments

Last week, a fellow WordPress developer and I were having a conversation about a particular feature that he’s been contracted to implement for an existing site.

In short, he was trying to decide between introducing the new feature in the form of a child theme or in the form of a plugin.

It’s a question that I see raised more often than not, but I think there’s a series of questions that we can ask ourselves before jumping into writing any code.

Generally, it has to do with the true definition of a theme and the true definition of a plugin. Of course, there’s room for deliberation, but here’s how I normally see it.

A Look at The UI Design Process in WordPress Plugins

Object-Oriented WordPress Plugin Development

Tipsy Social Icons Now on GitHub

Properly Instantiating WordPress Plugins

Should I Do This in a WordPress Theme or Plugin?