Project

General

Profile

Actions

Feature #2457

closed

Feature #404: Customizable user profiles

Widgetized profile API

Added by Boone Gorges about 11 years ago. Updated over 10 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 #1

Updated by Boone Gorges almost 11 years ago

  • Status changed from Assigned to Resolved

This is finished. See #404 and https://github.com/cuny-academic-commons/cac-advanced-profiles

In a nutshell, the new structure is as follows. There is a abstract class called CACAP_Widget that has a bunch of dummy utility methods for creating new widget types. Then, in the widgets directory, there are a number of implementations: Text, Positions, RSS, Academic Interests (extends Text), etc. User/widget-type connections are represented by CACAP_Widget_Instance, which provides container methods for fetching and saving user-specific widget data (using internal methods provided by the CACAP_Widget extending class, which gives widget-specific data schemas).

Actions #2

Updated by Matt Gold almost 11 years ago

w00t!!

Actions

Also available in: Atom PDF