[@jivany Participant 16 years, 7 months ago]

Considering the relationship between BP, WP, Gravatar and Automattic, this topic is not going to get the answer you’re looking for.

If you don’t like Gravatar, then disable it and use local avatars only.

That said, make sure your local avatars are then being served from a fast CDN. If not, you likely won’t see any better load times than Gravatar.

[@jivany Participant 16 years, 7 months ago]

Both should have been default wp/bp behavior imho.

I’ll disagree with that. Especially with sites where you use the bp-default theme style of having a login box on every page. I don’t want to be redirected to my profile page if there is a reason I’m logging in on page X.

Redirecting to the user’s profile page makes sense on a closed/private installation where you need to login to see anything (ala Facebook)

[@jivany Participant 16 years, 7 months ago]

Redirect to User’s Profile Page on Login

Place the following snippet in either wp-content/plugins/bp-custom.php or in your child theme’s functions.php file.

function oci_login_redirect($redirect_to, $set_for, $user){

$redirect_to = bp_core_get_userurl($user->id);

return $redirect_to;

}

add_filter('login_redirect', 'oci_login_redirect', 10, 3);

From https://buddypress.org/forums/topic/two-questions-about-the-login-process#post-8380

(alternate method)

Use Brajesh’s plugin (which does basically the same thing as above):

https://wordpress.org/extend/plugins/bp-redirect-to-profile/

[@jivany Participant 16 years, 7 months ago]

Searching works but so does following tags.

https://buddypress.org/forums/topic/two-questions-about-the-login-process#post-8380

[@jivany Participant 16 years, 7 months ago]

Bummer. IIS isn’t really that common with WP and I think the majority of people here are using Apache based hosts.

You could try what is mentioned at the end of this thread: https://buddypress.org/forums/topic/friendly-http-error-messages-causes-404

The specific error it talks about isn’t what you’re seeing though as I get a 404 on your site with Firefox also.

This link talks about a modified 404 error handler to deal with some of the oddities in IIS handling:

http://ikailo.com/94/url-modrewrite-workaround-iis-60/

If you do get this working, please post back here and/or in the FAQ topic because it seems there are a lot of IIS users running into similar issues.

[@jivany Participant 16 years, 7 months ago]

Install Firefox (if you haven’t already) and then get the addon called Firebug. This will help you immensely when you are trying to track down what CSS to edit. You can even edit values on the fly in Firebug and see their immediate impact. Then al you have to do is take those changes and toss them in your child theme’s style.css file.

[@jivany Participant 16 years, 7 months ago]

If you are using IIS, you might have to follow the directions suggested here:

https://codex.wordpress.org/Using_Permalinks#Permalinks_without_mod_rewrite

I don’t think IIS supports mod_rewrite which is what WP uses (and BP).

Does your site work with BP installed?

[@jivany Participant 16 years, 7 months ago]

@cpentleton & @xiv-studios: Sorry if I offended either of you.

BuddyPress has the unfortunate (and fortunate) ability to be installed via the plugin installer built into WordPress. Out of the box it is fantastic and very complex. This can create a very confusing and quite steep learning curve for anyone starting out.

@cpentleton: I look forward to your new topic. Hopefully it’s something I can give you a hand with. If not, I’m sure there will be a BP community member who can.

[@jivany Participant 16 years, 7 months ago]

Displaying groups on any page is relatively easy – use one of the widgets. If your target page doesn’t have a widget area where you want one, you’ll have to update the template file (in your child theme) and add a widget area. Register the new widget area through your functions.php file. There are a fair number of resources on the ‘net for how to create new widget areas.

Displaying some forums posts from each group at the same time is going to be much more complex. It’s not going to be easy unless writing a fair bit of code is something you find easy. It can be done though.

[@jivany Participant 16 years, 7 months ago]

What if you removed the existing bp_core_fetch_avatar_filter from get_avatar and then created your own copy that passed ‘no_grav’=>true into the bp_core_fetch_avatar function?

I think this should kill the attempt to use Gravatar to fetch an avatar. I’m assuming that bp_core_fetch_avatar isn’t being called directly anywhere. If you do find anywhere that does, it should probably have a ticket raised against it.

[@jivany Participant 16 years, 7 months ago]

Eek. Just realize if you edit a core file it will get lost when you upgrade to the next BP version. Editing core files is never a recommended solution.

Open a ticket if you need this code to have a user definable time period.

[@jivany Participant 16 years, 7 months ago]

Thinkimg about your Gravatar https issue – I thought that was fixed in a recent version of BP.

[@jivany Participant 16 years, 7 months ago]

Try this: https://buddypress.org/forums/topic/how-to-disable-gravatar-completely

[@jivany Participant 16 years, 7 months ago]

Even with the biggest screen out there, people can only handle columns that are a certain width. Generally you only want to have between 10-15 words per line. Any wider and it’s hard to read. One of my gripes with bp-default is how wide the main content area is. Check out something called the “golden ratio”.

Oh, and make sure your site woks on a 1024×768 display. ~1000px is as wide as I’d go.

[@jivany Participant 16 years, 7 months ago]

@gian-ava: For your second question, check out this post https://buddypress.org/forums/topic/faq-how-to-code-snippets-and-solutions#post-13243

I haven’t tried this but it would suggest you could do something like:

<?php if ( bp_has_profile('profile_group_id=9') || bp_has_profile('profile_group_id=7') ) : ?>

<?php while ( bp_profile_groups() ) : bp_the_profile_group(); ?>

<div id="widget1">

<?php if (bp_the_profile_group() == "9") : ?>

// Do whatever you want with group 9

<?php endif; ?>

<?php if (bp_the_profile_group() == "7") : ?>

// Do whatever you want with group 7

<?php endif; ?>

</div>

<? endwhile; ?>

<?php endif; ?>

The only part I’m not sure about is if you need the first call to bp_the_profile_group() on the second line (after the start of the while loop).

[@jivany Participant 16 years, 7 months ago]

Sorry Jim, I tried the same on my WP 2.9.2 + BP 1.2.3 install and I can’t reproduce the problem you are seeing.

[@jivany Participant 16 years, 7 months ago]

There are plugins that allow WP users to write posts without going into the backend. I think TDO Mini Forms (https://wordpress.org/extend/plugins/tdo-mini-forms/) allows this. I’m not that familiar with the plugin though.

I think there is also a “quickpress” type plugin to allow the same as what the “quickpress” function does on the main dashboard in WP.

[@jivany Participant 16 years, 7 months ago]

Creating your own copy of the register.php file in your child theme is fine.

If you don’t want to touch the file, you could hook into either bp_before_account_details_field or bp_signup_username_errors to display a similar notice. Just create a new function in your theme’s functions.php that spits out your message and use the add_action function to hook into your chosen location.

[@jivany Participant 16 years, 7 months ago]

You should probably check with the plugin author.

[@jivany Participant 16 years, 7 months ago]

I took another look at this and I think I have a potential solution.

You can filter xprofile_get_field_data and make sure that the return value is not a blank or some other non value. The downside of this method is I think you would need to then set the returned string to a known value that indicates it is not populated. The only reason I say this is ideally, you probably want to make bp_custom_get_member_list_xprofile_data return FALSE if the string is blank but I don’t think you can do this within the filter.

As for your second issue, a really hallf-assed way to do it is with two loops. I’m sure there’s a more elegant way but I’ve never written elegant code.

That said, I don’t see a way to dump out two groups in one loop but I’m not very familiar with this code.

[@jivany Participant 16 years, 7 months ago]

Yes, but your custom_xprofile call just does an “echo”. echo will always return something. Something might be a string or it might be a blank but it will always return something. You can’t test a function return value if you aren’t returning a value. Inside custom_xprofile, you need a “return TRUE” or something like that to be able ot use it in a boolean logic check that the if does.

[@jivany Participant 16 years, 7 months ago]

Yes. Use groups and extend them. If you haven’t seen it, @Andy is creating a new plugin repository for Buddypress. The whole thing is based on the regular buddypress groups but it’s quite different.

http://twitpic.com/1b0joi

This might help you too:

https://codex.buddypress.org/developer-docs/group-extension-api/

If you create a plugin to do this, I’m sure there are other people who would love to see it.

[@jivany Participant 16 years, 7 months ago]

I think you need to look at what @DJPaul said. If your function always returns true then you’re always going to output something, even if that something is blank.

function custom_xprofile( $field ) {

echo bp_custom_get_member_list_xprofile_data( $field );

}

That echo will always return something. You need to dig into bp_custom_get_member_list_xprofile_data and see if there’s a way to determine if $field exists.

[@jivany Participant 16 years, 7 months ago]

Do you have any plugins installed? Other than BP of course.

[@jivany Participant 16 years, 7 months ago]

The answer is still the same – no, not out of the box.