BuddyPress.org

Well, it’s not an easy thing to do fullstop. You have to know a certain amount of PHP and HTML to create or edit a WordPress theme, and it is no different here. Have you, via BP Template Pack, copied the templates / css / js into your theme? Does the CSS get loaded when you visit the front of the site?

Are you getting any errors? A blank site is usually called by a fatal error. Set WP_DEBUG to true in your config file define( ‘WP_DEBUG’, true ); . If you still don’t see any errors then do search through the files in wp-content/plugins/buddypress for any error_reporting(); calls and set it to error_reporting( E_ALL);

Same here, BuddyPress 1.2.5.2, WordPress 3.01 and can’t delete users.

@kebdarge http://gsoc2010.wordpress.com/2010/08/16/eventpress/

@lupin3 – I don’t know any off the shelf function that prints the filename. Depending on your browser, tools like firebug on firefox and developer tools on Safari may help you.

Location of the files really depends which part of your theme you mean: the main blog / news ones or the social network specific ones such as profile, groups, etc.

For the blog specific pages – this page gives you an overview of all the WP files: https://codex.wordpress.org/Theme_Development

I don’t know what documentation is still around on 1.1.3 theme files. However, most of the files were typically in fairly explanatory-named subfolders of your member theme (e.g. in folders such as friends, members, wire, activity, profile)

Another option is to use/create a widget, something like https://wordpress.org/extend/plugins/user-bio-widget/ perhaps (untested).

member-header.php is located in /bp-default/members/single/.

If you’re making modifications to the bp-default theme, build a child theme so your changes will not be wiped out:
https://codex.buddypress.org/how-to-guides/building-a-buddypress-child-theme/

seobrien –
Read this: http://wpmu.org/how-to-add-a-custom-default-avatar-for-buddypress-members-and-groups/

iamnorthwind –
If you’re using another plugin to upload avatars, you’ll need to override the way BuddyPress fetches avatars.

Specifically, you’ll need to override the “bp_core_fetch_avatar” filter located in /buddypress/bp-core-avatars.php file.

Need a primer on filters? Read this:
https://codex.wordpress.org/Plugin_API#Filters

I can’t find my member-header.php. What version are you using?

I have to admit I’m still confused–there is no the_time() reference in index.php, nor is there any obvious place that I can see where you would insert such a date command. I just want the date of a blog post to appear on the main page, as it would in an ordinary WordPress blog installation, but it’s unclear to me where one would do so.

@ch8rt

The BuddyPress activity loop fetches blog post activity, so yes – you can get the latest blog posts from within the activity loop.

https://codex.buddypress.org/developer-docs/custom-buddypress-loops/the-activity-stream-loop/

@mvvspr @rossagrant @fashionblogs and everyone else – I’ve changed some things and added the plugin to the repo https://wordpress.org/extend/plugins/buddypress-mass-messaging.

All of the errors should be taken care of, but if you still have issues please post here http://jeremylitten.com/buddypress-mass-messaging-plugin

Quick thoughts from my iPad…

For there to be more core committers, there needs for there to be more outstanding core patchers. There are a handful of great ones already, and they are noticed and recognized for their contributions. The leads are Andy and myself, and ultimately the future of the core project is decided by us. Very similar to WordPress, we keep an eye on developer plugins to look for anything that would make a good core feature.

Feature requests are great when there are people to do create them, but the best place to talk about core development is on the trac. The forums are more for support and discussion than they are for code talk, but part of that is also because currently the forums don’t play nicely with code blocks.

I don’t think we’re closing threads unless the discussion goes severely off topic or is no longer productive. If we are, I would agree that we shouldn’t be locking topics prematurely. Regarding the codex, anyone has the ability to modify it, so if anything is out of date anyone is free to fix it.

I also agree that things will be easier for us and make more sense when buddypress.org is a website worthy of being in its own showcase. Right now it’s a basic install with lots of custom bits to help integrate wp.org plugins.

It hurts to just add committers for the sake of having committers. Commit rights are earned through writing great core patches and showing a comprehension for the direction of the core project. There are plenty of great plugin devs that have written thousands of lines of their own code, but haven’t directly contributed to core.

Ultimately it would be great if we had one developer per core component to focus on it’s future, but so far no one has showed initiative to want to make improvements to anything. Right now we’re in a transition period where the branch and trunk need to be merged before I think a few more people are comfortable writing giant patches, but that time will come.

Paul hit almost every nail on the head in his reply above. It’s great that you see the need, now fill it.

We are trying to set up a main site powered by wordpress, and a secondary one with buddypress. We got to use WordPress MultiSite just fine, and were able to set up Buddypress to work with the secondary one. However, after activating it, we discovered the following:

On the secondary site, we get the following on the blos tab:
http://prssamembers.freehostia.com/wp/testmp/blogs/

Secondly, on the admin dashboard it is impossible to create posts or pages since you get a 500 Error.

Also, attempting to edit a profile or clicking to go to settings always sends you to the members tab.

We have WordPress 3.0, and have tried using Buddypress version 1.2.5.2 and the trunk version 1.3-bleeding. Both present the same issue. The current one is 1.2.5.2.