Making WordPress.org

Opened 10 years ago

Last modified 4 months ago

#518 assigned enhancement

unify profiles

Reported by: fstaude's profile f.staude Owned by:
Milestone: Priority: high
Component: Profiles Keywords:
Cc:

Description

depending on where I am, I have different profiles.

in the plugin area - http://profiles.wordpress.org/fstaude

in the support area - http://wordpress.org/support/profile/fstaude

in the german support area - http://de.forums.wordpress.org/profile/fstaude

can not be combined?

Change History (20)

#1 @iandunn
10 years ago

  • Keywords needs-patch removed
  • Owner set to iandunn
  • Status changed from new to accepted
  • Type changed from defect to task

This is already planned, but we need to migrate some of the Forums data into the main Profile system first.

#2 @extendwings
10 years ago

  • Cc daisuke@… added

This ticket was mentioned in Slack in #forums by netweb. View the logs.


9 years ago

#4 @kidsguide
9 years ago

  • Cc mpsplugins@… added

This ticket was mentioned in Slack in #meta by sam. View the logs.


9 years ago

#6 follow-up: @samuelsidler
9 years ago

  • Owner changed from iandunn to samuelsidler
  • Status changed from accepted to assigned

What things need to be migrated? An audit of those things would be good so we can start on this. Adding it to my list...

#7 @netweb
8 years ago

Related: https://github.com/WordPress/meta-environment/issues/64

  • Add profiles.wordpress.org to the BuddyPress.org network in the Meta Environment

#8 in reply to: ↑ 6 @SergeyBiryukov
8 years ago

Replying to samuelsidler:

What things need to be migrated? An audit of those things would be good so we can start on this.

#129 is now fixed, so that's great. Other things to consider (from #1868):

  • The Activity page only displays the latest replies. There should be a way to browse all user's topics and replies.
  • Forum profiles should have UI in the forum language, whereas WP.org profiles are intentionally English-only. Merging them would require some kind of i18n roadmap for WP.org profiles.

This ticket was mentioned in Slack in #forums by sergey. View the logs.


8 years ago

This ticket was mentioned in Slack in #meta by netweb. View the logs.


7 years ago

#11 @obenland
7 years ago

  • Type changed from task to enhancement

@iandunn What do you think is needed to fix this ticket?

#12 @iandunn
7 years ago

I'm not sure, I don't think I ever got too deep into this one. IIRC, there are a handful of things that people like about the Forum profiles that aren't supported by the BP Profiles, but I don't remember what they are (other than what's already been mentioned above).

#13 @netweb
7 years ago

Another case of "open sourcing" the profiles code used on w.org I'm afraid

There's plenty of bbPress and BuddyPress peeps about I'm sure would lend a hand to make w.org profiles amazeballs :)

#14 @dd32
4 years ago

  • Owner samuelsidler deleted

I was going to propose this as a new ticket, but I'm just going to re-use this old one since it's pretty much the same thing.


Currently there's several pieces of information between Profiles and Support Forum profiles which get out of sync:

  • Profiles: URL (BuddyPress field)
  • Profiles: About Me (BuddyPress field)
  • Support Profiles: URL (users table record)
  • Support Profiles: About me (usermeta description key)

There's also fields that get treated differently, the following fields are the same:

  • Support: First name / Last name / Display / Nickname fields
  • Profiles: Name (expands to )

Then there's fields which can only be set in one place:

  • Support: Email address
  • Support: Password
  • Support: Language (per support site?)
  • Support: Custom Support Title (per support site?)
  • Profiles: Location
  • Profiles: Origin Story
  • Profiles: GitHub Profile
  • Profiles: Contribution info
  • Profiles: Company / Job Title
  • Profiles: WordPress usage

In the past, Profiles couldn't do the same thing as the support forum, as it didn't have access to the memcache instance that the Support forums (and everything else) used, so it was impossible to have details changed in all places from profiles.

I think we should centralise these things, possibly removing most of the settings from the Support side and pushing it back into profiles instead, or at least sync the fields between the two. That can probably be achieved by having the fields marked read-only on Support sites, and have BuddyPress update the global "central" stores for the fields.

WordCamp/BuddyPress.org/bbPress.org sites can also alter some of these records through their user pages, as they use our shared user tables. Most of their edit ability should be removed/redirected too.

Version 0, edited 4 years ago by dd32 (next)

This ticket was mentioned in Slack in #bbpress by dd32. View the logs.


3 years ago

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


3 years ago

#17 @ocean90
3 years ago

#5813 was marked as a duplicate.

#18 @jonoaldersonwp
3 years ago

  • Priority changed from normal to high

Escalating, as this is causing some pretty serious SEO headaches (the sheet volume of thin/duplicate + noindex'd URLs are problematic). See #5813.

Last edited 3 years ago by jonoaldersonwp (previous) (diff)

#19 @dd32
2 years ago

In 12254:

Profiles: Add a method to allow non-profiles.wordpress.org sites to update xProfile fields.

Pre-set the users profile website field with the data from registration.

See #518.

This ticket was mentioned in Slack in #meta by dufresnesteven. View the logs.


4 months ago

Note: See TracTickets for help on using tickets.