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

[foxly]

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

Clues:

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

[foxly]

Here's the system dump:

​http://code.google.com/p/buddypress-media/downloads/detail?name=debug_dump_2011-08-15.zip

[foxly]

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.

[foxly]

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.

[foxly]

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!

[boonebgorges]

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?

[foxly]

​http://localhost/

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.

[boonebgorges]

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

[foxly]

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

[fanquake]

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

​http://buddypress-media.googlecode.com/files/MACOSX_System_debug_snapshot.zip

[DJPaul]

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?

[DJPaul]

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

[foxly]

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?​https://buddypress.trac.wordpress.org/attachment/ticket/3454/3454.patch)

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

[fanquake]

I have reproduced it on a completely clean WP installation with unpatched Beta 2 downloaded from ​http://buddypress.trac.wordpress.org/changeset/4925/tags/1.5-beta-2?old_path=%2F&format=zip"

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

[foxly]

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.

[foxly]

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!

[boonebgorges]

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).

So...

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!

[DJPaul]

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

[boonebgorges]

(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