WordPress MU

I am planning to build a very comprehensive events catalog and registration plugin to form the core of a project I'm developing. This plugin will allow blog owners to list programs and accept online registrations. It will work in WP and WPMU. The plugin will be simple at first, but it will evolve many features down the road.

My question is this: Should I create my own new tables such as wp_#_programs and wp_1_programs_meta, or should I be using custom post types.

If I use custom post types and put all data in the wp_#_posts and wp_#_postsmeta tables then I'm doing everything the 'Wordpress Way' and I will get some benefits by using all the built in wordpress functions (such as children, revisions, attachements, etc). However the downside is that most of my data will actually be in the meta table. will there be performance issues? what about accessing the data remotely?

however if I make my own tables then I have full flexibility in db structure, but I will have to code all the functions myself.

I would really be interested in hearing feedback about these two choices. And if it is best to go with new tables, what is the best guess as to the tables to create.

thanks in advance :)

If I were going to implement it in MU, I would be inclined to do the custom post types and use the existing blog tables.

thanks for the input. could you give reasons why? and does it matter if the plugin is complex or simple?

Each blog requires 9 tables. If you create a plugin that adds 3 (for example), that means that 1000 blogs require 12K tables instead of 9K. So, it's harder to admin/backup, etc.

If you can make a plugin that uses global tables, then you're golden to go whichever route you like.

I'm a theme guy more than a plugin developer, but when reviewing plugins for our MU environment my preference is utilizing the existing table structures rather than creating new ones.

The main rationale for this is that it works hand in hand with WordPress functionality so things like export/import of the site XML, major core upgrades that affect DB architecture, etc have a better chance of being supported. Using custom tables ensures that on export when a user wants to migrate a site, they will lose data. And while for single instance installs of wordpress, a db export is the best approach to get everything, the xml export is the option available to users of MU environments.

I think some of it is simply bias against clutter.
http://planetozh.com/blog/2008/06/wordpress-plugin-coding-tips/
http://planetozh.com/blog/2009/09/top-10-most-common-coding-mistakes-in-wordpress-plugins/

Also, based on posts and comments by other wordpress developers serialized arrays are the bees knees. For instance:

http://wefunction.com/2009/10/revisited-creating-custom-write-panels-in-wordpress/

But that said, there are still times when custom tables may be the best solution.

thanks for the pointers. I'm wondering what would be the times when you would use custom tables. the wpmu install is going to be run more like a CMS install, so i won't be seeing 10,000 blogs, probably an average of 1000. I will also be using this as a stand alone WP plugin where many tables don't matter so much. So I'm not too concerned with just adding more tables.

My concern is what are the benefits I gain by using built in tables (like export, and compatibility as mentioned) and what are the benefits and drawbacks of using my own tables.

many thanks for the replies. The link to serializing meta box input is very helpful.

So far it seems people are leaning towards using the built in tables. But at what point is one constricted by those tables and you need to create new tables?

Here is a mockup that gives an idea of the final plugin admin screen.
http://www.retreatsite.com/program-admin/
It is pretty full featured.

any other insights?

How open are you to using an existing plugin that would do what you want without writing a whole new one? :D

http://pods.uproot.us/

Thanks andrea, I'll check that out. I'm open to anything. I was even thinking of using this: http://www.gravityforms.com as a base, then extending from there.

Pods could be great to prototype with, but how will it be in a working environment, what with two updates to deal with: wp and then pods on top of it. do you have experience with it? In the past, I've used More Fields, but i don't know how well it is updated/supported.

My personal opinion is that Pods probably is a bad choice for blog hosting in MU. From what I've seen, it's a fairly powerful application development framework for WordPress. It's modeled on the popular Content Construction Kit in Drupal, and I agree with the Pods developer that the default wordpress content types are a serious limitation for using WordPress as a full featured CMS.

However, Pods requires actual developer involvement to write PHP to handle the content types that Pods generates and that becomes a security risk in blog hosting and community site implementations of MU where users are their own blog admins.

This tutorial is both awesome to me as a developer and scary as hell as an MU administrator. (The video link skips right to the scary part.)
http://www.youtube.com/watch?v=AYzgy0RcEqQ#t=3m3s

It will be interesting to see how Custom Post Types in wordpress 2.9/3.0 may change some of the landscape for building these kinds of solutions too.

about custom post types in 2.9, I couldn't quite understand how to implement any of that. According to this post http://wordpress.org/support/topic/327370 the UI is put off for 3.0 but some of the fixes and functionality is included in 2.9. Is that accurate? and if so, is anyone working on plugins to work with any of that? Or is there documentation on what can be done?

But Pods (or something similar) might work in my situation if I am the only one doing the development. All the blog users will never touch php, they will just use the system built for them.

Considering it's still in development, the best you can do is get the beta and dig in to the code, scour the trac discussions, etc. But it could be a cool opportunity to be one of the early plugins to support them and define some of the UI conventions.

I've seen it in action, it's freakin' amazing. Insane type of amazing.

thanks all, I'll dig in.

I just talked to another developer and his suggestion was to use custom post types for as much as you can, and then only when you have cases where it won't work, then switch over the making your own tables. The downside with using your own tables is that you have to recreate many wordpress functions.

The plugin I mentioned above makes it so you don't have to even think about any of that. You can do more with it in a couple hours than you could ever code in that amount of time.

what happened to this?
would like to see a beta at least :)

I believe the direction everything is going in is WP 2.9 (and soon with UI) custom post types. My guess is that the likes of pods and flutter will become less popular once there are easy ways to use custom post types. Or maybe the power of those plugins will be moved over and use custom post types as their base and build from there.

If it creates 9 new tables for new blog. Is chance to get any database size errors? Let me know you feedbacks. Thanks