Comment meta

[markjaquith]

There was some discussion about comment meta (I think in a wp-meetup), but I can't find a ticket, so here it is.

There should be a commentmeta table that stores metadata associated with specific comments. This allows plugins to store data associated with specific comments, instead of trying to shoehorn it into postmeta somehow. Some possible uses:

• Geo data
• Additional fields (like a quiz, or the commenter's age, etc)
• A link to the commenter's CoComment feed
• The name of the commenter's site
• Comment subscription status (my plugin alters the comment table... something I wish could have been avoided)
• Antispam plugin data related to the comment

[markjaquith]

Take 1

[markjaquith]

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.

[markjaquith]

Take 2

[markjaquith]

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

[matt]

This seems like somewhat edge functionality.

[markjaquith]

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.

[MikeLittle]

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.

[markjaquith]

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).

[ryan]

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

[mdawaffe]

I like.

[markjaquith]

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

[McShelby]

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

[technosailor]

+1

Is this patch needing refreshing?

[westi]

+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|....)?

[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.

[filosofo]

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.

[westi]

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)

[markjaquith]

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

[matt]

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.

[pishmishy]

Bumping milestone for feature freeze.

[alexkingorg]

I see there hasn't been much action on this lately, but this would be a very valuable feature for WordPress.

When using WordPress as a CMS it would enable comments to be re-purposed in a much more robust way when needed.

When using WordPress as a blog, it would eliminate the need for plugin authors to create new db tables/columns to store additional comment information.

[kolev]

Is it possible to move this to the 2.8 milestone as it would add great value to the platform and yet it's been pushed back almost indefinitely?

[Denis-de-Bernardy]

+1 to the idea too.

[ryan]

Moving to Future Release until we commit to it.

[scribu]

Also see #5183.

[Otto42]

I find myself needing something like this today. I want to store some data about every comment made, like the commenter's FriendFeed account name. I want to be able to display links to the commenter's social sites, sort of thing.

Easiest way is to simply store this information as metadata alongside the comment, tied to its ID. Then in the comment loop, I can pull comment meta info and display the resulting link, if there is one.

As it stands now, it appears I have to have my plugin make its own table for what is basically one piece of information tied directly to the comment. :(

+1 from me.

[scribu]

Replying to Otto42:

As it stands now, it appears I have to have my plugin make its own table for what is basically one piece of information tied directly to the comment. :(

If it's only one piece of information per comment, you can just add another column to the comments table.

[westi]

Replying to scribu:

Replying to Otto42:

As it stands now, it appears I have to have my plugin make its own table for what is basically one piece of information tied directly to the comment. :(

If it's only one piece of information per comment, you can just add another column to the comments table.

Not every row will have an entry (pingbacks, trackbacks)

Comment Meta will be useful for lots of other stuff too

[scribu]

So why hasn't it been commited in 3 years, then?

I would venture to say that one of the primary reasons is the fact that adding a new table from a plugin isn't difficult at all. Plus you get to add whatever columns you need. The same goes for all the other meta tables suggested.

[Otto42]

Adding a new table from a plugin is indeed not difficult. However it is badly "unclean" and it makes it very difficult to add support for WordPress MU as well, which I would very much like. Same problem with altering the comments table.

And it's not one piece of information per comment. It's zero to undefined pieces of information, because I may later expand it to include other services as well.

[Otto42]

Replying to scribu:

So why hasn't it been commited in 3 years, then?

I would venture to say that one of the primary reasons is the fact that adding a new table from a plugin isn't difficult at all. Plus you get to add whatever columns you need. The same goes for all the other meta tables suggested.

The other meta tables suggested already exist. usermeta, postmeta, these have been around a while.

There was talk about a generic object meta table, unifying these, but that hasn't been done for a lot of reasons, with speed being a big one.

[Otto42]

What I'd like to see:
CREATE TABLE $wpdb->postmeta (

meta_id bigint(20) unsigned NOT NULL auto_increment,
comment_id bigint(20) unsigned NOT NULL default '0',
post_id bigint(20) unsigned NOT NULL default '0',
meta_key varchar(255) default NULL,
meta_value longtext,
PRIMARY KEY (meta_id),
KEY post_id (post_id),
KEY comment_id (comment_id),
KEY meta_key (meta_key)

) $charset_collate;

This gives you the ability to add arbitrary key=value pairs to a comment. It's particularly handy in cases where you need to store some piece of information to go with the comment.

Example use: If I want to allow somebody to sign their comment using, say, Twitter, then I can store their Twitter ID with the comment and post a link to their Twitter. At the same time, I can go and use Twitter's API to get their profile picture from there. A simple action added to the get_avatar hook will then let me override the displayed gravatar (since I don't have their email anyway, since they used Twitter to authenticate) and I can show their profile pic from twitter instead. Repeat for FriendFeed (the code is actually much the same). Repeat for Facebook Connect, or Google's OpenSocial thing, or other service of your choice, many social systems offer these basic capabilities in the API.

I want people to be able to use other services to comment on my blog *without* signing up for an account. In other words, I don't want these people in my wp_users table, I just want to get their credentials from elsewhere, and use those credentials to let them sign their comments. Then i can display their comments and say "X from twitter says" and "Y from facebook replied" and so on.

[westi]

Per this weeks dev meeting this is going into 2.9.

Primary reason is to store the Trash Metadata for comments.

Patches for a comment_meta system welcome.

[Otto42]

I think your patch is missing something here. Where's add_metadata, update_metadata and get_metadata?

[scribu]

Otto, you're right. Forgot to include meta.php. It's fixed now.

[filosofo]

The API functions should be named add_meta_data, update_meta_data, and get_meta_data, where the significant difference is that there is an underscore separating the key words.

It seems like a small difference, but the vast majority of WordPress functions are of the form [word]_[word], except for a few exceptions (such as the user meta functions) which make things hard to remember.

[Otto42]

Replying to filosofo:

The API functions should be named add_meta_data, update_meta_data, and get_meta_data, where the significant difference is that there is an underscore separating the key words.

It seems like a small difference, but the vast majority of WordPress functions are of the form [word]_[word], except for a few exceptions (such as the user meta functions) which make things hard to remember.

But "metadata" is one word. Not two.

Still, it's a bikeshed issue that isn't worth arguing about. Whichever way the devs prefer.

[scribu]

I moved the *_comment_meta() functions from wp-admin/includes/comment.php to wp-includes/comment.php

Left the *_metadata() names.

[filosofo]

Replying to Otto42:

But "metadata" is one word. Not two.

I guess you're right. That does seem to be how WP uses it in wp_generate_attachment_metadata and wp_read_image_metadata.

[hakre]

any chance to see a testcase for this?

[scribu]

I've added the meta-testing.php plugin for testing.

Feel free to expand it.

[scribu]

Patch for 2.9 (uses common api for posts and comments)

[scribu]

Refreshed patch with additional hooks for inserting and deleting.

[ryan]

Looks good to me. Haven't been able to break the postmeta parts yet.

[westi]

Looks good here too.

Passes all the postmeta tests I have written for wordpress-tests and fails the one the current code failed too.

Going to remove a little of the noise from the patch to keep this just commentmeta stuff for now.

[westi]

(In [11943]) First pass commentmeta implementation. See #2659 props scribu.

[westi]

See #10803 for the bug identified.

[westi]

(In [11946]) Don't pass undefined vars to action hooks. See #2659.

[Lazy79]

(In [11943]) First pass commentmeta implementation. See #2659 props scribu.

tried it, but after uploading the files and db update the frontpage shows:

cannot find function: update_meta_cache in /wp-includes/post.php

is it known or has it something to do with my installation of wp?

if i am in the wrong place, pls don`t be angry - i am really new to this.

[westi]

Replying to Lazy79:

(In [11943]) First pass commentmeta implementation. See #2659 props scribu.

tried it, but after uploading the files and db update the frontpage shows:

cannot find function: update_meta_cache in /wp-includes/post.php

is it known or has it something to do with my installation of wp?

if i am in the wrong place, pls don`t be angry - i am really new to this.

This sounds like you have not got all the files - probably missing the new file wp-includes/meta.php.

It may be easier to use the builtin updater and go to the latest nightly build.

[ryan]

(In [11955]) Key should be comment_id not post_id. see #2659

[hakre]

Replying to scribu:

I've added the meta-testing.php plugin for testing.

Feel free to expand it.

I thought about tests in the testsuite working on blank data and therefore be re-produceable. your test does not reset the comments metadata after certain tests have been made and therefore it can influence each other and compromise the output.

[caesarsgrunt]

There is a bug which I'm pretty sure is in the commentmeta handler, so that when a piece of metadata is deleted for one comment, metadata with than name is deleted for all comments. See ​http://core.trac.wordpress.org/ticket/4529#comment:95

[azaozz]

(In [11996]) Fix delete_metadata(), see #2659

[azaozz]

Replying to caesarsgrunt:

There is a bug which I'm pretty sure is in the commentmeta handler...

Yes, delete_metadata() was ignoring comment_id/post_id and deleting all fields with the meta name for all comments/posts. Fixed in [11996].

[westi]

(In [11999]) Fix the specification of the object_type column in delete_metadata so that it will delete stuff if $delete_all is false. See #2659

[westi]

I think we can say this is done.

Please open a new ticket for any bugs found with the new feature.