By their nature, WordPress themes are open source. Whether or not you want to be is kind of a moot point because anything work that is a derivative of a GPL-based work must be licensed as GPL, as well.

WordPress is GPL, thus plugins, themes, and any other work that’s built on top of it should be GPL’d, as well.

When you’re working on a plugin or a theme or any other project, this doesn’t mean that you have to have the repository open. By that, I mean you can work on the code in a private repository on GitHub and, when the product is ready, have it released as GPL and then share it with users, customers, and so on.

Such a great open source contributor.

Honestly, though, unless you’re running some type of hosting platform where people sign up for the service and install themes (think WordPress.com or Evermore), then they have to get the source code anyway in order to install the theme on their server.

Nonetheless, I still feel like there’s a little resistance when it comes to working on a theme (or a plugin, even) in a public repository where anyone and everyone has the ability to fork it, open issues, offer suggestions, issue pull requests, and so on.

Continue reading

Niche WordPress themes is regular of topic of discussion for those involved in creating themes for WordPress. Discussions range from debating whether or not niche themes are dead all the way to why niche WordPress themes continue to be one of the ways to create something unique for WordPress.

Regardless of where you fall on the topic, niche WordPress themes currently exist – and need to be maintained – and will likely continue to be created for the next few years.

One of the challenges that comes with creating niche WordPress themes is how to manage certain aspects of WordPress that are typical for standard publishing themes but aren’t necessarily required for niche WordPress themes.

Continue reading

When building things for the web, we normally refer to “the stack” as the set of software that we use that powers an entire application. Generally speaking, this usually consists of three things:

1. The database
2. The application layer (or the server-side programming language
3. The front-end

Today, there are many different types of data stores available: We can use anything from a traditional database to using a document-based database system, or some type of abstraction provided by another service like Amazon.

For the application layer, we can have Rails, PHP, .NET, Python, and who-knows-how-many-more. And for the front-end, we generally use HTML/5, CSS/3, and JavaScript (and variations thereof).

But if a stack usually refers to a set of languages, tools, or technology that goes into building something, and each area of an application can be further divided into subsets (like with the front-end), does it make sense to have terminology for each of these areas as well?

Continue reading

There’s this perspective in the WordPress development community that results in a bit of divide among those who are involved. Granted, this is not the only perspective – it’s one of many – but it’s one that prevalent enough that most anyone who spends any amount of time chatting with peers online is likely to stumble across:

• Bad: Themes with a lot of options and features.
• Good: Themes without many options or features.

I’m oversimplifying this a little bit because the truth is not everyone thinks a theme without many options is a good thing (though we do love to get behind the “Decisions, Not Options” philosophy). Instead, it’s more like:

• Bad: Themes with a lot of options
• Good: Themes with a few options
• Weird: Themes with no options

Maybe “weird” isn’t the right word, maybe it is, but it’s a lot more concise than saying “something that doesn’t really fit between these two,” isn’t it?

To be clear, I’m not defending the idea that it’s okay for themes to have a lot of features and a lot of options and and a lot of proverbial knobs to turn, but I do question is it really productive continually talk about it?

Continue reading

When working with arrays in PHP, specifically in the context of WordPress (which is obviously the norm around here), it’s become pretty common to see code using the foreach construct versus a vanilla for loop when working through an array.

Personally, I think it’s easier to read and that it works especially well when working with an associative array. That is, it’s really useful when you need to iterate through a collection that’s indexed with a unique set of keys that aren’t necessarily in numerical order (which is something you’re more like to see in a for loop).

Most who have been working in WordPress, let alone PHP, for sometime are likely familiar with everything that’s just been said. That is, when it comes to working with a collection, it’s easy to think

“Okay, so I’ve got a collection of information and I need to iterate through it. Working with a `foreach` loop is easy because it will allow me to traverse the list just like a `for` loop without having to initialize a variable, set an upper limit, and increment the iterator.”

Granted, maybe that’s a bit of a mouthful – maybe we just say “foreach loops are easier” – regardless, there’s another way that we can think about using language constructs like this.

That is, rather than think of them as ways to simply iterate through collections of data, we can also think of them as ways that inform the decisions that we make when building a user interface.

Continue reading