[arghagain]

bump

[arghagain]

I’m so happy that now I got activity problem solved which I had to follow the suggestion at http://premium.wpmudev.org/forums/topic/buddypress-upgrades-with-multi-db#post-28120. Unfortunately, I couldn’t solve the broken message problem where a member or even admin cannot send a private message to another member. Whenever trying to send a private message to a friend (which had been accepted as a friend already), I get this error “There was an error sending that message, please try again.”

Anyone has any idea how to go about fixing the private message problem?

[arghagain]

After looking through global db, I saw the buddypress did not installed any bbpress table at all. After looking into defaults.bb-schema.php, I recreated the bbpress tables as follow:

CREATE TABLE mydb_global.wp_bb_forums (

forum_id int(10) NOT NULL auto_increment,

forum_name varchar(150) NOT NULL default ”,

forum_slug varchar(255) NOT NULL default ”,

forum_desc text NOT NULL,

forum_parent int(10) NOT NULL default 0,

forum_order int(10) NOT NULL default 0,

topics bigint(20) NOT NULL default 0,

posts bigint(20) NOT NULL default 0,

PRIMARY KEY (forum_id),

KEY forum_slug (forum_slug)

);

CREATE TABLE mydb_global.wp_bb_meta (

meta_id bigint(20) NOT NULL auto_increment,

object_type varchar(16) NOT NULL default ‘bb_option’,

object_id bigint(20) NOT NULL default 0,

meta_key varchar(255) default NULL,

meta_value longtext default NULL,

PRIMARY KEY (meta_id),

KEY object_type__meta_key (object_type, meta_key),

KEY object_type__object_id__meta_key (object_type, object_id, meta_key)

);

CREATE TABLE mydb_global.wp_bb_posts (

post_id bigint(20) NOT NULL auto_increment,

forum_id int(10) NOT NULL default 1,

topic_id bigint(20) NOT NULL default 1,

poster_id int(10) NOT NULL default 0,

post_text text NOT NULL,

post_time datetime NOT NULL default ‘0000-00-00 00:00:00’,

poster_ip varchar(15) NOT NULL default ”,

post_status tinyint(1) NOT NULL default 0,

post_position bigint(20) NOT NULL default 0,

PRIMARY KEY (post_id),

KEY topic_time (topic_id, post_time),

KEY poster_time (poster_id, post_time),

KEY post_time (post_time),

FULLTEXT KEY post_text (post_text)

) TYPE = MYISAM;

CREATE TABLE mydb_global.wp_bb_terms (

term_id bigint(20) NOT NULL auto_increment,

name varchar(55) NOT NULL default ”,

slug varchar(200) NOT NULL default ”,

term_group bigint(10) NOT NULL default 0,

PRIMARY KEY (term_id),

UNIQUE KEY slug (slug),

KEY name (name)

);

CREATE TABLE mydb_global.wp_bb_term_relationships (

object_id bigint(20) NOT NULL default 0,

term_taxonomy_id bigint(20) NOT NULL default 0,

user_id bigint(20) NOT NULL default 0,

term_order int(11) NOT NULL default 0,

PRIMARY KEY (object_id, term_taxonomy_id),

KEY term_taxonomy_id (term_taxonomy_id)

);

CREATE TABLE mydb_global.wp_bb_term_taxonomy (

term_taxonomy_id bigint(20) NOT NULL auto_increment,

term_id bigint(20) NOT NULL default 0,

taxonomy varchar(32) NOT NULL default ”,

description longtext NOT NULL,

parent bigint(20) NOT NULL default 0,

count bigint(20) NOT NULL default 0,

PRIMARY KEY (term_taxonomy_id),

UNIQUE KEY term_id_taxonomy (term_id, taxonomy),

KEY taxonomy (taxonomy)

);

CREATE TABLE mydb_global.wp_bb_topics (

topic_id bigint(20) NOT NULL auto_increment,

topic_title varchar(100) NOT NULL default ”,

topic_slug varchar(255) NOT NULL default ”,

topic_poster bigint(20) NOT NULL default 0,

topic_poster_name varchar(40) NOT NULL default ‘Anonymous’,

topic_last_poster bigint(20) NOT NULL default 0,

topic_last_poster_name varchar(40) NOT NULL default ”,

topic_start_time datetime NOT NULL default ‘0000-00-00 00:00:00’,

topic_time datetime NOT NULL default ‘0000-00-00 00:00:00’,

forum_id int(10) NOT NULL default 1,

topic_status tinyint(1) NOT NULL default 0,

topic_open tinyint(1) NOT NULL default 1,

topic_last_post_id bigint(20) NOT NULL default 1,

topic_sticky tinyint(1) NOT NULL default 0,

topic_posts bigint(20) NOT NULL default 0,

tag_count bigint(20) NOT NULL default 0,

PRIMARY KEY (topic_id),

KEY topic_slug (topic_slug),

KEY forum_time (forum_id, topic_time),

KEY user_start_time (topic_poster, topic_start_time),

KEY stickies (topic_status, topic_sticky, topic_time)

);

CREATE TABLE mydb_global.wp_bb_users (

ID bigint(20) unsigned NOT NULL auto_increment,

user_login varchar(60) NOT NULL default ”,

user_pass varchar(64) NOT NULL default ”,

user_nicename varchar(50) NOT NULL default ”,

user_email varchar(100) NOT NULL default ”,

user_url varchar(100) NOT NULL default ”,

user_registered datetime NOT NULL default ‘0000-00-00 00:00:00’,

user_status int(11) NOT NULL default 0,

display_name varchar(250) NOT NULL default ”,

PRIMARY KEY (ID),

UNIQUE KEY user_login (user_login),

UNIQUE KEY user_nicename (user_nicename),

KEY user_registered (user_registered)

);

CREATE TABLE mydb_global.wp_bb_usermeta (

umeta_id bigint(20) NOT NULL auto_increment,

user_id bigint(20) NOT NULL default 0,

meta_key varchar(255),

meta_value longtext,

PRIMARY KEY (umeta_id),

KEY user_id (user_id),

KEY meta_key (meta_key)

);

Unfortunately, test user is still cannot create topic. BBpress forum is essentially broken.

[arghagain]

John, yes it say it did it successfully. I’m looking into defaults.bb-schema.php right now to see if I can find anything. I’m clueless now. Funny thing is that this file is not in buddypress plugin before, but I downloaded the buddypress again from buddypress.org and found it. This file supposed to be gone after buddypress got upgraded or installed?

[arghagain]

I did not use bbpress for buddypress 1.0.0, but after upgrade to buddypress 1.1.2, I use the one click install bbpress mode. No existing bbpress before that.

[arghagain]

OK, I saw this in bp-activity.php:

/* Drop the old sitewide and user activity tables */

$wpdb->query( “DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_user_activity” );

$wpdb->query( “DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_sitewide” );

And so I look in the db and saw there is no bp_activity_user_activity table, and there is no bp_activity_sitewide table. This means it’s a good thing since these got dropped.

Though I saw this

$sql[] = “CREATE TABLE {$bp->activity->table_name}

but to my lack of knowledge of programming, I see this and think it’s bp_activity_something (but no idea)…

Looked everywhere and I only saw this in db bp_activity_user_activity_cached. This table doesn’t look like it was created by

$sql[] = “CREATE TABLE {$bp->activity->table_name}, but I could be wrong because I looked at the part under $sql[] = “CREATE TABLE {$bp->activity ->table_name} and saw similar rows get created and these rows are in my bp_activity_user_activity_cached table.

For example, in bp-activity.php,

function bp_activity_install() {

global $wpdb, $bp;

if ( !empty($wpdb->charset) )

$charset_collate = “DEFAULT CHARACTER SET $wpdb->charset”;

$sql[] = “CREATE TABLE {$bp->activity->table_name} (

id bigint(20) NOT NULL AUTO_INCREMENT PRIMARY KEY,

user_id bigint(20) NOT NULL,

component_name varchar(75) NOT NULL,

component_action varchar(75) NOT NULL,

content longtext NOT NULL,

primary_link varchar(150) NOT NULL,

item_id varchar(75) NOT NULL,

secondary_item_id varchar(75) NOT NULL,

date_recorded datetime NOT NULL,

hide_sitewide bool DEFAULT 0,

KEY date_recorded (date_recorded),

KEY user_id (user_id),

KEY item_id (item_id),

KEY component_name (component_name)

) {$charset_collate};”;

require_once( ABSPATH . ‘wp-admin/upgrade-functions.php’ );

dbDelta($sql);

In my current db, table bp_activity_user_activity_cached has everything except hide_sitewide row. In my current db, table bp_activity_user_activity_cached has extra rows that function_bp_activity_install doesn’t have such as date_cached and is_private rows.

Any suggestion? What rows should I add or remove? Am I looking at the right stuff?

Looked like at the end of the function bp_activity_install(), it has require_once( ABSPATH . ‘wp-admin/upgrade-functions.php’ );

dbDelta($sql);

Maybe the upgrade-functions.php had not gone smoothly?

[arghagain]

bump

[arghagain]

Unless you have 1 million splogs sign up a day, you can always manually check and delete each splog. Trust me, you can discourage spammers to splog you, but you won’t be able to get rid of new spammers and new splogs. Unless you have a smart programmer that programs a good algorithm in recognizing splogs and spammers, but it probably gonna cost ya big time.

[arghagain]

I hope this post help some of smart people on buddypress.org to help me figure out an easy solution to this problem. http://premium.wpmudev.org/forums/topic/activity-broken-for-buddypress-112-and-wpmu-2852

[arghagain]

I know this may be a stupid reply or may be repeating someone else saying, but have anyone see a problem of getting buddypress 1.1.2 on wpmu 2.8.5.2?

[arghagain]

Ya I experience this with firefox 3.5.3, but I have not tested this with ie7 or ie8 yet.

[arghagain]

This is great idea. If you can integrate sites’ users of the like such as Twitter, Facebook, Linkedin and so on… it will be a killer app for bb.

[arghagain]

You can try use another template or theme to see if the problem is the same as a default theme? I think on buddypress.org there is another bb 1.1 theme that is available for you to download.

[arghagain]

bump

[arghagain]

Automatic upgrade is not that smooth. I think it’s best for you to do manual upgrade in the future, and especially true when you did some customization.

[arghagain]

New update: I couldn’t figure out what had gone wrong . This time around, I used a working database that was backed up before I had updated wpmu to 2.8.4.a, and bp before 1.0.3. Then I apply the working bp1.0.3 and working wpmu2.8.4a with that old database, and I ran the upgrade process in wpmu to synch the blogs — this done without any additional plugins and mu-plugins (all default). After all that work, I still got new sign up users cannot set correct privacy setting with the sign-up page. Instead, he/she must logged in, changed the privacy setting again to have everything works out. This sound like a template problem to you? Maybe the template is passing in the wrong sql call at the privacy portion? The funny thing is that this isn’t a problem with wpmu2.8.2 and bp1.

[arghagain]

OK, I have tested all methods. I even deactivated buddypress plugin, remove all plugins, and then sign up a test user with just wpmu, when did this, wpmu set privacy option for blog correctly, but right after I activate buddypress again, I saw the same user I just had created with wpmu earlier – the privacy went private again and not set as public.

This makes me think that wpmu 2.8.4a is conflicting with buddypress 1.0.3. Maybe buddypress 1.0.3 is trying to change the privacy from wpmu 2.8.4a. Since none of the plugins I installed is conflicting with either buddypress 1.0.3 or wpmu 2.8.4a at all. So this must be the problem of buddypress 1.0.3.

Can anyone help me confirm this problem? Or it’s me that the only one who has this problem? Thanks…

[arghagain]

Has anyone confirm that this work yet?

[arghagain]

I’m using “First Comment” from http://premium.wpmudev.org/project/first-comment

is similar to New Blog Defaults I think. Please tell me if you know how to fix this… thanks.

[arghagain]

Upon looking to see if anyone has the same issue as me, I found this thread. Here is my thread https://buddypress.org/forums/topic/sitewide-activity-and-sitewide-post-problems

Have anyone finally fixes this yet?

My issue? New users sign up, their blog’s privacy is set to private even though in sign up page they set it to public. After first time log in, users can set the blog to public privacy again. It’s bothering me when blog is not public even though users want it to be when first sign up, this means when they write a blog post, it will not appear in sitewide posts widget! Also when other users visit a member that has private blog, there will be an error says that “[membername] has not created any public blog.”

I’m using buddypress 1.0.3 and wpmu 2.8.4a

[arghagain]

OK, I figured the problem out but have no answer. After upgrade to wpmu 2.8.4a from 2.8.2 using buddypress 1.0.3, I noticed that when new users sign up, even though they apply for public privacy at the sign up page, when logged in, their blogs aren’t public, and as a test member, I have to go to settings >> privacy >> and choose a radio button for public privacy again, and afterward it works.

Seem to me the sign up page did not allow public privacy even though members wanted that option!

Any idea how to fix this?

[arghagain]

Confirm wpmu 2.8.2 and buddypress 1.0.3 is working fine together.

[arghagain]

Ya BBPress makes u mess with cookies and I didn’t like it. I have a hard time to make it work, but removing BBPress, the BuddyPress is still working fine. BBPress is only a module, and so it shouldn’t affect the whole BuddyPress.

[arghagain]

anyone know a solution to this?

[arghagain]

I didn’t notice status changed to resolve, but it’s not. It’s somewhat resolved because I remove those lines.

I have a perfect working WPMU 2.7.1, and all I want to do is to add those lines as wordpress mu’s tutorial site suggests for security reason. I don’t need BBPress. I had tried installed BBPress before when I first installed BuddyPress. I didn’t get BBPress worked with BuddyPress so I ditched BBPress.

Clearly I have a working WPMU 2.7.1, and working BuddyPress 1.0 (final). Though my only problem is by adding those lines, the logout link won’t work properly. It’s obvious it has to do with cookies and sessions.

So by removing those lines meaning I’m not doing exactly like WordPress MU tutorial suggests. So it’s not resolved. I wonder because what I did with BBPress before and then decided not to use BBPress by removing it has an after effect that affects my situation now? I remember that BBPress requires you to mess around with cookies and stuffs like that.