Tag: WordPress (Page 172 of 220)

You’ve gotta be prepared for the future, just in case you end up there.

For those of you who have read this blog long enough, you know that I’m a big advocate for using WordPress for web application development.

No, I don’t think it’s the end all, be all of foundations for web applications, but it’s one that shouldn’t be overlooked depending on the nature of your requirements.

Anyway, a friend of mine recently contacted me asking what I do to future proof WordPress when I begin to use it build applications on top of it. Specifically, he asked what steps I take when working on projects that may end up breaking with the next WordPress upgrade.

Since I don’t recall ever sharing the steps and tools that I use, thought it would be good to cover here.

Note that these aren’t all the things that I do or that can be done (and I’m sure you guys have some great suggestions, too), but these are the things that came to mind that I’ve found to be absolutely critical.

Continue reading

A previous post, I shared a strategy on how to separate comments, trackbacks, and pings in a WordPress post.

In short, the article covered how to create a template such that the comments would be listed first, then the trackbacks and pings would be listed second.

In addition to creating templates that separate the types of comments related to a post, I also find it useful to have a helper function to determine if a given post has comments and/or pingbacks.

Continue reading

This is post one of two on how to upload files in WordPress and created associated meta data.

In a recent project, I’ve been working on a plugin in which the user needs to upload a file to a custom post type by using an input element (of type file, obviously) rather than using the WordPress media uploader.

In addition to being able to upload the file, the user must also be able to view the file and remove the file (via Ajax) by an available anchor.

In order to do this, the plugin has to do the following:

1. Upload the file to the `uploads` directory
2. Save the file URL to the custom post type’s post meta data
3. Save the file path to the custom post type’s post meta data
4. Delete the file from the `uploads directory
5. Clear the post meta data referencing the file

The primary reason that you have to store the file’s location on disk is because you can’t rely on PHP to delete a file via remote requests.

To that end, you need to be able to store not only where the file is on disk (for the sake of being able to delete), but also the URL of the file so that visitors or viewers can access the file via their browser.

Over the next two articles, I’ll share how to programmatically upload files in WordPress and save their associated meta data, and then I’ll share how to programmatically delete the files in WordPress as well as their associated meta data.
Continue reading

If you hang around the WordPress Community long enough (that is, those people who are involved in working on WordPress or building something on WordPress in some way), you’ll notice that we all have a tendency to aim to build the best thing possible – whatever that may be.

At least, that’s what we claim to be doing.

And I’m just as guilty of this as the next person.

But let’s face it: developers need help marketing WordPress themes. Perhaps designers do, too. And let’s not forget plugins or other add-ons.

Basically, I think that we get so involved with the community of which we’re a part, we forget about the market and the terms in which they think. We’re busy trying to help one another other, perhaps even impress one another, and even working to try to out-do each other (I mean, come on, that is competition, right?), that we end up marketing our products in the same way every single time.

And you know what I’m talking about.

Continue reading