Comment meta

Take 1

Take 1 is up. I bumped the WP DB version to 3673, which is current+1 as of this posting. After applying the patch, go to your wp-admin. If it doesn't say your DB is out of date, you'll have to manually UPDATE prefix_options SET option_value = '3672' WHERE option_name = 'db_version';

Test it out by using add_comment_meta(), delete_comment_meta(), and get_comment_meta(). They work exactly like their 'post' brethren, except that they take a comment id. In fact, the [add/delete/get]_[comment/post]_meta() functions are just pointers now to generic wp_[add/delete/get]_meta() functions whose last parameter is a string of 'comment' or 'post' ... these aren't meant to be used directly... they just save having 6 big functions when 3 flexible ones will do.

Things to test:

• adding meta
• updating meta
• deleting meta
• deleting a comment (make sure the meta goes too)
• deleting a post (make sure all of its comments have their meta deleted)

Let me know how it goes.

Take 2

Take 2 adds automatic comment meta querying for all comments returned by comments_template()

This seems like somewhat edge functionality.

Just today I came upon another instance where I would have liked to have had comment meta. I host pages about my WP plugins on my blog, and I get a lot of support questions on there. It would be nice to be able to have a "This is a support question" tick box for the comment form. I could then highlight them, or put them on my WP dashboard. When resolved, the meta value could change to something else and it would be marked as resolved. Bam, all of a sudden WP has basic support ticket capability.

If no one else thinks Comment Meta is a useful feature, I'll let it die, but I think there are a lot of plugin authors who could put this to good use, and really expand what is possible with WP.

I too think this is a good idea. I recently had to add voluntary capture of company and occupation to a WordPress comment form. Whilst I used filters and actions for some of the work. I ended up adding columns to the wp_comments table! Meta data would have been great! +1 from me. I'll try to d/load your patch and see if I could have implemented what I needed with it.

Alright... last plea for this one. Yea or nay, people. I still hold that it could really open WP up to some cool plugin functionality. If all else fails, I can release it as a plugin that other plugin authors can use (similar to Skippy's wp-cron plugin).

I don't have a burning desire for it, but I'll give it the ole plusone.

I like.

I'll have to rework the patch, which I'll do if I get the official thumbs up. Let me know.

The Favatar plugin also adds new columns to the comments table in lack of a commentsmeta table. I would appreciate to have commentsmeta table.

+1

Is this patch needing refreshing?

+1 for the idea.

It's too late for 2.3 though.

Pushing to 2.4 - lets get the framework for this in early.

Things that would be nice to store in comment_meta in the core:

1. Outcome of the built in spam checks.

Should we move to a single generic "meta" table rather than a table for each type of meta (post|comment|....)?

I'm not to sure about this. What kind of performance impact will it have on blogs that see heavy comments? I'm thinking of sites that get 1,000+ comments a day, with some posts getting 300+ comments.

Would there be a significant performance hit if we just had a general object meta, for posts, users, comments, links, or whatever? It might be better than filling up the options table, which is what a number of plugins do when they need meta-data but don't have enough to warrant creating their own table.

Replying to intoxination:

I'm not to sure about this. What kind of performance impact will it have on blogs that see heavy comments? I'm thinking of sites that get 1,000+ comments a day, with some posts getting 300+ comments.

There is some performance impact.

Most of it though is inserting stuff in the database rather than quering the meta - i would not expect the meta to be autoloaded by queried on demand.

There are already plugins that do this themselves with there own tables (SK2 for example has a table for storing it's meta info about a comment)

We don't have to load it unless we're going to use it. But if we do load-on-demand, it would make sense to query commentdata for the entire $post->ID when the first request comes in. If we store a secondary id (the post ID), we could query them without any joins.

And yeah, it might be worth moving to a generic metadata table.

1. No new tables
2. Term meta
3. Plugin meta

This discussion is going in weird places, it'd probably be best to consider:

1. What are specific use cases we hope to enable.
2. What is the most flexible way to do that, and the least flexible way.
3. What new overhead is introduced, and how much new code does it create.
4. How much of our userbase do we hope to use this.

Also maybe a forum like wp-hackers would be more appropriate.

Bumping milestone for feature freeze.