Skip to:

Opened 14 years ago

Closed 13 years ago

#2789 closed defect (bug) (fixed)

bp-default can be activated before upgrade/install process has been completed

Reported by: r-a-y's profile r-a-y Owned by:
Milestone: 1.5 Priority: blocker
Severity: Version: 1.5
Component: Core Keywords: dev-feedback has-patch


When activating BuddyPress 1.3 for the first time, the /buddypress/bp-themes/ directory is already registered, but bp-wizard hasn't been completed yet.

An admin could potentially activate the bp-default theme without going through BP setup. Hence, they'd receive a fatal error that bp_is_active() is undefined as it doesn't exist yet.

Patch removes the line registering the /bp-themes/ directory in /bp-core/admin/bp-core-upgrade.php.

Attachments (11)

2789.001.patch (595 bytes) - added by r-a-y 14 years ago.
2789.002.patch (595 bytes) - added by r-a-y 14 years ago.
2789.003.patch (1.6 KB) - added by r-a-y 14 years ago.
2789b.001.patch (1.5 KB) - added by DJPaul 14 years ago.
2789.004.patch (8.6 KB) - added by boonebgorges 14 years ago.
2789.005.patch (9.6 KB) - added by boonebgorges 14 years ago.
2789.006.patch (9.0 KB) - added by DJPaul 14 years ago.
2789.007.patch (9.5 KB) - added by boonebgorges 14 years ago.
2789.008.patch (10.2 KB) - added by boonebgorges 14 years ago.
2789.009.patch (14.0 KB) - added by boonebgorges 14 years ago.
2789.010.patch (15.6 KB) - added by boonebgorges 13 years ago.

Download all attachments as: .zip

Change History (38)

14 years ago

#1 @DJPaul
14 years ago

Potential problem with this patch is that you'd break the theme for someone visiting the front-end whilst a newer version of BuddyPress has been installed, but before the upgrade has been run. Is this an issue?

#2 @r-a-y
14 years ago

You're right.

I guess an admin notice could be displayed saying "Please run BuddyPress setup before activating a BuddyPress theme". That would kind of address the issue.

One minor issue is the bp_is_active() calls in /bp-default/functions.php.

If you have a BP theme enabled and you attempt to deactivate BuddyPress, you'll get the fatal error. The other example is the one noted in the bug report.

#3 @ev3rywh3re
14 years ago

Just noting that I ran face-first into this one. As I was going through the wizard I hit the theme compatibility screen, got momentarily distracted into checking for installation of bp-template-pack, then activated the default theme.

Now this was a case of ooh-shiny stupidity distracting me from completing the wizard and activating the BP-default theme, but this user error will lead to a site-wide white screen.

Shouldn't BuddyPress be aware it's only half installed/upgraded?

#4 @r-a-y
14 years ago

  • Keywords dev-feedback added; has-patch removed

Hi ev3rywh3re, yes that's another example of the fatal error because of having the bp_is_active() calls scattered in the theme / Template Pack.

I'm going to create a new ticket for removing the bp_is_active() calls, as that will fix that problem.

Core devs: any additional thoughts?

#5 @r-a-y
14 years ago

Okay, after fully waking up, I take back creating that new ticket.

Need some more time to think about it.

14 years ago

14 years ago

#6 @r-a-y
14 years ago

  • Keywords has-patch added

Ignore patch-002, patch-003 is the "admin_notices" method mentioned here:

It's a soft approach to the problem.

14 years ago

#7 @DJPaul
14 years ago

I agree we need to add a notification into wp-admin, like r-a-y's 2789.003.patch. But the problem remains of the white screen of death.

2789b.001.patch duplicates the declarations of (what appear to be, not extensively tested) the minimum required functions to avoid the white screen of death. This would change any support queries from "BuddyPress killed my site" to "BuddyPress isn't working", which is much better. Thoughts?

#8 @boonebgorges
14 years ago

DJPaul - It would be nice to avoid that strategy if at all possible. It reeks of hackery.

How about insisting that the WP default theme be activated whenever an update is in progress? (This could happen automatically, with a notice to inform the admin.)

#9 @DJPaul
14 years ago

That assumes that twentyten is always available; I know that's a fairly reasonable assumption but I bet there's some custom installs out in the wild where twentyten has been deleted because they aren't using it.

I don't think declaring empty functions for this purpose is any more hacky than (the current implementation of) bp-loader.php not loading the core files, when we're upgrading or installing. WP's /wp-admin/load-scripts.php does something simliar, which is what gave me the idea.

#10 @r-a-y
14 years ago

I was thinking about both approaches.

Switching the theme was something I was thinking about as well. However, this might be undesirable for certain websites.

Couldn't we switch to WP 3.0's maintenance mode on the frontend?

The only empty function needed would be the bp_is_active() function so the backend can keep functioning.

#11 @DJPaul
14 years ago

Interesting idea. Would have to check that maintenance mode wouldn't make unavailable anything that the BP upgrader needs. I'm just not sure that a plugin should make an entire site unavailable just because its upgrader/installer hasn't been run yet.

#12 @DJPaul
14 years ago

  • Summary changed from bp-core-upgrade.php - do not register theme directory to bp-default can be activated before upgrade/install process has been completed

#13 @DJPaul
14 years ago

  • Milestone changed from Awaiting Review to 1.3
  • Priority changed from normal to major

#14 @boonebgorges
14 years ago

  • Priority changed from major to blocker

Not having this problem fixed is making it extremely tiresome to test upgrade and installation issues.

I don't much like but I have a sense that it might be the best solution at our disposal.

#15 @DJPaul
14 years ago

If we go the dummy functions route, we'll need to add bp_is_blog_page() in as a result of [3655]

#16 @boonebgorges
14 years ago

2789.004.patch skirts the entire problem by doing two things:
1) Don't disable BP while an upgrade is in progress (required reconfiguring the way files are loaded in bp-loader.php and functions are redefined in the upgrade file)
2) Kill bp_dtheme_setup() if bp_is_active() doesn't exist, which will only happen on the page load immediately following the completion of the wizard.

I've checked this with both fresh installs and upgrades. Please have a look.

#17 @boonebgorges
14 years ago

2789.004 changes the load order in such a way that bp-core-wpabstraction.php is not loaded in time for the activation function bp_loader_activate(), which requires get_blog_option() (not defined in WP single, but supplied in bp-core-wpabstraction). 2789.005 fixes this by including the abstraction file if necessary at activation time.

14 years ago

#18 @DJPaul
14 years ago

New patch fixes the theme not loading on 1.2 -> 1.3 upgrades; had to bump the database revision to the current trunk revision number.

#19 @boonebgorges
14 years ago

Patch will have to be revisited in light of [3704] and [3706].

From a preliminary look (haven't yet tested), I'd say that the changes in those commits that are relevant are as follows:

  • update_site_option( 'bp-db-version', constant( 'BP_DB_VERSION' ) ); is now moved before bp-default is changed over, which might fix the problem this ticket was originally opened for
  • The temporary workaround in [3706] will only kick in in instances where bp-default is activated when BP is not. In theory, this should never happen, since WP shouldn't know about bp-default until BP calls register_theme_directory().

From what I can see, this patch does not address the more general question of whether BP core files are loaded (and, by extension, whether the front end of BP is accessible) after a BP upgrade but before the upgrade wizard has been run. For that, we will probably still need something along the lines of 2789.006.patch.

#20 @johnjamesjacoby
14 years ago

Sorry to walk all over this ticket. We're going to be upgrading this weekend and I needed to fix some obvious incompatibilities between BP trunk and WP trunk right away just to get it to install and update.

Last edited 14 years ago by johnjamesjacoby (previous) (diff)

#21 @boonebgorges
14 years ago

2789.007.patch is a refresh that takes into account some of the changes that John made. Please make sure to svn up before applying, as this new patch is dependent on a couple other patches.

bp-wizard-step cookie setting/deleting is still broken, but you really need to have a patch like this one in order to even test the cookie stuff, so it'd be nice to keep the issues separate. Please test soon, so this puppy doesn't go stale.

#22 @DJPaul
14 years ago

2789.007.patch re-introduces the problem of the white-screening when you update an existing install. To recreate, new WordPress install with BuddyPress 1.2 branch. Get everything set up and select the bp-default theme. Then, svn switch the BuddyPress to trunk and try to reload the front of the site page (not /wp-admin/). WSOD.

#23 @boonebgorges
14 years ago

This was being caused by John's recent commit [3706], which I missed in my tests. 2789.008.patch works around it.

You'll notice that BP doesn't fully load - clicking the links doesn't work, as you get sent back to the home page for every one. That's because the bp_pages haven't been created yet. I am afraid there is no way around this. On the bright side, during maintenance releases, this won't be the case - 1.3.x-1.3.x should keep the site totally intact.

#24 @boonebgorges
14 years ago

Ugh, don't bother testing this atm - I found scenario where it doesn't fully work. I'll post another patch as soon as I can finagle it.

#25 @boonebgorges
14 years ago

2789.009.patch IS THE MONEY PATCH

I tested with BP 1.2.x-1.3 upgrades, fresh installs, and 1.3-1.3.x upgrades (by bumping the DB version). Everything looks super duper.

Please test so I can get this committed and move on with my life :)

Last edited 14 years ago by boonebgorges (previous) (diff)

#26 @boonebgorges
13 years ago

I couldn't manage to reproduce exactly the redirect loop that Paul reported with 2789.009.patch, but I did put something in place so that there would be some sort of fallback when bp_pages is unavailable. Essentially, it populates $bp->pages with some dummy component information - in some cases it will get lucky and the components will continue to work during the upgrade, in others your links will 404, but in any case it should not crash.

I present 2789.010.patch for your Kindest Consideration

#27 @boonebgorges
13 years ago

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

(In [3736]) Modifies upgrade routine so that a site's front-end can continue to be accessible after a BP upgrade but before the wizard has been completed. Adds upgrade nags to the Dashboard. Fixes #2789. Props r-a-y and DJPaul for earlier patches and help testing

Note: See TracTickets for help on using tickets.