Tag: WordPress (Page 187 of 220)

Last week, I wrote a post discussing why I think it’s important to use a trailing slash in WordPress.

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.

Continue reading

When it comes to working with URLs, I believe that we should often be using `trailingslashit` in WordPress.

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.

Continue reading

When it comes to introducing custom functionality into a WordPress project, the debate between functions.php vs. plugin usage is nothing new.

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?

Continue reading

The conversation about the ethics of what it means to copy WordPress plugins, theme, applications, and more isn’t new. In fact, just the other day, I was having a conversation with a friend of mine about what competition looks like in various marketplaces.

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. Continue reading