[wildchild]

@John: We multilangual users are sitting on the tip of our chairs for qTranslate to work

Thanks for looking into this; I tried this myself and gave up after a few days because my efforts didn’t really work out good except continuesly corrupting the database with thousands of dupes..

I wish you the very best luck in getting this fixed …

[wildchild]

@John: Did you have any details yet about qTranslate & Buddypress? Since this dreadfull bug is still haunting my installation as we speak

Thanks in advance, Freaking Wildchild.

[wildchild]

@Bercy: It’s wp-signup.php etc.. it’s possible to seperate all buddypress installations, although you’ve have to be creative which databases and scripts you are going to talk to when.

[wildchild]

@JeffSayre: I’ve tried creating it’s own topic but bbpress seems not to register my new topics … don’t know why exactly …

[wildchild]

@Dbascent94: Do you got qtranslate installed by any hand ? If so ; try to disable and test again ….

[wildchild]

@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…

[wildchild]

@JohnJamesJacoby: Is there any possibility to override the bp slugs like members, groups etc.. so they would still work? Because since the problem is pinpointed to that single qTranslated module, I’m having problems with the multi-translations …

or is the progress in the latest svn/trunks ?

[wildchild]

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?

[wildchild]

@Socialpreneur: So how do you currently handle multi-language posts on your front page of your main blog? Or do you use it differently?

[wildchild]

@WillPCG & Sgoetz: Do you got qTranslate installed by any hand? If so, check out the post at https://buddypress.org/forums/topic.php?id=2693#post-14750 which is started especially to this 404 problem caused by qTranslate.

[wildchild]

@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

[wildchild]

@all: I’ve found the culprit of the entire 404 soap which has been terrorizing my screen the last few weeks (smashes drums): It’s Qtranslate!

Any of you having the same problems while qtranslate is installed? Check out the topic at: https://buddypress.org/forums/topic.php?id=2693#post-14750 which is started especially to this solution.

[wildchild]

@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 …

[wildchild]

@Jeff Sayre: Whenever I start migrating normal production data from the existing RC1 blog to v1.0…

I am unable to migrate existing data towards the v1.0 standard and I’m seemingly not the only one with those problems. I’m very sure it is database related ; errors or I don’t know why … It’s currently blocking my further buddypress development since it just doesn’t work…

As soon as I import the database the members, groups and other slugs towards Buddypress social functions stop working. Please read the previous messages I’ve written for a detailed outline about which I did with the database…

[wildchild]

@Jeff: I’m for sure running the latest WPMu 2.7.1 with BP 1.0 ; the problem occurs after restoring “certain” data which gives this behavior.

[wildchild]

Interesting behavior – any developer got any clue what this can be ?

[wildchild]

@JohnJamesJacoby: I’ve tested this with the bphome theme, visible on beta.artistplug.me ; I’ve also tested with a standard install, copying over the database data … since then things got wicked… — also tested copying over the functions.

I’m very sure you are on to something ; how can we verify everything gets passed well through these functions ?

I also wonder for how far and reliable the WordPress XML export/import functions work towards a succesfull migration for 10 RC1 blogs towards BP v1.0 ..

[wildchild]

@Theeasybutton & Ncandelier: I’m glad I’m not the only one with this problem, hopefully it will lead to a solution for the next upcoming releases because this is quite annoying

@Ncandelier: Did you use existing data or is this a fresh install?

[wildchild]

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…

[wildchild]

@Bercy Just install your WordPress MU in a different directory; create a new database, preferably with a new user for security and you\’ve got it working …

With a fresh user and database you won\’t be overwriting your existing bp\’s.

If you want to use the same userdatabase and share it serverwide, use the same database but change the prefix per buddypress installation.

Hope that has answered your question with virtual hosting & wordpress ..

I wish it was as easy to migrate existing data towards upgraded BP\’s

[wildchild]

@Patriotsandheroes: Welcome to the official BuddyPress 404 club

In order to enter, your page has to be broken

[wildchild]

@Sgrunt: I’m not completely convinced my problem is an exclusive Buddypress problem either ; since I’ve tried to upgrade the site and no slugs worked anymore.

The basic WordPress MU blogs -DO- work perfect though, after database migration; Buddypress seems to be giving a lot more problems with all of them 404 errors..

With exception the normal WordPress MU functions which seem to continue working..

[wildchild]

update: Tried too with BuddyPress v1.0 with the same results… 404 errors on the social slugs…

Anyone around knowing a good tool to export/import the database of WordPress MU/Buddypress so I’d not need to do all this manually? I know I’ll be making errors because there are minimally 10 blogs to move.

[wildchild]

Is there any news yet from anyone having 404 problems having it fixed? Since I’m still in the dark, not really motivated moving all data over again-and-again by hand..

[wildchild]

@Sgrunt: Was your problem by any chance related to which I’m still having, documented at https://buddypress.org/forums/topic.php?id=2314 ? I’m continuesly getting 404’s as soon as I use the old buddypress database on the new install. The “save” didn’t help at all..

The only known way of fixing this is manually inserting ALL articles and parameters by hand from one to another database requiring 2 builds to work parallel. This is heavy for just an upgrade .. what will it be with RC3 etc..?