Make WordPress Core

Opened 15 years ago

Closed 12 years ago

Last modified 6 years ago

#11541 closed enhancement (fixed)

Remove all IM fields from core.

Reported by: shanef's profile ShaneF Owned by: shanef's profile ShaneF
Milestone: 3.6 Priority: normal
Severity: normal Version: 2.9
Component: Users Keywords:
Focuses: Cc:

Description (last modified by dd32)

Due to the Contact Method fields not being used by the majority of themes, and the current list of Contact Methods is lacking many of the networks certain cultures use.

Perhaps it's best that they be removed entirely, and relied upon the Theme and/or Plugins to add the contact methods which suit the Culture group to be added.

Attached patch removes current contact methods from the profile page, Does not affect the underlying database.

Attachments (4)

11541.diff (501 bytes) - added by ShaneF 15 years ago.
11541.2.diff (633 bytes) - added by ShaneF 15 years ago.
360upgrade.diff (666 bytes) - added by tw2113 12 years ago.
11541ut.patch (637 bytes) - added by bananastalktome 12 years ago.
Remove contact methods from test_update_user

Download all attachments as: .zip

Change History (42)

@ShaneF
15 years ago

#1 @ShaneF
15 years ago

  • Owner set to ShaneF
  • Status changed from new to accepted
  • Type changed from defect (bug) to enhancement

#2 @demetris
15 years ago

If I may be so bold as to ask, why? :-)

Or, why not adding identi.ca too? (Or identi.ca only, since we should be supporting open solutions, and identi.ca runs on a platform that supports federated microblogging.)

And what about Facebook?

In my opinion, this is not core material.

#3 @nacin
15 years ago

The Twitter explosion potentially warrants its inclusion in core, but that filter was added in 2.9 and makes it extremely easy:

function add_twitter_as_contact_method( $user_contactmethods ) {
   return array_merge( $user_contactmethods, array( 'twitter' => 'Twitter' ) );
}
add_filter( 'user_contactmethods', 'add_twitter_as_contact_method' );
...
the_author_meta('twitter');

#4 @ShaneF
15 years ago

A lot of people use twitter and from what I am reading on twitter itself is that this should be nativity supported, not have to work because of a plugin.

Again.. not all users can do this and know how even though there is a thing in codex. But people look for that all the time. Why not just add it?

#5 follow-up: @dd32
15 years ago

In my opinion, All IM fields should be striped from core. Its impossible to cater for everyone, whilst not over-doing it.

Every culture group and country prefer different networks, in the past, there were a limited selection so it was fine, Today, You might as well include FaceBook, Myspace, Orkut, Tagged, Bebo, Windows Live Spaces (different from MSN AFAIK?).. All those mentioned are supposably more common than Twitter world wide, which i agree with.

@ShaneF
15 years ago

#6 follow-up: @ShaneF
15 years ago

  • Summary changed from Add Twitter to User Profile Field to Remove all IM fields from core.

Agree. Patch has nothing. Plugins/Themes will have to provide those in the user_contactmethods filter for them to be added.

#7 @dd32
15 years ago

  • Description modified (diff)
  • Keywords dev-feedback added; commit removed

#8 in reply to: ↑ 6 ; follow-up: @nacin
15 years ago

Replying to ShaneF:

Agree. Patch has nothing. Plugins/Themes will have to provide those in the user_contactmethods filter for them to be added.

If we are to do this, it needs to be backwards compatible. People currently using the core fields will suddenly find their data inaccessible.

The easiest way to be backwards compatible, and to raise awareness of the user_contactmethods filter, is to leave them in. Of course, if this new filter isn't documented in the Codex, it should be.

I know we hate core options, and I'd definitely like to see a (core/canonical?) plugin to step up and manage these. Perhaps I'll do it...

#9 in reply to: ↑ 8 @ShaneF
15 years ago

Replying to nacin:

I know we hate core options, and I'd definitely like to see a (core/canonical?) plugin to step up and manage these. Perhaps I'll do it...

Go for it. In this case I would agree this is the proper thing for a canonical/core plugin.

#10 @hakre
15 years ago

Since this patch will break backwards compability, what now? Drop it? Core-Plugin it prior to delete? Add a filter-function that provides the (current) default one so that it can be removed by other plugin authors?

How to deal with changes that break backwards compability?

#11 @dd32
15 years ago

what now? Drop it? Core-Plugin it prior to delete?

My opinion is to just drop the thing, and let a plugin be developed before next release, By then, should at least have the canonical plugins ideas worked out a bit.

I'll write the plugin to make it happen if need be.

#12 @hakre
15 years ago

For a plugin stub, see this plugin code, it might be of use.

#13 @nacin
15 years ago

  • Milestone changed from 3.0 to 3.1

We need this to be backwards compatible, or at least have a core plugin tied to all of it. dd32 and I have talked about this, and I can begin to work on something at some point.

Moving it out of 3.0 as we're not going to satisfy those requirements now.

#14 in reply to: ↑ 5 ; follow-up: @mikeschinkel
15 years ago

  • Cc mikeschinkel@… added

Replying to dd32:

In my opinion, All IM fields should be striped from core. Its impossible to cater for everyone, whilst not over-doing it.

Every culture group and country prefer different networks, in the past, there were a limited selection so it was fine, Today, You might as well include FaceBook, Myspace, Orkut, Tagged, Bebo, Windows Live Spaces (different from MSN AFAIK?).. All those mentioned are supposably more common than Twitter world wide, which i agree with.

A better idea would be to remove them by default from the core and then provide an admin page where all known ones are listed that allows a user to select the ones they want and add them. "Known" ones could be added with each new version much like known places for import/export are added.

#15 @nacin
14 years ago

  • Milestone changed from Awaiting Triage to Future Release

#16 @Ipstenu
13 years ago

  • Cc ipstenu@… added

#17 in reply to: ↑ 14 ; follow-up: @jane
13 years ago

Replying to mikeschinkel:

A better idea would be to remove them by default from the core and then provide an admin page where all known ones are listed that allows a user to select the ones they want and add them.

Decisions, not options.

I'm with Dion in thinking that we should work toward removing these at some point. If someone proposed IM fields as a new feature today we'd probably say plugin territory. Can we do a check of themes/plugins in the directory to see who's using those fields, give them a 6 month advance notice that it will be leaving, and then just break backwards compat in this case to sub with a plugin?

#18 @andrea_r
13 years ago

+1 to ripping it out and replacing with a plugin.

#19 @scribu
13 years ago

  • Cc scribu added

#20 in reply to: ↑ 17 @mikeschinkel
13 years ago

Replying to jane:

Replying to mikeschinkel:

A better idea would be to remove them by default from the core and then provide an admin page where all known ones are listed that allows a user to select the ones they want and add them.

Decisions, not options.

Then rip them out and allow them to be added via a plugin. Or, what @andrea_r said.

#21 @sc0ttkclark
12 years ago

  • Cc lol@… added

+1 to andrea_r being to rip out and replace as plugin

#22 @tw2113
12 years ago

  • Cc michael.d.beckwith@… added

I would like to champion this for either 3.6 or 3.7. Having the filter in place will make it easy for anyone wanting to add their own listings/social media profiles/etc is well enough, and having the spot blank will reduce visual clutter and space for those not needing at all. Simplification.

#23 @nacin
12 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed
  • Milestone changed from Future Release to 3.6

A few years ago, I would argue it was fairly rare to put stuff in the options (or sitemeta) tables for the purposes of hiding or disabling something (or a general behavior shift) for new installs. This is partially why I've avoided pushing this until now.

But, we've shown we haven't been afraid to put stuff in options/sitemeta. 3.5 gave us ms_files_rewriting and link_manager_enabled, and flipped the default multisite setting for upload checks to no default limit.

We've done this before, however fleeting. 3.0 gave us global_terms_enabled. 2.6 gave us enable_xmlrpc and enable_app. In 3.3, we added initial_db_version but didn't use it; that's because for pointers we decided to go with the user-specific dismissed_wp_pointers (which is created for all new users).

I think it is time to shut these off for new installs. New option: legacy_contact_methods = 0. We can even shut them off for old installs that don't use them, by checking if this query returns anything:

SELECT meta_key FROM $wpdb->usermeta WHERE meta_key IN ('yim', 'jabber', 'aim') AND meta_value <> '' LIMIT 1

Some notes on implementation:

  • We should avoid doing this query when DO_NOT_UPGRADE_GLOBAL_TABLES is set, because that will signify this may be run on a huge usermeta table.
  • It should be run only on the main site, as usermeta is of course a global table in multisite.
  • As it is global, it should be stored globally, so get_site_option().

It probably took me longer to write this comment than it would be to code it.

Last edited 12 years ago by nacin (previous) (diff)

#24 @nacin
12 years ago

A cheap way out would be to simply check initial_db_version. Won't shut it off for new installs, but also will mean no new option, too. If an old install wanted to remove them, they would need to write a plugin to remove (or modify) them.

#25 @tw2113
12 years ago

Diff file added for wp-admin/includes/upgrade.php for a start where the code would take place for 3.6 upgrade/install.

Has main_site/DO_NOT_UPGRADE if statement, ready for code. Not quite sure how to do the rest, but it's a start.

@tw2113
12 years ago

#26 @TheAdityaJain
12 years ago

  • Cc mail@… added

#27 @toscho
12 years ago

  • Cc info@… added

#28 @bradparbs
12 years ago

  • Cc brad@… added

#29 @SergeyBiryukov
12 years ago

#23193 was marked as a duplicate.

#30 @kovshenin
12 years ago

  • Cc kovshenin added

#31 @sabreuse
12 years ago

  • Cc sabreuse added

#32 @alex-ye
12 years ago

  • Cc nashwan.doaqan@… added

#33 @mboynes
12 years ago

  • Cc mboynes@… added

#34 @nacin
12 years ago

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

In 23588:

Remove the three default contact methods (AIM, YIM, Jabber) for new installs. fixes #11541.

@bananastalktome
12 years ago

Remove contact methods from test_update_user

#35 @bananastalktome
12 years ago

  • Cc bananastalktome@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Removed aim, yim, and jabber from unit tests in test_update_user

#36 @SergeyBiryukov
12 years ago

In 1245/tests:

Remove AIM, YIM, and Jabber fields from wp_update_user() test. props bananastalktome. see #11541.

#37 @SergeyBiryukov
12 years ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from reopened to closed

#38 @butterflymedia
6 years ago

This has been reopened as #44374.

Note: See TracTickets for help on using tickets.