Skip to:
Content

BuddyPress.org

Opened 9 years ago

Closed 9 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 Owned by:
Milestone: 1.5 Priority: critical
Severity: critical Version: 1.5
Component: Core Keywords: has-patch commit
Cc:

Description

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


Attachments (14)

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

Download all attachments as: .zip

Change History (33)

#2 @foxly
9 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.

@foxly
9 years ago

@foxly
9 years ago

@foxly
9 years ago

@foxly
9 years ago

@foxly
9 years ago

#3 @boonebgorges
9 years ago

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

#4 @foxly
9 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
9 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
9 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
9 years ago

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.

#8 @boonebgorges
9 years ago

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

#9 @foxly
9 years ago

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

#10 @fanquake
9 years ago

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

#11 @DJPaul
9 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
9 years ago

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

#13 @foxly
9 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?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.

#14 @fanquake
9 years ago

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.

#15 @foxly
9 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.

@foxly
9 years ago

#16 @foxly
9 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
9 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).

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!

#18 @DJPaul
9 years ago

  • Keywords commit added

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

#19 @boonebgorges
9 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.