Category: Articles (Page 224 of 258)

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

The Danger of Third Party APIs

August 15, 2013 / Tom / 0 Comments

Generally speaking, the majority of the work that I do with third party APIs is done so in the context of WordPress, but the truth is that what I’m about to say is subject to whatever platform you’re work with – be it .NET, Rails, COBOL, or whatever you or your dad maybe using :).

But a feature in Standard recently quit working because of an underlying change in a third party API. Now, to our credit, we normally do a good job with following blogs and release notes when an API is going to change.

In this case, there was no documentation on any of this – something just stopped working, so we needed to dig in and fix it. The fix is under testing and will be released later, but the point that I’m trying to make is that there is always a danger in working with third party APIs.

WordPress Directories: inc and lib

August 14, 2013 / Tom / 0 Comments

In the previous post, I spoke briefly about WordPress directories. Specifically, I talked about placing files in an `inc` directory whenever building a theme. This lead to a comment by Richard that I thought was worth covering here:

In the theme folder, sometimes I see people use “lib” to include theme assets and other times I see them use “inc”, as you’ve done here. Is there a reason for one vs the other?

I gave a short response in the comments, but thought that this warranted a longer form explanation to share my perspective, and to hear what you guys have to say, as well.

Not Everything Can Be a WordPress Plugin

August 12, 2013 / Tom / 0 Comments

One of the things that I – and most developers, designers, and implementors – love about WordPress is how easy to is to implement new functionality through the use of plugins.

Yes, I’ve shared at length my thoughts on the plugin economy and it’s not coming from a point of disdain. Of course not. It’s coming from a place of appreciating something, wanting to see it being made better, and simply sharing gaps in experience.

But a second thing that I’ve begun to notice is that people want plugins for everything – even things that I believe should remain core business logic.

Save Time with WordPress Shortcuts

August 7, 2013 / Tom

Comments on this post have been closed. Please leave your comments on the original article!

Earlier this week, I had the pleasure of being featured on the ManageWP blog with some other fantastic writers, developers, designers, and bloggers all of whom opted to share their favorite WordPress shortcuts, tools, and tricks for getting their work done faster.

Overall, there were 28 people who were featured all of whom had some great things to say.

Some Thoughts on Design Patterns in WordPress

August 6, 2013 / Tom / 0 Comments

A few months ago, I did a series of articles on Design Patterns in WordPress that was meant to provide an introduction to object-oriented design patterns, and how they can be used when developing projects on top of WordPress.

When it comes to working with WordPress, code is normally written one of two ways:

Procedural
Object-oriented

For procedural programming, think of `functions.php` in theme development, and for object-oriented think of plugins. This isn’t to say that procedural programming isn’t used in plugins – it often is (case in point: Markdown Code For WordPress) – but so are object-oriented techniques (see the WordPress Plugin Boilerplate).

In short, decide patterns exist for a reason: They are proven solutions to common problems that appear in software development.

Yes, they may have to be tweaked a bit for a given situation, but the definition, structure, and so on remains the same. The thing is, I don’t often see many design patterns used throughout WordPress product development.

To be clear, I’m not talking about WordPress core, I’m talking about products built on top of WordPress. Perhaps I’ve just not done enough digging or paid enough attention to some of the work that’s out there, but I think if we – as developers – spent time working on implementing design patterns in our work, projects could have much more longevity rather than devolving into spaghetti code that’s so often found in WordPress work.