[wp-hackers] Plugin Questions

[Owen Winkler]

Scott Merrill wrote:
> Bill Smith wrote:
> 
>>1) I'm working on a small plugin that requires an additional database
>>table. Currently I'm using a query like
>>
>>SHOW TABLES LIKE 'wp_mytable'
> 
> Here's what I do in my subscribe2 plugin, which uses a custom table:
> ///////////////////////
> function s2_install() {
> // include upgrade-functions for maybe_create_table;
> if (! function_exists('maybe_create_table')) {
>         require_once(ABSPATH . '/wp-admin/upgrade-functions.php');
> }

maybe_create_table() also uses SHOW TABLES, which is fine, but doesn't 
avoid that query if that's the intent.

Here's what I do:

class MyPlugin {
  $table_version = 1;
  function MyPlugin() {
   $this->settings = get_settings('MyPlugin');
   if($this->settings['table_version'] < $this->$table_version)
    $this->make_tables();
   //These also go here:
   // add_action('admin_menu', array(&$this, 'admin_menu'));
  }
  function make_tables() {
   global $table_prefix;
   if(!require_once(ABSPATH . 'wp-admin/upgrade-functions.php')) {
    die('Foolish plugin has added its own maybe_upgrade* functions');
   }
   $qry = "CREATE TABLE {$table_prefix}mytable (
    mytable_id BIGINT(11) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY  (mytable_id)
    );
    ";
   dbDelta($qry);
   $this->settings['table_version'] = $this->table_version;
   update_option('MyPlugin', $this->settings);
  }
}
$myplugin = new MyPlugin();

What benefit has all this?  If you change the table structure in an 
upgrade (add a field, change a field type, add an enum value, etc.), you 
simply increment the $table_version and the plugin will automatically 
upgrade the table.  Plus it's one less database hit if the options info 
is already cached.

 >> 2) This may be more of a php question. There are occasions where I
 >> would like to perform a longer running task in the background (in
 >> terms of a minute or two, not hours).

I've been considering this type of thing myself, but my process is a 
series of repetitious function calls, each of which could take some 
length of time.  I'm considering adding a client-side reload hack for 
this issue, since the methods to extend allowed execution time for PHP 
executed from the web are not reliable enough for me, and provide no 
user feedback for the process.

>>3) Last one... for the moment. :) In certain parts of my plugin, I'd
>>like to restrict access to either the admin or users of a certain level.
>>Is there a call that can tell me the users credentials so I can
>>determine what they are allowed to do?
> 
> get_currentuserinfo() usually works; though there might be some
> complication now with the "pluggable functions" recently introduced.

get_currentuserinfo() works inside of functions that are executed from 
plugin hooks.  Do not attempt to call get_currentuserinfo() before all 
plugins are loaded.

It doesn't seem like the pluggable functions list is in the Codex.  Here 
it is:  get_currentuserinfo, get_userdata, get_userdatabylogin, wp_mail, 
wp_login, auth_redirect, wp_redirect, wp_setcookie, wp_clearcookie, 
wp_notify_postauthor, wp_notify_moderator

Calling any of those functions before all plugins are loaded will cause 
you problems.  This I know all too well.

Owen