Deactivating Buddypress Using MultiDB 3.0 Creates Unworkable WP-ADMIN
I suspect multidb is having a major compatible problem with Buddypress! Or I could be wrong completely! Still, I like to give this problem some voice in hope that someone smarter than I may figure out what is going on if the same thing is occurring with him/her.
So what on earth? The problem is that if I deactivate Buddypress, when network reactivate Buddypress, the backend of wp-admin is completely screw. By this I mean in option page, nothing can be saved, links in plugin page that connect to discovered categories such as active, inactive, network, drop-ins, may work incorrectly as these appear to be redirected incorrectly as in broken links.
My setting of installation should be fine since I have the latest of everything: I'm using WordPress 3.0, Buddypress 1.2.5.2, Multi-DB 3.0, latest apache, latest php, latest OS, latest of everything else!
For your information: I've always been deactivating all other plugins before I even attempting to deactivate Buddypress. This means, it's not a plugin problem either!
All files and folders within my installations have correct permissions, and these are 644 for files, and 755 for directories. .htaccess is in the right place with right information.
Notice, after the deactivation of Buddypress and things went to hell, a simple solution to quick fix is to remove Buddypress completely! Does this mean Buddypress is the main culprit?
Also, so far the only way I can ever update Buddypress since this weird issue with the deactivation of Buddypress happens (it may very well be after the upgrades of multi-db 3.0 and wordpress 3.0), is to not deactivate Buddypress at all, but to overwrite Buddypress's directories and files with newer version.
So please, advice me on this? To my knowledge, usually it's best to deactivate Buddypress, completely delete buddypress plugin in wp-content/plugins/ and then replace the removed buddypress with newer buddypress files and directories. Since deactivating Buddypress will completely screw up the whole installation and wp-admin, the only way to update is to overwrite buddypress (but only after deactivating all plugins and removed all mu-plugins). So please, anyone has an idea how to fix this problem so my updating process in the future will be more aligned with the normal procedure that has always been the case? Thanks!
Everyday at WPMU DEV we help hundreds of WP Users. Become a member today to:
- Download 250+ Premium Plugins and Themes
- Get unlimited support from WordPress Experts
- Get help with your WordPress or BuddyPress projects
Help & Support from WPMU DEV members and staff
Hi
I've got WP3, mutil-db and the latest buddypress and am activating and deactivating buddypress multiple times a day (the joys of dev testing with and without certain plugins).
I suspect it may be a global tables issue, or a global table configuration - can you check your db-config.php files and check you have the buddypress tables listed as being global. Also make sure you have a global database identified in the config table as well.
Also check your error logs!
Get personal, comprehensive and timely support and assistance
from WordPress Experts
Hi Barry,
So I need to have buddypress tables listed as being global in db-config.php? To my knowledge, in my db-config.php, I have not listed any buddypress tables as global table. Maybe this is the real reason for my problem?
Hi Aaron,
My error log for some reason has not log any problem related to this unique situation. Sadly!
Erstwhile founder
You shouldn't have to list BP tables as global tables. Multi-DB already recognizes those tables as global tables.
Thanks,
Andrew
Barry, can you clarify this a little more when you said: Also make sure you have a global database identified in the config table as well.
I kind of not understanding what you trying to tell me there, if you could clarify it further, I really appreciate, thanks!
I'm not at my computer at the moment, but you should have a line identifying your global database in the db config file so that the multi db system knows where to store the global tables.
Any tables such as the bp tables, that are accessible across the site should be held in this database and identified as being global in your config file.
Get personal, comprehensive and timely support and assistance
from WordPress Experts
Dear Barry,
I do have the global database list in db-config.php.
When I looked into global db, the tables below are what I saw I have in global db:
prefix_bb_forums
prefix_bb_meta
prefix_bb_posts
prefix_bb_terms
prefix_bb_term_relationships
prefix_bb_term_taxonomy
prefix_bb_topics
prefix_blogs
prefix_blog_versions
prefix_bp_activity
prefix_bp_activity_meta
prefix_bp_friends
prefix_bp_groups
prefix_bp_groups_calendars
prefix_bp_groups_groupmeta
prefix_bp_groups_members
prefix_bp_messages_messages
prefix_bp_messages_notices
prefix_bp_messages_recipients
prefix_bp_notifications
prefix_bp_user_blogs
prefix_bp_user_blogs_blogmeta
prefix_bp_xprofile_data
prefix_bp_xprofile_fields
prefix_bp_xprofile_groups
prefix_commentmeta
prefix_comments
prefix_domain_mapping
prefix_links
prefix_mass_mailer
prefix_options
prefix_postmeta
prefix_posts
prefix_registration_log
prefix_signups
prefix_site
prefix_sitemeta
prefix_subscriptions
prefix_terms
prefix_term_relationships
prefix_term_taxonomy
prefix_usermeta
prefix_users
prefix_ust
Does this look abnormal to you?
I'm having the same problem but no replies!
Help!
'm having the same problem but no replies!
Any chance of describing your problem? It may well not be the same but we won't know unless you tell us what it is :)
@argh2xxx - that looks correct to me - you should just have the prefix_ ones and no prefix_x_ (where x is a number) ones.
So the deactivating issue must (I think) be something else - is it worth removing buddypress completely (delete it) and remove the tables for buddypress (prefix bp) and seeing if your install stabilises before re-installing.
