Skip to:
Content

BuddyPress.org

Opened 6 years ago

Closed 6 years ago

#7817 closed enhancement (fixed)

Privacy: Data export for XProfile

Reported by: boonebgorges's profile boonebgorges Owned by:
Milestone: 4.0 Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords:
Cc:

Description

Parent ticket: #7698

We should include XProfile data in WP user data exports.

I'll post a patch here momentarily with some preliminary questions for discussion.

Attachments (2)

Screenshot_2018-05-11_15-21-43.png (53.9 KB) - added by boonebgorges 6 years ago.
7817.diff (4.7 KB) - added by boonebgorges 6 years ago.

Download all attachments as: .zip

Change History (12)

#1 @boonebgorges
6 years ago

7817.diff is a first pass at a patch. Screenshot_2018-05-11_15-21-43.png shows what it looks like in the data export. A few comments:

  1. I chose to call it 'Extended Profile Data' in the export, because users may not know (or want to know) that it has anything to do with BuddyPress.
  2. The method I'm using for fetching user data is not totally efficient. I'm sorta fetching it twice: a single query to see which data a user has created, and a second query for each field. The second query is so that I can use BP's built-in filters for formatting data (comma formatting for arrays, stripslashes, unserialize, etc etc etc). I think the duplicated queries are better than the other tricks we'd have to use (reapplying filters, hijacking an existing filter name, etc).

#2 @boonebgorges
6 years ago

  • Type changed from defect (bug) to enhancement

@boonebgorges
6 years ago

#3 @DJPaul
6 years ago

At a quick glance, the approach in the patch looks OK. I couldn't remember what BP_XProfile_ProfileData::get_all_for_user() is used for; it seems odd it doesn't do the output processing we expect. Is that something we could change there, or if not appropriate, could we have xprofile_get_field_data() optionally take that field object/array, rather than re-fetch?

That relatively minor detail aside, this looks fine. Great work!

#4 @DJPaul
6 years ago

  • Milestone changed from 3.1 to 4.0

Milestone renamed

#5 @boonebgorges
6 years ago

In 12110:

Privacy: Data exporter for XProfile.

See #7817.

#6 @boonebgorges
6 years ago

Thanks for the feedback, @DJPaul. I agree that the get_all_for_user() treatment is quite clunky, and I agree that something should be done about it. That said, I don't want to hold up progress on this ticket for internal improvements of that nature, which might end up being tricky - adding the output processing to the existing function might, for example, introduce compatibilty problems. So let's go with the inefficient solution for now.

The first version has been committed, to make iteration easier for this importer and others.

#7 @boonebgorges
6 years ago

In 12111:

Privacy: Better naming conventions for functions introduced in [12110].

See #7817.

#8 @DJPaul
6 years ago

We've used BuddyPress XProfile Data as the user-facing name of the exporter. That "xprofile" needs spelling out ("extended profile") as the former is jargon that the project uses internally.

#9 @boonebgorges
6 years ago

To be clear: the label that's in the data export is 'Extended Profile Data'. The label that used in the WP Dashboard in case of errors is "BuddyPress XProfile Data", so should only be seen by admins.

#10 @boonebgorges
6 years ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.