Use plugin or custom post type for game score functionality

4 Views

The last couple of days I’ve been working on a plug-in that adds the functionality of keeping scores from a paintball game. When I manage to finish it I want to present players with a form so they can add in stuff like: hits, deaths, wins, losses, location, role and date.

That goes to a custom table in the WP database.

Read More

They will also get a profile page that shows the last 5 records, win/lose ratio’s and the likes.

The admin also has a menu that shows this table, and should be able to manipulate the date (incase of abuse).

I’ve got further with the plugin then I thought. Admin screen is present and loading the info from the table (sorting some columns). But I haven’t yet got the edit or delete functionality to work.

Which got me thinking. I’ve worked with custom post types before. Wont it be easier to make this plug-in in to a custom post type? Can users send data to it from the front-end? Can I query the data and do some simple math with it? Admins can change the data fairly easy with a custom post type if I’m not mistaken.

Only downsides I can think of now is theme problems. I think its easier to show the data from the custom table with a plug-in via short codes then integrate custom-posts in a theme?

Can I create short code’s for the custom post type?

So should I drop the plug-in way and go for a custom post type? I’d like to be able to share this plug-in eventually, so if I go with the custom-type I’ll probably end up making it in to a plug-in that enables the custom-post-type.

Post Views: 4

Related posts

Leave a Reply

1 comment

  1. The posts and post_meta tables are made for regular blog posts and similar content. Look at the schema and ask yourself: Do I need these fields?

    CREATE TABLE $wpdb->posts (
  ID bigint(20) unsigned NOT NULL auto_increment,
  post_author bigint(20) unsigned NOT NULL default '0',
  post_date datetime NOT NULL default '0000-00-00 00:00:00',
  post_date_gmt datetime NOT NULL default '0000-00-00 00:00:00',
  post_content longtext NOT NULL,
  post_title text NOT NULL,
  post_excerpt text NOT NULL,
  post_status varchar(20) NOT NULL default 'publish',
  comment_status varchar(20) NOT NULL default 'open',
  ping_status varchar(20) NOT NULL default 'open',
  post_password varchar(20) NOT NULL default '',
  post_name varchar(200) NOT NULL default '',
  to_ping text NOT NULL,
  pinged text NOT NULL,
  post_modified datetime NOT NULL default '0000-00-00 00:00:00',
  post_modified_gmt datetime NOT NULL default '0000-00-00 00:00:00',
  post_content_filtered longtext NOT NULL,
  post_parent bigint(20) unsigned NOT NULL default '0',
  guid varchar(255) NOT NULL default '',
  menu_order int(11) NOT NULL default '0',
  post_type varchar(20) NOT NULL default 'post',
  post_mime_type varchar(100) NOT NULL default '',
  comment_count bigint(20) NOT NULL default '0',
  PRIMARY KEY  (ID),
  KEY post_name (post_name),
  KEY type_status_date (post_type,post_status,post_date,ID),
  KEY post_parent (post_parent),
  KEY post_author (post_author)
)

    Building a custom form for your custom table is almost the same process as building one for a custom post type. But in your own table you can use just the fields you need, you can even use another DB engine and PDO if you want.

    Plus, custom post types don’t work across a multi-site network, they might be affected by badly written plugins (some enable their metaboxes or taxonomies for all public post types).

    The tables you use should fit your data model, not the other way around.