Tag: WordPress (Page 186 of 219)

Earlier this week, I was talking with Chris – our product midwife at 8BIT – about the differences in expectations between engineers, developers, designers, tweakers, and end users when it comes to modifying WordPress themes.

I started my career in software engineering – specifically, I used to work in .NET followed by Ruby on Rails – as well as object-oriented programming before moving into fulltime WordPress development.

And you know what they say: Old habits die hard.

Did someone say “die hard?”

Case in point: ask my team what I did when I first became the lead developer of Standard. I spent more time yanking out template code, abstracting it into `functions.php` and a collection of other files all of which would make sense to someone comes from a different background, but not WordPress.

And here I am, years later, where I’m significantly more familiar with “the WordPress-way” (even writing blog posts on Coding Standards and various APIs even) and there are still issues to be solved around this very issue.

Continue reading

On of the things that I’ve enjoyed the most about working through the live workshop on WordPress plugin development is the conversation that’s ensued around writing WordPress code and PHP code readability in our Basecamp discussions.

For those of you who have been around a while, you know that I’m opinionated when it comes to writing WordPress code. Specifically, I believe that just because WordPress is written in PHP does not mean that we should forgo the APIs and use PHP functions just because we’re either more familiar with them or because we find them easier to use.

That said, there are times in which the native PHP functions are the way to go.

For example, string comparison.

Continue reading

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