Tag: WordPress (Page 146 of 219)

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

Recently, Stephen shared an interesting site with me – User Onboarding – in which, as the site states, seeks to do the following:

User Onboarding is the process of increasing the likelihood that new users become successful when adopting your product.

Learn some lessons from how popular web apps do it!

It’s a really simple, straightforward site that highlights how various applications sign up, sign in, and continue using a product. Not only that, it also looks at what’s bad about the process, too.

In short, it’s a great site to peruse (or to throw in your RSS reader) if for no other reason to check out some of the ways in which other companies attempt to garner customers.

But principles, by nature, tend to be transferrable (not always, but many times). This means that some of the lessons explored throughout the various teardowns the site does are applicable to onboarding users with WordPress.

Continue reading

Last week, I shared a few thoughts on how I think that major updates to an existing WordPress theme are actually more analogous to a new product rather than an update of the existing product.

That is, if a theme is identified by the way it presents the content of the blog, then it stands to reason updating the look and feel of the theme is changing the very thing that gives the theme its identity.

So, from there, it’s reasonable to ask the question: Once a theme’s design is locked in, should it ever change?

Continue reading