Tag: WordPress (Page 1 of 204)

TL;DR: The code shared in this post shows how you can modify the query that runs on the All Posts page so you can limit how you search posts to a specified date range.

It’s been a little while since I last wrote about using the post_where filter for modifying the search query that runs on a given page, such as the All Posts area of WordPress. But given the fact that there are a variety of uses for retrieving posts – and custom post types – in different ways, there’s a variety of ways to use this single filter.

TL;DR: This article outlines the code needed to add a custom link on the All Posts screen that uses a custom piece of post metadata.

Note: A few months ago, I wrote an article on how to add a custom view to the All Posts screen. This article is not all together the same, but not all together different. Think of it as a more detailed and perhaps for more practical implementation of the concept.

Assume that you have a standard post type or a custom post type and you’re going to simply filter by a headline that you define using a mechanism that allows you to save data to the post_metadata table.

For example, let’s say that you have a post and it as a piece of meta data with:

• a meta_key with the value of article_attribute
• a meta_value with the value of headline

And you want to use this information to add a new Headlines link that automatically filters everything out except articles with that metadata.

Here’s how to do it.

TL;DR: If you’re looking for an easy way to sort WordPress posts by date (be it descending or ascending) in the administration area without having users click on the Date column header, you can do so through the use of the pre_get_posts filter that provides a reference to the instance WP_Query running on the page.

For examples in code on how to do that, check out the rest of the article.

TL;DR: I’m going to be working on a series that looks at how to achieve a useful task with taxonomies, likely categories, then refactor it into an object-oriented plugin that will serve as a utility plugin for taxonomies, in general.

A Brief History of OOP Posts

Some time ago, I did a lengthy series about the principles of object-oriented programming (and tried to share a decent amount as to how to achieve certain things within the context of WordPress).

I’ve also written a bunch of articles about the whole paradigm over the years for those who are interested in catching up on some of those articles.

And I’d be remiss if I didn’t share that a good friend of mine has literally written a book on the topic, too.

And thus, as I’ve been thinking about various topics to write about (after taking an admittedly longer period of time off than I planned), thought that it might be worth talking about practical things we can do with normal APIs and hooks and then refactor that into a type of utility plugin.

The landscape of WordPress has changed.

A few years ago, we were all tasked with learning JavaScript deeply and rightly so. With the advent of Gutenberg and projects like Calypso, it’s obvious that JavaScript is becoming a dominant force in WordPress (not to mention the web as a whole), if you don’t consider it to be so already.

And for anyone who has read Coding Horror within the last decade or so, you’re likely familiar with Atwood’s Law:

any application that can be written in JavaScript, will eventually be written in JavaScript.

Jeff Atwood

But as this has happened, it seems as if its created a clearer divide between what constitutes a front-end developer and a back-end developer in the WordPress economy.

Personally, I welcome it as I find myself even more eager to learn, grow, and work on the back-end as PHP grows and changes. But that’s just me and there’s more to examine.