Forum Replies Created
-
This was bugging me and I decided to do some research. I posted the results here: http://architectedfutures.info/2011/08/23/bp-wp-profile-sync/ If I made any errors that misinform please help me to correct them by posting a comment or using the contact page to send me a note. Thanks!
Basically I want to post this to leave a track for others with the same issue. Note also, there is a BP TRAC ticket 3335 opened on this.
@larrysmith1000, @Arwym, @FitzUCF, @janismo, @hnla
I don’t know if anyone is still looking at this, but I think it is a topic that is worth pursuing. What seems to be getting lost though is what it takes to do the job.A facility like Justin Tadlock’s members plugin is a big help. It provides a mechanism to define and edit roles and apply them to users. That covers a lot of territory. However, unless the content management part of the software looks for and enforces those roles, it is meaningless. Justin provides a facility to do that if what you are talking about posts/pages and potentially custom post types. That is fine for WP content or even things like BuddyPress Docs where Boone implemented it as a custom content type (although I haven’t look at the details of his implementation relative to permissions). However, BP adds additional content types. And it is not just FORUMS. Groups are a content type. Private messaging is a content type. etc.
That is where the current_user_can() checks make sense. Users should have permission to perform actions. That doesn’t necessarily mean new roles, but it does mean distinct capabilities. Those capabilities can then be assigned to any role that makes sense. But the capability list needs to be published like it is for WP https://codex.wordpress.org/Roles_and_Capabilities
The mechanism for assigning capabilities to roles and roles to users and doing the actual check is all WP. It’s already there. Justin provides UI to access it. What I am seeing missing in BP is published string literals that have meaning in terms of capability sets and I assume the current_user_can() checks that actually make it happen. (I looked for it on Google and this is where I was directed!)
@DJPaul you talked here in terms of BP1.3, which is now 1.5 I believe. Did any of this actually make it into the code? If not, it sure would make sense to me to find it’s way on to a revised RoadMap.
My 2 cents!
I was posting on a StudioPress forum about their efforts to upgrade their Genesis Connect plugin for compatibility with v1.5 and asked about the recommended install process (uninstall/re-install). The answer in part was:
“There are BP 1.2.9 functions calls in GC 1.0.7 that are not in the BP 1.5 beta-2. If you leave GC 1.0.7 active and upgrade BP, you end up with call to undefined function errors both in the front end and in the admin area of your site.”
BP 1.5 seems like a major move and, from what I’ve seen as I begin to look at it, a very beneficial move. However, it also seems, from the discussion in this forum, to be a move with big impact in terms of plugins. I’m new here, but on that basis I have a question:
Would it have been possible or make sense to ease the transition in some cases by providing some adapter functions that would translate old replaced functions with re-directions to their new counterparts? The old functions could then be identified as deprecated and removed at a later date, but in the immediate horizon some plugin modules might continue to work rather than needing to be modified or abandoned? Simply dropping stuff without fair warning seems drastic.
It might not be possible in all cases, but it might help with the transition. I know a lot of people want to move forward to the new v1.5 and this type of code strategy might help.
Just a thought.
BTW – I’m beginning to play with beta 5029 and it looks fantastic! Great job … you guys did a lot of good work!
