Tag: WordPress (Page 135 of 219)

When it comes to working with WordPress themes and plugins, there’s a general rule of thumb that most experienced designers and developers follow:

Themes are for presentation, plugins are for functionality.

Sure, there’s a little bit of blurring of lines, but this is the goal for which we strive when working through our code. And yes, there’s a lot that can be said (and has been said) about themes that include a ton of features, options, bundled plugins, and so on, but that’s not where this is going.

Instead, I’ve been thinking about how this relates to general theme development, niche theme development, and using WordPress as a platform for application development.

Continue reading

One of the things that I think is easy to forget about working within the WordPress space is that we’re often talking to a circle of [many of] the same people. By that, I mean that developers are largely talking to other developers (and likely some designers), designers are talking to other designers (and likely some other developers), and so on.

I mean, I have no expectations that anyone who reads this blog is outside the scope of someone who writes or wants to write WordPress code.

And though there’s nothing inherently wrong with this – I mean we’re naturally all about creating groups and communities – I think that it can negatively influence how we may be marketing our products or even discussing our work with other people.

In fact, I’d argue that one of the biggest problems that we have as it relates to marketing our WordPress projects is the fact that we use phrases “clean code” or something similar when trying to sell others on our work.

Continue reading

Most experienced WordPress developers will likely make the case that themes are for presentation and plugins are functionality. I agree with this and it’s something that I try to take into account with each project that I work on.

That is, whenever I have a project that consists of some unique functionality, then I’ll build out said functionality into a plugin and then either advise the customer or the user of the theme to download the plugin (for which there are some great tools available for this) or I’ll include it in such a way that the theme will include it and activate it.

Honestly, I’m not a big fan of the latter – it assumes the user doesn’t already have a version of the plugin installed, it creates a dependency that’s harder to manage, and it’s activating something that the user may not want activated even though we may see it as something that’s crucial for the site to function properly.

This is something that could probably be argued ad nauseam and though that’d make for a lot of fun in writing up a blog post and chatting in the comments, that’s not the purpose of this post so I digress.

Instead, it’s to offer up the idea that perhaps there are shades of gray as it relates to building specific functionality for highly niche themes.

Continue reading

If you’re ever interested in getting into WordPress plugins, then there’s a wide array of material available for you to read – this includes material across who-knows-how-many blogs, people on Twitter, and even physical books available on Amazon or likely your local bookstore (well, maybe – heh).

But when it comes to building and maintaining a free plugin (let alone several), I’ve found that there’s not as much discussion, sharing, and overall dissemination of information available. To that end, I thought it might be worth looking at four things that I’ve found useful when maintaining free WordPress plugins.

Continue reading

A few years ago, I was working on a WordPress theme that had some really cool features (if I can say that without sounding as if I’m bragging). The features were brainstormed by a team and gathered through feedback through a number of customers and users, and all were implemented over a long period of time.

When the time came to actually release the theme, it proved to be worth it – it was well-received.

As with any product, we then went into maintenance mode doing the usual round of fielding bug reports, features requests, and so on, and then continued maintaining the product with periodic releases in order to provide bug fixes, minor feature updates, and so on.

Generally speaking, it was great. There was a lot to be proud of and things were going well.

But, as with anything, things couldn’t continue on the up and up forever and during one of the releases, I neglected to remove a line of code that was intended only for the development environment.

We shipped it.

And it negatively affected all of the customers who applied the update.

Continue reading