I recently had to make direct changes to my wp_posts table from a WordPress plugin. I first tried to do this with wp_update_post(), thinking that would would do it. Apparently, wp_update_post() is only able to edit a predefined set of table fields (presumably the WP default ones). Then I happened upon $wpdb class. I thought I read that wp_update_post() uses $wpdb which is interesting, but then begs the question, why have wp_update_post() when you can just use the $wpdb class directly? What does wp_update_post() do that the $wpdb does not? What need is it filling? Or is it more of an administration concern, like resources or security? If that's the case, what are the downsides of using $wpdb directly?

3 Answers 3

  1. wp_update_post() calls some hooks that $wpdb doesn't on it's own. You'll have to do it on your own to make it compatible with other plugins.

  2. wp_update_post() calls some functions related to database entry sanitation, thumbnails, attachments, time (format, zone etc.), comment, taxonomy, meta, cache etc. So if you use $wpdb, make sure you handle all of them as appropriate.

  3. WordPress will update wp_update_post() to always keep it compatible with the current state of Database, core CODE, plugin support etc. Even if you do everything right, future updates will be difficult for you with $wpdb.

So if something can be done with wp_update_post(), then always use it, only use $wpdb if your desired action related to updating post can't be done with it.


Why have WP_Query() when you can just use WPDB?

The idea is that these functions make it easier and quicker to pull data based on keywords instead of writing out SQL queries. The functions themselves will generate the necessary SQL to pull the desired data which in turn makes the development faster.

The referenced question regarding wp_update_post() and predefined fields talks about 2 fields that are not part of a default WordPress installation which are group_access and tag_list. The wp_update_post() function will hit all the built-in fields just fine.

Downsides of $wpdb are that you do need to know SQL and you need to be conscious of normal data sanitization and when to use prepare() and what functions already prepare your statement which are hardly downsides at all. The $wpdb Class is by nature more powerful than any of the default WordPress functions because you have access to all the data, custom or not, assuming you know the proper SQL to get, modify, or remove it.

TL;DR $wpdb is more powerful but less friendly and forgiving.

  • Thank you. As you can tell, I'm a long time WP user, but only been trying to work in the code for a very short time. I'm still learning the structures that do all the work behind the scenes. So, would you say that wp_update_post() exists to meet a user skill level that does not include SQL queries? It is meant to make this aspect of WP more user friendly?
    – user38365
    Commented Mar 6, 2017 at 17:31
  • 1
    @fredsbend All these functions create SQL. What it does is makes the development process faster and prevents repetition by creating reusable code blocks in the call of a function. Otherwise you would need to create your own SQL every time you wanted to insert a post or create an archive page. It also makes code more readable. It is meant to make working with WordPress more streamlined. I may know SQL but I wouldn't want to develop an entire WordPress website with my own custom SQL.
    – Howdy_McGee
    Commented Mar 6, 2017 at 17:40
  • Yes, I just verified that using $wpdb will throw an error if you try to update a field with a pretty quote or a long/em dash . I'll have to integrate some data sanitation if I want a complete and user friendly plugin.
    – user38365
    Commented Mar 6, 2017 at 19:09

Most API functions have either/both actions and filters attached to them. Other plugins or themes might have code attached to these actions that won't trigger when you add/update tables directly.

For example- a cache plugin serves pages from cache, and only refreshes the cache when a post is updated. You update the post data directly, and the cache continues to serve the old version because nothing triggered the action to refresh.

  • Are you saying that caveat may be that some plugins use a cache, not the table directly, so will not be using the updated table data if you use $wpdb until the cache is refreshed?
    – user38365
    Commented Mar 6, 2017 at 17:44
  • 1
    That was just a specific example. I'm saying there are hundreds of plugins out there that are doing something when posts are added or updated. You can't possibly know what all of those things are, and by bypassing the API, you will break all of that functionality.
    – Milo
    Commented Mar 6, 2017 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.