Skip to:

Opened 13 years ago

Closed 13 years ago

#3480 closed defect (bug) (fixed)

Upgrade from 1.2.9 to 1.5 breaks profile page, causes permanent redirect to site homepage

Reported by: foxly's profile foxly Owned by:
Milestone: 1.5 Priority: critical
Severity: critical Version: 1.5
Component: Core Keywords: has-patch commit


During testing we encountered an anomaly in the BuddyPress upgrader on one of our systems. It causes the browser to be redirected to the site homepage whenever a user tries to visit their profile by going to /sitename/members/username/.

A complete dump of the system is attached.

Login: Admin, Pass: Test


1) This is essentially a "fresh" WP install
2) In deviation from our normal test procedure, the tester used their local IP ( for the site instead of "localhost"
3) Changing the local IP to "localhost" in the WP backend did not resolve the problem

Attachments (14)

wizard-1.jpg (237.7 KB) - added by foxly 13 years ago.
Wizard-2.jpg (225.8 KB) - added by foxly 13 years ago.
Wizard-3.jpg (224.8 KB) - added by foxly 13 years ago.
Wizard-4.jpg (226.3 KB) - added by foxly 13 years ago. (138.0 KB) - added by foxly 13 years ago. (66.1 KB) - added by foxly 13 years ago.
Upgrade-Snapshot-1.png (104.4 KB) - added by fanquake 13 years ago.
Upgrade-Snapshot-2.png (120.6 KB) - added by fanquake 13 years ago.
Upgrade-Snapshot-3.png (129.4 KB) - added by fanquake 13 years ago.
Upgrade-Snapshot-4.png (110.6 KB) - added by fanquake 13 years ago.
Upgrade-Snapshot-5.png (102.0 KB) - added by fanquake 13 years ago.
Upgrade-Snapshot-6.png (97.8 KB) - added by fanquake 13 years ago.
admin.php.htm (14.8 KB) - added by foxly 13 years ago.
3480.01.patch (2.1 KB) - added by boonebgorges 13 years ago.

Download all attachments as: .zip

Change History (33)

#2 @foxly
13 years ago

I have been able to reproduce this defect on my system. Screen caps and DB snapshots attached.

It is unrelated to the plugin being tested in the previous dump file, the only plugin I had installed on my system was BuddyPress.

13 years ago

13 years ago

13 years ago

13 years ago

13 years ago

#3 @boonebgorges
13 years ago

  • Milestone changed from Awaiting Review to 1.5
  • Priority changed from normal to critical
  • Severity changed from major to critical

#4 @foxly
13 years ago

Currently trying to see if I can reproduce it by installing 1.5 without an upgrade. If I'm successful it could mean there's something wrong with our test build, not the BP code. Totally hoping this is the case.

#5 @foxly
13 years ago

Installing 1.5 directly doesn't cause the error on my dev system. DB snapshot attached. It looks like we successfully trapped last week's bug for you!

#6 @boonebgorges
13 years ago

I'll run some tests later today with a clean install, as well as with a dump of yours. Can you tell me what the URL of your install was, so I can set my hosts file up correctly?

#7 @foxly
13 years ago


I've sent a request to some of our devs to try and reproduce this on their systems. You should see a couple more posts to this ticket with more debugging info later today.

#8 @boonebgorges
13 years ago

I guess I don't need a hosts file for http://localhost :)

#9 @foxly
13 years ago

Rule #1 of sending in a bug report: make it easy to reproduce ... :)

#10 @fanquake
13 years ago

Looks like we have some misbehaving functions here. I've managed to recreate on MACOSX.

#11 @DJPaul
13 years ago

Please would you clarify/list exactly the steps that you took to reproduce this? Is this on multisite or regular flavour WordPress, to check we're doing the same things?

#12 @DJPaul
13 years ago

Also, was this with beta 2 or a specific trunk revision? Thanks.

#13 @foxly
13 years ago

Beta 2 + JJJ's patch from 6 days ago (@foxly – Any chance you kind folks can test the plugins with menu issues against this patch?

Hey fanquake, try re-testing on the unpatched version from the BP dev site long-shot but maybe it was the patch, or our master got corrupted somehow.

#14 @fanquake
13 years ago

I have reproduced it on a completely clean WP installation with unpatched Beta 2 downloaded from"

Doesn't look like it's the BP-Media team's master image.

#15 @foxly
13 years ago

I've also managed to reproduce it on my system with a clean WP install. Debug output attached.

Specific steps to reproduce:

1) Create database 'test' on SQL Server
2) Install wordpress using database 'test' login 'root' pass (none), admin account 'admin' pass 'test'
3) Copy buddypress 1.2.9 files to plugins directory
4) Activate buddypress
5) Go through config wizard changing URL structure, setting template as pb-default, etc
6) Delete all the files in the buddypress plugin folder
7) Copy the buddypress 1.5 beta2 files to the plugin folder
8) Refresh admin screen
9) Error

...fanquake, let's try deactivating BP before we do the file overwrite.

13 years ago

#16 @foxly
13 years ago

Nailed it. It was overwriting the files while the plugin was activated.

So it looks like we've found a REALLY nasty edge-case here because (in earlier testing iirc) it permanently damaged the BP install ...even upon deactivating and reactivating BP, the redirect to homepage error persisted.

Alright guys, this about all the time I can afford to throw at this one today. Have fun with it!

#17 @boonebgorges
13 years ago

  • Keywords has-patch added

I spent some time digging into the issue this morning. It's fairly complicated, but a workable fix is easy. Here's the summary of the problem, for those interested.

  • When you visit a member profile and you haven't overridden BP_DEFAULT_COMPONENT, $bp->current_component is set to 'activity' (as long as 'activity' and 'xprofile' are both active)
  • In order for this to work correctly, the components must load in the correct order. In particular, it looks like xprofile has to load before activity, though I didn't do enough testing to be positive that this is the pair that really matters.
  • On a fresh BP installation, this sorting happens automatically during the installation process (because of the order in which the components are listed during the installation wizard).
  • However, on an upgrade, the components step in the wizard is skipped, under the assumption that this information does not need to be filled in again.
  • That means that $bp->active_components gets filled in by some code in bp-core-loader, which orders the active components array according to the optional_components array, which is alphabetical. Moreover, the script in bp-core-loader.php doesn't save the array to bp-active-components, so the mistake keeps happening (otherwise it would get corrected by the array_flip on bp-active-components).


My solution is to reintroduce the Components step of the wizard. That also means doing a bit of logic inside of bp_core_admin_component_options() to convert bp-deactivated-components (the 1.2.9 setting) into active_components. This solves the problem, and plus I think it's kinda nice to be reminded of the components during an upgrade anyway, so it's not a big UI loss (I'd argue it's a gain).

Please test 3480.01.patch!

#18 @DJPaul
13 years ago

  • Keywords commit added

I agree with what your say, and I've tested the patch and it works. Good job!

#19 @boonebgorges
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [4992]) Adds Components step into upgrade Wizard when coming from pre-1.5, so that active components are properly migrated from bp-deactivated-components (and are activated in the correct order). Fixes #3480

Note: See TracTickets for help on using tickets.