Writing a WordPress Plugin: Part II

In Part One we discussed adding actions and filters to WordPress as an initial step in writing a WordPress plugin. These hooks into the WordPress API allow your code to be called by WordPress as certain events and code are generated.
However, your plugin may need to access the WordPress database to use WordPress’ data for outputting various pieces of information. WordPress’ $wpdb object is perfect for the job and easy to use.

The WordPress database interaction object is created in the WordPress code for you, so all you’ll need to do is import it into your functions that are called by WordPress like so:

function suckMyDatabasesBrainsOut(){
global $wpdb, $tableposts;
// other code here to make the world a better place
}

You’ll also need to import the database name that you’ll need access to because WordPress 1.2 uses variables to hold the database names. The database names are dynamic because you can have multiple WordPress installations and each installation has a different prefix. The list of default tables are found in the wp-settings.php file:

  • $tableposts
  • $tableusers
  • $tablesettings
  • $tablecategories
  • $tablepost2cat
  • $tablecomments
  • $tablelinks
  • $tablelinkcategories
  • $tableoptions
  • $tableoptiontypes
  • $tableoptionvalues
  • $tableoptiongroups
  • $tableoptiongroup_options
  • $tablepostmeta

You’ll have to determine what table has the data you’re after. I recommend using PHPMyAdmin to look at the information in your database.

OK, so you’ve got access in your plugin, but now you need data, because access is [only] half the battle (to mutilate G.I. Joe). You can use the following functions to get data from WordPress and to control how the WordPress Database object controls output [found in the wp-includes/wp-db.php file]:

$wpdb->escape($string)
Returns a string escaped for safety in MySQL queries.
show_errors()
Turns on WordPress returning MySQL error reporting when errors are encountered.
$wpdb->hide_errors()
Turns off WordPress’ returning MySQL errors when they are encountered.
$wpdb->flush()
Sets cached query results to null
$wpdb->query($SQLQuery)
Used to execute DELETE or UPDATE queries
$wpdb->get_var($SQLQuery, $x, $y)
Use this to get one value from the database, where $x and $y are specific data values. You can call this function with just the query if one result is expected from the query. I have found no documentation regarding the second and third parameter and no where are they used in the WordPress code for version 1.2.
$wpdb->get_row($SQLQuery)
Returns one database result row from a query.
$wpdb->get_col($SQLQuery)
Returns the values from a table column for use as a PHP array.
$wpdb->get_results($SQLQuery, $objectForValueToBeReturnedIn)
Returns the SQL query results in an object that can be accessed by the result column names. If you don’t care what object is used for access you can skip the second parameter.
$wpdb->get_col_info($informationType, $columnOffset)
Returns column meta information for the last column requested. $informationType defaults to 'name' and $columnOffset defaults to -1.

Remember that the data returned by the $wpdb->get_results($SQLQuery)

Notes:It should be noted that WordPress 1.3 changes database access by only requiring you to import the $wpdb global. Currently no information has been published that explains how to add external databases (for example the StatTraq statistics database).

16 thoughts on “Writing a WordPress Plugin: Part II

  1. Pingback: wordlog.com » How to write a plugin

  2. Great going!
    Just a note, about the table names. In 1.3 (upcoming) and later, the table names will be of a different form, for example “$wpdb->posts” will replace $tableposts and so on.
    I will look forward to III, if there is one 🙂

  3. Wow…as a noobie to WP and PHP but nonetheless a programmer, I have begun “mucking about” in the code and wondered what all of these calls did (no, I still have not gotten my PHP book yet – darn it). Thanks for the great explanation. I hope to see some more – maybe even a series. 😉

  4. Pingback: ?????Geek?? » Plugin API

  5. Pingback: ?????Geek?? » Plugin API

  6. Pingback: CodeProfessor » Create Your Own Wordpress Themes + Plugins

  7. IMHO, I don’t think these blog post links should be in the codex. There’s no info here that’s not already on the WordPress website.

  8. Wow, PJ. That’s like saying there’s no need for modern translations of Homer because between the ancient greek transcriptions and a English-to-Ancient-Greek dictionary, his epics are fully described.

    Randy, as a non-programmer and a new user of WP, this entry (two years old!!) helped me a lot as I wrote a couple important plug-ins for my site. I’m sure glad PJ didn’t act on your clever response. Thanks!

  9. Pingback: Writing a Plugin | Web Design

  10. What if you need a plugin to access data that is not ordinarily a part of the wordpress database…. should you extend the data base or create a new one? I am creating a webpage for a school and I want a plugin to display the current courses being offered by a specific department.

  11. Safia, In the case of extending the data I would recommend adding it to a new table in the same WP database. Assuming its all going to be managed and and displayed within WordPress you’re in good shape to handle it like that. I personally wrote a plugin for my church’s website that uses the WP database, but has several tables to manage recordings and schedules of the series, teachers, files, and lessons. I hope that helps!

  12. Thank for writing about this topic. That is what is so great about having a WordPress website… the great plugins and people like you who are willing to share there experience with the rest of the community. I have to set aside some time to write a custom WordPress plugin for my website and give it bask to the community. Thanks again for the great post.

  13. Pingback: The Sharing and Caring of the WordPress Community Shines « Lorelle on WordPress

Comments are closed.