The point of the post was to state that when you’re working with URLs and you’re looking for the last index of the array, the only way to guarantee the it’s always at the final position is if there’s a trailing slash so that you can explode on the ‘/’ character.

This post lead to some good discussion about why or why not to use trailingslashit, it brought to light to some other important and useful functions, and actually reminded me that there are times when trailing slashes should be used and when they shouldn’t.

To that end, I thought I’d thought I’d do a more thorough explanation as to each of the “trailing slash” functions WordPress offers, their purpose, and why trailing slashes are even important in the context of URLs.

The Trailing Slash in WordPress

As I mentioned earlier, using the trailing slash in WordPress is something that can provide benefits especially when it comes to locating the last index of the array.

The thing is, there are actually three different functions (at least, that I’m awareof) that deal with trailing slashes. On top of that, there’s a time and a place when when should include a trailing slash and when we shouldn’t.

When should we use a trailing slash in WordPress?

This is actually a question that can be more generalized that just WordPress. In fact, you could simply ask: “when should be use a trailing slash.”

The short answer is this:

• If your anchor is linking to a directory, then use a trailing slash.
• If it’s linking to a file, do not use a trailing slash.

Easy enough, right?

To that end, there’s actually more reading on this if you’re interested in the technical reasons for this. First, the Google Webmasters blog provides a good, short article on the topic. Secondly, the Wikipedia article on URI’s – or uniform resource identifiers – provides a much more technical piece on URL structures.

How do we remove a trailing slash in WordPress?

Before answering this question, I want to give Antonio props for bringing up this alternative scenario in the comments of the previous post.

untrailingslashit in WordPress

In short, if you’re looking to guarantee that you will not have a trailing slash on the URL using the WordPress API, then take advantage of the untrailingslashit function.

Just as the Codex mentions:

Removes trailing slash if it exists.

But that’s not all. There’s a short note that the Codex also states that should be recognized:

The primary use of this is for paths and thus should be used for paths. It is not restricted to paths and offers no specific path support.

This means that if you’re trying to follow the best practices of using a slash for directories and no slashes for files, then using this function could have unintended consequences. Namely, it will remove the trailing slash from all URL’s that it’s given.

And how do we add a trailing slash in WordPress?

I covered this last week, but in order to be complete, I thought it may be worth summarizing again here in this post.

Simply put, if you’re looking to guarantee that you do have a slash at the end of the URL, then checkout the trailingslashit function in the WordPress API.

trailingslashit in WordPress

Practically speaking, this is the inverse of untrailingslashit. First, just as the Codex mentions:

Appends a trailing slash.

It also provides the same note that it’s inverse function offers:

The primary use of this is for paths and thus should be used for paths. It is not restricted to paths and offers no specific path support.

For those of you who are curious, trailingslashit actually uses untrailingslashit to remove any trailing slashes before adding a new one.

What is user_trailingslashit?

user_trailingslashit is an API function that WordPress provides that makes sure that the format of a given URL matches the settings that the user has configured in their settings.

At the time of this writing, I could not find a Codex article about this particular function; however, the code comments offer the following:

/**
 * Retrieve trailing slash string, if blog set for adding trailing slashes.
 *
 * Conditionally adds a trailing slash if the permalink structure has a trailing
 * slash, strips the trailing slash if not. The string is passed through the
 * 'user_trailingslashit' filter. Will remove trailing slash from string, if
 * blog is not set to have them.
 *
 * @since 2.2.0
 * @uses $wp_rewrite
 *
 * @param string $string URL with or without a trailing slash.
 * @param string $type_of_url The type of URL being considered (e.g. single, category, etc) for use in the filter.
 * @return string
 */

I’ve personally had to use this function when working on Standard and documented the reasons why in this post.

This particular function, although useful, is one that requires a bit of care as you need to really understand the path to which you’re linking and whether or not it should have a trailing slash or not.

Once you’ve determined that, prepare the URL then send it to this function. That should yield the best results.

A Summary of The Trailing Slash in WordPress

Dealing with trailing slashes isn’t so much complicated as it is knowing what you’re linking to and what the best practices for each scenario are.

Once you understand that, I think understanding exactly what functions to use makes sense – in fact, each one lends itself to the proper scenario:

• If you’re linking to a file, use untrailingslashit.
• If you’re linking to a path, use trailingslashit.
• If you’re looking to leverage the user’s settings, use user_trailingslashit but only after one of the above functions has processed the URL.

Hopefully, this post clarifies some issues around trailing slashes in WordPress, how to use, how to abuse, and how to mitigate whatever other crazy situations we end find ourselves in when working on projects.

All About The Trailing Slash in WordPress first appeared on Tom McFarlin's blog. Consider leaving a comment!

This is post is part of a larger discussion that I’ll be covering in more detail in another post, but here’s the gist of why I’m a fan of using trailingslashit.

Here’s why: there’s only a handful of operations that you can really be doing:

• Setting up some type of rewrite rules or routes
• Sniffing out parts of the URL to check for data
• Redirecting (or protecting) users from content based on their status
• …and maybe a few more

When it comes to examining the contents of the URL, one of the most common – if not the most common – way of doing it is using explode and then examine the various indexes of the array.

But in order to properly handle this, I think that we have an obligation to code defensively against URLs because we never know how users, third party libraries, or other clients are going to provide said URL.

And thus the case for always using trailingslashit in WordPress projects.

trailingslashit in WordPress

Simply put, trailingslashit will append a backslash to the end of a URL that’s passed as its parameter. If one already exists, then it won’t duplicate the existing trailing slash.

But the reasons for doing this aren’t arbitrary – it makes managing, parsing, and examining URL’s much easier, and here’s why:

Whenever you implement a trailing slash at the end of a URL, you are giving a definitive end point to your URL such that calling explode on a URL will allow you to have a fixed set of array indexes that contain each component.

Without having a trailing slash, you may end up running into an undefined index. Antonio offers a second opinion, which is completely viable, and which I’ll be discussing in the next post, too.

Consider this: Let’s say that you’re expecting a value to be at the last index of the array. If the trailing slash is present, then the value at the end of the array will always be two-off from the end; otherwise, it will be one-off from the end.

If the input is variable, then there’s no way to know which index to check. By applying trailingslashit, you can ensure the value for which you’re looking is always at the same index.

$arr_example = explode( '/', trailingslashit( $url ) );
$value = $arr_example[ count( $arr_example ) - 2 ];

Without using trailingslashit, you have no way of knowing if this index will actually exist at the end of the array or one index away from the end of the array, whereas using it will prevent that very problem from occurring.

Although there are multiple applications for this function, this is a safe guard when it comes to inspecting the last component of a URL.

That said, this isn’t the definitive way to go about handling trailing slashes. It’s a good way, but there’s another use case to consider. Thanks to thoughts by several commenters, I’ll be covering the flip side of this in the next post.

Using trailingslashit in WordPress first appeared on Tom McFarlin's blog. Consider leaving a comment!

This week, I ended up writing my first post on Medium and, as promised, thought I’d share my thoughts on my initial experience.

Ah, an in case you’re a drive-by reader, last week, I shared that I had received an invitation to Medium and shared a few of my thoughts on the tension of writing on the platform. So the purpose of this post is to revisit my thoughts from that post, and share about my experience thus far.

At this point, with a single post, there’s not much to say, but here’s what I have to offer.

My Post on Medium: This Post on That Post

First off, what motivated me to post on Medium – aside from simply wanting to try the service – was that I had content that I felt was worth sharing, but didn’t exactly fit in the context of this blog, or any of the other ones to which I contribute.

Secondly, the content ownership issue is one that I have to get over, but Medium makes this really easy:

• I can link to the original post from this post and be good to go
• I can download my content from Medium at any time
• If I really want to own the content, I’ll just save it in a text file and store it in Dropbox

So with that said, here’s a post-mortem of sorts.

First Post!

As mentioned, the whole idea behind posting on Medium was sharing content that I didn’t feel really belong on this site or any of the others to which I contributed.

Specifically, the article is titled “It’s So Hard To Find Good Help These Days“ and generally captures some of the struggles of what it’s been like to find and hire (or not) others to help grow a company.

A Place For Everything

One of the things that helped inspire this particular post was a conversation I had with John a week or so ago. And when I noticed that Medium offers Collections for your posts, I created a collection What I’m Learning Building a Company and dropped the post in there.

Overtime, we’ll see if I continue to contribute to the collection.

A Medium Experience

Above all else, I really enjoyed the process of writing on Medium. Being able to see exactly what your post is going to look like as soon as you hit publish is nice.

There’s no toggling between browser tabs to make sure things look the way they should.

Additionally, the fact that there’s a single theme and set of typography takes all of the overhead out from thinking about “how should I present this?” or “do I want this there, or there?” It just is. And I like that.

Anyway, as I said, we’ll see if I continue to contribute to the collection, but for now you can read other posts that people have contributed to said collection.

My First Post on Medium: “It’s So Hard To Find Good Help These Days” first appeared on Tom McFarlin's blog. Consider leaving a comment!

One of the more common UI design patterns is to render a table of data that includes rows that include people’s names, various information about them, and so on.

Usually, there are some type of control elements that allow you to filter the data by some type of criteria. Obviously, this is especially useful with large datasets where you don’t want to page through pages of data or scroll for a significantly long length of time.

Though there are a variety of ways to filter data – especially if you want to do so through the use of different values – one way that’s most common is to filter data by a person’s name.

If the data set is really large, this is often something that’s best left to process on the server side; however, if the data set is modest, it’s really easy to filter names in jQuery.

One Way To Set This Up

Here’s an example of what I’m talking about:

Above the table of data, there are anchors on which the users can click to filter the data based on the letter. For all intents an purposes, let’s say that I want to filter the data by the person’s last name.

For example, when a user clicks on ‘A’ then all people whose last name does not begin with ‘A’ will disappear. Then, when you click on the same letter, all names will appear.

Similarly, let’s say that you click on a different letter, then the current set of data will be hidden and the data matching the clicked letter will display.

Though there are a variety of ways to do this, I’m doing the following:

• The rows need to be identified by the users last name. As such, that will be the ID of each row.
• The letter that’s clicked needs to be identified
• We need to hide all elements that do not start with the letter that was clicked

Easy enough, right?

Filter Names in jQuery

To make this simple, I’m only going to be showing small pieces of code to demonstrate the steps that are outlined above.

Name Each Row

When the data is rendered out to the page, it should look like this:

<table>
  <tbody>
    <tr id="ames">
      <td>Ames, Chris</td>
      <td>...</td>
    </tr>
    <tr id="erickson">
      <td>Erickson, Jared</td>
      <td>...</td>
    </tr>
    <tr id="...">
      <td>...</td>
    </tr>
  </tbody>
</table>

Again, the ID of the row is that of the person’s last name.

Identify The Clicked Anchor

Next, when the user clicks on a letter, we need to be able to identify which letter was clicked. The letters can be stored in a variety of elements – unordered lists, spans, paragraphs, and so on.

I’m a fan of using styled, unordered lists so here’s what my code looks like:

</pre>
<ul id="alphabet-list">
	<li><a href="javascript:;">A</a></li>
	<li><a href="javascript:;">B</a></li>
	<li><a href="javascript:;">C</a></li>
	<li><a href="javascript:;">...</a></li>
</ul>
<pre>
<!-- /#alphabet-list -->

Not that the anchor’s href attribute is set to javascript:;. This is because we want the let the user know that the text can be clicked (but we’re going to let the rest of the work be done in JavaScript).

Filter The Names

Finally, we’re ready to filter all rows that do not start with the clicked letter. To do this, jQuery’s selectors make this really easy.

Simply put, we’ll hide all elements that do not start with the letter that was clicked:

$('#alphabet-list').on('click', 'li a', function(evt) {

	evt.preventDefault();

	// Grab the letter that was clicked
	var sCurrentLetter = $(this).text().toLowerCase();

	// Now hide all rows that have IDs that do not start with this letter
	$('tbody > tr:not( [id^="' + sCurrentLetter + '"] )').hide();

});

And that does it.

Sure, you can take this a step further and provide some styling and additional filtering to enhance the experience, but this is enough to get started.

Again, this isn’t something I recommend for exceptionally large datasets, but if the data is relatively modest, then go for it.

How To Easily Filter Names in jQuery first appeared on Tom McFarlin's blog. Consider leaving a comment!

Here are the details on the event:

Improve Your WordPress Development Skills

On Thursday, July 25, 2013, I’ll be speaking at the Business Accelerators conference center in Kennesaw, Georgia. The talk is geared towards both aspiring and intermediate WordPress developers.

I’ll be covering the following topics:

1. Understand the Importance of the WordPress Codex
2. Learn The WordPress APIs and How To Use Them
3. Hear Why The Coding Standards Are Important
4. Learn To Identify Your Niche Within The WordPress Community
5. How To Continue To Educate Yourself Beyond Conferences

The goal is not only to provide some practical advice around improving your WordPress development skills, but also to have an open discussion about any of the above points as well as anything else that’s relevant.

The Details

For those of you in the Atlanta-area, or those of you who are interested in attending, here’s all the information:

• We’ll be meeting at the Business Accelerators conference center
• We’ll be meeting from 9am to 12pm
• The price is $89 through June 30 as an early bird special (30% off the normal ticket price)
• You can RSVP and pay via the event’s meetup page.

If you’ve got any other questions, leave ‘em in the comments; otherwise, I hope to see you there.

Five Ways To Improve Your WordPress Development Skills first appeared on Tom McFarlin's blog. Consider leaving a comment!

Specifically, the person was using a plugin that allowed for certain attachments to the plugin. In order to make sure that the comment could be screened prior to allowing it to go public on the blog, they wanted to moderate it from the dashboard without needed to completely enable comment moderation across the board.

This is something that’s relatively easy to achieve programmatically.

How To Mark a Comment as Unapproved

First, you need to register an action with the wp_insert_comment action.

For example:

add_filter( 'wp_insert_comment', 'example_save_comment' );

Next, you’ll need to define the example_save_comment function. Note that this function will receive the comment ID as a parameter whenever the action is called.

As such, the function should look like this:

function example_save_comment( $comment_id ) {
    // ...
}

After that, it’s a matter of performing the following steps:

1. Retrieve the comment either as an object or as an array. I’ll be using an object.
2. Set the comment_approved flag to 0 (which is used to indicate that it’s not approved).
3. Use the wp_update_comment WordPress API function to update the comment.

The final version of the function should look like this:

function example_save_comment( $comment_id ) {

    // Get the comment based on the incoming ID
    $comment = get_comment( $comment_id );

    // Set its approved comment to 0
    $comment->comment_approved = 0;

    // Save this value to the database
    wp_update_comment( $comment );

}

In the code above, this will actually mark every comment as unapproved, so you’ll obviously want to use some type of conditional if you’re looking to only mark some of the comments are unapproved.

But that’s easy enough – just wrap the code in the hook in whatever conditional that’s necessary.

But There’s a Gotcha

The main problem with doing something like this is that it may cause a disjunction between what the user expects to happen and what really happens.

Case in point: Assume that the user as their WordPress settings configured in such a way that once a comment is approved by a single author, then their future comments should always be approved.

With the code above, that’s not the case.

Arguably, the best way to handle this is to introduce a settings page that gives the user the option to mark a comment (or a specific type of comment, depending on how complicated your work is) as unapproved based on a certain condition.

Though that level of detail is beyond the scope of what I’m trying to show here, it’s still an important consideration if you’re going to be introducing this into a project.

Programmatically Mark a Comment as Unapproved first appeared on Tom McFarlin's blog. Consider leaving a comment!

Generally speaking, I think of themes are presentation and plugins as functionality that transcend whatever theme or themes with which they’re installed.

But sometimes, this delineation isn’t so clear. For example, let’s say that you’re working on a theme that needs to introduce a custom meta box – or several – into the post editor screen.

Though this is presentation related in that it will impact what’s displayed to the users, it’s also a bit of custom functionality but it’s only relegated to this particular theme.

What then?

Functions.php vs. Plugin Files

A bit over dramatic, perhaps?

Here’s the thing: Conventional wisdom is the WordPress development community says that anything that exists in functions.php can exist in a plugin file.

This is true, although I think plugins – especially larger ones – should be developed using alternative techniques such as object-oriented programming which is something that functions.php cannot offer.

That said, we have to remember that when we’re working on our projects, it’s not always a matter of picking either functions.php or using a plugin especially when the custom functionality is unique to the theme yet impacts the presentation of the theme.

Anyone who has built relatively large themes or slightly complex web applications using WordPress knows that functions.php can get large very quickly. On top of that, no matter what amount of documentation you provide, the file simply gets larger which can make it difficult to locate whatever it is that you’re looking to find.

I think one thing that we often forget is maintenance factor that comes with creating and releasing a theme or application.

Finding Middle Ground

To that end, there is middle ground that exists between functions.php and plugins and that’s to use separate files and place them in a separate directory.

Perhaps it’s a lib directory, perhaps its an inc directory (which is short for includes), or whatever convention your theme uses.

Custom functionality located in the inc directory

The idea behind this strategy is to make sure that that core theme functionality is kept in functions.php. This includes features such as:

• The content width
• Theme features such as support for featured images
• Functionality related to custom header and custom background support
• …and more

Files kept in the inc directory are usually related to core theme functionality but are more specialized. They aren’t quite plugin territory because they don’t need to be made available to all themes, but they’re specific enough to warrant their own file.

This can include:

• Custom post types
• Meta boxes
• Custom menu pages
• …and more

Note that this strategy is also employed by a variety of boilerplates and starter themes such as Underscores.

And For What It’s Worth

If you find yourself torn between placing something in functions.php or writing a plugin, but still feeling as if both options are wrong, consider this third alternative.

Personally, when it comes to organizing code, I use lib directories to contain third-party libraries, source code, and so on. I also keep them organized on a per-language basis. This means that my JavaScript directory may have a lib directory, as will my CSS, and so on.

Then, I use inc as the directory for my own libraries, code, and functions that are used throughout the theme.

Ultimately, this comes down to a factor of maintenance – you can make a place for each piece of functionality without sacrificing the integrity of your project, and without having to generalize the functionality into a plugin.

Functions.php vs Plugin, Who Wins? first appeared on Tom McFarlin's blog. Consider leaving a comment!

Granted, you have to take the good with the bad, but the problem with the bad is that it’s so much easier to take to heart and/or focus on that the good, right?

But the irony in this is that not only do we subject ourselves to said criticism, but some also offer criticism to what others have done.

If you’re on the receiving end of said criticism, it’s easy to get defensive; if you’re on the giving end of the criticism, it’s easy to mask it as constructive when, in fact, it may not be at all.

So how do we deal with this kind of stuff on a day-to-day basis?

What Have You Done?

The truth is that I wish I had an answer.

Dear Abby: Why does others’ work suck so much?

Honestly, even writing this sounds like a “Dear Abby” letter or some type of self-help post, so I can only imagine how it’s coming off when you’re reading it .

Come at Me, Bro

Here’s what I do know: many of us are our own worst critics, so when we see others criticizing something that we’re doing, it feels almost a bit like affirmation of a fear that we already have.

Being in that place sucks.

Not only does it make us a bit skeptical about what we’re doing, but it also puts us on the defense – which may or may not be warranted – thus wondering if the effort is even worth it, and likely even feeling a bit of animosity of disrespect towards the critics.

A Little Help

I’d like to think that those who are offering criticism are doing so with the best of intentions, but are simply having to keep it concise thanks to channels such as Twitter that require such short messages (which raises the question: is Twitter the best place for this type of conversation?).

And if you find yourself in that place, then maybe it’s better if the criticism is kept into an email or something that supports more longer form opinions. Sure, there are other options, but I digress for now.

Haters Gonna Hate (Or “Sticks and Stones”)

So here’s the thing: Whenever someone ends up critiquing work we’ve done, it’s much easier to simply ask “Oh yeah, well what have you done?” as a way to help deflect some of the criticism.

But what does this matter, really?

The thing is, people are going to say what they are going to say whether or not they’ve done anything. Those who have understand just how hard it is to ship something – anything, really - and those who don’t might as well be trolling.

Haters gonna hate, but I don’t think that helps.

I don’t know how the rest of you guys and gals handle criticism. For what it’s worth, I think it’s actually a learned skill. The more you put yourself out there, the thicker your skin has to get, but the truth is that I don’t know if the sting of negative critique ever really goes away (of course, that’s just my experience).

And yeah, it’s easy to say “haters gonna hate” (which is nothing more than the adult version of sticks and stones, am I right? ), but if I get caught in a bad day, criticism simply sucks. Plain and simple.

It generates pure old fashioned anger that ends up sending you in a bit of a spiral wondering if it was worth putting said project out there. Surely we can all identify with this in some way.

Make It Stop!

As I mentioned earlier in the post:

I’d like to think that those who are offering criticism are doing so with the best of intentions, but are simply having to keep it concise thanks to channels such as Twitter that require such short messages.

But the truth is that as much as I’d like to think that, the truth is that I don’t really believe that. I see far too many debates, arguments, passive aggressive whatever, and flat-out negativity permeating our social networks to know better.

So how do we actually make this stop? I don’t think we can. As much as I want to go all John Lennon and “give peace a chance” on this kind of stuff, I think that half of being involved in open projects is accepting the potential negativity that exists.

Dealing with it is the tough spot, sure, and for those of us who have ever offered up criticism of someone else’s work, perhaps it’s better if we opt to do it in private first and see what happens then go from there.

It results in being able to provide longer form explanations, examples, discussion, and respect that’s simply lost in short-form posts.

Then again, it feels almost futile to even mention this because the critics who we’d like to see do this likely won’t dig it, anyway. And for those who already do it, the whole post may seem redundant.

Tell Me: What Have You Done? first appeared on Tom McFarlin's blog. Consider leaving a comment!

Thanks to a heads up from one of my partners, I can now write documentation with markdown.

Here’s the thing: I’ve mentioned that I’m a huge advocate for code comments - I think it’s better to go a little overboard for the sake of clarity than not, especially in open source projects.

And sure, PHP DocBlocks and tools like PHPDocumentor make it relatively easy to generate documentation, but documentation like that is best suited for other developers. It’s not exactly end-user friendly, right?

In that case, you’re talking about writing a manual.

Documentation For Users

When it comes to writing documentation for users, there’s a variety of things to consider:

• How easy is it for them to discover the documentation?
• Is it written in language that they understand?
• Is it kept up-to-date with each release?

On top of that, there are a number of tools for writing said manual.

Up to this point, my team and I have generally stuck with using WordPress and some light customizations of a theme.

The Standard Theme User Manual on WordPress

No, it’s nothing glamorous and it’s a relatively simple solution, but it gets the job done, it’s easy to maintain, and it’s linked up from within the theme admin.

But this still requires a little bit of initial overhead – namely, setting up the server, database, WordPress installation, and so on.

Documentation with Markdown

Enter Flatdoc.

Flatdoc for Documentation with Markdown

In short, Flatdoc is an open source project for writing documentation in Markdown.

I love the way it works:

• Write the documentation using markdown
• Include a JavaScript file in a page (and direct the JavaScript to the markdown file)
• Provide some options for theme customization
• Profit!

To be fair, I don’t think this solution is right for everyone. After all, if you’ve got someone on your team who’s in the business of writing documentation for other projects, they have their own tools, and/or they have a different way of doing things, then go for it.

After all, markdown is still one of those languages that leans in the direction of developers.

But that’s exactly it: If you’re a developer who wants to include more documentation than that for fellow developers, and you’re looking for an easy way to do it such that you can write it in markdown format and then have a tool generate a good looking page (or set of pages for you), then Flatdoc’s the way to go.

I’m aiming to begin releasing a couple of projects with documentation using Flatdoc. Eager to see how it goes.

Flatdoc For Documentation with Markdown first appeared on Tom McFarlin's blog. Consider leaving a comment!

Based on my conversation with him (and a number of others, for what it’s worth), there tends to be two schools of thought on releasing products into a marketplace that can be summed up in the following two statements:

• If a similar product already exists, don’t do it.
• If a similar product already exists, do it.

Sure, that’s an oversimplification of the idea and there’s a lot to be said about both; however, I’ve seen this same thing discussed in the context of both WordPress theme and plugin development.

Specifically, the quote I read was as follows:

1. Check the plugin repository to see if similar plugin exists.

2. If so, don’t reinvent the wheel.

Initially, I categorically disagreed with this perspective.

Believe The Best (Don’t Assume The Worst)

But here’s the thing: As we all know, when it comes to the Internet, we have a habit of condensing our thoughts into the smallest pieces of consumable information – with the exception of our blogs – for others to read (thanks to Twitter, Facebook, et al.).

To that end, I think that we owe one another the benefit of the doubt when people make statements like that above, because I want to believe the best (rather than assume the worst) and think that most people won’t speak in terms of sweeping generalities. That’s a byproduct of the means of communication we have today.

I hope.

It happens, but surely it’s not as common as we accuse one another. But I digress.

The point still remains: if a similar plugin – or product, for that matter – exists to what you’re attempting to build should you aim to to create something different?

I don’t think anyone would advocate for simply copying an existing product down to the bits and bytes (or to the exact design, ingredients, or what have you). By that, I mean what’s the purpose of doing so?

• When you go to the grocery store, how many different kinds of ketchup do you see?
• How many different brands of cars are available?
• What about how many varieties of ice cream we have?

All of the above have a single thing in common, too: All ketchup serves the same purpose. All cars get us from point A to point B, and all – well, most – ice cream is cold and tastes awesome.

The Price is Right?

The Price is Right, Right?

Odds are, if there’s already a leader in the market that you’re attempting to tackle and you aren’t doing anything different, what incentive to other people have to swap to your product?

One of the primary answers, in this case, is price. If you offer an identical product for a lower price, you may get some conversions, but you can’t discount emotional or sweat equity.

People put time, energy, and a lot of their work into using an existing product and a cheaper price still may not be enough to convince them it’s worth swapping.

Think Different

Think different about your solution

Here’s the thing: it’s important to distinguish if you’re copying an existing product, or if your core product is the same with a differentiation in features (be it more or less), or a different approach to solving the problem.

At this point, I think it’s worth pursuing, because there are often n-number of ways to solve a particular problem.

Some do it elegantly and some just do it. If you’re second or third or ninth to market but you’ve got a sleeker, more elegant solution to solving the same problem as another product, market it.

Other people will likely take notice and at least investigate it.

And, if you’ve done the job well, price is less of a factor here. Because if a customer has invested hours in a similar project but it causes them pain, and yours comes around and makes it a dream with which to work, then the cost of their time to migrate to your solution may be worth the extra cash.

Competition Fosters Innovation

Overall, I think that it’s all about how well the problem is solved. It’s not about copying, it’s not about imitating, and it certainly isn’t about ripping off. That’s a whole other post.

As people seeking to provide a solution to the needs of others, it’s about making their lives easier. So sure, look to see if another plugin – or product – exists, but do so with the intent to know your competition and what you’re up against – not to dissuade yourself from working on it.

Don’t Copy WordPress Plugins first appeared on Tom McFarlin's blog. Consider leaving a comment!