Two separate database u mean?
By 2 separate DBs I mean that:
1. Earlier we were not using BuddyPress and had MySQl as backend DB.
2. We shifted to BuddyPress later on but maintaining MySQL DB as well for SignUp by the users.
Now the problem is when the user adds himself the records are saved in our MySQL DB but when the user updates his records the updated data goes and is saved in the BuddyPress DB.
How to replicate & sync the updated records in the BuddyPress DB to our MySQl DB (some 35 fields are getting updated and needs to be replicated in the MySQL DB)
A help is really solicited.
best regards
So you got only 1 db right? When not using bp users go into wp_users with bp installed they still go there…only 4 extra xprofile fields rows are created..which store the xprofile data
Does that solve your issue?
Okay I will try, getting some clue. But how will I maintain data consistency say user updates CITY information and same information must be reflected in the CITY field of the MySQL DB created by me.
Am afraid..if user is updating his profile data will get stored in xprofile db…you will need to replicate this xprofile data..check the 4 xprofile rows I mentioned would be clear…wp_users will have the username and password…rest all in xprofile
It woud be better if you merge your 2 db to the one controlled by WP.
That said, you can also try to get something (even if not easy), after reading from here.
okay i will try and get back soon.
@danbp: Thanks for the support. I have checked HyperDB, But I think that it is not useful for our problem scenario.
@sharmavishal: Thanks for the support. I know that BP is saving extra profile data in xprofile tables and when user is updating his info that will be reflected in those xprofile tables only(these xprofile tables are in database named “wp_900”). I want to reflect those changes (updates) in one more table named “USER_data” which is in different database named “AlumniDB”. The AlumniDB tables store the data of single user in single row whereas xprofile table stores the data of single user in 35 rows (each row for each profile field.)
It will be helpful if you suggest some plugin for this work.
no plugin for that…as @danbp suggested better to have one db of users..else its going to get quite complicated…
before you installed buddypress was your site a wordpress site?
also i see you installed bp in a sub folder..not in the root…http://mujalumni.in/portal/ is that correct?
is the root site a wordpress enabled site?
are you looking at having a main site and the community (powered by buddypress) on a seperate folder/subdomain?
I have two site one for static info about MUJ Alumni (http://mujalumni.in/muj2). It is also a wordpress site. The second one is a portal for our members (http://mujalumni.in/portal). It is also a wordpress site with buddypress support.
No, I am not thinking of having subdomain /subfolder. I am already managing that.
If you can provide your contact details, we can have a talk about this.
you need to have a wordpress multisite done….and install buddypress on a folder/domain…check codex’s of both..you will get an idea how you can run wp on main domain and bp on sub domain or sub folder
trust me..you are not able to manage in the current scenario which you have…
this is a free support forum..you dont need to talk to me on a one2one basis…custom help is not an option here…you might have a look at the job board if you are looking at custom help
best of luck
Thanks for the help. I will go through your suggestions.
As both sites are WordPress, you can, for example, share the wp_users table between separate WordPress installations, but all the BuddyPress profile data is stored in custom BuddyPress tables. The non-BuddyPress site will have no idea where or how to get the profile data from the BuddyPress-powered site.
You could, for example, copy the database tables across each night to keep the non-BuddyPress site updated, but you’ll still end up running BuddyPress on the main site in order to have access to APIs to query/fetch/display that data. Again, you could write custom SQL to achieve this, but you’re digging yourself into a large hole.
I agree with the previous advice given 🙂
