[ZooneyParticipant @zooney 3 years, 1 month ago]

Hrrm, what do these PDO errors say?

PDO is essentially a library of database drivers. These errors would probably have something to do with things not being properly written to your database…

It may be a different issue entirely, it’s hard to say.

[ZooneyParticipant @zooney 3 years, 1 month ago]

Hrrm… I’m no longer getting the issue after the fix…

Have you checked your error logs to see if something strange is going on?

[ZooneyParticipant @zooney 3 years, 2 months ago]

Looks like we’ve got a fix for this:

http://trac.buddypress.org/ticket/1999

The milestone seems to be for 1.2.3, but that patch should work for now.

[ZooneyParticipant @zooney 3 years, 2 months ago]

…err, I think the change would probably only be horribly detrimental if you were running anything else out of that database that required strict transactions.

It’s likely that there won’t be much impact, but there’s really no way for me to say.

Alternatively, you could just modify the table in the database to give those two values a default… That’s a little involved. You’ll need to make some queries and have the ALTER_TABLES privilege and all of that…

A kind soul added to the ticket I posted (#1999) and found where the table in question was actually being defined and added defaults to the columns that seem to be causing the issue.

Hopefully that will provide a fix, but I don’t know enough about BuddyPress to even know what those columns do…

[ZooneyParticipant @zooney 3 years, 2 months ago]

Hrrm, I’ve been updating the ticket (first of all to add the milestone of 1.2.2)… d’oh…

I’ve looked at my error logs and have come up with an error like this:

WordPress database error Field 'mptt_left' doesn't have a default value for query INSERT INTO wp_bp_activity ( user_id, component, type, action, content, primary_link, date_recorded, item_id, secondary_item_id, hide_sitewide ) VALUES ( 1, 'activity', 'activity_update', '<a href=\"http://localhost.localdomain/BuddyPress/members/admin/\" title=\"admin\">admin</a> posted an update:', 'Update.', 'http://localhost.localdomain/BuddyPress/members/admin/&#039;, '2010-02-24 14:23:43', '', '', 0 ) made by require_once, require_once, do_action, call_user_func_array, bp_core_add_ajax_hook, do_action, call_user_func_array, bp_dtheme_post_update, bp_activity_post_update, bp_activity_add, BP_Activity_Activity->save

So, either something is going wrong by the time BP_Activity_Activity->save is being called…

…or, the wp_bp_activity table simply needs a default value for mptt_left when the table is created in the first place.

If you don’t mind messing with your database tables, I’ve found that simply adding a default value of 0 for the mptt_left and mptt_right columns corrects the error as well, without the need to turn off strict mode.

It’s hard to see if this bug is an improperly defined table, or an improperly formed function call…

…anyone have any thoughts?

[ZooneyParticipant @zooney 3 years, 2 months ago]

I’ve reported it in this ticket:

http://trac.buddypress.org/ticket/1999

I’ve made a few updates to the ticket after I figured out it was being caused by strict mode… …hopefully someone closer to BuddyPress can sort this out, but I s’pose I’ll keep digging through the code to see if I can find the actual bug…

[ZooneyParticipant @zooney 3 years, 2 months ago]

To turn of strict mode in MySQL you’ll have to locate your MySQL instance’s .ini file and look for a line like:

sql-mode=STRICT_TRANS_TABLES,…

And remove “STRICT_TRANS_TABLES” and restart the instance.

Unfortunately the scope of this setting is for the entire MySQL server instance and can’t be done on a schema-by-schema basis…

I’d only do this as a workaround, though. My guess is that BuddyPress should be supporting strict mode, and there’s just a bug in there…

[ZooneyParticipant @zooney 3 years, 2 months ago]

…ah-ha…

This is being caused by MySQL running in strict mode… …shutting off strict mode stops the issue (could be a temporary work-around for some people).

…does BuddyPress support strict mode?

If anything, there must be some bug in there which is trying to add improperly formatted data to the database…

[ZooneyParticipant @zooney 3 years, 2 months ago]

I’m also getting a lot of:

“Sorry, there was no activity found. Please try a different filter.”

…messages in orange boxes. Although I’m sure it should be listing some activity…

[ZooneyParticipant @zooney 3 years, 2 months ago]

I’ve started with a fresh install of WordPress Mu (new database and all) and still get this issue.

Thanks for the tip about bp_activity_add. I’ll start looking there.

[ZooneyParticipant @zooney 3 years, 2 months ago]

Hrrm… I’ve found this old ticket:

http://trac.buddypress.org/ticket/1647

…and the advice is to “upgrade your db” whatever that vague phrase is meant to mean. I installed a fresh copy of both WordPress Mu and BuddyPress from the ground up and still get the issue.

I opened my own ticket a few days ago:

http://trac.buddypress.org/ticket/1999

…if anyone has anything to add to it. I just can’t even begin to trace what the problem is.

[ZooneyParticipant @zooney 3 years, 3 months ago]

…I just don’t see the sense in BuddyPress needing to treat usernames in a different manner than WordPress does. It smacks of a questionable design decision, that’s all.

Regardless, I’m not getting this problem in BuddyPress 1.2 it seems…

…although in BuddyPress 1.2 I’m getting “There was a problem posting your update, please try again.” everytime I try to do anything, but that’s a different story.

[ZooneyParticipant @zooney 3 years, 3 months ago]

I’ve come to a resolution in the Bug Report I filed.

One foolish error on my part was placing the define statement in the wrong area of wp-config.php (after the “no more edits” comment).

Regardless, I think this has clarified the bug I was actually experiencing.

The BP_USERNAME_COMPATIBILITY_MODE flag does stop the issues associated with periods in the username from occurring, as it appears to be designed to.

I’m running into an problem, however, where usernames with “@” in them are causing a very odd issue. For some reason if a username has an “@” in it, it will cause 2 problems I’ve found so far:

1.) Clicking on the “Create a Group” link takes you back to the BuddyPress home page

2.) Posting on your own wire does post the message, but for some reason redirects you to the BuddyPress home page after hitting post.

…I have to admit I’m a little baffled as to why there needs to be a “username compatibility mode”. Wouldn’t using the “user_nicename” for everything (except just literally displaying the username) sidestep any issues with the actual form of the username? I’m just speaking from my wealth of ignorance, but that just seems weird to me.

[ZooneyParticipant @zooney 3 years, 3 months ago]

Hrrm… That’s interesting, but the thing about my issue is that I would like to default to user_login and not user_nicename (user_nicename is causing the problem).

From your fix, I’d simply have to imagine that it should already be doing what I want, but it doesn’t. It attempts to always put in user_nicename.

It’s very confusing. It’s also very disappointing. BuddyPress seemed to have promise for a few applications at my university, but I’m not going to be able to use it effectively without being able to use usernames that essentially look like emails (they would be Shibboleth eppns).

I don’t get it, why is BuddyPress such a pain about usernames? If BuddyPress is a WordPress Mu plugin, it should work with any username that is valid in WordPress… I can only assume this is some kind of bug within BuddyPress itself, and I’ll continue treating it as such.

[ZooneyParticipant @zooney 3 years, 3 months ago]

To anyone who happens upon this post in desperation…

After posting this issue in BuddyPress’s bug tracking system, I was informed that I needed to set:

define( ‘BP_ENABLE_USERNAME_COMPATIBILITY_MODE’, true );

…in wp-config.php

This seemed to resolve some of the issues, but not all of them. For some reason BuddyPress’s theme still seems to be forming the incorrect URIs in some areas.

So, that may help in your case. I’ve actually reopened the issue to see if there’s anything further that can be done…