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

[r-a-y]

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.

[DJPaul]

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?

[r-a-y]

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.

[ev3rywh3re]

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?

[r-a-y]

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?

[r-a-y]

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

Need some more time to think about it.

[r-a-y]

Ignore patch-002, patch-003 is the "admin_notices" method mentioned here:
​http://trac.buddypress.org/ticket/2789#comment:2

It's a soft approach to the problem.

[DJPaul]

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?

[boonebgorges]

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

[DJPaul]

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.

[r-a-y]

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.

[DJPaul]

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.

[boonebgorges]

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

I don't much like ​http://trac.buddypress.org/attachment/ticket/2789/2789b.001.patch but I have a sense that it might be the best solution at our disposal.

[DJPaul]

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

[boonebgorges]

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.

[boonebgorges]

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.

[DJPaul]

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.

[boonebgorges]

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.

[johnjamesjacoby]

Sorry to walk all over this ticket. We're going to be upgrading bp.org 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.

[boonebgorges]

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.

[DJPaul]

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.

[boonebgorges]

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.

[boonebgorges]

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.

[boonebgorges]

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

[boonebgorges]

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

[boonebgorges]

(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