WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 4 years ago

#2659 closed task (blessed) (fixed)

Comment meta

Reported by: markjaquith Owned by: westi
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.1
Component: Comments Keywords: has-patch tested commit
Focuses: Cc:

Description

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

Attachments (4)

comment_meta_001.diff (10.7 KB) - added by markjaquith 8 years ago.
Take 1
comment_meta_002.diff (12.6 KB) - added by markjaquith 8 years ago.
Take 2
meta-testing.php (1.4 KB) - added by scribu 5 years ago.
comment_meta.diff (17.8 KB) - added by scribu 5 years ago.
Patch for 2.9 (uses common api for posts and comments)

Download all attachments as: .zip

Change History (65)

markjaquith8 years ago

Take 1

comment:1 markjaquith8 years ago

  • Keywords has-patch needs-testing added
  • Status changed from new to assigned

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.

markjaquith8 years ago

Take 2

comment:2 markjaquith8 years ago

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

comment:3 matt8 years ago

This seems like somewhat edge functionality.

comment:4 markjaquith8 years ago

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.

comment:5 MikeLittle8 years ago

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.

comment:6 markjaquith8 years ago

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

comment:7 ryan8 years ago

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

comment:8 mdawaffe8 years ago

I like.

comment:9 markjaquith8 years ago

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

comment:10 McShelby7 years ago

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

comment:11 matt7 years ago

  • Milestone changed from 2.1 to 2.2

comment:12 foolswisdom7 years ago

  • Milestone changed from 2.2 to 2.3

comment:13 technosailor7 years ago

+1

Is this patch needing refreshing?

comment:14 westi7 years ago

  • Milestone changed from 2.3 to 2.4 (next)

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

comment:15 follow-up: intoxination7 years ago

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.

comment:16 filosofo7 years ago

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.

comment:17 in reply to: ↑ 15 westi7 years ago

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)

comment:18 markjaquith7 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

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

comment:19 matt7 years ago

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.

comment:20 foolswisdom7 years ago

  • Keywords early added

comment:21 pishmishy6 years ago

  • Milestone changed from 2.5 to 2.6

Bumping milestone for feature freeze.

comment:22 alexkingorg6 years ago

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.

comment:23 kolev5 years ago

  • Component changed from General to Comments
  • Milestone changed from 2.9 to 2.8
  • Type changed from defect (bug) to feature request

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?

comment:24 ryan5 years ago

  • Milestone changed from 2.8 to 2.9

comment:25 Denis-de-Bernardy5 years ago

+1 to the idea too.

comment:26 ryan5 years ago

  • Milestone changed from 2.9 to Future Release

Moving to Future Release until we commit to it.

comment:27 Denis-de-Bernardy5 years ago

  • Keywords early removed

comment:28 scribu5 years ago

Also see #5183.

comment:29 follow-up: Otto425 years ago

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.

comment:30 in reply to: ↑ 29 ; follow-up: scribu5 years ago

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.

comment:31 in reply to: ↑ 30 westi5 years ago

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

comment:32 follow-up: scribu5 years ago

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.

comment:33 Otto425 years ago

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.

comment:34 in reply to: ↑ 32 Otto425 years ago

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.

comment:35 Otto425 years ago

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.

comment:36 westi5 years ago

  • Milestone changed from Future Release to 2.9
  • Owner changed from markjaquith to westi
  • Status changed from accepted to assigned
  • Type changed from feature request to task (blessed)

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.

comment:37 scribu5 years ago

  • Cc scribu@… added

scribu5 years ago

comment:38 scribu5 years ago

  • Keywords has-patch added; needs-patch removed

comment:39 Otto425 years ago

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

comment:40 scribu5 years ago

  • Keywords comment meta removed

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

comment:41 follow-up: filosofo5 years ago

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.

comment:42 in reply to: ↑ 41 ; follow-up: Otto425 years ago

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.

comment:43 scribu5 years ago

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

Left the *_metadata() names.

comment:44 in reply to: ↑ 42 filosofo5 years ago

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.

comment:45 hakre5 years ago

  • Keywords needs-testing added

any chance to see a testcase for this?

comment:46 follow-up: scribu5 years ago

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

Feel free to expand it.

scribu5 years ago

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

comment:47 scribu5 years ago

  • Keywords tested commit added; needs-testing removed

Refreshed patch with additional hooks for inserting and deleting.

comment:48 ryan5 years ago

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

comment:49 westi5 years ago

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.

comment:50 westi5 years ago

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

comment:51 westi5 years ago

See #10803 for the bug identified.

comment:52 westi5 years ago

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

comment:53 follow-up: Lazy795 years ago

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

comment:54 in reply to: ↑ 53 westi5 years ago

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.

comment:55 ryan5 years ago

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

comment:56 in reply to: ↑ 46 hakre5 years ago

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.

comment:57 follow-up: caesarsgrunt5 years ago

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

comment:58 azaozz5 years ago

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

comment:59 in reply to: ↑ 57 azaozz5 years ago

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

comment:60 westi5 years ago

(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

comment:61 westi4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

I think we can say this is done.

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

Note: See TracTickets for help on using tickets.