Page 286 of 433

The Beginner’s Guide to Object-Oriented Programming in WordPress

March 14, 2014 / Tom

Comments are closed on this post. Please keep the discussion on each article in the series.

When it comes to writing code for WordPress, I’ve been told that I come off as someone who espouses object-oriented programming as the way to write code for WordPress.

Within theme development, that definitely isn’t true, and when it comes to plugins, it’s true only when the plugin has more than than a few functions or few moving parts that are needed to get work to done.

But one of the things that I’ve noticed in speaking with other developers is that people those who aim to start out writing object-oriented code with WordPress are kind of figuring it out as they go.

Though doing this can yield some positive results, it may also end up preventing you from learning some more of that basic techniques – or even some of the more advanced techniques – that object-oriented developers users in their day to day work.

So in my latest series on Envato, I’m working on series targeting the absolute beginner who wishes to learn object-oriented programming, and to do so within the context of WordPress.

How to Sort an Array by Locale in PHP

March 13, 2014 / Tom / 0 Comments

As easy as it is to translate content within WordPress, there are times in which some of the content in the database may be different than the original locale of the site.

Say, for example, you’re running a site that includes a list of names in a flavor German when your server (or even perhaps your site) is based on an English locale. The goal is to read the names into a collection – rather, an array – and then sort them alphabetically.

Obviously, different locales have different alphabets so what works in, say, the United States won’t necessarily work in Germany.

There are a couple of ways to go about handling this, but the easiest way that I’ve found is to use PHP’s Collator class.

Passing Variables in WordPress: Loops

March 12, 2014 / Tom / 0 Comments

Check out the first post on passing variables in WordPress using WP_Query.

In the previous post, I shared how I used to use the following rule of them when passing variables in WordPress (and other programming languages, really):

“Only if I need to use this value more than once, then I will store it in a variable.”

And though I still think it’s a fair rule to follow, there are exceptions.

The more time I’ve spent writing code and having to maintain codebases from both myself and others, the more I’ve appreciated having variables defined – even if they are used only once – that hold more complex information for the sake of readability, clarity, and maintainability.

In the last post, I looked at an example as it relates to `WP_Query` since it’s one of the more powerful aspects of the WordPress API, but I’ve found that the same is true in simpler complex such as loops.

Passing Variables in WordPress: WP_Query

March 11, 2014 / Tom / 0 Comments

Check out the second post on passing variables in WordPress in loops.

One of the most minute aspects of writing code is opting when – or when not – to use variables.

It sounds like a trivial decision, right? And in some respects, it is, but the longer I’ve been writing code (or, perhaps a better way to put it), is that the more code that I’ve written and had to maintain, the more my opinion has changed on how frequently I use variables.

After being in the industry for a couple of years, I tried to follow the this rule of thumb:

“Only if I need to use this value more than once, then I will store it in a variable.”

And I still think that’s a decent rule of thumb, but the more I’ve worked with systems that, say, interface with a database, or that leverage multi-dimensional arrays, or that some type of iteration (be it an each iterator, a foreach iterator, or something similar), the more I’ve found how storing a variable – even if it’s only going to be used once – can make for slightly more readable code.

Coding Standards and Guidelines (“When in Rome, Program Like the Romans”)

March 10, 2014 / Tom / 0 Comments

Recently, I was talking with a fellow developer about the various strategies there are for writing code.

By that, I mean we’ve got a number of different paradigms such as object-oriented programming, functional programming, and procedural programming. We’ve got design patterns, strategies, ideas like SOLID, domain-driven design, aspect-oriented programming, and so on.

When it comes to these things – and as with most things – developers can be really opinionated (myself included) about which things are the best to use. To some degree, I think that there’s some part of us that wants to believe the thing that we’ve just learned is “the next great thing” as it relates to writing code.

Maybe that’s an amateur’s mistake, though. I mean, that’s how I felt earlier in my career – I remember whenever I learned, say, domain-driven design and all of the stuff that comes with it, I wanted to implement in all of my future projects because I thought it makes the code so much more readable.

But over time, my opinions have changed.

Sure, I still really like certain aspects of all of the aforementioned programming techniques, but I also know that I can’t apply them all in what I’m doing.

Tom McFarlin