Author: Tom (Page 279 of 433)

Last week, I shared a post on how I go about organizing my WordPress theme functions.

Generally speaking, the conversation that ensued in the comments was more interesting the post itself (at least as far as I’m concerned :) because it raised some interesting points of how others organize their files, as well as raised questions as to some strategies for organizing other types of files.

Specifically, Mike said:

I did the same thing recently with the /inc/ folder and needing to add a bunch of different loop files for post types, wondering if I should add a folder within the /inc/ to separate the loop files from the other files I needed. I think I may have been over complicating things a bit, too.

I thought it was a good comment and my answer is a bit longer than a normal comment, so I thought I’d draft a post about it not only to share my thoughts, but also to allow others to chime in, as well.

After all, half the reason I end up thinking through some of the things that I do comes from opinions shared in the comment stream, in related Tweets, and so on.

Continue reading

One of the points of discussion that often comes up among software developers is how to best organize code and files within a project.

Some frameworks enforce for you to follow an organization scheme – such as Rails which prizes “convention over configuration” – and then other foundations, like WordPress, have standards for certain things – like markup and PHP – but don’t have standards for other things.

For example, there’s no real standard on how to name your stylesheet or JavaScript directories. There’s no standard for where libraries should be kept, nor is there a standard for where preprocessed or pre-minified files should be kept.

Sure, most of us have opinions on this, and developers often spend a lot of time (perhaps more time than they’d like to admit) thinking about optimal ways to organize this information, whereas others are happy to dump things in a directory and as long as the project has some semblance of organization (even if it makes sense only to them), they’re good to go.

Granted, there are personality traits at play here, but I digress.

I’m of the former case where I prefer to try to make sure things are highly organized – perhaps to my own detriment – and I try to bring the idea of “convention over configuration” to work I do within plugins and themes.

And though I spend more time talking about plugins, general practices, and other topics here, there are a few guidelines that I’ve been following as it relates to WordPress theme development that I’ve used in both my own projects as well as contract work.

Continue reading

Over the past couple of years, I’ve written a number of articles about using design patterns in WordPress. One that I’ve written about a number of times has to do with the Singleton Pattern.

Although I’m not really expecting anyone to spend time reading through the following list, some of the articles and/or comments that discuss the pattern include:

• An Introduction to the Singleton Pattern
• Properly Instantiate a WordPress Plugin
• Instantiating WordPress Plugins
• Object-Oriented WordPress Plugin Development

The funny thing about blogging is that when you’ve written something two years, one year, or even six months ago, you may not feel the same way as you did when you initially wrote the post. And that’s fine – as far as I’m concerned, it’s an indication of professional growth (or just getting better at what you do).

So with that said, I don’t use the singleton pattern as much as I used to the reasons for which are a topic for another discussion. Instead, I was recently talking with a good friend about implementing the singleton pattern within the context of a WordPress plugin and the discussion really came down to this:

Should plugins that implement the singleton pattern be instantiated in a hook?

Make sense? Continue reading

One of the greatest strengths that’s offered to designers and developers who work with WordPress is the ability to use just about any client-side technology that we’d like. That is to say that for anyone who is working on building themes has the ability to chose from a seemingly endless number of frameworks, libraries, tools, and so on.

Off the cuff and in no certain order, we have technologies like:

• Bower
• Bootstrap
• Composer
• LESS
• Foundation
• Sass
• Grunt
• Any number of jQuery plugins
• Backbone.js
• CodeKit
• …and so on forever and ever.

Continue reading