One of the things I look for when digging in to software systems (just because I’m me) are high level architecture diagrams (blueprints) that help me understand the big picture of how things are put together.I don’t often find them. So, sometimes I put them together myself. And that’s what I did in this case.
As I understand WordPress (WP) I think an Information Model for WP would be centralized around posts, the core information element that is central to both blogs and the page-based web content within WP. While users are not unimportant, they are not the core of the system. WP is not a Human Resource Management or a Customer Relationship Management system. For WP the User concept manages ownership and access rights to the post content, but the posts themselves are core to the functionality of the system. WP could potentially provide a functional system without, or with a very limited concept of, User as a key information entity. (Think about Wikipedia. No one needs to ‘log in’ to access content and even authors may only be known by their IP addresses, not their names.)
For BuddyPress (BP) this is not the case. For BP the user (the member) is central to the functionality and the purpose of the system. BP defines itself as “social networking in a box.” It is entirely about the users! Yet, BP, as a plugin component of WP, is dependent on some portion of the WP concept and implementation of User. (The WP user is still the gateway to access and authentication for the system.) I don’t know whether that difference of perspective is at the root of some of the synchronization issues (or lack thereof), or whether there may be code evolution history that also is part of the story. In either case, I think looking at things from those two perspectives can help in understanding why things are done differently within the two sets of software. It also starts to offer a way of looking at two sides of the combined system for people who want it to work as an integrated whole (which would be my thought).
WP-BP User Information Model
Figure 1, below, provides my reverse-engineered version of a conceptual information model for the User concept as implemented in a WP-BP environment. (A general introduction to information models can be found here. My tendency is to generally follow the Information Engineering graphic notation, sometimes referred to as Crow’s Foot Notation, as I think it is the most visually descriptive.)
Without explicit labeling of the relationships (assume all relationships read as “relates to” or “connects with”), this diagram identifies 6 core concepts involved in dealing with User when looking at BP. One of these is entirely a BP entity and the others are elements where BP is dependent on the WP base concepts.
- BuddyPress Profile Features, as implemented in today’s system, is entirely a BP concept implementation. It exists and operates outside of WP, but is directly tied to and dependent on the WP User concept implementation. Profile features can be shared by multiple users and any one user may have multiple profile features.
- WP User in the model defines the concept of User to both WP and BP. The fact that someone who can be authenticated using a particular set of credentials is a particular person is validated using this entity.It exists primarily as an access management device and is directly tied to the concept of Role. A User can have multiple Roles. A Role can be an attribute of multiple Users.
- WP Role defines what users can do. A Role defines a collection of Capabilities that can be assigned to a User. In effect the Capability collection defines the Role. A Role can be assigned multiple Capabilities. Any one Capability can be assigned to multiple Roles.
- WP Capability as a collection does not exist physically in the system (which is one reason tracing this is hard) but it is very much a part of the conceptual model at this level. Individual Capabilities are identified as strings with identified significance of Activities that can be applied to Object Types. One Capability defines a particular action or Activity that can be accomplished to or with a particular Object Type. For example “create_users” or “edit_posts” or “upload_files.”
- Activity in the model represents the action sets, the things that users may do.
- Object Type in the model represents the type of things (information sets) that can be operated on.