Articles

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Publicly Display Post Meta Data in WordPress

Comments are closed on this article. If you have something to add, please do so on the original article!

A couple of weeks ago, I shared a simple plugin that added a meta box to the post editor dashboard screen that demonstrated how to display post meta data within WordPress. After it was released, I received a few questions as to how one would go about displaying this information on the frontend of a WordPress blog.

That is, how would one go about displaying the post meta data as part of the content for a single post (or post type) in WordPress.

Though I’m not necessarily a fan of doing this, I am a fan of giving other developers practical advice on how to extend existing plugins (using practices used throughout an existing plugin), and I’m also a fan of discussing why I am a fan or not a fan of doing something.

So in my latest article at Tuts+ Code, I did exactly that.

Does WordPress Encourage Poor Programming?

If you hang around any group of programmers long enough, you’re bound to get into a discussion as to which language is currently the best language and why that’s the case.

Well. Then again. Maybe not.

I’d say this is true is some cases, but I’d venture to say that if you’re hanging around a group who has been at it for quite some time (read: at least a decade or so), you’re going to have discussions as to what features of what languages are nicer in contrast to features of other languages.

A more mature discussion, right? At least a little.

But then you take this one step further: You sit and chat with a group of people who have been working on the same platform or framework for a while and you may find yourself in a discussion about what features of a given framework has that are better than its alternatives..

Perhaps a better way of putting it is: You may end up discussing why one language, framework, or set of tools encourages better programming practices than any other given set of languages, frameworks or tools.

You know you’ve been there when you can quickly list off several reasons, say, Python programmers prefer white space, Rubyists prefer unit testing, Rails developers appreciate MVC, jQuery developers like method chaining, JavaScript programmers love the prototypal inheritance, and Smalltalk programmers love how few of them exist (I kid, I kid).

On a more serious note, there’s no shying away from the fact that people either love or hate PHP. Sure, there’s middle ground but there’s no fun in taking a stance there so you don’t read many articles on people simply saying “Yeah, I think PHP’s okay.” But when it’s used in the context of another framework like CakePHP or Laravel, then you’re likely to find something different.

So ultimately, I think it’s worth asking the question, does WordPress encourage strong or poor programming practices?

The Embarrassing Nature of Modern WordPress Products

As far as WordPress projects are concerned, I’m far more comfortable talking about projects that I’ve been working on myself regardless of if they are for fun or profit.

And yes, there are times where I’ll share code and other snippets that come from contract work, but I generally do not talk about those types of projects out of respect for the client and/or out of respect for the terms of our agreement.

Contracts, respect, professionalism, and all that fun stuff.

The Disenchanted Young Professional

The Disenchanted Young Professional

But there’s been a project that I’ve been a part of for a few months now, and I received an email last week that struck a chord with me. I asked the client if I could share the quote – keeping them anonymous of course – but use it to try to make a point.

They obliged.

I hate trying to support a theme that’s so dated and broken. I can hardly wait until I can offer support for a theme that I am proud of and is coded well and will be kept up-to-date.

And though it’s already been referenced through a number of different blogs, and the article is already over a week old (which is, you know, practically forever in Internet time), I couldn’t help but think: “We’re ruining WordPress.”

You may or may not think of it as hyperbole, but this is a very real problem.

All of the Options in the WordPress Theme Customizer

I’ve written a little bit about the WordPress Theme Customizer in a number of previous posts primarily because I think it’s one of the best features that has been introduced into WordPress in a long time (of course, this isn’t meant to downplay any of the work that’s been done since ;).

To be clear, I’m a fan because it takes a significant amount of guesswork away from the end user allowing them to see the results of their changes almost immediately versus, say, having to tab back and forth between the settings in the dashboard and the public-facing view of the site.

The WordPress Theme Customizer

Couple that with additional changes introduced in more recent versions such as being able to add and remove widgets from within the customizer and improvements to this particular experience in the pipeline for a future release (such as 4.0), then you’ve got a nice feature that’s only getting better.

It’s evident that the same problems that have plagued us in one part of the application are migrating elsewhere in the application.

I’m sure this is something that happens in any language, framework, foundation, library, or platform, but if you’ve specifically been with WordPress for the last few years, then you’ve seen this happen.

Getting Started With WordPress

Last week, I had the opportunity to answer a question that I’ve often gotten via email, Twitter, meetups, and so on:

How do I go about getting started with WordPress?

It’s a simple question, to be sure; however, for those of us who are actively involved within the WordPress economy – or for anyone who has been involved in any development community, then you are more than likely familiar with how easy it is to forget what it was like getting started with the platform.

To that end, I wanted to provide some practice tips for how to do exactly that for the absolutely beginner.

We’re Ignoring the WordPress Philosophy: The Bill of Rights

Over the last week or so, I’ve been writing about the various pillars of the WordPress Philosophy.

These include:

And today, I finally finish up with the Bill of Rights.

The WordPress Philosophy

Ultimately, I’ve been looking at how I believe that the majority of us who are involved in driving the WordPress economy in some way have been ignoring these core tenants.

This isn’t to say that we’re all doing it, and this isn’t to say that they’re all being ignored, but I do believe that there are some significant issues that are happening within the WordPress product space that need solutions.

This isn’t to say that I have it figured out – hardly so – but I do believe that one of the things that many of us need to do is to begin forcing segmentation in the market based on how we price, support, and offer our products.

The final aspect of the philosophy to cover is that of the WordPress Bill of Rights. I almost opted not to write about this particular part because it’s directly influenced by the GPL which always has been, and always will be a fire starter of sorts for the WordPress economy.

Even still, it’s part of the philosophy and should be included.

We’re Ignoring the WordPress Philosophy: The Vocal Minority

For those who have been following along, the purpose of this post should come as no surprise: I’m going to be talking about another pillar of the WordPress Philosophy.

Specifically, I’m going to be talking about The Vocal Minority which, in my opinion, is arguably the least discussed, and the least shared among all aspects of philosophy. That doesn’t make it any less important, though – it just means that we, as those who are involved in the WordPress economy, have more with which to familiarize ourselves.

The WordPress Philosophy

Then again, to be fair, there are probably those who are just as familiar with this particular aspect of the philosophy as they are as much with the rest of the philosophy – and that’s great!

But remember: We’re primarily looking at how we can take the philosophy and not only how it applies to WordPress, but how we can apply it to the products that we’re building on top of it.

So the vocal minority – what does that even mean?

We’re Ignoring the WordPress Philosophy: Deadlines Are Not Arbitrary

When it comes to writing software – regardless of the type – it seems as if it’s always easy to get the first 80% done. This isn’t a new problem, either. You may have also heard it stated as:

80% of the work is done 80% of the time.

Or some variation thereof.

But anyway, when it comes to a project like WordPress – which is software – and it comes to projects being built on top of it – which are also software – then it stands to reason that they are subject to falling into the same trap.

And they are.

This is why this particular aspect of the philosophy is so important.

The WordPress Philosophy

Of course, for anyone who has followed not only WordPress but who have worked on projects that sit on top of it as a foundation, then you know that deadlines have slipped and work that we do does miss deadlines.

There are so many different reasons that people can list for this that an entire series of posts could be written about each one in and of itself. That doesn’t mean that this part of the philosophy is being ignored, nor that we should treat it lightly.

If anything, I think it builds a stronger case for why it’s needed.

We’re Ignoring the WordPress Philosophy: Striving for Simplicity

When you look around the world – both online and offline – it appears as if the world is beginning to value simplicity more than it has in a very long time.

By this, I mean that the way that things are designed: From billboards or magazine covers, to the minimalistic approach of interior decorating, all the way down to the interfaces on our phone. On top of that, I think that we’re collectively beginning to understand that simplicity is not necessarily an antonym for complexity – instead, it’s a way that functionality can be achieved such that it’s easy for the consumer.

Complex operations happen all of the time through the use of simple actions. Think about what happens when you turn the key to your car, press the power button on your computer, and so on.

The neat thing is that WordPress values simplicity to the point that it’s included within its very philosophy. And for the past few articles, I’ve been writing about the WordPress philosophy and how we – as people who help to drive the WordPress economy – are disrespecting the philosophy.

The WordPress Philosophy

I want us to turn that around.

First, if you’re just catching up, be sure to read the previous articles in the series:

With that said, let’s talk about simplicity.

We’re Ignoring the WordPress Philosophy: Clean, Lean, and Mean

Over the past week or so, I’ve been looking at each of the pillars of the WordPress Philosophy – many of which I think that we, as developers and designers, have completely ignored in our work – and have been talking through what is says, what we’ve done, and potential ways that we can correct it.

Up to this point, I’ve covered:

There’s obviously more to come since the philosophy encapsulates more than just those three. So I’m going to continue moving forward with “Clean, Lean, and Mean,” which is arguably one the pillars that’s talked about the least.

The WordPress Philosophy

I say that because when you talk to other people about WordPress or building things for WordPress, they are generally familiar with some of the ones mentioned above (and some not mentioned yet), but this is not only one that you don’t hear much about, but this is one that I’ve think many of us have just completely disregarded.