Kaizen and WordPress

According to Wikipedia, kaizen is defined like so:

Japanese for “improvement” or “change for the best”, refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, business management or any process.

Generally speaking, this is used to talk about the continuous improvement of a product. It’s also a core idea of lean manufacturing that has also been adapted into lean software development.

Anyway, the idea isn’t anything new and I honestly think now, more than ever, more people are familiar with the idea (even if it isn’t practiced) than ever before especially because some applications use the word in the release notes for their application.

Kaizen in Paper By FiftyThree

Paper By FiftyThree mentions it with nearly every release.

As far as building products is concerned, this is something that I think many designers and developers want to do (if they aren’t already doing it, of course), but it are sometimes hindered by the nature of their environment.

By that, I mean that can we do continuous improvement – that is, can we practice kaizen – on projects that aren’t deployed on any type of particular schedule?

How We’re Planning The Next Iteration of the WordPress Plugin Boilerplate

Months ago, I announced that there was going to be a major update to the WordPress Plugin Boilerplate.

Because of its nature in being a hobby project, because this project is something that’s being worked on by a number of contributors, and because the next iteration is going to be a major rewrite of what we have so far, it’s taking a while to begin pushing code for the new Boilerplate.

But there are a lot of neat things coming, and I think that even if it’s taking us a while to get something on GitHub, it’s worth providing updates as to where we currently stand with the project.

Using LighthouseApp For WordPress Issues

One of the things that I love about GitHub is how they’ve done a great job integrating source code, milestones, tickets, pull requests, and so on.

But if you’re working with WordPress, not all projects all on which you work will use GitHub.

Case in point: If you’re selling a theme on WordPress.com or if you’re working on a plugin that is hosted in the WordPress Plugin Repository, then you’re going to be using Subversion as your source control system. But this doesn’t mean that you have to sacrifice the work flow of milestones, tickets, and so on.

It just requires that you use a third-party solution. For example, for the past couple of months, I’ve been using LighthouseApp as my issue tracker of choice for Mayer.

Two Versions of WordPress Themes (“Is It Worth It?”)

When it comes to selling a theme for both WordPress.com and for self-hosted installations, one of the questions that I find myself asking is:

“Is it worth maintaining two repositories for the same theme?”

And I wonder this because when it comes to maintaining a codebase of a theme on WordPress.com and a version for the self-hosted version of WordPress, you can make the case that there’s no need to have a difference in the version of the themes.

But for anyone who has worked in both variants of WordPress, then you know there’s actually little bit in variation.

Managing Email with Flywheel and Pobox Email Forwarding

Late last year, I migrated this site to Flywheel for managed WordPress hosting (which I talked a little bit about in this post). I’ve been incredibly happy with them for a number of reasons, each of which I cover at a later time; however, one of the features that they do not offer is email hosting.

Straight from their support channel:

At Flywheel we believe strongly in working with “best of breed” providers for everything we do, and we view ourselves to be a “best of breed WordPress host.” As such, we do not currently host email for our clients. We make a deliberate effort to focus on building a great WordPress hosting environment – and being the absolute best at it.

I love the mentality and the vision they’re after, but this does leave us needing to look for an alternative host.

They mention Google Apps, Zoho Mail, and Rackspace Email as alternatives, but the last thing that I wanted to do was setup yet-another-email-address.

I have a handful of email addresses all of which forward to a single Gmail box that allow me to respond from the address to which the email was sent, and I wanted to duplicate that for this particular domain.

So I tried one of the recommended solutions for a couple of months, and I couldn’t get it to jive with my workflow (for a number of different reasons, none of which I’m covering here).

This ultimately lead me to try out Pobox.

The Third Version of Live Theme For WordPress

Comments are closed on this post. Please leave comments on the original blog post.

About four years ago, I had the pleasure of working with a team to help deliver the first iteration of Live Theme for WordPress; however, as the team leaned out, changed directions, and paired down our product focus, we sold the product to someone else for continued development and maintenance.

To make a somewhat long (perhaps even boring) story short, I’m currently working on the third version of Live Theme for WordPress.

How to Set an SMTP Server in WordPress

When it comes to sending emails in WordPress, the wp_mail function and its related filters such as wp_mail_content_type, wp_mail_from, and wp_mail_from_name are usually enough to accomplish the majority of what we need.

But there are times where it’s not enough. Specifically, there are times where we may need to define the details for using a custom SMTP server in WordPress.

Fortunately, WordPress provides a hook that makes this really easy to do.

How Not To Market WordPress Products (or “Why Customers Don’t Care”)

If you’re any sort of a WordPress developer, then one of the things that you’ve no doubt noticed is how we market our work.

I’d say that it can be divided into two camps:

  1. You have the developers who promote the features, design, and options that the theme or plugin offers.
  2. You have the developers who promote all of the things that have gone into the theme as to what makes it significant.

When it comes to marketing WordPress themes or plugins (or any product, for that matter), then the first group has it absolutely correct.

The second group, on the other hand, can take a few cues from the first group – namely, stop trying to market your WordPress products based on the tools and technology that were used when working on the project.

Dealing with Custom Post Types, Taxonomies, and Permalinks

Comments are closed on this post. Please leave your thoughts on this original article.

One of the most confusing aspects of working with WordPress is managing its rewrite rules. For anyone who has taken a dive into the Rewrite API and looked at how it works, and how to customize it to fit your own needs can vouch for this.

Honestly, if you’ve ever done any work with custom post types, taxonomies, and permalinks and worked with the rewrite parameter (or perhaps have left it out), then you’ve experienced a little bit of the confusion (or frustration, perhaps) that can come with it.

For those who have been wrestling specifically with the latter, I wrote up a short guide for making sense of this occasionally confusing aspect of WordPress.

An Example of How To Remove Empty HTML Tags

One of the most tedious aspects of building WordPress themes is customizing and styling the comments template. This includes not only the comment form and the pingbacks, but the response text, as well.

Don’t get me wrong: It could be worse, and after you’ve done it a few times, it’s likely that you’re going to use many of the same strategies that you’ve used in previous themes or templates.

But there are examples in which certain elements will render as empty HTML tags. If you have given those tags a specific, say, background style then it can really create somewhat of an ugly experience for your readers.

The challenge, then, comes at being able to remove empty elements before the user can see them. But there’s a catch: It can’t be done on the server side because the server side sees the HTML as you would expect it to be rendered whereas the browsers take the liberty of parsing the document and adjusting the markup so that it’s a bit more semantic.

At least that’s what most of them try to do.

Anyway, this can cause some unintended side-effects.