BuddyPress.org

update: with wp-hooks-filters-flow.php I get the following errormessage:

82. comment_post

* Priority 10 :

1. bp_blogs_record_comment()

2. SearchUnleashedPlugin->comment_post()

Catchable fatal error: Object of class SearchUnleashed_Widget could not be converted to string in /webserver/wordpress/wp-admin/wp-hooks-filters-flow.php on line 62

Maybe anything related with the problem, breaking off the database upgrade process of buddypress?? I’m wildly guessing now since I’ve been debugging like crazy…

Forgot to mention:

– Running WPMU, ran automatic upgrade to 2.7.1 prior to installing BP

– Installed BP 1 using the Plugin Installer in the WPMU admin gui (did not upgrade from an RC, have never run BP before)

Okay, since we’ve had a few people make this mistake I need to ask this just in case. Everyone in this thread who is having 404 issues is running BuddyPress with WPMU and not the single-user version of WordPress, correct?

This means downloading WordPress from here: https://mu.wordpress.org/download/

Specifically @Sgoetz-

Running WPMU, ran automatic upgrade to 2.7.1 prior to installing BP

Were you running WPMu 2.7.1-beta1 before upgrading?

If so, you cannot upgrade from beta1 to public 2.7.1 using the automatic upgrade feature. This is because the upgrade script “sees” WPMU 2.7.1 = WPMU 2.7.1, meaning it does not upgrade you from beta1 since it thinks you are already running 2.7.1.

So, you must manually upgrade WPMU following these instructions: https://codex.wordpress.org/Upgrading_WPMU

Freaking Wildchild-

the problem occurs after restoring “certain” data which gives this behavior.

What do you mean by “certain”? Can you be more specific?

Okay, I’ve reread this thread for the second time. You state that:

The problem must be with the data; since a fresh install works perfectly and after the data gets imported, I get the nasty 404 bug.

Andy’s answer is:

This is normal with WPMU, you are not going to be able to transfer over blog tables as there are all sorts of URL settings in the DB.

I have a few questions based on this interchange:

1. Which version of MySQL are you (is your host) running?
2. Have you tried repairing the DB tables before reimport?
3. Are you moving your data between different domains?

Since WPMU 2.7.1 + BuddyPress 1.0 + standard themes work fine with a new, empty MySQL DB, the issue is, as you state, with the data. Either you have data corruption, indices that need reindexing, or hardcoded links within the tables that are causing the 404s.

If the domain mapping is not identical to the hardcoded links in your WPMU tables, you will have issues.

So, here’s what I’d suggest:

1. Backup your data again
2. Then, repair/reindex
3. Then, if your domain mapping is not identical, follow these instructions keeping in mind that these articles are for WP and not WPMU. You’ll have to adjust accordingly:

   • https://codex.wordpress.org/Changing_The_Site_URL
   • https://codex.wordpress.org/Moving_WordPress

Sgoetz-

Just log into the backend as Site Admin. The dashboard shows which version of WPMU you’re currently running.

@JeffSayre: I’m running MySQL v5, tried repairing before importing and am not moving inbetween different domains. Although I am using the sunrise domain plugin on the original blog.

I’ve tried those things but it didn’t really give any differences at all; if I could know which exactly is required and which not in the sql tables, I could try to hunt specifically which data it gets weird on …

Freaking Wildchild-

Since Donncha’s WordPress MU Domain Mapping plugin (aka the sunrise domain plugin) allows you to map a blog to another domain, this could be the issue. I would post on the WPMU forum or, better yet, contact Donncha directly to ask for his assistance. http://ocaoimh.ie/wordpress-mu-domain-mapping/

This is beyond scope of the BuddyPress support forums.

@JeffSayre: It’s a glad thing I can mention the sunrise plug-in works perfectly with Buddypress as before; it was qTranslate which seemed to be the culprit.. So we’re already a step closer to the solution (as mentioned one post above) …

Thanks for the extensive help though, since development and problem-solving starts with ruling anything of special parameters out.

I guess qTranslate was very special and overseen….

ps: Do you have any idea why we both are marked “inactive” on the forums? I don’t feel idle at all :p

JohnJamesJacoby: Very strange, I’ve posted it again and it doesn’t show up in the list. Seems to be posts are not being registered well?

When trying to change the resolved flag, it says the posts don’t exist; also with the second one I’ve created.

Bugs in the bbpress backend integration?

@JeffSayre: the problem was first discovered on a running install with 10 blogs (which is currently crippled because of different languages). I’m thinking about creating a separate plugin with some regexp support so it’ll filter out the basic language for non-qtranslate enabled blogs.

With the first test install, not everything didn’t work like specified because I was using different domains. After I needed to play with a development version on live domains for that, for swift periods so those changes wouldn’t interrupt too much of the normal services.

Since the test install didn’t work under a test-domain, I needed to do it this ackward way, which required more time. Now I’m again porting the entire buddypress template towards the one I’m currently having installed…

Still, the qtranslate is a big miss, since it is currently causing havoc on the main “hotsite” and also for those with bi-langual articles…

Freaking Wildchild-

I do understand that this has been a big mess for you. Please don’t take my last post personally. I appreciate your willingness to share your issues.

If you have not yet done so, I suggest starting a new thread to discussion this particular issue and to track the progress you are making. Now that we know more about your particular setup, it will be interesting to see how this works itself out.