* Better customisation options of the activity stream: ie to be able to define a set of “or” filters for content type, and who. So (with plugin support) I can define a feed to include things from “me or friends or followers” showing “topics and topic replies and posts and new users” (and ideally be able to have a permalink to this with no other fluff on display). The current activity feed selectors are a mess and don’t provide what most people want to see.
* A way to select which filters and views are available in activity/, and persistently set the default activity feed view (from the admin panel)
* live activity updates
* A reply by PM hook into bbpress
* Better options for users to self delete
* Improved management/rethink of the tabs on profile pages (because this rapidly piles up as you add in plugins) : “Activity Profile Messages Friends Following Followers Location Groups Blog Forums Events Gallery Settings Links” Is not viable for a one line menu bar – this is maybe a display issue, but…!
* be able to pass a function to the members loop, thats called to determine the display order (e.g. so I can easily order by City or age or any xprofile field)
Maybe these are already there, but these are the things that are bugging me as a non-expert dev right now…
* Better options for users to self delete
Expanding. Without backend access, it would be nice for a site allow a user to delete in several ways. Purge all their profile fields and networks (‘destroy all personal data’), Retain their profile fields and networks whilst making it look like they have vanished (‘hide’ if you like), Delete Uterly.
* Multiple networks. We have friends, and with plugins one sided friendships (aka followers). sometimes its useful to have different types of relationships identified – “close friends” or “have done business with” or “merely online buddies”. It would be nice for an admin to be able to define additional types of friendships either independently, or by associating a scale (an integer valued friendship, 1=I want to see your feed stuff 2=online mates 3=actual real life chums 4=we’re married).
It would be nice for an admin to be able to define additional types of friendships either independently, or by associating a scale (an integer valued friendship, 1=I want to see your feed stuff 2=online mates 3=actual real life chums 4=we’re married)
If I remember correctly friends were changed to a type of groups earlier this year. The kind of friendship levels/ privacy settings you request may actually be a use case for hierarchical groups then.
I would have to say an API so we could build mobile apps. Maybe way beyond scope.
API so we could build mobile apps
Just “API” is a bit vague. Do you, perhaps, want to create a ticket, with exactly what you are after, at https://buddypress.trac.wordpress.org/ ?
I assume you are aware of the existing API https://codex.buddypress.org/developer/action-reference/
I would like to offer two ideas for consideration:
1) Integrating basic anti-spam capabilities into core
2) Improving performance via fragment caching
1) I realize that there are already good plugins that deal with spam, both comment and multisite blogspam. But being spam, it is a cat and mouse game and I feel that buddypress should have some basic anti-spam protection out of the box. For example, a hidden text field via css as a honeypot. Users who are not at all comfortable coding or editing files can turn this on or have it on by default (rather than try to follow guides like this: http://www.pixeljar.net/2012/09/19/eliminate-buddypress-spam-registrations/)
2) This was touched on in the recent buddypress panel discussion:
(caching: 19min – 22min)
After spam, the biggest issue that I’ve heard is with performance. I think we should start to address this. For more info and details see this thread.
One of the challenges of using caching plugins like WT3 is that they don’t work for signed in members of buddypress sites. But a fragment caching system can still cache parts of the page which are ‘static’ and would not change as a result of the user activity.
@sooskriszta I am not sure I follow. Is the suggestion that each user has a number of nested private groups? that *would* be one way to define relationships, but… pretty clunky, no?
Hit enter too soon – can you link to documentation for that?
I’d love big new features to be left up to plugins and 2.0 to focus on speed improvements and code optimisations which will all make for a zippy user experience.
I haven’t been around enough in the past number of months to know exactly where BuddyPress stands now, however in the past there were a couple of areas that really effected my ability to use BP.
1. Privacy – There were way to many holes in the privacy settings for users. Meaning that users were not able to define EXACTLY what was shown and to whom it was shown. Any public facing field ever entered by a user should have the ability to define who sees what is being posted.
2. Speed – There were way to many ‘joins’ throughout the code and on a somewhat ‘large’ site it basically made using BP impossible for us. We had tied together using bbPress with BP via the group forums, and even with only a few million replies a fully dedicated server would consistently be brought to its knees. There have been tons of tickets with numerous ideas on patches and fixes for this, but overall I would say that anything which can be done to help optimize some of the more intensive queries would help a lot.
@anointed with reference to the large number of joins throughout the code and speed issues – where would you say speed improvements can be made in BP?
@synaptic
a fragment caching system
I totally agree with you, and would love to see fragment caching in BuddyPress (or more generally in WordPress)
That being said, if WordPress doesn’t include caching in core, it’s highly unlikely that BuddyPress would. If you created a ticket for this in Trac, it would probably quickly be closed as plugin territory.
The quickest way of getting this implemented would be to convince the author of FragmentCache or Fragment Cache or Redis cache to add support for BuddyPress.
@boonebgorges talks about some of the ugly and unscalable joins here
fragmented caching and general performance enhancements should be at the top of the list – as more features get added the problem will only worsen…
Better customisation options of the activity stream: ie to be able to define a set of “or” filters for content type, and who. So (with plugin support) I can define a feed to include things from “me or friends or followers” showing “topics and topic replies and posts and new users” (and ideally be able to have a permalink to this with no other fluff on display). The current activity feed selectors are a mess and don’t provide what most people want to see.
Should be nummer 1.
And I don’t even want lots of new features to the activity stream but first just an easy way to customize the default lay-out would be so much pleasant!
All BP pages are very easy to customize, move code around to give the page an unique feeling but when it comes to the activity stream the code is very fixed.
There are about 50-75 Premium BuddyPress themes online for sale and 99% of them have the same activity stream page-layout. While all those premium theme developers can do lots of customization to all other pages the activity stream is like Twitter’s Bootstrap to BuddyPress it always tells you it’s a BuddyPress website without looking at the code.
* live activity updates (ajax)
* caching system
The reason all those themes activity look alike is because previously it was a nightmare to create something that wasn’t derivative of bp-default and it’s heavy-handed javascript. This is not the case anymore.
Better customisation options of the activity stream: ie to be able to define a set of “or” filters for content type, and who. So (with plugin support) I can define a feed to include things from “me or friends or followers” showing “topics and topic replies and posts and new users” (and ideally be able to have a permalink to this with no other fluff on display). The current activity feed selectors are a mess and don’t provide what most people want to see.
There are about 50-75 Premium BuddyPress themes online for sale and 99% of them have the same activity stream page-layout. While all those premium theme developers can do lots of customization to all other pages the activity stream is like Twitter’s Bootstrap to BuddyPress it always tells you it’s a BuddyPress website without looking at the code.
The reason all those themes activity look alike is because previously it was a nightmare to create something that wasn’t derivative of bp-default and it’s heavy-handed javascript. This is not the case anymore.
In other words, this issue has already been fixed. Now it is upto the theme developers to customize the feed aesthetics to their hearts’ content.
well, activity streams are all similar. You can edit the css and templates all you want.
A relatively simple suggestion for 2.0 – Get rid of tables in all templates so developers can style everything for mobile without having to override templates to convert tables to lists. Notifications and Messages use tables right now and they don’t have to.
A harder feature BP could really use is admin editable fields for groups. Basically the exact same thing as xprofile fields but for groups. This is the kind of thing that makes more sense in core than a plugin.
@buddyboss
A relatively simple suggestion for 2.0 – Get rid of tables in all templates so developers can style everything for mobile without having to override templates to convert tables to lists. Notifications and Messages use tables right now and they don’t have to.
This is fundamentally a really bad notion, you do not change markup to suit devices – ever! Markup exists to accurately describe data in a semantic manner if that means that a table is the correct element then a table is what is used; if a devise can’t handle that then it’s the devices problem, if you have to try and change the markup in that instance then so be it and good luck.
‘Notifications’ correctly uses a table to display a columner/row relationship of data it’s not a case that it needn’t, this is correct; if you tried to put that into a list you would break the header relationship and would need to lump all of a notifications meta into one list and then have to use something like a dl list to associate date received to the metadata.
Of course though if you wish to modify the templates for your theme then you’re quite at liberty to do so that is why they are overloadable!
@buddyboss if you’re not happy with the notification tables then you can remove the default and add your own. e.g:
remove_action( 'bp_notification_settings', 'messages_screen_notification_settings', 2 );
// remove the rest too...
function custom_notification_settings() {
// your own custom stuff
}
add_action( 'bp_notification_settings', 'custom_notification_settings' );
I have run into an issue where I converted a vBulletin forum over to bbpress/buddypress combination.
I really do not quite understand why, but over the course of the past week since the migration. Me and my users have been getting non-stop emails 50-100 a day with @mentions. The longer a user has been involved in the community, the worse it got. I started out by completely disabling emails from WordPress, then I found r-a-y’s no mention plug-in. I’m hoping that does the trick.
Either way, there should be a way to disable certain notifications or messages transmitted from Buddypress.
Kudos to all the devs that work on this project! Thank you.
Another idea. My understanding is that this can be done through child-themes, but seems kind of taxing for what I would think should be a standard feature.
There should be a means to configure the Activity Stream in the Buddypress settings. I don’t necessarily think that all my users should see everytime someone becomes a friend with someone else. This would be a bonus IMO.
