Project

General

Profile

Actions

Feature #2457

closed

Feature #404: Customizable user profiles

Widgetized profile API

Added by Boone Gorges over 11 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
BuddyPress (misc)
Target version:
Start date:
2013-02-20
Due date:
% Done:

100%

Estimated time:
(Total: 25.00 h)
Deployment actions:

Description

A large part of the profile redesign (#404) is the introduction of a widgetized section of the profile. The current ticket is a catch-all for the underlying API that will power this new profile. Here's a brief spec, as I currently understand it. (See the bottom half of http://teachingmultimedia.com/commons/portfolio_protoype/portfolio.html for a visual reference.)

a. We need an extensible base class for registering, storing, retrieving, and displaying profile widgets. This'll be roughly akin to WP_Widget, in function if not in technical details.
b. We'll need a core hook where we (and other plugin authors) can register their own profile widgets. (Something like widgets_init and the WP widget factory.)
c. A modular data storage layer for the widget API. In MVC terms, (a) is sort of a controller; the storage model that I'm referring to in this bullet point should be independent and swappable. The modularity is important in case any of this ever gets considered for BuddyPress core.
d. Some of this data will be easily stored in the existing BP xprofile data tables (though we may have to fudge the xprofile_groups stuff, since fields will be defined on a user-by-user basis rather than by an admin). Some data will not fit naturally into xprofile: for instance, RSS addresses will be awkward, because you don't want them to show up in WP's default search, and structured data (such as Positions, which I'll describe in a separate ticket) will be taxonomy-like in structure. It's likely that in some cases, data will be mirrored (eg, structured data stored in taxonomies, with a concatenated string stored in xprofile for search and display).
e. BP's xprofile visibility API should be supported. (This is an argument for using xprofile for storage/display wherever possible.)
f. The first implementation of the Edit interface will probably have to be done in parallel with the API work. This initial implementation should be javascript-free. The JS/AJAX version, a progressive enhancement, will be covered by a separate ticket.

Assigning to myself for now, as I have some rough ideas about the technical structure. My plan is to do a first pass at the core functionality myself, and then to powwow with Ray and Dom about moving forward and fleshing it out.


Subtasks 1 (0 open1 closed)

Feature #2464: Profile widget typesResolvedBoone Gorges2013-02-20

Actions
Actions

Also available in: Atom PDF