Tag: WordPress (Page 171 of 220)

In the previous post, I shared a little bit about the idea of separation of concerns – a concept that’s usually isolated to software development – and one way in which it can be achieved as it relates to working with WordPress templates.

But there’s always more work that can be done to help make our code as modular, reusable, maintainable, and readable (and any other buzzwords that I forgot ;) as it relates to programming projects.

One of the challenges of working in a system like WordPress is that it doesn’t necessarily promote practices that are typically seen in more classical programming environments, but – the way that I see it – we’re doing many of the same things:

• Solving problems through the use of code,
• Abstracting reusable components,
• Querying for information from a database through the use of provided APIs,
• Keeping areas of the code modular and related to the areas of the application and their best related,
• …and more.

So why should we avoid trying to apply better programming practices to our code regardless of if it’s a high-end object-oriented application, or – say – a theme with a number of different templates, JavaScript, styles, and queries (and even more things such as post types and taxonomies depending on the nature of your project)?

After all, it’s all code, right?

Continue reading

One of the biggest pain points in working with WordPress templates – or, really, any  PHP and HTML in general – is how we end up jumping from language to language within the context of a single file.

Obviously, this is unavoidable. I mean, the same thing even happens in other frameworks like .NET and Rails, but one of the things that I’ve seen that continually sets WordPress apart (and I don’t mean that in a good way) is that developers often don’t bother to spend time separating their concerns as it relates to the work being done in any given template.

A Vanilla Template File

For those who have been working in WordPress for several years likely know this, and know the frustration this causes.

For those who have recently hopped into WordPress development, there’s a strong chance you’ve likely been overwhelmed with some of what you’ve seen.

It’s a bummer, I know.

But it doesn’t have to be that way.

Continue reading

For anyone who has worked with WordPress on some level, you’re likely familiar with the concept of templates.

In the context of WordPress, templates are the files in which information retrieved from the database is rendered. In other frameworks or platforms, they may also be called templates, but are also often referred to as views.

But for anyone who has done enough work with building web applications, you know that as much as we like to build reusable components on the server-side – be it functions, classes, or whatever else – that we also like to do so with client-side related code, too.

Continue reading

I think that one of the more underestimated aspects of building solutions with WordPress comes with leveraging custom post types and custom taxonomies.

For those who are currently building products for others – be it plugins, custom themes, or web applications – then you’re likely familiar with how powerful these two features can be.

Specifically, if you’re used to the ideas of models and views, or data objects and a presentation layer (or whatever language your framework of choice uses to describe this information), you can think of custom post types as a bit of a hybrid of models and views.

Similarly, you can think of taxonomies as an easy way to stamp your data – in WordPress, we think of these as categories and tags – but sometimes, I think the terminology may limit us in thinking how we can leverage the features.

Nonetheless, if you’re used to working with WordPress, custom post types, and custom taxonomies, then you’ve likely faced a time when you’ve needed to query information based on a combination of the two.

And though there are a variety of different ways to retrieve custom post types and how they are tagged, here’s one way to grab information that’s stamped with multiple taxonomies.

Continue reading

This is post two of two on how to upload files in WordPress and created associated meta data. Read the first post here.

In the first post in this series, I mentioned that I’ve been working on a plugin in which the users needs to upload a file to a custom post type without the use of the Media Uploader.

This is basically done via use of an `input` type of `file`, WordPress `nonce` values, and some basic PHP functionality, but if you’d like to read more, then be sure to review the first post.

As mention in the first article, the second part of being able to store files and their associated meta data is so that you can also remove the files (and the meta data) when the user triggers the appropriate action.

Specifically, the plugin must do the following:

1. Verify the request’s incoming `nonce` value
2. Use (or somehow retrieve) the specified meta key for the file to be deleted
3. Delete the file from the file system
4. Remove the database entries – that is, the meta data – associated with the file

Just as in the last article, we’ll take a look at each step and the code required for each, as well.

Continue reading