Forum Replies Created
-
Thanks for listening.
And thanks for adding the link. My comment at the end was about that change.Just so its clear for everyone else, although the change went in in January, this fix was not in 1.2.9.
I am using WP Super Cache on a BuddyPress installation right now, but it is not caching any of the BuddyPress or bbPress pages — only the blog. This actually does help a lot because it is the blog that gets a lot of search and direct traffic. WPSC is a great idea that works really well for pages that aren’t *too* dynamic, like a blog. It stores static versions of the pages so that they don’t have to be rebuilt all the time. Site response for a new visitor that hasn’t logged in is improved massively.
But for a very dynamic site (e.g. with activity lists updating frequently) you really need db object caching in memory (e.g. memcache) to speed things up and reduce the load on the db. I think this is what W3 Total Cache does, but I don’t (yet) have experience with it.
Andy also wrote this page on other optimization options: https://codex.buddypress.org/getting-started/improving-performance/
Ah, it seems that the 1.2 branch is more up to date than the trunk. The “bp_core_avatar_upload_path()” and “bp_core_avatar_url()” there solve my problem by correcting the path/url for the multiblog case.
Peter, this is info that you could get in trac as easily as Paul. I think he may be referring to this ticket: https://trac.buddypress.org/ticket/2451. But it isn’t exactly the same bug. My issue seems independent of BP_ENABLE_MULTIBLOG.
Digging around in trac I found this changeset by @apeatling that introduced the problem: https://trac.buddypress.org/changeset/2984 (as a fix to https://trac.buddypress.org/ticket/2317 ).
After this change the BP_AVATAR_URL and BP_AVATAR_UPLOAD_PATH are derived from wp_upload_dir(). So the avatar location is based on the uploads location for the individual blogs, instead of being based on the upload location for the primary blog.
I would suggest using “get_blog_option( BP_ROOT_BLOG, ‘upload_url_path’ )” and “get_blog_option( BP_ROOT_BLOG, ‘siteurl’ )” but it seems from the comments in the ticket that JJJ thought they weren’t reliable.
UPDATE: I have opened https://trac.buddypress.org/ticket/2469
Quick update on how I made this work. Added the following filters in bp-custom.php.
I would still like to know if BP is expected to look for different avatars depending on the blog that is currently active.
/* Set sitewide avatar path for all blogs */
function _core_avatar_upload_path( $path )
{
return ABSPATH . ‘wp-content/blogs.dir/1/files’;
}
add_filter(‘bp_core_avatar_upload_path’, ‘_core_avatar_upload_path’ );function _core_avatar_url( $url )
{
return ‘http://’ . get_current_site()->domain . ‘/files’;
}
add_filter(‘bp_core_avatar_url’, ‘_core_avatar_url’ );Thanks JJJ. Here are the steps:
1. Log in as a member
2. Go to the “change your avatar” option
3. Browse to a new avatar photo, say new.jpg
4. Press “upload”, which will take you to a page where you can crop your avatar
5. Drop out and go to some other page without completing the process
If you then look in blogs.dir in the member’s folder you will see “new.jpg”. The process never completed, so this image wasn’t deleted.
Anyone else having this issue? Thoughts on how to deal with it?
Thanks JJJ, Andrea.
Andrea, I was remiss in not giving props to the mu forum. You’ve helped me out several times over there.
This is a little risky for a non-programmer, but here is some code that would replace the profile-loop.php file in the skeleton member theme. Note that this theme is deprecated in the new parent-child theme setup. It is also not a sophisticated privacy component like the one Jeff is working on. It simply omits everything except the base profile fieldset when a non-member views the profile.
This is from my own installation, but I have removed some pieces (mostly formatting) to simplify things a bit. I haven’t tested it in the simplified form.
It assumes that “Base” is the base profile group name you specified in the BP dashboard settings.
<?php
/*
* /profile/profile-loop.php
* This file loops through the profile field groups, and then each profile field to
* display the profile information that a user has entered.
*
* Loaded by: 'profile/index.php' (via the xprofile_get_profile() template tag)
*/
?>
<?php if ( bp_has_profile() ) : ?>
<?php while ( bp_profile_groups() ) : bp_the_profile_group(); ?>
<?php if ( (bp_get_the_profile_group_name() == "Base") || ( is_user_logged_in() ) ) : ?>
<div class="info-group">
<?php if ( bp_group_has_fields() ) : ?>
<h4><?php bp_the_profile_group_name() ?></h4>
<table class="profile-fields">
<?php while ( bp_profile_fields() ) : bp_the_profile_field(); ?>
<?php if ( bp_field_has_data() ) : ?>
<tr<?php bp_field_css_class() ?>>
<td class="label">
<?php bp_the_profile_field_name() ?>
</td>
<td class="data">
<?php bp_the_profile_field_value() ?>
</td>
</tr>
<?php endif; ?>
<?php endwhile; ?>
</table>
<?php else : ?>
<h4><?php bp_the_profile_group_name() ?></h4>
No info yet.
<?php endif; ?>
</div>
<?php endif; ?>
<?php endwhile; ?>
<?php if ( !is_user_logged_in() ) : ?>
<p class="not-a-member">You need to log in to see full member profiles.</p>
<?php endif; ?>
<?php else: ?>
<div id="message" class="info">
<p><?php _e( 'Sorry, this person does not have a public profile.', 'buddypress' ) ?></p>
</div>
<?php endif;?>One way is to use the “is_user_logged_in()” function in the profile loop (normally, “profile-loop.php” in the member theme).
You need to use that in conjunction with (bp_get_the_profile_group_name() == “BASIC”), where BASIC is the base profile group name you specified in the BP dashboard settings, to test whether you’re on the BASIC profile.
Yes. That will give you the profile URL for the currently logged in member. But if all you want is a link to the currently logged in user, then you could use the bp_loggedinuser_link() tag. Note that this returns a LINK (i.e. <a href=”… etc.) and not just a URL. Just put…
<?php bp_loggedinuser_link(); ?>…in your template where you want the link.
If you do call my _profile_url() above to get the URL for a specific user, then note that you must provide the login name. So it depends what you have to begin with. Let’s say you have the user ID, then you need to get the login name as follows:
$user = get_userdata( $user_id );
$url = _profile_url( $user->user_login );And while we’re at it, if you want the URL for the displayed user, you can get it using…
global $bp;
return $bp->displayed_user->domain;Here is what I do (in BP 1.0.3):
function _profile_url( $login_name=0 ) {
global $bp;
/* if no login name is specified, use logged in user */
if ($login_name) {
$url = $bp->root_domain . '/members/' . $login_name . '/profile';
} else {
$url = $bp->loggedin_user->domain . 'profile';
}
return $url;
}I got some help on the bbPress forum and think I’ve sorted this out. I was loading “wp-blog-header.php” for deep integration, but loading “wp-load.php” seems to be better. No more 404 headers in the forum, and the RSS feed problem I had previously is also fixed.
I suspect buddypress.org is using “wp-blog-header.php” because it is showing the same symptoms. Perhaps the admin here would like to try “wp-load.php”.
Thread on bbPress forum:
This is really a WPMU issue, so I’ve posted it over there: https://mu.wordpress.org/forums/topic/14425?replies=1#post-83354
I think this issue will stop Google (and other search engines) from indexing your forum pages. So if you are using deep integration it might be a good idea to watch for a patch.
Use my little workaround at at your own risk.
I’ve also seen the blank pages.
Returning to the 404 issue (and cross posting from https://bbpress.org/forums/topic/help-404-error-but-page-displays?replies=3#post-57822), it looks like WordPress is setting the 404 because it doesn’t recognize the bbPress page that is loading.
When the global WP object is constructed, the function WP->handle_404 calls “status_header( 404 )”.
As a workaround, I modified “handle_404” to lay off the 404 if “BB_PATH” is defined (i.e. when a bbPress page is loading). This seems to work ok.
Here’s the new “handle_404” at around line 445 in “wp-includes/classes.php”.
function handle_404() {
global $wp_query;
if ( !defined( 'BB_PATH' ) && (0 == count($wp_query->posts)) && !is_404() && !is_search() && ( $this->did_permalink || (!empty($_SERVER['QUERY_STRING']) && (false === strpos($_SERVER['REQUEST_URI'], '?'))) ) ) {
// Don't 404 for these queries if they matched an object.
if ( ( is_tag() || is_category() || is_author() ) && $wp_query->get_queried_object() ) {
if ( !is_404() )
status_header( 200 );
return;
}
$wp_query->set_404();
status_header( 404 );
nocache_headers();
} elseif ( !is_404() ) {
status_header( 200 );
}
}WordPress blog since 2006, bbPress forum added in 2008, and now a BuddyPress community. To start with we’re only using extended profiles and private messaging, but will layer in additional features over time.
Very grateful for the powerful platform that Andy and team have created, and for the great support offered by Burt, JJJ, Jeff and all the others on the forum.
I think that warning may be associated with a php4 incompatibility. Is your server currently supporting php5? If not, you may want to try switching to php5 to see whether the message goes away.
The thing is that bbPress doesn’t know that the user “nbsmrt” has BP Name “murat”.
UPDATE: Scratch that – your display names should actually be working, and in fact I see that they are for users other than “nbsmrt”. The bit I put below is necessary if you want the author link to go back to their BP profile instead of the bbPress profile page.
I wanted the name to be consistent everywhere, so I have a bit of common code that displays the user’s details in forum posts, blog comments, etc. Note that it requires deep integration because I am accessing BP variables inside bbPress.
For example, here is what I do in the forum…
First, in post.php I get the author’s details like so:
$author_id = get_post_author_id( $post_id );
$author = get_userdata( $author_id );
$author_loginname = $author->user_login;
$author_displayname = get_post_author();Then I call a function to display the user link, avatar and other things. Part of this function does the following:
<?php
$author_url = _profile_url( $author_loginname );
?>
<div class="username">
<a href="<?php echo $author_url ?>"><?php echo $author_displayname ?></a>
</div>And here is the code for the _profile_url() function:
function _profile_url( $login_name=0 ) {
global $bp;
/* if no login name is specified, use logged in user */
if ($login_name) {
$url = $bp->root_domain . '/members/' . $login_name . '/profile';
} else {
$url = $bp->loggedin_user->domain . 'profile';
}
return $url;
}So the user’s BP Name is always used, and it always links to their BP profile.
My one concern about all this is that get_userdata() does a SQL query, adding one query for each author in a topic thread.
Does anyone know how much (server) memory is used by a single user visiting an integrated bbPress+BuddyPress installation (assuming standard installs and themes)? This could be a big impact on the ability of the system to scale to many users and lots of traffic.
I remember _ck_ (moderator on the bbPress forum) saying that it would be about 1MB, but that was before BackPress integrated a lot of the overlapping functionality.
How would one measure something like this?
Thanks again. This is really useful.
BTW, the new function does work inside override_bp_core_settings_nav().
How much of a difference should we expect to get when using WP single user (when this is an option in future)?
And if it is significant, why is this the case? And is it also true for WPMU with a single blog, or is the difference that people are expecting a WPMU installation to have multiple blogs?
Ray, this is more than a pointer – it works as is. Awesome.
Couple of questions for my ongoing education… it seems that ‘init’ is a WP hook after everything is initialized. So you are using it to ensure we replace the function *after* bp has added it?
Secondly, is there a particular reason that you didn’t add the new function inside the override_bp_core_settings_nav() function?
Thanks very much.
Thanks JJJ. Let’s use a forum topic page as a specific example. For each post in the thread I will call get_userdata() at least once.
Is there another way I can access each post author’s user_login?
korhanekinci, this is a change that I made in the database itself. I use phpmyadmin for database manipulation.
In this case the operation (i.e. the SQL query) was pretty simple, but if you haven’t manipulated the database directly before then it is a little risky. One thing you definitely want to do is to create a backup copy of the db before starting.
I’m working on a test version of my site so there is no risk of damaging the production version.
The SQL query I used:
UPDATE wp_users SET user_login = user_nicename WHERE 1Thanks Jason. I have copied user_nicename into user_login and all is well.
