[chestnut_jp]

Thanks for you comment, @hnla

Yes, I have tried a various ways, and have found that <div> and <ul> collapse the layout of post.
Try and you will see what I mean.

Anyway, the point is that single.php uses a wrong function.

[chestnut_jp]

Thank you very much, @boonebgorges.
Without your comment, I would not have noticed my mistake.

[chestnut_jp]

I found the reason.

At line 826 of bp-core/bp-core-templatetags.php:
$date = date( ‘F j, Y ‘, $time_offset );

It was my mistake, as I made a typo of “offest” when I change the above time format to Japanese one.
Fixing “offest” to “offset” let the problem disappear.

[chestnut_jp]

Thank you for your comment, @boonebgorges

Yes, I use several bp-related plugins, but all of them were already used with BP 1.2.6.
Since the proplem began surfacing right after BP was upgraded to 1.2.7, I thought it would be a bug in 1.2.7.

I will once again test 1.2.7 with bp-related plugins deactivated.

[chestnut_jp]

Because I know the field name or id for datebox, and I use onlye one datebox for birthday, I changed as following just for myself:

At around line 40 of profile-loop.php located in /wp-content/plugins/buddypress/bp-themes/bp-default/members/single/profile

[ Original ]
<?php bp_the_profile_field_value() ?>

[ Changed ]
<?php
if (bp_get_the_profile_field_name() == ‘FIELD NAME’) {
echo date(‘DATE FORMAT’,xprofile_get_field_data(“FIELD NAME or FIELD ID”));
}
else {
bp_the_profile_field_value();
}
?>
Note that DATE FORMAT, FIELD NAME and FIELD ID are to be replaced with the true value.

Once again, this is just only temporary fix, and I still wait until someone comments to this post. Currently, I am wandering if I post to http://trac.buddypress.org.

[chestnut_jp]

Though I tried both “https://trac.buddypress.org/ticket/2947&#8221; and “https://trac.buddypress.org/ticket/2240&#8221;, the problem prolongs.

The reason why 1970 January 1st is always displayed is that bp_the_profile_field_value and/or related functions always return “0” ignorring the true value.

I need to use date(‘Y/m/d’) instead of bp_the_profile_field_value for “datebox” for the time being…

Anybody has any idea?

[chestnut_jp]

I changed the version from 1.2.6 to 1.3, as it is still awaiting review.

[chestnut_jp]

I changed the version from 1.2.6 to 1.3, as it is still awaiting review.

[chestnut_jp]

I submitted https://trac.buddypress.org/ticket/2964

[chestnut_jp]

Hi @andrea_r,
Oh, I see.

But my situation is a little bit defrrent from what you seem to understand.
First, I use WP 3.0.3 with multi site enabled. Then I install buddypress plugin and enable it.
Thus, I have no extra blog but only one attached to buddypress (primary) site.

In this situation, a user registers the site and he/she becomes “author” of the site blog. However, it does not show in the user’s “My Blogs” nor listed in “Blog Directory”.

As a result, when the user wants to post, he/she has to access to dashboard by typing directory the url of dashboard.
Of course, the user can post a new post, and it will be displayed in the site blog. Nevertheless, the user still can not see the site blog in his/her “My Blogs” in the admin bar nor in “Blog Directory” until the administrator re-activates the buddypress plugin.

I do not think this is due to WP core features. I think this is a bug lies in the buddypress plugin.

How do you think?

[chestnut_jp]

Hi @andrea_r,

Do you mean it is natural that the buddypress plugins is re-activated in order to show site blog under each user’s My Blogs?
Sorry, but I am not with you…

How about your buddypress site? Each user does not have site blog under their My Blogs unless the re-activation of buddypress plugin?

If so, I will report it as a bug to the tracker, since it does not hapen only for me, and I really do want this to be fixed.
Anyway, aren’t there any other people seeing the same thing happening?

[chestnut_jp]

Thanks for your reply, @andrea_r

If so, why re-activating buddypress plugin makes a blog that the user belongs to show up in his/her “My Blogs” and listed in his/her “Blog Directory”?
I do not remember when, but the old (previous) buddypress immediately showed the site blog in “My Blogs” of the user who is a member of that blog.

It is weird that the user can post in the blog that is not shown in “My Blogs” nor not listed in “Blog Directory”, isn’t it?

[chestnut_jp]

Thank you @djpaul and @hnla.

Because I?am not sure nor have a good solutions, I hesitate to write trac tickets.
Well, I will write tickets as just a bug report even without supposed solutions, from now on.

[chestnut_jp]

OK,
I made a custom “Dashboard” button in admin bar until the best solution is found.
For people who want to add the custom dashboard, seeing the same trouble:

1) make bp-custom.php in /wp-content/plugins/
2) write the folowing in bp-custom.php:

function custom_adminbar_dashboard_button() {
	if (is_user_logged_in()) {
		echo '<li><a href="/wp-admin/">' . __('Dashboard', 'buddypress') . '</a>';
		echo '<ul>';
		echo '<li><a href="/wp-admin/">' . __('Dashboard', 'buddypress') . '</a></li>';
		echo '<li><a href="/wp-admin/post-new.php">' . __('New Post', 'buddypress') . '</a></li>';
		echo '<li><a href="/wp-admin/edit.php">' . __('Manage Posts', 'buddypress') . '</a></li>';
		echo '<li><a href="/wp-admin/edit-comments.php">' . __('Manage Comments', 'buddypress') . '</a></li>';
		echo '</ul>';
		echo '</li>';
	}
}
add_action('bp_adminbar_menus', 'custom_adminbar_dashboard_button', 1);

Nevertheless, “Blog Directory” does not show the site blog, so I have to re-activate the buddypress plugin anyway.

[chestnut_jp]

Umm..

It seems that the following phenomenon revives:

Version 1.2.4.1 – May 23, 2010
Fixed bug with WPMU installs where the blog directory would show no blogs. No change for standard WordPress installs.

[chestnut_jp]

I found the way, and everything seems to be right now.

[chestnut_jp]

@DJPaul
I finally found the reason.
It is due to my customization of the plugin named “BuddyPress Group Email Subscription”.
Due to the setting of WP3.0.1, which forces Time zone to UTC ignoring the local date_default_timezone_set, the plugin claims that the server time is UTC. As a result, the displayed time from the plugin is 9 hours behind Japan time.

For this reason, I added “date_default_timezone_set(‘Asia/Tokyo’);” to the plugin’s script, which is the reason of the problem I posted here.

Ummm….
I should once again think about the solution how to fix the plugin. Any idea?

[chestnut_jp]

@AnindyaRay
If your case is that uploaded avatar is not be displayed but Gravatar is, see the following topic and try my post:
https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/avatars-of-member-not-showing-in-all-blogs

[chestnut_jp]

@DJPaul
I am not yet sure but corrections of message time in InBox or some other plugins related to activity stream may be the source of my mentioned problem, because the new BuddyPress site that I made with WP3.0.1 with only buddypress plugin shows the right time.

I am still investigating the reason and the source of this problem.

[chestnut_jp]

@hnla
Thank you for your information.

[chestnut_jp]

@DJPaul

Thanks for you advise.
Because I am not yet good at PHP scripts, I posted here so that people can see what is wrong and what is right.

Regarding the correction I posted, it surely corrects the time displayed, but not all. There are some parts still showing the wrong time. Thus, I have to consider once again from the start.

Doesn’t it have an influence that the current WP ignores the date_default_timezone_set setting? The current WP 3.0.1 sets the date_default_timezone_set setting to just ‘UTC’, even though we set our time zone in PHP.ini.

This WP setting sometimes interferes…

Anyway, it is true that current BP shows wrong time display, it is not the real JAPAN time. Isn’t there someone facing the same problem?

[chestnut_jp]

SInce BP 1.2.6 has the same problem, I would like to open my idea, which is based on @liemcc.

As $upload_dir in bp-core-avatars.php seems to be correct, I changed $upload_dir only.

At line 571 or so,

`[ Original ]
$upload_dir = str_replace( get_blog_option( $current_blog->blog_id, ‘home’ ) , get_blog_option( BP_ROOT_BLOG, ‘home’ ), $upload_dir );

[ Changed ]
$upload_dir = get_home_url( BP_ROOT_BLOG, ‘/’ ) . get_blog_option( BP_ROOT_BLOG, ‘upload_path’);`

Note: There are some other way of correction, and I selected the above becuase I do not want to write the direct path like “/wp-content/” in case upload path changes in the future again.
The reason why we have to change the original script is that WP 3.0.1 has changed upload path for the Blog ID 1 from blogs.dir to “wp^content/uploads” unless we change the default upload path, where “BP_ROOT_BLOG” means Blog ID 1.

I hope this will be helpful for everyone and the next-version BP.