About two months ago, I wrote about the usability of WordPress featured images.

Though nothing has changed in the last few months, there has been one use case that I find leans in the direction of supporting featured images despite their potential improvement for usability. Specifically, it deals with using the Related Posts feature of Jetpack.

Related Posts without Featured Images

For those who are new to WordPress or this specific feature of Jetpack, Related Posts makes it really easy to add links to similar posts at the end of each post:

The Related Posts feature scans all of your posts, analyzes them, and lets you show contextual posts your visitors might be interested in reading after they’re done with whatever post they’re on.

Nice, right?

Continue reading

For years, the whole “doing_it_wrong” meme has permeated the WordPress development community. Generally speaking, I think that it’s been toned down quite a bit in the last year or two and I consider that a good thing, but recently I’ve begun to see people say they are being chastised for not doing things “the WordPress way.”

Granted, this may be something that’s been going on for far longer than I’m aware, but the fact that it’s beginning to reach a point at which we’re seeing a number of different people share this feeling in blog comments is, at the very least, interesting (if not a bit disconcerting).

Honestly, I’m of two minds about it: Telling someone they are “doing_it_wrong” is negative – it’s condescending. And perhaps telling people they aren’t doing it “the WordPress way” is just a flip side of the same coin, but I also think that it just has a more positive, approachable spin to it (depending on how it’s shared, I guess).

Whenever anyone starts off a discussion with a negative then proceeds to tell you why you’re wrong, you can’t help but feel a bit defensive and possibly even offended.

Using a more positive approach yields better conversation, doesn’t it?

And I think there’s something about “the WordPress way” that is more accessible and approachable. Though it still indicates that something isn’t being done correctly, it does come with the implication of “this isn’t the WordPress way, here’s how you should be doing it, and here’s why you should be doing it this way.”

And in that respect, it does matter whether or not we’re doing something correctly within the context of our software.

Continue reading

There are a number of different ways that you can setup a debugging WordPress projects. It may be in the form of an IDE, it may be in the form of another application like MacGDBp, or it may be in the form of using something that fits your workflow.

Whatever the case, when a project reaches production, you normally don’t have access to any of the above. Instead, you’ve access to error logs. Obviously, they’re really useful when needing to, say, follow a stack trace for any given warning or error.

Sure, it sucks not being able to attach a debugger to your code on the server-side and then trace where the problem is, but given log files and pouring over enough information, you should be able to (well, at least hopefully) reproduce the error in both development and staging.

As such, I think it’s valuable not only to have quick access to error logs for WordPress in your staging environment but in your development environment, as well.

Continue reading