[@boonebgorges Keymaster 15 years, 9 months ago]

That thread is correct that there are no blog avatares built into BP. But it is incorrect about being able to display custom avatars in blog directories. The strategy I outline above will do just that.

[@boonebgorges Keymaster 15 years, 9 months ago]

You will have te create a custom function, either in your theme’s functions.php or in plugins/bp-custom.php, that filters the output of that function and replaces it with the avatar of your choice. Eg, if your blog_id is 5,
‘function my_blog_avatar( $old_avatar ) {
// Do some stuff to get the avatar you want, then
return $new_avatar;
}
add_filter( ‘bp_get_blog_avatar_5’, ‘my_blog_avatar’ );`

The ‘do some stuff’ part will depend highly on your setup. If by ‘the associated group’ you mean that you are using bp-groupblog, then you will likely have to do some direct queries of the groupmeta database table to find the group that is associated with a particular blog (I don’t think that the plugin stores that info in a place that is easily accessible by blog_id). Then you will use some permutation of bp_core_fetch_avatar() to pull up the avatar for that group_id.

Good luck!

[@boonebgorges Keymaster 15 years, 9 months ago]

Yeah, without a $user_id argument, it’ll only work on profile pages. See bp-activity/bp-activity-templatetags.php bp_activity_latest_update().

Try:
`if ( bp_get_activity_latest_update( bp_loggedin_user_id() ) )
bp_activity_latest_update( bp_loggedin_user_id() ); //then show the update
else
// then show this`

[@boonebgorges Keymaster 15 years, 9 months ago]

I would like to see a full fidelity import-export tool, but it’s a lot of work. Look for it in 2011.

[@boonebgorges Keymaster 15 years, 9 months ago]

`var jq = jQuery;
jq(document).ready( function() {
/* @mention username help button display */
if ( jq( ‘span.highlight span’ ).length )
jq( ‘span.highlight span’ ).toggle();
});`

[@boonebgorges Keymaster 15 years, 9 months ago]

Please go ahead and open a bug ticket on trac.buddypress.org with a detailed description of what you know, steps to reproduce, and a link back to this thread. You can use the same user name and password as on this site. Then I or another dev can have a look at whether there is a bug in the way that that cookie works.

Thanks!

[@boonebgorges Keymaster 15 years, 9 months ago]

Try
`if ( bp_get_activity_latest_update() )
bp_activity_latest_update(); //then show the update
else
// then show this`

[@boonebgorges Keymaster 15 years, 9 months ago]

I have seen this before. I think it might be a BP bug. If you have a development site, would you mind testing to see whether this is the case with all plugins deactivated (other than BP) and using the bp-default theme?

[@boonebgorges Keymaster 15 years, 9 months ago]

The procedure suggested by @aljuk is probably as good as you’re going to get right now. For now, the WP import/export process does not recognize the majority of BP content, and there is no standalone BP import/export tool yet.

[@boonebgorges Keymaster 15 years, 9 months ago]

WP upgrades, especially security and maintenance releases (ie when the version number is 3.x.x rather than 3.x), are generally very unlikely to break any plugins, including BP. I’d recommend that you upgrade to maintenance releases immediately.

Feature releases, like WP 3.0 and 3.1, are somewhat more likely to cause problems with plugins like BP. But the BP core team works closely with the WP core team to ensure that BuddyPress is ready for whatever changes come along ahead of time. If there is something in BuddyPress that absolutely cannot be fixed prior to a major WP release, we’ll do our best to warn you about it before you upgrade.

[@boonebgorges Keymaster 15 years, 10 months ago]

I also have found myself torn about using pages for BP directories. In the end, though, I think it’s a compromise that works out for the better in the short- to medium-run, and does not have awful long-term consequences.

In my view, it is a gross overstatement to say that this move ‘ruins’ BP. However, there are a few things about it that are unappealing:
1) It forces the creation of what are, essentially, dummy pages – whatever content you might add to the page through the normal WP editor is totally ignored
2) Related – It uses part of the WP page infrastructure (URLs) without using others (in particular, WP page templates)

Problem (1) is unappealing, but it is mitigated by a couple of points. First, the current system is not a whole lot better. Instead of having ‘dummy’ pages that you can see in the admin (like BP trunk has), the current version of BP has ‘phantom’ pages, so that when BP detects a URL like example.com/groups, it essentially hijacks the page load in order to do its own stuff. This is a bit jarring, and not at all transparent. So there is a trade-off, but it’s not all bad. Second, while the idea that ‘Pages in WordPress are supposed to be static content’ seems right to me in broad strokes, it doesn’t seem to me to be a hard-and-fast rule. Many plugins (gallery plugins, ecommerce plugins, etc) display their content by means of a shortcode that is manually inserted on a page or post, with pages being used for their pretty URLs.

On the other hand, there are some real benefits to directories-as-pages:
A) Easier URLs (as @driz has noted)
Integration into WP 3.0-type menus (this is the big one IMO)

How important are things like (A) and (? For sites maintained by folks with some PHP chops (and organizations with money to pay people with PHP chops), they could be fairly easily accomplished with BP_GROUPS_SLUG, etc, and with some other finagling. But – and this is just a guess – this profile does not match most of the users of BP. Nor should it, necessarily. To the extent that BP can be easy to use and install for people with little technical knowledge, without at the same time making it less flexible from a developer’s point of view, it should be. This change is good for end users, and is no more difficult for developers than the current technique, so it seems like a net win.

Another more theoretical argument for the directories-as-pages move (especially as compared to the new admin panel @driz suggests for changing slugs) is that BP shouldn’t reproduce functionality that WP could provide, unless there is a convincing reason for doing so. Using WP pages for BP directories is a step toward greater BP-WP integration. It’s not perfect (see my problem (2) above) but it is a start.

As for custom post types: It’s likely that at least some of BP’s components will be refactored to use custom post types in the future. When that happens, part of the upgrade script will probably involve removing the dummy pages at issue here. So from the user’s point of view, the transition will be seamless.

I should say that I am in agreement with a lot of the sentiment in this thread about making BP a bit more lightweight, framework-y, and disjointed than the sometimes hulking behemoth it is now. However, that kind of transition can and probably should be gradual (at least more gradual than the 1.3 release).

[@boonebgorges Keymaster 15 years, 10 months ago]

@bgrun80 I’ve added you as an Editor on the codex. (The script that is supposed to handle this setup automatically has been acting buggy lately.)

When you load a URL that matches a pattern that BP is looking for (eg /members/boonebgorges), BP first finds the corresponding data in the database (in this example, the profile data for a member matching the name ‘boonebgorges’) and then loads the theme file designated for this kind of data (members/single/home). In broad strokes, it’s not that different from how a standard WP post query works.

The relationship between core files is conventional. For something like the groups component:
– bp-groups/bp-groups-templatetags.php contains all function that are called from theme templates, along with the loop builder classes
– bp-groups/bp-groups-filters.php contains the functions that modify the output of the groups component via apply_filters(), plus the application of any WP-native filters like kses
– bp-groups/bp-groups-classes.php contains the database classes (for the most part, the -classes.php files should be the only place where SQL statements appear) as well as any other miscellaneous classes (like the BP_Group_Extension class, in the case of groups)
– bp-groups/bp-groups-notifications.php contains the functions that format and send email notifications related to the group
– bp-groups.php contains some setup functions for the component (like groups_setup_globals() and the functions that set up navigation), as well as any other functions that don’t have a natural home in any of the other files listed above.

[@boonebgorges Keymaster 15 years, 10 months ago]

Instances of do_action() don’t actually do anything. They are just hooks for other plugins or themes to use. So, while I agree that there should be a great deal more documentation throughout the BP core, documentation for the do_action calls in bp-defaultisn’t really possible because of the simple fact that most of them are not actually used by BuddyPress itself.

If you would like to see where (or whether) a particular hook is being used by BP, search for that hook name in the context of an add_action() in the BP package.

And fyi, every user account here on buddypress.org should have edit access to codex.buddypress.org. Try visiting codex.buddypress.org/wp-admin. If you find you don’t have access, it’s an error – let me know and I’ll be happy to set it up.

[@boonebgorges Keymaster 15 years, 10 months ago]

Hear, hear!

Happy holidays, everyone!

[@boonebgorges Keymaster 15 years, 10 months ago]

I’m not able to reproduce the problem on my installations of 1.2.7. bp_get_the_profile_field_value() is returning the correct UNIX timestamp for dates.

Are you running other BP-related plugins? Have you tried reproducing the problem with those plugins deactivated?

[@boonebgorges Keymaster 15 years, 10 months ago]

@dlabbe – Check out how BP itself validates its own fields. See groups_action_create_group() in bp-groups.php, in particular the stuff after
`if ( ‘group-details’ == $bp->groups->current_create_step ) {`

[@boonebgorges Keymaster 15 years, 10 months ago]

Did you remember to import the stylesheet of the parent theme in your child theme’s style.css?

See “Inheriting CSS” on https://codex.buddypress.org/theme-development/building-a-buddypress-child-theme/

[@boonebgorges Keymaster 15 years, 10 months ago]

We’re shooting for a late-January release of BP 1.3, so you don’t have long to wait.

If you want to ensure that it gets out faster, check out a copy of the trunk and grab a ticket trac.buddypress.org

[@boonebgorges Keymaster 15 years, 10 months ago]

I added the first idea to my future feature list for Invite Anyone. We’ll see when I get around to it

[@boonebgorges Keymaster 15 years, 10 months ago]

In BP 1.3, bp_has_groups() will takes an ‘include’ parameter. It’s already in the trunk.

[@boonebgorges Keymaster 15 years, 10 months ago]

There isn’t really any support built into BP for custom pay types, but supporting them is no different from supporting other kinds of custom content in BP. See the BuddyPress Skeleton Component for some guidance on integrating custom content into BP navigation, etc.

In the next couple weeks I might whip up a new plugin to provide a framework for custom post type support in BP (front end editing, integration into nav menus, etc). I’ve had to do stuff like this for a couple clients in the past few months and I think I have a sense of some good strategies.

[@boonebgorges Keymaster 15 years, 10 months ago]

The preferred method is to hook your nav setup function to the ‘bp_setup_nav’ hook. If you are unable to do so in your functions.php, it’s probably because functions.php and other theme files are loaded too late. Put your code in wp-content/bp-custom.php (create it if it doesn’t exist) and try that. A standalone plugin should work fine too.

[@boonebgorges Keymaster 15 years, 10 months ago]

The plugin works fine on all my installations of the latest WordPress.

If your users are not able to leave a star rating, it is likely that you are having a Javascript conflict. Are you using a custom theme? Try reverting to the BuddyPress Default theme to see if the stars work that way. If so, then maybe I it someone else can help you to troubleshoot the theme.

I should make it an option in the future for admins to turn off the part of the plugin that requires star ratings.

[@boonebgorges Keymaster 15 years, 10 months ago]

@imjscn – There is no straightforward way to do what you’re trying to do.

For the message at the top of the screen, you can change that with a language file and then change the display with CSS. Removing the class=”error” div will be more trouble than it’s worth.

The other part will be harder. You can get the error info out of the $bp global – $bp->signup->errors – on page load. Then you’ll probably have to use Javascript to change the color of the labels.

[@boonebgorges Keymaster 15 years, 10 months ago]

Awesome!